Date: Fri, 1 Aug 2025 06:23:29 +0200
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.
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.
Received on 2025-08-01 04:23:42