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
It's also to force the compiler to accept the code even when the return type is not movable---which is the use case that Frederick is targeting.
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
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals