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.

On Fri, 1 Aug 2025 at 05:23, Jan Schultke via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>