> 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.

I agree with having a gadget to be able to tell you "when it cannot do it". But that's a different thing from having a gadget that tells it that "it must do it" or "to what to do it too".
Warning that it didn't do it when you expect it too. Is a different thing from adding a rule as to when it must do it.
The doing it part should require no annotation. You can have an annotation to tell you if it did.


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

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



--
Std-Proposals mailing list
Std-Proposals_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals