Wilson Snyder

Yes, please contribute a pull which adds a new flag to add these accessors. I'd prefer to follow Verilator naming where e.g. for signal sig we have: ``` VL_IN8 __Vm_sig;...

BTW the __Vm_sig renaming should be done in V3Name.cpp.

I had a typo should be: VI_IN8& sig() { return __Vm_sig; } const VI_IN8& sig() const { return __Vm_sig; } That is ok to get constant information on constant pointer...

Member for Verilog "sig" would be __Vm_sig so as not to conflict with "sig()". I'd think with this option __Vm_sig should be moved to "private:".

Correct, I presume that works for your purpose.

Great, BTW separately would welcome a pull to docs/guide, or just general web article you can to point to from an issue here, to describe how to use with rust.

For my reference docs on the Rust naming of overloads: https://google.github.io/autocxx/cpp_functions.html#overloads---and-identifiers-ending-in-digits It's not stated but I presume the order of the overloads determines the number suffix. I'd prefer to follow...

Definitely is currently inconsistent: ``` void randSeed(int val) VL_MT_SAFE; int randSeed() const VL_MT_SAFE { return m_s.m_randSeed; } ... inline uint64_t time() const VL_MT_SAFE; void time(uint64_t value) VL_MT_SAFE { m_s.m_time =...

The name unfortunately may get used for other purposes later, so I'd prefer not to have (another - as there's an origName) member for this. I'd suggest simply asserting there's...

>Just make the __Vm_sig_ variables public I think that's ok and probably needed anyways as DPI exports and other generated code might need to access those members from other classes...