I went through a few rounds with this, from various kinds of macros, to what I have now. The primary benefits to this kind of approach are:
We don't overload normal rust syntax for conditionals. I think this is actually crucial, since we want to be sure we can differentiate between RTL and rust/meta code clearly and easily.
if_ expressions work just like other expressions and are predictable in their behavior. You can also chain them with rust code to add as many else_if expressions as desired; it plays well with metaprogramming.
Some downsides:
The naming convention isn't very pretty, but I want it to be obvious and light, and I think this is achieved currently, but there may be a better solution still.
rustfmt doesn't handle the extra scopes too well and likes to screw up formatting. Ideally there'd be a solution that works better with this, especially one that wouldn't require custom rustfmt configuration/annotation.
It can certainly be annoying to pack up all the alternatives in tuples for cases where you want to handle multiple Signals at a time, especially as this number grows (not to mention explicitly having to implement these cases in the lib itself, though I'm sure there's a macro-based solution for this that would make it much more manageable).
It's certainly not the prettiest but I like it more than other alternatives so far - though I want to continue considering other possibilities.
In particular syntax for
if-like expressions.I went through a few rounds with this, from various kinds of macros, to what I have now. The primary benefits to this kind of approach are:
if_expressions work just like other expressions and are predictable in their behavior. You can also chain them with rust code to add as manyelse_ifexpressions as desired; it plays well with metaprogramming.Some downsides:
rustfmtdoesn't handle the extra scopes too well and likes to screw up formatting. Ideally there'd be a solution that works better with this, especially one that wouldn't require customrustfmtconfiguration/annotation.Signals at a time, especially as this number grows (not to mention explicitly having to implement these cases in the lib itself, though I'm sure there's a macro-based solution for this that would make it much more manageable).It's certainly not the prettiest but I like it more than other alternatives so far - though I want to continue considering other possibilities.