Not all return paths in the callable should cause the caller to immediately
return.

I’m still thinking that the callable shouldn’t have to know about this, and
it should be entirely within the caller’s domain as to whether to return
immediately or not.


On Fri, Aug 1, 2025 at 5:54 AM Iúri Chaer via Std-Proposals <
std-proposals_at_[hidden]> wrote:

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