Personally I'm fully against the "feature". I want to maintain control over if and when I return and what I return in that event, I certainly do not want to hand that control over to another function, the matter would likely be made worse in c++ because of stuff like constructors and destructors.
Hi,
I can see how there's motivation for such a feature, but I'm not
convinced the design you have is quite right.
Kotlin is a language that got non-local returns right, in my opinion.
A non-local return can only be performed using a lambda at the call
site, so you can write:
val x = y.getOr { return false }
Since the non-local return is restricted to be visible at the call
site, it's rather unproblematic. It's basically a do-expression except
using a lambda.
No matter the design, this feature is pretty powerful and hard to
implement. It's not enough for a function to be inlined by the
optimizer; the non-local return basically needs to be pulled out to
the call site, on any build type, so the inlining must be 100%
guaranteed. As much as I like Kotlin non-local returns, they seem like
a bad fit for C++, and this proposal would die on the basis of
implementation effort alone.
You can get your unwrap() function with macros though, and there's
still room in the language for "hygienic macros". Macros are 100%
guaranteed inlining in the frontend already, so they solve this whole
issue trivially.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals