Hi Tiago,   > It depends on a feature that doesn’t exist in the language.   std::factory was implemented with the operator trick here, so the feature exists: http://www.virjacode.com/papers/factory.htm#implementation     > The feature is useful, the function by itself is not.   Can you give specific use cases not solved by the library features? Or you just generally want the possibility of general NRVO in functions with broad applicability?     > std::factory will not fix it, it actually requires part of it to be solved to begin with. So that problem needs to be solved independently.   std::factory is easily implemented (by the compilers). The rules are simple. There are no special cases. General NRVO, as you would like it, or P2025 specifies it, would be much more involved.     > Solve nrvo, and there’s a paper that does, and std::factory is completely unnecessary.   True. General NRVO could be done instead.      - One solution with general NRVO is to have complicated rules similar to the current P2025, which probably will not get consensus.    - Another solution is to keep NRVO implementation-defined (similar to the current standard), but introduce a mark or attribute that you rely on NRVO in a specific case and generate an error, if it is not applied, as Thiago wrote. To keep C++ code compatible, all compilers should then be able to do NRVO, when the rules are met, or at least with the that mark on demand.   Best, Sebastian     -----Ursprüngliche Nachricht----- Von:Tiago Freire <tmiguelf_at_[hidden]> Gesendet:Fr 12.07.2024 00:33 Betreff:RE: [std-proposals] Stop gap required for NRVO until Anton‘s paper is assimilated An:Sebastian Wittmeier <wittmeier_at_[hidden]>; std-proposals_at_[hidden];   > Not sure, where your strong disagreement comes from. Hoping for a different solution instead? Not liking the syntax?   It depends on a feature that doesn’t exist in the language. The feature is useful, the function by itself is not.     > Hasn't Frederik solved it except for constexpr'ness?   No. A class that optionally nrvo will never be a guaranteed nrvo. You can’t do it by just writing a function on existing code, you need something that doesn’t yet exist to do it.     > 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.   Let’s say you do this. std::factory would not help addressing the issues of where you would want nrvo and you can’t. cSo that problem needs to be solved independently. Solve nrvo, and there’s a paper that does, and std::factory is completely unnecessary. There’s a better solution, and std::factory is obsolete before it even came out.   That’s it.     From: Sebastian Wittmeier <wittmeier_at_[hidden]> Sent: Thursday, July 11, 2024 23:45 To: std-proposals_at_[hidden]; Tiago Freire <tmiguelf_at_[hidden]> Subject: AW: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated   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] <mailto: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] <mailto:std-proposals_at_[hidden]> ; CC: Sebastian Wittmeier <wittmeier_at_[hidden] <mailto: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!