So, I like the idea of supporting break and cont (and, ideally, ret) within blocks but I am not sure how they ought to be implemented. In particular, I don't like the idea of the compiler magically inserting code around block calls to handle non-local returns. Therefore, I am throwing out this half-way scheme to see what people think. It does not allow ret within blocks but it does allow break and cont and involves relatively little magic.

The idea is to create a "well-known" enum in the core library:

enum loop_ctl {
    lc_break,
    lc_cont
}

Within a sugared closure, break and cont would be equivalent to ret lc_break and ret lc_cont. Next, if there is no existing tail expression in the sugared closure and the expected return type is loop_ctl, the tail expression lc_cont is added by default. Finally, we disallow explicit use of ret within sugared closures all together, because it is potentially confusing and (besides) hurts our current type inference.

The final condition is not needed. We could keep ret with the current meaning of "return from the closure early" and just fix up the type inference algorithm. I am somewhat indifferent but I do think it's mildly confusing, particularly if break and cont start to work.