Better error message for "error: `break' outside of loop" inside of `do' inside of `for'

[bblum]

fn main() {
    let vec = ~[some(())];
    for vec::each(vec) |slot| {
        do slot.iter |bucket| {
            break;
        }
    }
}

fails to compile, though I claim it should, and be the same as:

fn main() {
    let vec = ~[some(())];
    for vec::each(vec) |slot| {
        alt slot {
            some(bucket) { break; }
            none { }
        }
    }
}

[mitsuhiko]

The issue also exists for loop constructs.

[nikomatsakis]

You cannot break from a do because do does not require any sort of protocol, unlike for. The best we could do is to make break equivalent to "return" from the closure---which perhaps we ought to do, but I am not sure. There is no reason to think that the function will observe "break-like" semantics.

[bblum]

oh, huh, for some reason I forgot that there was another closure going on here. Yeah, this is correct behaviour. Maybe a better error message.

[mitsuhiko]

The way it works for ruby is that the interpreter sets jump targets in the method frame. Each black executed from the stack will look at the method's frame to find where to jump to for continue/break/return.

[pnkfelix]

Here is the syntax modernized version of the examples.

    fn foo1() {
        let vec = ~[Some(())];
        for vec::each(vec) |slot| {
            do slot.each |_bucket| {
                break; // error: `break` outside of loop
            }
        }
    }

    fn foo2() {
        let vec = ~[Some(())];
        for vec::each(vec) |slot| {
            match *slot {
                Some(_bucket) => { break; }
                None => { }
            }
        }

I vote for either leaving things as is (and accept the odd error message as a consequence of integration of light-weight closure syntax), or finding some way to "improve" the error message (though it is not clear how best to do so).

[pnkfelix]

Not critical for 0.6; de-milestoning

[pnkfelix]

(there are of course other options. e.g. we could look into mitsuhiko's suggestion and change the calling convention so that invoking a closure implicitly passes along some number >1 of continuations, corresponding to different places control should shift in response to continue vs break vs return; but we would probably need to see some very convincing use-cases to motivate such a change.)

[catamorphism]

@pnkfelix - Changing the calling convention is what might be needed in order to make labelled-break-out-of-a-for work (see #4131). I'm not sure whether we need to ever fix that, though.

[nikomatsakis]

Changing the calling convention is not needed. If we can return out of the whole function, we can certainly break out of a subloop---you just break set a variable in your local stack indicating the point you wish to break to. To handle do, on the other hand, is more complex.

[nikomatsakis]

(Let me rephrase: we cannot handle do. That's the whole point of do is that it doesn't introduce any syntactic sugar or anything)

[graydon]

Yeah, I'm sensing this is more of a WONTFIX. We're landing those enhancements to the for-protocol we can (eg. 3e0400f / #6223 ) but I think encoding arbitrary loop-label break targets into it as in #4131 is likely pushing it beyond the breaking point. And I agree with @nikomatsakis that there's not much we can do about do without demanding that it acquire a protocol-and-rewriting of its own (which would affect all users, on the off chance that they're called inside a loop)

[bblum]

I agree that the functionality shouldn't be supported, but you don't think a less confusing error message would be doable?

[nikomatsakis]

@graydon to be clear, I think that break to an arbitrary target from inside a for loop ought to work---at least there is no theoretical impediment, no changes to the protocol are needed etc---but that's not what this bug is about

[huonw]

Visiting for triage, the error message is still the same.