[dom96]

There is nothing wrong with using equals for assignment, the language designers just have to disallow assignments in if conditions.

[tel]

It's a little weird. lvalues and rvalues are different things so a biased symbol feels nice to me, <-, e.g.

[junke]

One more corner case, instead of designing orthogonal features.

[kibwen]

It's not a corner case if you do it right.

For example, in C the assignment operator evaluates to the value of the right-hand side expression (so `int x = (y = 2);` initializes `x` to 2). But in Rust, the assignment operator always evaluates to `()` (a.k.a. "unit", the empty tuple), and trust me, this is how you want the language to work in the presence of pervasive move semantics and single ownership. Furthermore, nothing in Rust is "truthy": if-expressions accept a boolean and nothing else (this is also, IMO, exactly what you want in every language, but I'm sure others will disagree :P ). So `if x = 2 {` is a compiler error in Rust because `()` can't be coerced to a boolean (to say nothing of the fact that this reassignment would probably be a compiler error anyway because most variables in Rust are immutable). This doesn't require any acrobatics, it's just the natural fallout of how the rest of the language works.

[junke]

Thanks, that's indeed a sensible way to do that.

[kazinator]

That's a cure worse than the disease. If I faced a false choice between = as an assignment operator or else accepting syntax that distinguishes statements and expressions, I'd just take the = operator.

[nilved]

There's nothing wrong with using assignment in if conditions. For example, `if let Some(thing) = computation_that_may_fail { ... }`.

[kazinator]

The operator there is let. The = is just a punctuator which indicates the initial value expression for the let.

Litmus test: if this was rendered into S-expressions, the let would stay, but the = would disappear.

[nilved]

No, that's just because the example I used was Rust. In Ruby it would be `if user = User.find(..)` and the same goes for Go and plenty of other languages.

[kazinator]

If user is being freshly bound, that isn't an assignment but an initialization.

If the construct is not allowed when user is already in scope, it reflects the designer's view that an assignment in a conditional isn't a good thing.

If the construct is allowed when user exists already, with no diagnostic, then it carries the pitfalls that this thread is about.