Hi Tiago,     Not sure, where your strong disagreement comes from. Hoping for a different solution instead? Not liking the syntax?     > You will not be able to write std::factory without adding to the compiler something akin to a core addition   Hasn't Frederik solved it except for constexpr'ness?     > and it will not be able to figure out when it could nrvo any better than what it does now.   Are you still talking here about the std::factory implementation or about functions, where NRVO is currently optional (or currently not possible/allowed?)?     > It is essentially trying to masquerade a core change as a library function, and worse without defining the rules of what that language feature is and how it would work.   There are several standard library functions, which cannot be fully implemented in user code. One of the many feedbacks, Frederick gets for his proposals is that he should just define the result, not try to do implementations. It is an advantage that there is no rule for recreating a full (with constexpr or in a simple way without operators) implementation. One less core language change needed. All uses of that facility have a standard syntax (calling std::factory). As long as its effect of NRVO is defined, no further details are needed, as long as it is not meant to be replicated in user code.     > The rules would be no less complicated just because you gave it a name, but you expect compiler vendors to figure > it out by themselves what those rules should be without telling them.   compiler vendors would not have to create rules or figure anything out, they would just have to special-case the simple case of std::factory. It would either be not implemented in normal C++ at all or use implementation-defined/internal features as do lots of other standard library functions.   Best, Sebastian     -----Ursprüngliche Nachricht----- Von:Tiago Freire <tmiguelf_at_[hidden]> Gesendet:Do 11.07.2024 23:15 Betreff:RE: [std-proposals] Stop gap required for NRVO until Anton‘s paper is assimilated An:std-proposals_at_[hidden]; CC:Sebastian Wittmeier <wittmeier_at_[hidden]>; > std::factory is one way to explicitly mark it and relegate it to a closed construct without a core language change.   I fundamentally disagree with this.   You will not be able to write std::factory without adding to the compiler something akin to a core addition, and it will not be able to figure out when it could nrvo any better than what it does now. It is essentially trying to masquerade a core change as a library function, and worse without defining the rules of what that language feature is and how it would work.   The rules would be no less complicated just because you gave it a name, but you expect compiler vendors to figure it out by themselves what those rules should be without telling them. That’s a big no!