Why not allow loop to take ExpressionWithoutBlock?

1

Presently, the loop expression can only accept a BlockExpression. Has anyone ever proposed extending the syntax to accept ExpressionWithoutBlock as well? This could reduce some indentation in a relatively common infinite loop case.

// Before
loop {
    match my_stream.next().await {
        Some(Ok(val)) => handle_token!(val),
        Some(Err(err)) => break Err(err),
        None => break Err(UnexpectedEnd),
    }
}

// After
loop match token_stream.next() {
    Some(Ok(val)) => handle_token!(val),
    Some(Err(err)) => break Err(err),
    None => break Err(UnexpectedEnd),
}

This loop match construct seems ergonomic to me. It would also work well as loop select! with the various select macros in the ecosystem.

I'm not sure it this would cause problems with syntax somewhere, but I wasn't able to find any discussion about such a change on the internet (or this forum specifically), so I thought I would ask.

I think that loop if p { x } else { y } is certainly less ergonomic than the current way, but rustfmt or clippy could easily have a "blockless loop permitted expressions" check to help keep things readable.

2

It comes up on IRLO occasionally (try searching for "loop match").

3
4

Ah, didn't realize there was a separate forum that I should also have checked. This certainly qualifies as a discussion. Thank you both!

The most relevant one is definitely the following. It is directly talking only modifying the rule to allow ExpressionWithoutBlock instead of BlockExpression. The summary I reach from reading the on-topic replies is that in general it can lead to awkward matchups that people don't like (async try { .. }.unwrap()), and specific cases aren't individually worth the trouble to implement (loop match).

1 Like
5

I'd say that the implementation complexity isn't really the issue. It wouldn't be hard.

The bigger problem is all the social questions. Should clippy tell you to remove the newly-unneeded braces? Should rustfmt start removing them next formatting edition? Should you write a style guide at your company saying that you should always have them even though it's allowed to omit them?

Way easier to just not have the option.

1 Like
6

The next step would be if and while etc without blocks in squiggle braces. Which if I understand correctly is not allowed in Rust as it encourages the kind of bugs we get in C when such constructs are modified.

All in all I would rather not see that and loop is best remaining consistent with the others. It's only two characters, hardly worth fussing about.

1 Like