Date: Thu, 11 Jul 2024 20:55:05 +0000
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]rg> On Behalf Of Jason McKesson via Std-Proposals
Sent: Thursday, July 11, 2024 22:41
To: std-proposals_at_[hidden]ocpp.org
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_lists.isocpp.org> 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_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
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]rg> On Behalf Of Jason McKesson via Std-Proposals
Sent: Thursday, July 11, 2024 22:41
To: std-proposals_at_[hidden]ocpp.org
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_lists.isocpp.org> 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_lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2024-07-11 20:55:07