[enhancement] Allow if without else in DSLX

[rw1nkler]

What's hard to do? (limit 100 words)

Currently, you can't have an if without an else part, which is different from Rust, where an if without an else always returns a unit type:

error[E0317]: `if` may be missing an `else` clause
 --> src/main.rs:2:5
  |
2 | /     if true {
3 | |         3
  | |         - found here
4 | |     };
  | |_____^ expected integer, found `()`
  |
  = note: `if` expressions without `else` evaluate to `()`
  = help: consider adding an `else` block that evaluates to the expected type

This is a small addition with well-defined behavior that can move DSLX closer to Rust syntax.
The change is not crucial by any means. We usually write empty else blocks when printing data with trace_fmt!.

Current best alternative workaround (limit 100 words)

Write if with an empty else

Your view of the "best case XLS enhancement" (limit 100 words)

As stated before, this is not a crucial addition to the language, but in my opinion, it could make code more readable. One thing to consider is the usage of IO operations in such statements, but this IO operations would have to ignore the returned token. Once again, this should be well-defined behavior.

[cdleary]

One of the major considerations around why we didn't add a "statement if" historically is that people can get confused about how to "evolve values" outside of the if block if they are written in side-effecting statement style; e.g. a new user going:

let my_var = 0;
if some_cond {
  my_var = 42;  // how do I make this work?
}

The fact that all conditions are actually ternaries (and that we can flag the syntax doesn't make sense for the if block) is supposed to help guide on the fact that it's all dataflow without mutation.

If we want to keep that property since there should not be a ton of side-effect-only operations an alternative here would be to add trace_fmt_if!(pred, ...) -- assert!(pred, ...) already does this for assertions so I think it's largely traces and covers that are left.

[mikex-oss]

Related: #707

[richmckeever]

I would vote for supporting it like in Rust. We could guide the user about data flow via the error/warning messages for invalid or useless assignments in an if block.

Needing to manually implement a foo_if! for every foo! feels like a non-sustainable strategy, which is why issues get filed about missing ones, though we could "auto-generate" those.

I think the bigger concern is that the current strategy promotes duplication of predicates.

[cdleary]

No objections so long as we check the diagnostics are good first so it's not an immediate stumbling block for new users. I've seen conditionals are usually the first place new users run into this. 👍