Hmmm, but say, what if `return_caller` were not how you return things, but
a property of the callable?

std::string handle_name(std::string&& foo) returns_from_caller {
    // in this context, plain `return` punches through the caller
    return foo + " was successful";
}

std::expected<std::string, void> frobnicate(std::optional<std::string>&&
foo) {
    std::move(foo).and_then(&handle_name);
    return std::unexpected<void>();
}

Monadic functions are awesome, I'd love to be able to use them more often...

I do hope folks can come up with better names, though ':).

On Fri, 1 Aug 2025 at 06:07, zxuiji via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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
>>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>