Tracking issue for RFC 2046, label-break-value

[Centril]

This is a tracking issue for RFC 2046 (rust-lang/rfcs#2046).

Steps:

• Implement the RFC (done in Implement label break value (RFC 2046) #50045)
• Adjust documentation (see instructions on forge)
• Stabilization PR (see instructions on forge)

Unresolved questions:

• Use return as the keyword instead of break? RFC: label-break-value rfcs#2046 (comment)
  • Sentiment is strongly in favour of break; call it resolved. Tracking issue for RFC 2046, label-break-value #48594 (comment)

---

Note from shepard: This is a very long thread. If you're just looking for the 2022 conversation in which this ended up stabilized, jump to the report @ #48594 (comment)

[SoniEx2]

Using "return" would have interesting implications for labeled ? (tryop questionmark operator thingy).

[est31]

Use return as the keyword instead of break?

@mark-i-m and @joshtriplett have already spoken out against return, but I'll join in given that it is still apparently an unresolved question.

break (and continue) are only usable with a loop.
If you can break something, you can continue it. (I don't think there's an obvious syntax to pick for continue on a block.)

In C, C++, Java, C#, JavaScript and probably more languages you are usually breaking a switch statement in order to prevent fall-through. Rust has solved this much nicer with | in patterns but people coming from those languages won't really see break as something only for for loops. Especially as Java and JavaScript expose the feature via break as well and not return.

The "rules to remember" argument works into the other direction really well however. From what I can tell it is a commonality of the mentioned languages as well as Rust that return only applies to functions and nothing else. So if you see a return, you know that a function is being left.

Labeling a block doesn't cause errors on existing unlabeled breaks

First, I think this happens very rarely as the labeled break feature is admittedly not something that will be used 10 times per 1000 lines. After all, it will only apply to unlabeled breaks that would cross the boundary of the block, not unlabeled breaks inside the block. Second, users of Rust are accustomed to complaints / error messages by the compiler, they will happily fix them! Third (this is the strongest point I think), if instead of labeling a block you wrap it into a loop, you already need to watch out for unlabeled breaks and there is no error message that conveniently lists the break statements, you've got to hunt for them yourself :).

[nikomatsakis]

Especially as Java and JavaScript expose the feature via break as well and not return.

This to me is the killer point. break from blocks is a thing in many languages. return from blocks...not so much.

[Centril]

Personally, I share @joshtriplett's view on using break instead of return, but it seemed to me like the discussion hadn't been resolved on the RFC... If you believe the question is resolved in the lang team, tick the box with a note =)

[est31]

Just saying that I'm working on this. Don't need mentor instructions. Just to not duplicate any efforts. Expect a PR soon.

[scottmcm]

I'm still in favour of return over break, but I can agree to disagree here. Question resolved.

[topecongiro]

Currently (with rustc 1.28.0-nightly (a1d4a9503 2018-05-20)) rustc does not allow unsafe on a labeled block. Is this expected?

[scottmcm]

@topecongiro Yes, I believe it's intentional that this is currently allowed only on plain blocks. It might change in future, but given that this is such a low-level and unusual feature, I'm inclined towards that being a feature rather than a restriction. (On the extreme, I certainly don't want else 'a: {.)

[mark-i-m]

Definitely agree. Unsafe + unusual control flow sounds like something to discourage.

In a pinch, though, you could use:

'a: {
unsafe {...}
}

Right?

[SoniEx2]

Actually, altho else does create a new lexical scope, it's not a block. The whole if-else is a block (kinda). So no, you wouldn't get else 'a: { you'd get 'a: if ... else {.

[eddyb]

else contains a block (expression). there is no "new lexical scope" without blocks.
An even worse surface syntax position than else would be 'a: while foo 'b: {...}.
(interestingly enough, continue 'a is break 'b, we might want to rely on that at least internally)

[Centril]

(interestingly enough, continue 'a is break 'b, we might want to rely on that at least internally)

That's a great observation!

[SoniEx2]

I think labels should be part of block-containing expressions, not blocks themselves. We already have precedent for this with loop. (As it happens, a plain block itself is also a block-containing expression. But things like if and loop are block-containing expressions without being blocks I guess.)

(Things like while or for shouldn't support label-break-value, because they could or could not return a value based on whether they complete normally or with a break.)

[mark-i-m]

@eddyb

(interestingly enough, continue 'a is break 'b, we might want to rely on that at least internally)

Only if break 'b re-checks the loop condition...

[eddyb]

@mark-i-m It's equivalent to 'a: while foo {'b: {...}}, the break wouldn't check the loop condition, the loop itself would, because the loop condition is checked before each iteration of the body block.

[mark-i-m]

Woah, I find that highly unintuitive. I expect break 'b to be basically goto 'b, meaning we never exit the loop body and the condition is not checked again...

[mark-i-m]

Oh 🤦‍♂️ I see...

[mark-i-m]

This is why I don't like labeled break/continue :/

[rpjohnst]

Well, we specifically don't have the ability to label these weird inner blocks, so I don't see the problem. break always means "leave this block" and, given the above restriction, there's no way for that to mean anything other than "goto the spot after the associated closing brace."

[mark-i-m]

My confusion was not specific to weird inner blocks, but I don't really want to reopen the discussion. That already happened and the community decided to add it.

[SoniEx2]

Okay, I understand accessibility is a big issue with programming languages... however, labeled break is extremely useful if you write code like me.

So, how can we make labeled break more accessible?

[mark-i-m]

So, how can we make labeled break more accessible?

That's a great question. Some ideas I had:

• We should collect some samples of how people use this in the wild. We can look for undesirable patterns or lazy habits.
• We should have opinionated style around when it is considered poor practice to use labeled break/continue.
• We may be able to add lints for some patterns that could be turned into loops/iterator combinators mechanically (I can't think of any such patterns off the top of my head, though).

As a first (admittedly biased) sample, my last (and first) encounter with labeled break in real code was not stellar: https://github.com/rust-lang/rust/pull/48456/files#diff-3ac60df36be32d72842bf5351fc2bb1dL51. I respectfully suggest that if the original author had put in slightly more effort they could have avoided using labeled break in that case altogether... This is an example of the sort of practice I would like to discourage if possible.

[rpjohnst]

That's... not labeled break?

[jyn514]

Should the 'b: have been on the {} in _ => {}, or is match just not usable as an example here?

@eddyb you're right, I misread https://doc.rust-lang.org/nightly/reference/expressions/match-expr.html#match-expressions. match is not usable as an example here because match arms allow any ExpressionWithBlock (which eventually allows LoopExpression). Here's a correct example of it being disallowed on BlockExpression: https://doc.rust-lang.org/nightly/reference/expressions/if-expr.html#if-expressions

fn labeled_match() {
    if true 'b: {  //~ ERROR block label not supported here

[scottmcm]

Looks like this was merged for 1.65 in #99332 !

[matklad]

Hm, is it intentional that async blocks use return while sync blocks use break?

fn _f() {
    let f = 'b: { break 'b 92 };
    assert_eq!(f, 92);
}

async fn _g() {
    let f = async { return 92 };
    assert_eq!(f.await, 92);
}    

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=db815319f8eb5cee0f7be84854b4bd5e

[est31]

Yeah it seems a bit weird at first impression, but IMO they are closer to closures than to sync blocks.

Like closures, async blocks are decoupled from the function's normal control flow, they can't interact with it. In other words, async blocks, like closures, are not ran when they are being declared, but when they are being evaluated.

This will print bar and then foo:

#[tokio::main]
async fn main() {
    let f = async { println!("foo"); return 92; };
    println!("bar");
    assert_eq!(f.await, 92);
}

This evaluation difference also shows up in other ways. You can't break out of an outer loop inside an async block for example, while you can in a sync block. You can't even return from the function that declared the block, as the async block can be evaluated long after the function that declared it terminated.

A return statement as to return the function makes no sense for an async block. On the other hand, for sync blocks, being able to return something from the function is highly useful. If the keyword were changed to return instead of break, you would have to introduce lifetimes for return statements, something that would be a new concept.

[RalfJung]

Hm, is it intentional that async blocks use return while sync blocks use break?

Those are completely different pieces of code? The async one already works on stable since forever. I don't see how that even has anything to do with break.

[jyn514]

break vs return has already been discussed at length. Let's please not bikeshed this further unless new information comes to light.

[matklad]

It does seem to me that interaction between async blocks and labeled blocks is novel information. This isn't covered in stabilization report. There is a bit of discussion here which culminates in

If nothing else, it seems like it should be updated to take async blocks into account

which update didn't seem to happen. Certainly, this wasn't discussed during break/return bikeshed which predates async blocks.

---

Hence, my question of "did we actually thought about this properly, or is this design by accident?". I don't necessary want to re-open bikescheding here, but I do want to make sure our language design process is capable of noticing feature interactions and surfacing them as documented explicit decisions.

I guess, one can say that these are two completely different snippets of code and there's no actual feature interactions here. But, as a naive user who doesn't look much beyond syntax, it sure does feel weird that we use "different" syntax to mean the "same" thing.

[afetisov]

it sure does feel weird that we use "different" syntax to mean the "same" thing.

It's not more weird than the fact that we have separate return and break operators to begin with, even if both "mean the same thing" of returning from a block. We just have a special syntax for the toplevel block, because it's so common and so familiar to programmers.

The break on blocks is chosen by analogy with break from loop. return from an async block is chosen by symmetry with return from async fn, since an async function is a sugar for a function returning an async block.

However, I'm not sure whether there was much discussion of the differences between break from block and return from async block, since the async RFC was proposed after label-break-value was accepted and the break syntax was agreed on. Personally I didn't find any explicit comparison between those.

[scottmcm]

return from async { } is because they're really closures, not blocks -- it produces something that will run later, not something that runs immediately like normal blocks or loops do.

You're better thinking of async { BODY } as (async || BODY)() than as a block at all.

it sure does feel weird that we use "different" syntax to mean the "same" thing.

I think the important distinguisher is that block-break only works with a label. There's no 'a: async { break 'a }, nor is there ever return 'a.

(And if you attempt 'a: { async { break 'a } }, then you get an error, just like if you attempt 'a: { || break 'a }.)

[ehuss]

This seems to have landed without a documentation PR being open. Usually there should be documentation ready before the feature is stabilized. Was there something that I missed? The documentation checkbox was marked, but I don't see where that documentation was posted.

Can someone please follow up on that?

[RalfJung]

It does seem to me that interaction between async blocks and labeled blocks is novel information.

I don't agree, they are entirely orthogonal. However, you need to think of async blocks as "closures without arguments", or "thunks" in PL speak. A thunk is a suspended computation, i.e., a computation that can be continued later. Calling them async "blocks" is indeed confusing since it makes them sound like regular blocks, which they are not:

fn main() {
  let _x = { println!("hello from block") };
  let _x = async { println!("hello from async block") };
}

The 2nd println is never executed.

Once you use an adequate mental model of async blocks thunks, I don't think there is any new information in their interaction with break 'label -- they interact exactly the same way closures do:

fn _f() {
    let f = 'b: { break 'b 92 };
    assert_eq!(f, 92);
}

fn _g() {
    let f = || { return 92 };
    assert_eq!(f(), 92);
}    

You're better thinking of async { BODY } as (async || BODY)() than as a block at all.

More like async || BODY; the closure is not actually invoked yet.

it sure does feel weird that we use "different" syntax to mean the "same" thing.

Your example is exactly like this one:

fn uwu() -> i32 {
    return 0;
}

fn foo() -> i32 { 'a: {
    break 'a 0;
}}

That's also "two different syntax to mean the same thing". break is strictly more general than return, so indeed we could remove return from the language now that we have break on labeled blocks -- but the return case is so common that it is worth having a separate keyword.

[jyn514]

@ehuss rust-lang/reference#1263