Date: Wed, 15 Jan 2020 05:40:48 +0530
On Wed, Jan 15, 2020, at 12:47 AM, Thiago Macieira via Std-Proposals wrote:
> On Monday, 13 January 2020 20:06:48 PST connor horman via Std-Proposals wrote:
> > I’d recommend having read/write properties return a reference, and
> > potentially having read properties return a const reference, and otherwise
> > be similar to methods (cv-qualifiers, ref-qualifiers, etc)
>
> So long as that's a recommendation, not required, that's fine.
>
> Because I recommend property getters always return by value, never a
> reference. That allows you to change the internal implementation to hold
> something different.
>
I strongly support this, and would recommend against any syntax that doesn't make such changes to implementation easyt.
Today I want to store radius, next year I may discover circumference has some advantage in my application. Proposals that require me to actually have the member in question are thus suspect because they limit my future self. Thus I think C++ code guidelines should adopt a don't use it rule for any syntax that doesn't allow such changes. Most of the time it won't matter, but pitty the poor programmer who made the wrong choice and need to change thousands of x=c.x to x=c.getx(), (particularly if tools fail to work for whatever reason)
> On Monday, 13 January 2020 20:06:48 PST connor horman via Std-Proposals wrote:
> > I’d recommend having read/write properties return a reference, and
> > potentially having read properties return a const reference, and otherwise
> > be similar to methods (cv-qualifiers, ref-qualifiers, etc)
>
> So long as that's a recommendation, not required, that's fine.
>
> Because I recommend property getters always return by value, never a
> reference. That allows you to change the internal implementation to hold
> something different.
>
I strongly support this, and would recommend against any syntax that doesn't make such changes to implementation easyt.
Today I want to store radius, next year I may discover circumference has some advantage in my application. Proposals that require me to actually have the member in question are thus suspect because they limit my future self. Thus I think C++ code guidelines should adopt a don't use it rule for any syntax that doesn't allow such changes. Most of the time it won't matter, but pitty the poor programmer who made the wrong choice and need to change thousands of x=c.x to x=c.getx(), (particularly if tools fail to work for whatever reason)
Received on 2020-01-14 18:13:41