This is another idea for a change, relating to #92 a bit. I've been thinking about the phrase "make illegal[/invalid] states unrepresentable" when working with structs generated from DBC files.
My main concern is that the try_from() message constructor only validates length, it doesn't validate signal values. So it's possible to parse a message with a payload where message.set_signalname(message.signalname()) would fail...
Of course, there are plenty of cases where a programmer might want this, for example a module which sends some signals initialised to FFs during startup. The programmer might even want to parse this partially invalid message, despite some signals being invalid.
I am not sure about this, but I have been wondering if it'd be convenient to have a generated signal API that knows about the possibility of invalid fields. Something like:
Cases where all possible bit patterns are valid stay the same as they are now, with simple getter and setter.
Cases where some bit patterns are invalid have a getter returning Option<signal-type>. Meaning the caller may get back None if the bit values in the struct aren't a valid signal. Add another signal_name_unchecked() getter that returns the value represented in the bits even if they are invalid (for example: not a named enum value, or outside the min/max range), i.e. signal_name_unchecked would behave the same as the current getters.
Of course this would be another breaking change, similar to #92, and I'm not sure about how ergonomic it would be to use.
The "purest" approach to "make illegal states unrepresentable" might be to encode signal restrictions in the types themselves, by having the signal functions get and set types such as bounded integers...
This is another idea for a change, relating to #92 a bit. I've been thinking about the phrase "make illegal[/invalid] states unrepresentable" when working with structs generated from DBC files.
My main concern is that the
try_from()message constructor only validates length, it doesn't validate signal values. So it's possible to parse a message with a payload wheremessage.set_signalname(message.signalname())would fail...Of course, there are plenty of cases where a programmer might want this, for example a module which sends some signals initialised to FFs during startup. The programmer might even want to parse this partially invalid message, despite some signals being invalid.
I am not sure about this, but I have been wondering if it'd be convenient to have a generated signal API that knows about the possibility of invalid fields. Something like:
Option<signal-type>. Meaning the caller may get backNoneif the bit values in the struct aren't a valid signal. Add anothersignal_name_unchecked()getter that returns the value represented in the bits even if they are invalid (for example: not a named enum value, or outside the min/max range), i.e.signal_name_uncheckedwould behave the same as the current getters.Of course this would be another breaking change, similar to #92, and I'm not sure about how ergonomic it would be to use.
The "purest" approach to "make illegal states unrepresentable" might be to encode signal restrictions in the types themselves, by having the signal functions get and set types such as bounded integers...