From 4f9b2c1776eb8fe98fbf6f037b71acd12a31aac5 Mon Sep 17 00:00:00 2001 From: John Ericson Date: Sat, 7 Jan 2017 12:09:53 -0500 Subject: [PATCH] Add unresolved question of `break 'fn ..` --- text/0000-fn-lifetime.md | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/text/0000-fn-lifetime.md b/text/0000-fn-lifetime.md index b19c0fb52cc..14456ec50c6 100644 --- a/text/0000-fn-lifetime.md +++ b/text/0000-fn-lifetime.md @@ -68,4 +68,19 @@ What other designs have been considered? What is the impact of not doing this? # Unresolved questions [unresolved]: #unresolved-questions +- Should we allow `break 'fn ..` with the same semantics as `return ..`. In + [RFC 1624](https://github.com/rust-lang/rfcs/blob/master/text/1624-loop-break-value.md) + we got breaking with a value out of loops, so the value part is already + established. This provides one canonnical syntax for breaking out of a loops + or functions, leaving `return` just a convenience. In a future with full + lifetime ascription, this would further generalize to supporting all labeled + blocks, not just loops and functions. + + A downside is `continue 'a` will still only make sense when `'a` is bound to a + loop, and `break 'a` won't make sense when `'a` is a lifetime parameter. That + means users will need to understand their are three tiers of lifetimes: loop, + block (including `'fn`), and, parameter, where each is less usable than the + last. Today loop lables and lifetimes are disjoint in that neither can be used + where the other is expected, though they do share the same syntax. + What parts of the design are still TBD?