Comment by mastax | Hacker News Reader

Comment by mastax | Hacker News Reader

`let else` looks strange to my eyes on first glance, but I can remember many cases when it would have been nice to have. (Not to mention, all Rust syntax used to look strange to my eyes so that's not a very useful criterion).

Break from labeled blocks is a pretty niche thing. I can remember a few cases it would have been useful, but I'm not sure I'll remember the feature exists next time it comes up.

I'm glad that GATs are finally here. I tend to be wary of complex type-system things. I can remember being a new rust programmer around 1.0, dealing with some library with a perhaps-overly-clever API with complex traits and lifetimes and being very frustrated randomly changing code trying to get it to compile. It didn't help that rustc error messages and rustdoc weren't as good and we didn't have any sort of language server back then. Perhaps I'm just not very smart. But even with my focus on simply-typed APIs I've run into several cases where I couldn't do something the obvious way because it needed GATs.

I used to be a lot more involved with Rust, reading a lot of /r/rust and blog posts and issue trackers. I get a warm wistful feeling seeing things like GATs, rust-analyzer, and MIR inlining get stabilized after all these years.

Note that this feature has precedence from Swift, where it's called `guard let`: https://www.hackingwithswift.com/quick-start/understanding-s... . Rust's syntax just drops the `guard` part.

> Break from labeled blocks is a pretty niche thing. I can remember a few cases it would have been useful, but I'm not sure I'll remember the feature exists next time it comes up.

Yeah, I feel like the vast majority of the time this would be better handled by splitting out that block into a function. There are situations where there the number of parameters needed to pass in would get unwieldy, but that is where I start thinking about if all that loose state is intrinsic to the problem, or a sign that I need to refactor my datastructures.

> Yeah, I feel like the vast majority of the time this would be better handled by splitting out that block into a function.

It's a nice idea, and Rust supports "local" fn definitions inside blocks so it would be quite elegant as well.

The borrow checker is "smarter" within a single function body though, so factoring code into a separate function is not necessarily as easy as in other languages.

You can use it with a closure to get the best of both worlds

I ran into this issue years ago (possibly even before labeled exit from loops or even NLL, although I'd have to dig through some old code to confirm this). I had some logic that I wanted to short-circuit, but moving everything to a separate method call would have required an extra borrow that would not have been allowed. I don't think that I'll end up needing to use this feature much, but I'm glad to finally have it as an option for the rare cases when it will improve the readability of my code.

One reason to support this sort of feature is that it makes it easier to split changes into two reviewable steps: first make a minimal change that introduces some ugly thing like break-with-label, then clean it up with a no-change-of-behaviour commit.

Like with GAT, I think one of the major reasons to support this feature is because it feels consistent. "I can put generics here, but not there? I can break here but not there?". I've run into "accidentally" writing the equivalent of GAT before just because I had expected it to work.

I imagine this is to make Torvalds happy.

The RFC for this feature was proposed in 2017, and accepted in early 2018. Implementation landed shortly after. Nothing to do with Linus.

> `let else` looks strange to my eyes on first glance

AIUI, this is a rather specialized feature that only supports diverging code in the "else" block. I assume that the weird syntax was purposely chosen to suggest something like that.

How does this improve on binding the `Err`?

Edit: I see now in the first example:

    let (Some(count_str), Some(item)) = (it.next(), it.next()) else {
        panic!("Can't segment count item pair: '{s}'");
    };

Binding the error here would be much verbose, since both must succeed.

Edit2: Doh, obviously `None` in this example, not `Err`.

I don't find the syntax weird, I think it's perfectly cromulent with the existing capabilities. To wit, pattern matching in `let` has always been possible:

    let (x, y) = (1, 2);

...But only for patterns that can never fail. For enums, not all patterns are irrefutable:

    let Some(x) = Some(42); // error, Rust can't tell that RHS isn't `None`

Note that some languages with pattern matching do allow the above, e.g. OCaml does, and just panics if the match doesn't succeed (so equivalent to `let x = Some(42).unwrap()` in Rust). But Rust favors exhaustive pattern matching, so that wasn't a good fit.

The way that Rust solves this is via `if`-style constructs. So you already have `if let`:

    if let Some(x) = Some(42) {
        // `x` exists in here
    }

This produces an inner scope where the contents of the enum are bound. And you can use `else` here as well:

    if let Some(x) = Some(42) {
        // `x` exists in here
    } else {
        // branch where `x` doesn't exist
    }

So the `let else` syntax feels like a natural continuation to me:

    let Some(x) = Some(42) else {
        // branch where `x` doesn't exist
    }
    // `x` exists here

This reduces the nesting required in several common cases of using enums, which makes code easier to read. (Of course, the interesting thing is that since `x` exists in the outer scope, the compiler requires the inner scope to never reach the outer scope (it must "diverge", by returning or panicking or infinite looping or whatever), which is an extra restriction above what a normal `if else` requires.)

So it just checks the type of the "diverging" else block is Never or something ?

Yes, the `else` branch in `let else` is required to diverge.

Reply on news.ycombinator.com