Making illegal states unrepresentable

[projectgus]

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...

[dlips]

I also just tripped over this, wondering why I get invalid signal values. Turns out I didn't read the generated code carefully. I activated the check_ranges feature and expected that ranges will be checked during parsing. It would be better to have range checking also in the TryFrom implementation, at least if you activate the feature, and then have a separate function that creates a message without signal range checking which makes it explicit by the name, e.g. try_from_unchecked_ranges()