Tracking issue for RFC 1624: `break` with values for `loop`

[aturon]

RFC.

Current status:

• Implemented.
• Decided to stabilize.
• Documentation PR: rust-lang-nursery/reference#56 (See final section of the Rust Forge stabilization instructions for advice.)
• Stabilization PR: #42016 (See the Rust Forge for instructions.)

[aturon]

Currently awaiting implementation.

cc @dhardy

[eddyb]

@aturon How would we go about advertising mentorship? If someone wants to implement this and they're not already familiar with the compiler internals, they can come to #rustc on IRC to discuss it.
This is the case for many such features with a relatively small footprint, we're glad to help.

(Although I may be spreading myself thin a bit too much instead of finishing my own refactors.)

[aturon]

@eddyb An important question we don't have a systematic answer for right now (cc @brson). We should probably move this to an internals thread or something, though.

[dhardy]

I hear you @aturon but don't have the time just now (and maybe for a few weeks).

[glaebhoerl]

Out of curiosity is there anything holding this back from being stabilized?

[aturon]

@glaebhoerl Not that I'm aware of. More obscure features like this are hard to judge, since we naturally tend to get very little feedback on them.

In any case, it's certainly been around long enough that going to FCP to try to advertise for more feedback seems good:

@rfcbot fcp merge

[rfcbot]

Team member @aturon has proposed to merge this. The next step is review by the rest of the tagged teams:

• @aturon
• @eddyb
• @nikomatsakis
• @nrc
• @pnkfelix
• @withoutboats

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[withoutboats]

@rfcbot reviewed

[nrc]

I guess I don't have any technical reason against stabilising this (I was in favour of the RFC and nothing has changed my mind). But I kind of think that if a feature isn't being used at all then we should consider removing it rather than stabilising it. Is it worth posting in users.r-l.o to see if people are using it and whether there are any problems?

[SimonSapin]

It’s not surprising that a feature isn’t used when it’s not available yet. Much of the ecosystem has moved to the stable channel.

[andrewtj]

@nrc I played with it, saw that it worked, and then promptly stopped using it because while it's nice (really!) it's not worth jumping off stable for some indeterminate period. So if my experience is a barometer you may not get that much feedback but maybe that's to be expected for this feature.

[Boscop]

FWIW, I'm using it, e.g. for things like:

			let (filename, mut file) = loop {
				let uuid = Uuid::new_v4().simple().to_string();
				let filename = format!("{}.{}", uuid, ImageFormat::from_image_format(fmt).as_str());
				let fpath = ::helper::filename_to_local(&filename);
				if let Ok(f) = fs::OpenOptions::new().write(true).create_new(true).open(&fpath) {
					break (filename, f);
				}
			};
			img.save(&mut file, fmt)?;

[withoutboats]

I also wouldn't depend on a nightly feature for this, but would use it if it were available. As it stands I'd tend to just use a temporary variable, but I'd rather not if this were stable.

[glaebhoerl]

(Likewise, I originally popped in here to ask about stabilization because I was going to suggest it to someone on twitter who was lamenting the necessity of the temporary variables, before I realized that it's only available on nightly.)

[crumblingstatue]

It should take more than just "apparent lack of usage" to remove a feature for which the RFC was accepted, with the motivation clearly understood.

People won't go out of their way to change their existing code just to use this feature, but it offers a better alternative for some cases, doesn't introduce any significant complexity, and makes the syntax more consistent with the expression oriented nature of Rust.

[Ericson2314]

While I'm personally wildly in favor of this, it is important that features be evaluated before stabilization. There was a thread before on this connundrum, but I don't recall it concluding with a solution either :/.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[nikomatsakis]

So, we've decided to stabilize this feature. That means we would like some PRs. I'm going to mark this bug as E-easy and E-mentor. The PRs we need are a documentation PR (first) and the stabilization PR (second). I've added some links to instructions into the head comment.

[pietroalbini]

Pull requests for the documentation sent to the various repositories. Should I wait for the stabilization PR?

[dhardy]

I noticed a small inconsistency between documentation and implementation: the RFC claims

break and break 'label become equivalent to break () and break 'label () respectively

but the impl doesn't support break () in while or for loops.

Perhaps this is for the best anyway until "break with value" is supported by for and while.

[dhardy]

New reference PR: rust-lang-nursery/reference#56

[ciphergoth]

It might make sense to allow break to take a value of type () in while and for loops too, for consistency.

[ciphergoth]

A future RFC could extend this to labelled blocks without loops.

    let result : u64 = 'block: {
        if foo() { break 'block 1 }
        if bar() { break 'block 2 }
        3
    };

This would also give you a way to handle for and while

    let result : u64 = 'block: {
        for e in container.iter() {
            let v = foo(e);
            if v > 0 { break 'block v }
        }
        0
    };

The semantics would be exactly the same as

    let result : u64 = 'block: loop { break {
        for e in container.iter() {
            let v = foo(e);
            if v > 0 { break 'block v }
        }
        0
    }};

EDIT: I made this into a Pre-RFC.

[nikomatsakis]

We specifically decided to limit this to loop loops. In fact, there is a (closed) rfc issue on this topic (rust-lang/rfcs#1767).

[aturon]

@nikomatsakis The proposal here is different: it's talking about jumping out to a labeled block, rather than simply breaking out of a loop. It just happens to combine reasonably well with loops.

[Ericson2314]

Hmm, one extra level of indentation, but way less controversy! That's a pretty neat trick @ciphergoth.

[est31]

Can this issue be closed? The stabilisation PR #42016 has been merged since.

[Mark-Simulacrum]

I think so, closing.