I disagree. I think the "need to explore" other solution such as an "explicit syntax" is just part of due diligence, not an outright rejection of this particular solution.
It doesn't mean that this will not be the solution.
IMO, it has to be the solution, I wouldn't accept anything else.
Annotating something to use nrvo doesn't automatically mean that nrvo is possible. How the function is written is what decides that.
Annotation would only make sense if you had 2 equally likely nrvo candidates and you have to decide one over the other and they can not both be nrvo, for that to happen they would need to have an overlapping life-time when returned with 2 return statements returning different things thus preventing both from being nrvo.

The compiler must be able to do it without being told. It has to be that solution!


-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_lists.isocpp.org> On Behalf Of Jason McKesson via Std-Proposals
Sent: Thursday, July 11, 2024 18:22
To: std-proposals_at_lists.isocpp.org
Cc: Jason McKesson <jmckesson_at_gmail.com>
Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated

On Thu, Jul 11, 2024 at 12:13 PM Tiago Freire via Std-Proposals <std-proposals_at_lists.isocpp.org> wrote:
>
> The way I see it, any other solution that is not achieving guaranteed nrvo extensions without any additional markings (this includes functions) is a waste of time.
>
> What you need is quite simple.
> Any named variable X that is returned should guarantee nrvo unless a return statement exist that does not return X and X is alive.
>
> I'm perfectly confident that the solution is this, and that this is implementable.
> Everything else is just adds clutter to the language and is an automatic no from my part.

OK, but... that's what version 1 of P2025 was, and the committee was pretty clear:

> This paper should explore an explicit syntax to opt-into this functionality:
>
> SF: 6, F: 10, N: 3, A: 1, SA: 3
>
> Conclusion: This paper needs to explore an explicit opt-in syntax and return to EWG.

So as far as the committee is concerned, your idea was considered and rejected.
--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals