can we get labeled returns as an alternative to ok-wrapping? anything with a labeled return would ok-wrap, labeled break would not, and labeled ? would handle errors and ok-unwrap.
additionally you’d be able to label the return type:
fn foo() -> 'bar: Result<Foo, Bar> {
return 'bar Foo::new();
}
Personally, I think it very ideal that return remain nothing more than (conceptually) break 'fn.
Labeling return introduces problems in that users’d probably expect to be able to return 'outer from within a closure 'inner, which is very impossible.
And the semantic difference between {return, break, break 'lt} and return 'lt if only the later Ok-wraps seems needlessly surprising.
[sarcasm]
Obviously the solution is just to make rustfmt accept the following style:
fn foo() -> Result<Foo, Bar> {Ok({
unimplemented!()
})}
[/sarcasm]
Variants of this (e.g. break ok, fail err, reta) have already been proposed. In that thread it seems like there are mixed feelings about such extensions.
So if you’re proposing a similar thing, it’d be worthwhile to address concerns already raised (how does it work with async wrapping? Does it work with try blocks? Does it work with the Try trait?), what new your proposal brings, and why this variant is better than others.
Why? Labeling is used in Rust to direct control flow to a specific point in the code. Since return is always for returning from the innermost function, why should it support labels at all, and why should labeling it do something other than alter control flow? It seems very inconsistent as well as non-intuitive in both regards with how labels and return work.
Return would be for blocks, just like break is for blocks. And anyway, you can’t break a function, so the distinction/“inconsistency” is between break 'label and return 'label. And think about it: break is supposed to just stop flow, whether it be due to an exceptional case (err) or not (ok). Whereas usually return is supposed to return an useful value. I think my proposal provides an useful syntactic and semantic distinction between the two, and it seems slightly more meaningful than that try block thing y’all keep insisting on.
That would be a wildly breaking change; but even if it weren't, it's not a great idea. I only know one language where return doesn't mean "return from the innermost function": in Haskell (where it isn't a language element, just a function that doesn't do anything remotely like return), and it's perhaps the single most confusing thing in there.
Distinction is not inconsistency. Different language features do different things. We shouldn't try to force break and return into the same molding shape because they are designed to work differently and accomplish different goals.
I never insisted on try blocks. I don't think they are that useful, and I'm not particularly keen on adding them to the language.
sorry about that I meant labeled return would be for blocks.
return would keep doing what it’s doing. it’s not a breaking change.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.