I imagine that if/if-else as expressions and then necessarily their bodies as expressions would entail a much more fundamental change to the language. You then have to think of a way for the bodies to indicate a result. That, or you have to make a special case for if/else sequences where the bodies are bare expressions, in which case you've just invented the ternary operator.

Zig and Rust have addressed the problem of how the result of a block expression should be presented, but neither solution seems particularly satisfying to me.

In Rust, blocks may end with an expression, giving them a non-void result. But a block may also end in a statement, the only difference being that the statement ends in a semicolon, in which case the expression still has the void result, and I think that semicolon being the only difference makes it hard to scan at a glance where values come from.

In Zig, blocks may give non-void results by `break`ing out of them with an expression. But break normally ignores blocks and break out of loops only, so to break out of blocks you have to provide a label for it and give that when you break so as to break out of the named block and not the outer loop, e.g. `const x = label: { break :label 35; }`. That creates a problem of one of the most difficult classes in software engineering: naming things. Ideally I think `break` from a block should have its own keyword, e.g. `const x = { give 35; }`

I don't think if-expressions have to affect existing semantics. Basically, in the parser you would have two different kinds of AST nodes, one for when the `if` keyword is encountered in statement position and another for when it's encountered in expression position.

Right now, `if` in expression position is just a syntax error ("unexpected symbol")