I notice that I'm using unwrap() a lot when setting signals in generated structs, even when the type of the argument maps perfectly to the possible values held by the signal (for an example, setting an 8-bit unsigned signal from a u8.)
(The best terminology I've come up with for this is exhaustive values, like for enums, when the signal can represent all values represented in the type. Similarly, "non-exhaustive" when it doesn't. An example of "non-exhaustive" would be a signal with a restrictive MIN/MAX, or a 4-bit wide signal represented as u8, or an 8-bit signal represented as an enum with 4 discrete values.)
A non-exhaustive signal's setter may fail.
An exhaustive signal's cannot fail.
However, at the moment all setters return Result<(), CanError>.
This causes no runtime issue as the unwrap()s (or ?s) can be optimised away by the compiler. However, it does make it harder to see in the code where a signal is being set that might fail.
I'm thinking it'd be convenient to determine exhaustive setters during code generation, and have those functions not return Result. This focuses the programmer's attention on the setters which can fail at runtime.
It'd be a breaking change, though, so I'm curious what people think. If it was a welcome change then I'd be happy to work on it.
I notice that I'm using
unwrap()a lot when setting signals in generated structs, even when the type of the argument maps perfectly to the possible values held by the signal (for an example, setting an 8-bit unsigned signal from au8.)(The best terminology I've come up with for this is exhaustive values, like for enums, when the signal can represent all values represented in the type. Similarly, "non-exhaustive" when it doesn't. An example of "non-exhaustive" would be a signal with a restrictive MIN/MAX, or a 4-bit wide signal represented as
u8, or an 8-bit signal represented as an enum with 4 discrete values.)However, at the moment all setters return
Result<(), CanError>.This causes no runtime issue as the
unwrap()s (or?s) can be optimised away by the compiler. However, it does make it harder to see in the code where a signal is being set that might fail.I'm thinking it'd be convenient to determine exhaustive setters during code generation, and have those functions not return
Result. This focuses the programmer's attention on the setters which can fail at runtime.It'd be a breaking change, though, so I'm curious what people think. If it was a welcome change then I'd be happy to work on it.