[Pre-Pre-RFC] Reviving Refutable Let [Runoff]

[Ixrec]

Maybe this is just because I’ve never used syn, but for me both of those are so awkward to read that the difference between them feels negligible.

[phaylon]

Huh, can m @ Something { ref x, ref y } work?

For these constructs, I generally prefer a form such as

let expr_while = match expr {
    Expr::ExprWhile(expr_while) => expr_while,
    Expr::ExprWhileLet(_)
    | Expr::ExprLoop(_) =>
        bail!("use normal while loops"),
    other => bail!("Expected a loop, got {:?}", other),
};
let expr_while = &expr_while;
let &ExprWhile { ref attrs, ref cond, ref body, .. } = expr_while;

[pierzchalski]

That’s what I get for not checking things on the playground… fixed, thanks! Also fair point on actually doing separate matches. I suppose once an enum gets too complex most libraries will move the struct variants out to their own types, like syn has - are there any good examples where that’s not the case, i.e. interesting examples that still keep enum struct variants?

[phaylon]

I use struct variants usually when some variants have more fields and no logical ordering, like for state machines.

But there I’d prefer to use

let (foo, bar) = match {
    State::A { foo, bar } => (foo, bar),
    State::B { .. } => return Err(..),
};
do_something(foo, bar);

kind of construct, because it’s easier to adjust when one has to react to multiple variants:

let (foo, bar) = match {
    State::A { foo, bar } => (foo, bar),
    State::B { .. } => return Err(..),
    State::X { foo } => (foo, None), // new variant
};
do_something(foo, bar);

But that doesn’t mean there aren’t any situations where it could be useful.

One syntax I think I haven’t seen yet is

let if Some(x) = expr else {
    log!();
    bail!();
};

This one

• Doesn’t need a new keyword.
• Still has let as current-scope-binding keyword.
• Has an early if implying some form of condition.
• Has some symmetry with if let (if let <cond> <scope> <else> into let if <cond> <else>; <scope> because the initial let means “current scope”).
• Makes the else more expected at the end due to the if directly after the let.

[burakumin]

Just as a general remark, my perception is that whichever special sugar is chosen (if any), I don’t see any reason not to consider a kind of “chainability”:

let TheVariantWeNeed(val) = expression1 or else expression2 or else expression3 or else ...

When we expect to match a certain variant, it’s not impossible or rare we have substitute expressions. All of these may fail, but the situation is not always as binary as match expression with the expected pattern or leave the golden path.

[nox]

Here is a real world example of code that is unrelated to bubbling up errors. That is not simplifiable without ad-hoc methods or making the code flow way more inscrutable. This needs a let...else expression of some sort.

[comex]

For the record, I still want to solve this by actually making let a bool-valued expression, so that if !let works and so do more complex expressions, e.g.

    if (let Some(bar) = foo) &&
       (let Some(baz) = bar.do_something()) &&
       baz.is_good() {
        // use baz
    }

or

    if !(let Some(x) = bar) && !(let Ok(x) = baz) {
        return;
    }
    // use x

Even though it’s a bit less pretty, I like how this approach can replace what would otherwise be three different features:

1. The use case of this thread;
2. If-let chaining (RFC: “Support && in if let expressions”)
3. A way to get a bool value of whether a pattern matches (RFC: “Add a matches!(expression, pattern) macro.”)

See also my old proposal for how to solve the variable scoping issue.

[leodasvacas]

If that’s open source code, can you point me to where it is so that I may patch it to use match instead of if let? It won’t solve all your problems but will save you three lines.

[nox]

From my experience with Erlang’s fancy scoping rules, this kind of code is highly confusing for readers. You can’t even describe the scoping in prose easily anymore.

[nikomatsakis]

Question. With regard to the let else ambiguity, has it been discussed to make the “return” or “break” be part of the keyword:

let Foo(x) = <expr> else return <expr>;

or

let Foo(x) = <expr> else break <expr>;

What I like about this is that it enforces the mentality that this syntax is intended for “inverting” rightward drift and nothing else. The main problem I see here is that sometimes you want to panic!. Of course you can do that but it feels a bit silly to have to specify a return or break that is dead code:

let Ok(x) = value else return {
    panic!("this should not happen")
};

The other concern I can think of about this idea is that it might be confusing why else return 22 works there but not if foo { .. } else return 22 here (of course, this is the key that makes it unambiguous).

[glaebhoerl]

Can somebody explain, maybe with a concrete example of something where it poses a problem, why the syntactic ambiguity is actually an issue? The only case where the ambiguity comes up is if you are using let ... else on something of type (), which there is no imaginable reason to do and it doesn’t even work (doing the same with if let errors out with “irrefutable if let pattern” and presumably this’d do likewise), so it’s absolutely clear that it should always be parsed the other way. There’s an ambiguity in theory, but not in practice.

I’m not saying we shouldn’t discuss it or anything, but it seems to be regarded as some kind of quasi-blocker and I don’t understand it.

The main problem I see here is that sometimes you want to panic!.

I guess if you also allow break-with-label and continue and also throw if we ever add that… but panic!() isn’t the only function with a return type of !, e.g. in a small command line app I’d call the “print help and exit” function. (Of course you could do the same workaround but as you say, it’s weird.) I guess my point is that the ways to short-circuit/exit are more varied in practice than one might assume in theory, so special-casing the few built-in ones doesn’t feel as justified. Also e.g. macros with one of the control flow keywords inside them… (or the type inference fallback to ! that’s going to happen, so maybe something like Err(x)? would work too…)

[nikomatsakis]

There’s an ambiguity in theory, but not in practice.

That’s a good point. I remember that now. =)

I will say that at this point I feel fairly persuaded that we should adopt let x = y else ...;, where ... must diverge.

Ever since we rejected the PR, I’ve suddenly been noticing a need for this all the time, and I’ve also been less satisfied with the current proposal of let x = match y { Ok(v) => v, _ => ... }.

[scottmcm]

The main problem I see here is that sometimes you want to panic!.

That seems fairly common in rustc (well, bug! not panic!, but).

The return one is interesting, but wouldn’t it give a dead code warning? I guess it could be exempted from the warning.

[CAD97]

This positive impression is the push I needed to get the revived RFC in a share-ready state. I agree that the ambiguity is an academic one only, and one where the “other” case doesn’t pass typeck 99.99% of the time and the other 0.01% of the time doesn’t make sense for a logical flow.

let ... else does seem to be the cleanest option, so the RFC will start out in favor of that formulation, though of course will list the other proposals as alternative realizations.

I do really think that the else match idea brought up in this thread is a logical extension to the original proposal, and one that makes handling the divergence case cleanly a lot easier. Though I’m not sure whether it should be part of the initial RFC or a listed possible extension. The primary use-case of destructure-or-diverge doesn’t need it, but any time you want to capture what failed to destructure for a better error, it’s going to be more work. I still think the refutable let expresses intent better than any other option available today.

The hardest part is of course finding small but motivating examples. Please, if anyone has some, share! I should have a sharable pre-RFC this weekend (but if I don’t, anyone feel free to beat me to the punch).

[nikomatsakis]

The primary use-case of destructure-or-diverge doesn’t need it, but any time you want to capture what failed to destructure for a better error, it’s going to be more work. I still think the refutable let expresses intent better than any other option available today.

This is an interesting point. I wonder how often that is the case, seems measurable. (It is – of course – a forward compatible extension, but it’s worth taking a look to see whether not handling match is excluding a lot of cases.)

[scottmcm]

The other concern I can think of about this idea is that it might be confusing why else return 22 works there but not if foo { … } else return 22

This. I don’t want to reopen the can of worms that was https://github.com/rust-lang/rfcs/pull/1712. (So I’d also rather it not be let ... else match ... either.)

[mrborrowck]

About that ambiguity with

// This is actually non-sense but just purely looking at the syntactic composition, it's confusing
let Some(val) = if x { () } else {
    panic!("wops");
};

Instead of extending the else keyword with return or break, we could also just use else do?

let Some(val) = if x { a } else { b } else do {
    panic!("wops");
};

[scottmcm]

There’s an ambiguity in theory, but not in practice.

And in the unlikely event that it does compile, clippy will tell you that you probably shouldn’t be doing what you’re doing: https://rust-lang-nursery.github.io/rust-clippy/v0.0.187/index.html#let_unit_value

I’m convinced.

[kennytm]

We could prohibit if/if let expressions at that position (perhaps also all control expressions like loop, while, for), just like you can’t use a struct literal in a for: for i in S { x: y } { … }.

If you need to use if, wrap it in (…) or {…}:

let Some(val) = (if x { a } else { b }) else { panic!("wops"); }
//              ^                     ^

[glaebhoerl]

@kennytm IINM the issue is that you can currently write:

let foo = if x { a } else { b };

With the let…else feature, the syntactic ambiguity could allow this to be parsed as:

let foo = (if x { a }) else { b };

Viewed from this perspective, not only is that interpretation nonsensical, but backwards compatibility also determines that we must parse it the other way.

But since this code is currently allowed (and common!), we also can’t require parentheses in it without breaking compatibility; and if we commit to parsing it the current way (which we must), then I believe that also wouldn’t leave any ambiguity in your slightly-larger and not-currently-legal example (even without parentheses).