The rules are so complicated that a refactoring could miss it, without everybody involved thinking hard of it.   So it makes sense to explicitly mark every instance, where code relies (wants) NRVO and give no guarantee for NRVO on purpose, when the code is not explicitly marked. Perhaps even disallow NRVO, if the code is not explicitly marked.   Otherwise some programmers rely on it, and NRVO vanishes during refactorings.   It is a teaching topic, a topic about language complexity.   Correctness could beat performance here. (You still get performance with code verbosity.)     std::factory is one way to explicitly mark it and relegate it to a closed construct without a core language change.   It is different enough that people could clearly mark, where they want NRVO.       -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 11.07.2024 22:55 Betreff:Re: [std-proposals] Stop gap required for NRVO until Anton‘s paper is assimilated An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; My question is, if it could nrvo why would you stop it? Telling it that it could nrvo is useless if the compiler cannot figure out how to do it. And if it can figure out how to do it, why would you not want it to? You can not force the compiler to magically do it because you annotated it. The rules on when it can do it are unchanged regardless of how you annotate it. Telling it that it could, but not when it could is just going to lead to different compilers deciding on different rules on how to do it, making code not portable. But if you have the rules, there's no need to tell it, why shouldn’t you get that optimization by default? -----Original Message----- From: Std-Proposals <std-proposals-bounces_at_[hidden]> On Behalf Of Jason McKesson via Std-Proposals Sent: Thursday, July 11, 2024 22:41 To: std-proposals_at_[hidden] Cc: Jason McKesson <jmckesson_at_[hidden]> Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated On Thu, Jul 11, 2024 at 4:34 PM Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> wrote: > > > 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. Think about it like this: who is it that actually *care* about NRVO? If I'm writing code and I don't care about whether NRVO is happening in that code, then... I don't need a change to the standard. My code does not rely on NRVO, so while I might *prefer* it, I don't need the standard to *enforce* it. If I'm writing code which by its nature *requires* NRVO, then I need to enforce it. I *need* to use that "annotation to tell you if it did", because I actually care about it happening. So why not tie that "annotation to tell you if it did" to the actual enforcement rules of the compiler? Why not leave it as an optimization unless the person uses the annotation? -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals