TBH, both of those look like code that could be really easily diagnosed and
thus should be ill-formed.

On Sun, 19 May 2024 at 16:43, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sun, May 19, 2024 at 9:28 PM Frederick Virchanza Gotham wrote:
> >
> > A less-ambitious alternative would be to
> > allow something like:
> >
> > mutex Func(void)
> > {
> > auto &m = _Retvar{};
> > m.lock();
> > return _Retvar;
> > }
> >
> > I propose that the operator "_Retvar" can only be used in a function
> > that returns by value. Its job is to create an object of the return
> > type, and it returns a reference to the new object. Then later you
> > just write "return _Retvar" to return from the function.
>
>
> Furthermore, to make it easier for the people writing the Standard,
> and to make it easier for compiler vendors, just dictate that it's
> undefined behaviour to use _Retvar incorrectly. Here are a few
> examples of incorrect usage:
>
> ----- Incorrect Usage No. 1:
>
> mutex Func(void)
> {
> auto &m = _Retvar{};
> m.lock();
> return mutex(); // oops, can't do this
> }
>
> ----- Incorrect Usage No. 2:
>
> mutex Func(int const a)
> {
> auto &m = _Retvar{};
> auto &m2 = _Retvar{}; // oops, can't do this
> m.lock();
> return _Retvar;
> }
>
> The job of the standard-writer and the compiler-writer is made a lot
> easier by stipulating that incorrect use of _Retvar results in
> undefined behaviour.
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>