Idea: Early returns and irrefutability

[comex]

It was my impression so far that Rust doesn’t do coercion to bool (for example, if 0 { isn’t allowed), unlike for example in Python, and I think that fits with the general style of Rust. Similarly, || currently only appears to accept bool (that is, 1 || 3 is not allowed). It seems like a sizable departure from this style to start coercing Option or other Try types to bool.

To clarify, what I think Centril is proposing does not actually involve coercion to bool – unlike the Perl and JavaScript constructs which serve as semi-inspiration. Rather, the idea is that

let Foo(x) = my_enum || continue;

would parse as

(let Foo(x) = my_enum) || continue;

let would be a bool-typed expression, evaluating to true or false based on whether the pattern matched (sort of retroactively justifying if let). It wouldn’t matter whether the value of my_enum itself was ‘truthy’ or ‘falsy’ or anything like that.

[CAD97]

I don’t think you have to do any of this trickery.

Parse it as let <pat> = (<expr> || <expr>);. Have a transformation that depending on context makes the || expand to { let temp = <lhs>; if temp { temp } else { <rhs> } or let <pat> = match <lhs> { <pat> => <pat>, _ => <rhs>.

Or if we’re ok with || only working with Try types rather than with refutable patterns, add impl Try for bool and desugar || to (approx) match <lhs>.as_result() { Ok(t) => typeof::<lhs>::from_ok(t), => <rhs> }.

We have a lot of power to (ab)use || (and &&) since they’re only magic for bool-typed expressions currently. I’m not sure when they’re “desugared”, but it’s definitely “possible” to intertwine it with type resolution, if not ideal. And the Try version doesn’t require it.

In any case, I personally prefer magic semantics for || over magic semantics for let ||.

---

Edit bad thought:

What keeps us from “just” introducing a new statement of form let <pat> = <expr - ||> $(|| <expr - ||>)* ; that “just” works for bools?

[comex]

The benefit of parsing it as (let <pat> = <expr>) || expr is that the desired semantics then become a natural consequence of existing precedent:

• if let is effectively precedent for treating let as a bool-typed expression. Of course, if let is currently parsed as a special case, but with let as an expression, if let Foo(x) = bar can be retconned as just an if followed by the expression (let Foo(x) = bar).
• || already works with a diverging expression on the right.
• The compiler will have to produce an error if you try to use the variables bound in pat when the expression on the right of || doesn’t diverge – but that can be seen as just a special case of the existing initializedness checks. This already works:

  let x;
  if let Foo(x_) = bar {
  	x = x_;
  } else {
  	continue
  }
  println!("{}", x);
  

  But if you replace the continue with a non-diverging expression, the compiler complains about a “borrow of possibly uninitialized variable”, as expected.

Thus the language becomes more uniform overall.

Furthermore, it would naturally enable other boolean expressions involving let, such as this often-requested one:

if let Foo(x) = get_foo() && let Bar(y) = get_bar(x) {
    ...
}

Or even:

let Foo(x) = get_foo() || let Bar(x) = get_bar() || continue;

although that’s a bit ugly.

That said, I think your first proposal is largely equivalent to mine, other than not supporting the other boolean expressions I just mentioned. You would special-case || rather than changing the overall operator precedence, which avoids the .. problem, but you can do the same thing in the parser – it’s just nicer to keep a consistent precedence. Doing it as a late transformation would allow delaying the decision until after name resolution, so in theory you wouldn’t have the problem with constant boolean-typed patterns – you could allow this to work:

const MY_TRUE: bool = true;
let MY_TRUE = expr || continue;

But as I said, that’s not very useful (and it’s quite confusing), so I don’t think there’s much benefit in allowing it.

[scottmcm]

It seems like a sizable departure from this style to start coercing Option or other Try types to bool.

That’s not my proposal.

let x1 = Some(3);
let x2 = None;
let y1 = x1 || 10; // y1 == 3
let y2 = x2 || 10; // y2 == 10
let z = x2 || z1; // z == Some(3)

This is perfectly consistent with bool under the type bool = Option<()>; const true: bool = Some(()); const false: bool = None; isomorphism. And it’s lazy just like foo() || bar() doesn’t call bar if foo returns true. And it has the exact same precedence as it does with bool.

[Centril]

Hmm. I do like that this avoids the need for ‘magic’ scoping rules as would be required for if !let , and it’s even more succinct. On the other hand, it feels a bit weird to be bringing a Perlism to Rust.

Hehe; my basic idea was that this would “fall out” from let p = e just being an expression and the same mechanism would make if !let p = e work. (let p = e) || continue is then mostly a matter of style.

I’d say this is uglier, but it arguably has readability benefits, as it’s more obvious that this is not a regular let , and the || continue sticks out more.

Yeah, that’s reasonable at least as a stopgap solution that may (or not) be relaxed later.

To clarify, what I think Centril is proposing does not actually involve coercion to bool – unlike the Perl and JavaScript constructs which serve as semi-inspiration. Rather, the idea is that

Yup!

Of course, if let is currently parsed as a special case, but with let as an expression, if let Foo(x) = bar can be retconned as just an if followed by the expression (let Foo(x) = bar) .

Indeed; I’m working on this atm partially for let_chains.

[comex]

Hehe; my basic idea was that this would “fall out” from let p = e just being an expression and the same mechanism would make if !let p = e work. (let p = e) || continue is then mostly a matter of style.

Oh? It’s quite significant that if !let would work as well, as it mitigates the “Perlism” issue. But I remember from previous discussions that scoping compared to if let was a sticking point; I’m interested by the idea of using || in part because it sidesteps the scoping issue. How do you intend to address it?