Skip to content

Removing Result from return type of "exhaustive" signal setters #92

@projectgus

Description

@projectgus

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions