> 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. 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.
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]ocpp.org; 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!