Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reserving "nobreak" as a keyword for Rust Edition 2021 #3152

Closed
JelteF opened this issue Jul 20, 2021 · 1 comment
Closed

Reserving "nobreak" as a keyword for Rust Edition 2021 #3152

JelteF opened this issue Jul 20, 2021 · 1 comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.

Comments

@JelteF
Copy link

JelteF commented Jul 20, 2021

The reason I'm opening this issue is that there has been some activity on the old issues, regarding returning values with break from for and while loops:

  1. Allow loops to return values other than () #961
  2. Allow for and while loop to return value (without discussion of keyword names) #1767

Rereading those threads, the main issues why those were originally closed seem to be:

  1. else being a confusing name for this block
  2. not being able to add a new keyword that makes the meaning of the block clear
  3. there was no experience with the loop version of the break <value> syntax

Number 1 is still valid (although some disagree). 3 is not valid anymore, this feature was stabilized more than 4 years ago in 2017. Number 2 seems much less of a problem these days, since we now have editions (which we didn't have when these original issues were opened).

That's why I'm proposing to reserve nobreak as a keyword in Rust Edition 2021. That way we at can add this feature in the future, using a clear keyword.

I think nobreak clearly shows the meaning of the block. It's the block that you enter when there was no break. Code would then look like this:

let found_six = for val in [1, 4, 3, 2] {
    if val == 6 {
        break true;
    }
} nobreak {
    false
}
@scottmcm
Copy link
Member

I'm going to close this because based on #2441 (comment), lang has decided not to do speculative reservations of specific keywords any more.

The new plan is to generally reserve space with #3101, and use that reserved space as a transition plan (perhaps via something like #3098) to allow the feature to be used on the latest edition with slightly-inferior syntax until the keyword can be fully reserved in a future one, after the RFC for the whole feature has been accepted.

(Note that this is neither a statement in opposition nor in support of the feature. Just that the way forward is to RFC the whole feature, including the eventual keyword -- not to separate out the keyword first.)

@scottmcm scottmcm added the T-lang Relevant to the language team, which will review and decide on the RFC. label Jul 20, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T-lang Relevant to the language team, which will review and decide on the RFC.
Projects
None yet
Development

No branches or pull requests

2 participants