On Thu, Jul 11, 2024 at 4:04 PM Thiago Macieira via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>

-- 
*Brian Bi*