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

What's the usage scenario you have in mind? The initial example from the
thread looks like it suffers from the same type of ergonomic constraint
that keeps me from using monadic functions more frequently, which doesn't
require that sort of complexity... I have to agree with the others who
compared that form of the proposal with exceptions, it's hard to reason
about control flow in the presence of something like that.

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

> -----Ursprüngliche Nachricht-----
> *Von:* Andre Kostur via Std-Proposals <std-proposals_at_[hidden]>
>
>
>
> >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.
>
>
>
>
>
> Then why not create a special command to invoke the callable.
>
> The caller can decide, whether to use this command or not..
>
>
>
>
>
> OTOH should this work the same as exceptions?
>
> Why not use the same or similar language constructs?
>
> Probably the in-between functions need to know more about, which
> exceptions can be thrown.
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>