Propose replacing the loop keyword with while true.

[jkleint]

This is one way we could remove the loop keyword from the language before Rust 1.0. It's straightforward and allows us to refine the implementation over time.

[mcpherrinm]

The only argument I have against this is based around a theoretical future feature that I want: valued break expressions. That is, let foo = loop { if let Some(bar) = baz() { break bar; } } -- break acts like return from a loop. This feature is a bit weirder than in a while loop, since you can just drop out the bottom of it, and what do you return in that case? () I guess, or the last while conditional evaluated.

[ghost]

@mcpherrinm why can't you just do something like this?

let foo = { let val; while true { if let Some(bar) = baz() { val = bar; break } }; val };

Edit: Ah, I see, 'possibly uninitialized'.

[nrc]

Whilst I'm sympathetic to the motivation, the idea of treating while true differently from, e.g., while (true) is pretty gross. Unfortunately, there is not a lot of middle ground here, we could recognise while e where e is a constant expression which evaluates to true, but that would still exclude some obviously correct programs and would be surprising in corner cases.

[reem]

I share pretty much the same viewpoint as @nick29581, this seems nice on the surface but really ends up bringing a lot of special casing and magic.

[thestinger]

@nick29581: We already have a concept of expressions valid in constant expressions. It could be reused to check this without surprises based on LLVM changes.

[ftxqxd]

@mcpherrinm See #352, which proposes breaking with values from loops and also adding else to non-loop loops, which is evaluated iff the loop exits normally. If while true were treated specially by the compiler for detecting potentially uninitialised variables, I see no reason why it couldn’t also let while true loops need no else section.

[jkleint]

@nick29581, I totally agree that only recognizing literal while true is a dirty implementaion hack -- it's certainly not the end-goal. But don't you feel that special-casing a keyword for an infinite loop is an even more gross design hack? It would be sad to tarnish Rust and have people question our desgin forever just because we couldn't recognize an infinite loop today. The implementation is ephemeral; the design is going to be around a long, long time.

The goal is to get loop out of the language before 1.0, after which we can improve the implementation at any time, in a backward-compatible way. My suggestion is a two-line change to the parser, the simplest possible solution that seems to work, the idea being simpler is more likely to be approved. If anybody wants to improve it to recognize constant expressions, or unify loop handling (or if a more complicated / complete solution is more likely to be approved) I'm all for it. I want Rust to be the best it can be. That starts by not making us look dumb with superfluous keywords.

@reem, it is special casing and magic for now, agreed. But isn't that exactly what the loop keyword is -- a special case of a while loop that magically allows the use of uninitialized variables? The difference is that one is a magic special case of the implementation, which can be fixed at any time; the other is a magic special case of the design, which will soon be frozen forever. As language designers (which I've never though of myself as until now, hmm...), isn't our goal to make beautiful, powerful magic for users of our language? We (and compilers and tools in general) go through all sorts of contortions to present a clean, simple interface for doing powerful, complicated things. I don't think it's beyond the brains of this esteemed community to devise an elegant solution to the problem of handling infinite loops -- even Java does that. ;) But it will be beyond us to repair the language design once it is released to the world.

[nrc]

Whilst it is kind of a wart, I feel we haven't actually got much criticism for the loop statement - it's really not a big deal. I'd much rather spend time and energy on the bigger gripes. I realise you're suggesting while true as a temporary hack, but I'd be more embarrassed about having that in the 1.0 release than having an extra loop keyword.

[Gankra]

Am I the only one who actually likes the loop keyword? It seems so much nicer than saying while true. "just loop forever" also overwhelmingly is my default mode for (non-for) loops, since it's often awkward to line up the time to end the loop with the start/end. Usually easier to just loop and break/return when most appropriate. I didn't even know that loop had special semantics over while.

[ghost]

@gankro I prefer it to while true too. I think it's clearer at a glance and also tend to use it far more than while since the other case is almost always iterating over some structure.

[reem]

I also agree with @gankro. I also reach for loop much more often than while, since it's usually easier to just loop forever and break when necessary.

[steveklabnik]

I also prefer 'loop'. I don't see encoding an explicitly infinite loop as a
hack, I see it as giving a concept a name, which is generally considered
good design, not bad.

[netvl]

-1. loop keyword is very nice and clearly conveys the intent of infinite loop. I use it very often in my code and I don't want to write while true instead.

[dobkeratops]

+1. one less thing to learn coming from elsewhere.
leaves the word 'loop' free for macros.. loop!... which could do more.
(tangentially, +1 to the suggestion of break expressions aswell)

(more tangentially, I do actually like go's approach here too, learn one versatile thing and it handles several cases, but I know the full c-like for is a whole other argument. let x=for init;cond;inc{ ...find something... } else{... not found..} would be great IMO.. really leverage the expression syntax and avoid excessive nesting )

[arielb1]

-1

There are always going to be infinite loops that aren't recognized by the compiler as such – having "magic true" would be ugly and/or complicate the language.

loop is almost as popular as all other kinds of while combined, so introducing a keyword for it isn't so bad.

[barosl]

I agree with @jkleint in that while true isn't that magical. To me, loop just feels like a 'shortcut' of while true. It's like an idiom. And it will also relieve a fear of a newcomer, which is a good news.

But I also think, at least in my daily code, while true clearly appears more often than while <condition>. So having the loop shortcut sounds good. I once thought that using an infinite loop and break is more familiar to human brain.

If I can imagine one scenario that makes while true useful, it would be while (line = get_next_line()) != "" { ... }. But assigning a value in while is not allowed in Rust, is it?

[reem]

@barosl assignment is an expression but it always evaluates to (), so it not useful for this case.

[Thiez]

@barosl You can do that, but it's not very pretty:

let mut line;
while { line = get_next_line(); line != "" } {
    // stuff...
}

[nrc]

We discussed this at this week's triage meeting and there was no appetite for removing loop. Thanks for writing and submitting the RFC.