On Thursday 11 July 2024 12:23:17 GMT-7 Tiago Freire via Std-Proposals wrote:
> 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!

That's an optimisation and we already have that. In that case, we need no
paper. If you don't like how your compiler is implementing it, it's just QoI.

The only reason to have mandatory RVO is if the user can be sure that it's
going to happen and be told when it can't happen. It's very easy to
accidentally make NVRO impossible according to your rules when refactoring the
code. So we need a syntax to tell the compiler we want it to tell us when it
could not do it.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering