Support generic structs in ethercat-wire-derive

[fpdotmonkey]

By using generics for e.g. measurement values, users can separate their network logic which touch ethercrab and the fieldbus from their control logic which will be concerned with how the value should be gained, scaled, and otherwise manipulated.

[fpdotmonkey]

The failures on Linux appear to be that It wants for my "Generic structs" section in /ethercrab-wire-derive/README.md to be an h3 (or at least that's the change that's being applied when I run cargo readme). That's incorrect, it should be an h2 header, so I'm not sure why it's advocating that change.

[jamwaffles]

Yes! Thank you for taking this on! I made a vague attempt some time ago but gave up so it's great to see an impl.

There's one problem though: how do we ensure the generic has the same bit width as the field? I suppose we could just rely on the runtime behaviour of panicking or erroring if the input slice is too short, but what are your thoughts on this?

[fpdotmonkey]

I can imagine two paths:

• Document that the user must ensure that T can be constructed with that many bits
  • Easy to implement
  • I don't think it's a very big burden for the user
  • Hard to debug when that contract isn't satisfied
• Create a marker trait PackedWidth<const BITS: usize> and add that as a type constraint
  • Moderately difficult to implement
  • Probably over-conservative since T could reasonably be !EtherCrabWireSized (e.g. String, Vec)
    • Maybe could be overcome when rust gets const type parameter arithmetic

I would personally advocate for the contract path. Perhaps it could include work on error reporting to help with troubleshooting. I'd be happy to look into that.

[jamwaffles]

I'm a bit more inclined to go with the documentation route and let the user ensure the types are correct. Less implementation effort and if it turns out to be a huge issue it can be changed later.