Date: Thu, 11 Jul 2024 23:04:14 +0000
I think we are just talking different things, and want different things.
> We're asking for a syntax to make it either ill-formed or at least a diagnostic when the syntax is used and NRVO is not permitted.
What you want is a way to markup where you would expect nrvo but you might not get it.
I.e. Like the attribute suggested by Arthur O'Dwyer: https://godbolt.org/z/fcK1b46c1
I agree with this 100%, it should be a thing, as long as it doesn't affect code generation. It warns you, even stops the compiler from compiling, but doesn't change how the code gets generated.
Which is different from Aton's paper, that extends nrvo rules and changes how the code gets generated with no annotations required.
Which is something that I also want, and I'm arguing it is how it should be done. But you are not interested in that.
This in itself is different from std::factory as proposed by Sebastian, which only exists because someone wants to change data before returning an object and still guarantee nrvo.
Which in itself requires an extension of the nrvo, but doesn't tell you what.
Neither of us wants this.
Staying on topic. std::factory was proposed, and I disagree with it being needed, because Aton's solution is better and is the way the problem should be solved.
The attribute is a good idea, but off topic.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]socpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Friday, July 12, 2024 00:26
To: std-proposals_at_lists.isocpp.org
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated
On Thursday 11 July 2024 13:55:05 GMT-7 Tiago Freire via Std-Proposals wrote:
> 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?
No one is asking that. You're reading too much into the request and came up with a corollary that doesn't follow.
We're asking for a syntax to make it either ill-formed or at least a diagnostic when the syntax is used and NRVO is not permitted. The corollary of that is if NRVO is not permitted and you don't mark it, nothing changes.
> 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.
Agreed. We need to have some rules so code can rely on them.
> But if you have the rules, there's no need to tell it, why shouldn’t
> you get that optimization by default?
See other replies, especially Sebastian's.
--
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
> We're asking for a syntax to make it either ill-formed or at least a diagnostic when the syntax is used and NRVO is not permitted.
What you want is a way to markup where you would expect nrvo but you might not get it.
I.e. Like the attribute suggested by Arthur O'Dwyer: https://godbolt.org/z/fcK1b46c1
I agree with this 100%, it should be a thing, as long as it doesn't affect code generation. It warns you, even stops the compiler from compiling, but doesn't change how the code gets generated.
Which is different from Aton's paper, that extends nrvo rules and changes how the code gets generated with no annotations required.
Which is something that I also want, and I'm arguing it is how it should be done. But you are not interested in that.
This in itself is different from std::factory as proposed by Sebastian, which only exists because someone wants to change data before returning an object and still guarantee nrvo.
Which in itself requires an extension of the nrvo, but doesn't tell you what.
Neither of us wants this.
Staying on topic. std::factory was proposed, and I disagree with it being needed, because Aton's solution is better and is the way the problem should be solved.
The attribute is a good idea, but off topic.
-----Original Message-----
From: Std-Proposals <std-proposals-bounces_at_[hidden]socpp.org> On Behalf Of Thiago Macieira via Std-Proposals
Sent: Friday, July 12, 2024 00:26
To: std-proposals_at_lists.isocpp.org
Cc: Thiago Macieira <thiago_at_[hidden]>
Subject: Re: [std-proposals] Stop gap required for NRVO until Anton's paper is assimilated
On Thursday 11 July 2024 13:55:05 GMT-7 Tiago Freire via Std-Proposals wrote:
> 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?
No one is asking that. You're reading too much into the request and came up with a corollary that doesn't follow.
We're asking for a syntax to make it either ill-formed or at least a diagnostic when the syntax is used and NRVO is not permitted. The corollary of that is if NRVO is not permitted and you don't mark it, nothing changes.
> 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.
Agreed. We need to have some rules so code can rely on them.
> But if you have the rules, there's no need to tell it, why shouldn’t
> you get that optimization by default?
See other replies, especially Sebastian's.
--
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
Received on 2024-07-11 23:04:20