loop-break-value (issue #961)

[dhardy]

This is the culmination of recent discussion in issue #961, minus discussion about extensions to for/while/while let (for which there is no clear solution).

[llogiq]

Rendered

[sfackler]

It's not that hard:

fn f() {
    let outcome;
    loop {
        // get and process some input, e.g. from the user or from a list of
        // files
        let result = get_result();

        if successful() {
            outcome = result;
            break;
        }
        // otherwise keep trying
    };

    use_the_result(outcome);
}

[dhardy]

Yes, you're right. I was able to reduce my problem to this pattern:

let computation = {
    let mut result = None;
    loop {
        if let Some(r) = self.do_something() {
            result = Some(s);
            break;
        }
    }
    result.unwrap().do_computation()
};
self.use(computation);

Lifetimes make some of these problems horrible to think about.

[dhardy]

Damn. The problem with being British is you expect people to spot the sarcasm.

1. Having to mutable a variable just to return a value is inelegant
2. Having to wrap with Option then unwrap just because there isn't an appropriate default value is clumsy
3. Having to do this while considering the lifetimes of generated references is confusing
4. It's a lot of extra code. Compare the above to:

let computation = loop {
        if let Some(r) = self.do_something() {
            break r;
        }
    }.do_computation();
self.use(computation);

(noting that due to reference lifetimes it may be possible to give the value fed to do_computation() a name in the outer scope).

Is that sufficient motivation?

The new lifetime rules under discussion may well simplify this problem, both with-and-without break-with-value, but I still think break-with-value is a neat pattern (or alternately, a generic break-from-block-with-value, but that opens another can of worms: the value if not broken out of).

[birkenfeld]

Well, @sfackler 's example works fine without a mutable variable or an Option. Am I missing something?

[dhardy]

Maybe, and maybe it's a good thing. Sounds like it's time I un-learned to never leave variables uninitialised (thanks to Rust's great flow & lifetime analysis).

Points 3 and 4 still hold (the example above can be four words shorter), but this weakens the argument.

[birkenfeld]

Point 3 - please give an example where these confusing-to-consider lifetimes are involved.
Point 4 - "a lot of extra code" when talking about essentially one extra assignment?

[JelteF]

The current pattern is not necessarily hard, but the main problem I think is that the new pattern expresses much better what is going on.
It is immediately clear that the loop is meant to set the value, while with the code of @sfackler this is not te case. Especially when considering loops with more content or with multiple exit points.

[durka]

Btw, I have a scary macro that mostly implements this as well as labeled blocks, in case you want to play around.

[notriddle]

Considering the fact that other blatantly stupid constructs like println!("{:?}", panic!()) type-check, do we really want to require break's expression to converge? AFAIK, this would be the first place in the entire language that explicitly bans diverging expressions.

[upsuper]

for and while may need something like Python's for-else structure. That could be another RFC I suppose.

[dhardy]

@notriddle good point; I have no idea.

@upsuper: already discussed a lot; explicitly not part of the RFC

[golddranks]

I think that the requirement for EXPR in break EXPR; to converge, as stated in the RFC text, is unnecessary. Like @notriddle said, the expressions in Rust work even without such requirements, so changing that would be a complication.

[solson]

syntactic nit: this should be 'a: loop { and 'b: loop { on the line below.

[chris-morgan]

break value should be behaving exactly like return value, except producing a value for a loop rather than a function. return break break return break up (please, continue) should therefore compile (presuming a suitable function up and variable please), just as return return return return return works fine now.

I look forward to this compiling:

fn main() {
}

struct X;
type B = Result<(X), (X)>;  // That signature looks scary.
const please: () = ();
macro_rules! escape { ($x:expr, $y:expr) => (()); }
fn out(_: (), _: ()) { }
const now: B = Ok(X);

fn attempt_escape() -> B {
    'prison: loop {
        if break out (please, continue) {
            escape! (oh, yeah?)
        } else {
            return now :(
            // You got caught. Maybe next time you should try wearing cool sunnies like this:
            B)
        }
    }
}

[wycats]

I like this improvement a lot.

Ruby is also an expression-oriented language and allows break EXPR. Even though I don't use the feature all that often in Ruby, it's pretty easy to remember (it has a good analogue with return) and makes code terser without a loss in clarity when it's useful.

I especially like the fact that this is a nice improvement to an existing expression form with minimal and intuitive new syntax.

Like the original issue thread, I have some concerns with other extensions, and am glad this RFC split out just break EXPR so it could be evaluated on its own.

[nikomatsakis]

I'm basically 👍 on this. Limiting to loop makes sense to me, at least initially.

[dhardy]

Nice. I'm still watching this but from what I gather no changes are needed to the RFC?

[dhardy]

@vitiral interesting point. But the RFC states that break (); is equivalent to break;, and as I understand it the return value of a statement ending ; is (), so if there is no break in the else block, the Python-esque for ... else ... with no break or return value would be completely legal (I think).

Besides, sometimes side-effects are much more important than return values. TBH I don't understand the Python ambiguity problem very well since it always seemed clear to me (yes, in Python).

[vitiral]

the return value of any statement ending in ; is (), so you could write:

for name in suggest_names() {
    if like(name) {
        print!("{}", name);
        break;
    }
} else {
    let last_resort = random_name();
    print!("{}", last_resort);
}

So you don't need a break in the else clause (just like you don't need one in if ... else even though that can return a value)

for ... else without break in the for loop would not be legal in rust, since the for block would not have a return value. This is good, as for ... else without break makes no sense at all -- else would always get executed (assuming you didn't return or panic).

[Amanieu]

Would it be better if finally (obviously this is open to bikeshedding) was used instead of break? This makes it clearer that this block is only executed if no break occurred in the loop.

let x = for name in suggest_names() {
    if like(name) {
        break name;
    }
} finally {
    random_name()
};

[vitiral]

@Amanieu do you mean use finally instead of else? No, I think that would be even worse. For one thing, in python finally means "execute me no matter what".

[Diggsey]

I'd like to know from the people who object to just using for {} else {} etc on the basis that it's confusing, whether using another keyword instead of else would solve the problem for them, or whether they'd still find it confusing?

If not, there's no point bike-shedding further on alternative names. The choices involving Option or some variation thereof seem to be flawed, so it's a simple choice between else or nothing.

[JelteF]

I'm still very pro my suggestion of using !break. I think it really
simply shows the meaning of the second block. Without even reading the loop
body (and seeing that values are being returned with break).

On 3 Oct 2016 11:09 pm, "Diggory Blake" notifications@github.com wrote:

I'd like to know from the people who object to just using for {} else {}
etc on the basis that it's confusing, whether using another keyword instead
of else would solve the problem for them, or whether they'd still find it
confusing?

If not, there's no point bike-shedding further on alternative names. The
choices involving Option or some variation thereof seem to be flawed, so
it's a simple choice between else or nothing.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1624 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABG8Ju5D5W2cQu0XkSMTYNnKKVJxtV-Cks5qwW8dgaJpZM4Ijc2V
.

[glaebhoerl]

Something like the last 10 comments (I didn't count) are reinventing or rehashing ideas, and then the objections to them, almost verbatim from the other thread. Nicely illustrating, if anyone needed it, why that feature was deliberately left out of this RFC.

[aturon]

@rfcbot resolved Cost/benefit and tail calls

I've been persuaded that, on the whole, this RFC moves the language toward greater uniformity, and that in particular proper tall calls are not necessarily a better choice. Let's do it!

[rfcbot]

All relevant subteam members have reviewed. No concerns remain.

[aturon]

🔔 This RFC is entering its final comment period, with disposition to merge. 🔔

[nagisa]

I have some concerns and general style nits.

[nagisa]

s/'/`/

[dhardy]

The RFC is written in English, not code. shrug. 'loop' isn't a code snippet in this context, it's a quoted keyword.

[nagisa]

s/'/`/

I will not nit on any more of the formatting, but the issues with it probably should be fixed across the document. Namely, plain apostrophe (') does not begin/end an inline code snippet.

[nagisa]

This list still has issues with handling of coercion. For example I imagine something like this ought to be valid:

loop {
     // ...
     break (expr: SomeT);
     // ...
     break (expr: OtherT);
}: RT

where SomeT and OtherT both coerce to RT. If this discrepancy was fixed, the list could avoid having to contain the last two notes/requirements. I also dislike those two extra requirements-exceptions-rules, because they have potential to diverge from type rules elsewhere in the language.

(Why this matters? Substitute SomeT = &[u8; 42], OtherT = &[u8; 32], RT = &[u8].)

[Ericson2314]

I think the typing and coersions rules here can be exactly like those for match arms or if-else.

[dhardy]

Please write a diff against the RFC; I was not 100% sure how to handle coercions (same with the ! special case).

[JelteF]

I just created a new issue to discuss other implementation details for returing from for and while than the the name of keywords. This issue can be found here for other people that are interested: #1767

[burdges]

Just noticed this slightly confusion loop that is not a loop :

let x = 'a loop { 
    ...
    if foo { break `a bar; }
    ...
    break `a baz;
};

It's obvious doing this with a closure would be more readable, but that's frequently true for loops too, if one had tail call optimization, so..

Is it desirable to support a less confusing form of this?

let x = 'a { 
    ...
    if foo { break `a bar; }
    ...
    baz
};

If so, does continue work in such a block? I presume no.

[glaebhoerl]

@burdges That's the orthogonal (but synergistic) "break from any block" feature, I'm surprised I can't find any existing issue or RFC for it. cc @Ericson2314?

[Ericson2314]

@glaebhoerl I don't think anybody wrote an RFC but we've both brought it up many times (e.g. ? And catch). Maybe it will finally stick :).

[vitiral]

@burdges this would not be backwards compatible. If I had code like:

loop {
    // do something
    {
        let foo = Bar();
        if x == foo {
            break;
        }
    }
}

currently this would break out of the loop block, but if we implemented your code it would break out of the inner block (and the loop would continue). I also don't like making break into a kind of goto (even though it often fulfills that role). If we want something like a generalized goto we should reserve a word for it and implement it separately rather than overload break

[nagisa]

Is the ; after break EXPR compulsory? Currently existing forms of break do not require a semicolon after if they are in expression position.

Could we get an example of what would the grammar look like with syntax changes? See this and this.

[vitiral]

I would say that the ; is not necessary. It should map how return works, and the following compiles:

fn test() -> bool {
    if true {
        return true
    } else {
        return false
    }
}

fn test2() -> bool {
    return false
}

[Ericson2314]

Yes just like today

---------------
(break 'a e): !

[burdges]

It's obviously "break from named blocks" @vitiral not literally "break from any block", so no compatibility issues. I donnot if it's a good idea or not, just thought it might be worth asking.

[rfcbot]

It has been one week since all blocks to the FCP were resolved.

[aturon]

RFC has been merged!

Further discussion should happen on the tracking issue.