------=_Part_1804_283435731.1467595542727
Content-Type: multipart/alternative;
 boundary="----=_Part_1805_236353798.1467595542727"

------=_Part_1805_236353798.1467595542727
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

One of the biggest things I have seen in developing medium to large scale=
=20
systems is how useful const is to show the original author's intent, that=
=20
this value should not be changed, even by grabbing a mutable variable and=
=20
creating a const auto& temporary and using that temporary to state that=20
this value should stay the same.

This get's tricky when dealing with class members, especially when=20
accessing them from the outside.

Should you limit access via private and provide a Get function?
- Writing all those Get type functions can get tiring and bloats the class=
=20
with very trivial functions, even if they return a copy or a const ref.

Should you keep it public and take the python stance of "we're all adults=
=20
here"?
- Opening the access to anyone outside can later down the line introduce=20
errors if it's a value that needs to be updated in a certain way to keep=20
the internal state of the class sane.

My idea to throw out there is to suggest "const public:" or "public const:"

Any member defined after "const public:" has an automatic const qualifier=
=20
to anyone accessing the member externally.

Here is an quick example I threw together.

https://gist.github.com/olafurw/693edb5aed460cd9468d52184a406d95

This removes the need to write any get functions=20
and shows the authors intent that you can read this value as you wish but=
=20
you can't change it thus keeping the internal state sane.

Same thing can be done with protected where the child class can read but=20
not modify values of the parent without the need of extra functions.

Possible issues would be:
- Adding extra layer to the access modifiers might be unnecessary=20
complication, might think that it means that the members are const, not=20
that they are const only to the public (valid point but convention has been=
=20
to put const before the types so it might not be a big issue)
- You have to check the header file to know if a member is public or const=
=20
public (this is true and could be alleviated by naming conventions and IDE=
=20
hints, but still we should not rely on those)
- Casting away the const to get modifiable access to the member (true as=20
well but if you were providing a const Foo& GetFoo() function before then=
=20
you are open to that anyway)
- What about functions or static members defined after the "const public:"=
=20
access modifier? (they would be given the const qualifier on external=20
access as well)

Thanks for reading and I hope I was able to describe the idea clearly as=20
it's my first post :)

Cheers,
=C3=93lafur Waage
@olafurw

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/7145a8aa-6a74-4ff3-8984-4a74aef66b5d%40isocpp.or=
g.

------=_Part_1805_236353798.1467595542727
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">One of the biggest things I have seen in developing medium=
 to large scale systems is how useful const is to show the original author&=
#39;s intent, that this value should not be changed, even by grabbing a mut=
able variable and creating a const auto&amp; temporary and using that tempo=
rary to state that this value should stay the same.<div><br></div><div>This=
 get&#39;s tricky when dealing with class members, especially when accessin=
g them from the outside.</div><div><br></div><div>Should you limit access v=
ia private and provide a Get function?</div><div>- Writing all those Get ty=
pe functions can get tiring and bloats the class with very trivial function=
s, even if they return a copy or a const ref.<br></div><div><br></div><div>=
Should you keep it public and take the python stance of &quot;we&#39;re all=
 adults here&quot;?</div><div>- Opening the access to anyone outside can la=
ter down the line introduce errors if it&#39;s a value that needs to be upd=
ated in a certain way to keep the internal state of the class sane.</div><d=
iv><br></div><div>My idea to throw out there is to suggest &quot;const publ=
ic:&quot; or &quot;public const:&quot;</div><div><br></div><div>Any member =
defined after &quot;const public:&quot; has an automatic const qualifier to=
 anyone accessing the member externally.</div><div><br></div><div>Here is a=
n quick example I threw together.</div><div><br></div><div>https://gist.git=
hub.com/olafurw/693edb5aed460cd9468d52184a406d95<br></div><div><br></div><d=
iv>This removes the need to write any get functions=C2=A0</div><div>and sho=
ws the authors intent that you can read this value as you wish but you can&=
#39;t change it thus keeping the internal state sane.</div><div><br></div><=
div>Same thing can be done with protected where the child class can read bu=
t not modify values of the parent without the need of extra functions.</div=
><div><br></div><div>Possible issues would be:</div><div>- Adding extra lay=
er to the access modifiers might be unnecessary complication, might think t=
hat it means that the members are const, not that they are const only to th=
e public (valid point but convention has been to put const before the types=
 so it might not be a big issue)</div><div>- You have to check the header f=
ile to know if a member is public or const public (this is true and could b=
e alleviated by naming conventions and IDE hints, but still we should not r=
ely on those)</div><div>- Casting away the const to get modifiable access t=
o the member (true as well but if you were providing a const Foo&amp; GetFo=
o() function before then you are open to that anyway)</div><div>- What abou=
t functions or static members defined after the &quot;const public:&quot; a=
ccess modifier? (they would be given the const qualifier on external access=
 as well)</div><div><br></div><div>Thanks for reading and I hope I was able=
 to describe the idea clearly as it&#39;s my first post :)</div><div><br></=
div><div>Cheers,</div><div>=C3=93lafur Waage</div><div>@olafurw</div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7145a8aa-6a74-4ff3-8984-4a74aef66b5d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7145a8aa-6a74-4ff3-8984-4a74aef66b5d=
%40isocpp.org</a>.<br />

------=_Part_1805_236353798.1467595542727--

------=_Part_1804_283435731.1467595542727--

.

On Sun, Jul 03, 2016 at 06:25:42PM -0700, =C3=93lafur Waage wrote:
> One of the biggest things I have seen in developing medium to large scale=
=20
> systems is how useful const is to show the original author's intent, that=
=20
> this value should not be changed, even by grabbing a mutable variable and=
=20
> creating a const auto& temporary and using that temporary to state that=
=20
> this value should stay the same.
>=20
> This get's tricky when dealing with class members, especially when=20
> accessing them from the outside.
>=20
> Should you limit access via private and provide a Get function?
> - Writing all those Get type functions can get tiring and bloats the clas=
s=20
> with very trivial functions, even if they return a copy or a const ref.
>=20
> Should you keep it public and take the python stance of "we're all adults=
=20
> here"?
> - Opening the access to anyone outside can later down the line introduce=
=20
> errors if it's a value that needs to be updated in a certain way to keep=
=20
> the internal state of the class sane.

The usual reply to this question is neither.

What you should do is move the logic that need to access the value into
methods of the class so that the class becomes more self contained.
Yes, I am aware of this beeing harder to but the resulting system is genera=
lly
easier to understand since there is less coupling between different classes=
..

/MF

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/20160704042756.GA19918%40noemi.

.

On 4 July 2016 at 07:27, Magnus Fromreide <magfr@lysator.liu.se> wrote:
> On Sun, Jul 03, 2016 at 06:25:42PM -0700, =C3=93lafur Waage wrote:
>> One of the biggest things I have seen in developing medium to large scal=
e
>> systems is how useful const is to show the original author's intent, tha=
t
>> this value should not be changed, even by grabbing a mutable variable an=
d
>> creating a const auto& temporary and using that temporary to state that
>> this value should stay the same.
>>
>> This get's tricky when dealing with class members, especially when
>> accessing them from the outside.
>>
>> Should you limit access via private and provide a Get function?
>> - Writing all those Get type functions can get tiring and bloats the cla=
ss
>> with very trivial functions, even if they return a copy or a const ref.
>>
>> Should you keep it public and take the python stance of "we're all adult=
s
>> here"?
>> - Opening the access to anyone outside can later down the line introduce
>> errors if it's a value that needs to be updated in a certain way to keep
>> the internal state of the class sane.
>
> The usual reply to this question is neither.
>
> What you should do is move the logic that need to access the value into
> methods of the class so that the class becomes more self contained.
> Yes, I am aware of this beeing harder to but the resulting system is gene=
rally
> easier to understand since there is less coupling between different class=
es.


With NDSMIs, this is what I'd do:

class X
{
    string data;
public:
    const string& cdata =3D data;
};

I don't think the suggested problem is so common that we need to
invent a new kind of an access specifier
to cater for it.

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/CAFk2RUaAW%2BxPzW5ov85qD0m9Dv6nikHZd0asUG7%3D2ri=
nv3navg%40mail.gmail.com.

.

On 2016-07-04 05:52, Ville Voutilainen wrote:
> On 4 July 2016 at 07:27, Magnus Fromreide <magfr@lysator.liu.se> wrote:
>> On Sun, Jul 03, 2016 at 06:25:42PM -0700, =C3=93lafur Waage wrote:
>>> One of the biggest things I have seen in developing medium to large sca=
le
>>> systems is how useful const is to show the original author's intent, th=
at
>>> this value should not be changed, even by grabbing a mutable variable a=
nd
>>> creating a const auto& temporary and using that temporary to state that
>>> this value should stay the same.
>>>
>>> This get's tricky when dealing with class members, especially when
>>> accessing them from the outside.
>>>
>>> Should you limit access via private and provide a Get function?
>>> - Writing all those Get type functions can get tiring and bloats the cl=
ass
>>> with very trivial functions, even if they return a copy or a const ref.
>>>
>>> Should you keep it public and take the python stance of "we're all adul=
ts
>>> here"?
>>> - Opening the access to anyone outside can later down the line introduc=
e
>>> errors if it's a value that needs to be updated in a certain way to kee=
p
>>> the internal state of the class sane.
>>
>> The usual reply to this question is neither.
>>
>> What you should do is move the logic that need to access the value into
>> methods of the class so that the class becomes more self contained.
>> Yes, I am aware of this beeing harder to but the resulting system is gen=
erally
>> easier to understand since there is less coupling between different clas=
ses.
>=20
> With NDSMIs, this is what I'd do:
>=20
> class X
> {
>     string data;
> public:
>     const string& cdata =3D data;
> };
>=20
> I don't think the suggested problem is so common that we need to
> invent a new kind of an access specifier
> to cater for it.

Actually, properties would be great here; provide a public get but no
set. The problem with the above is that it increases the size of the
class. The most recent iteration of "properties", involving inner
classes and zero-size members, would solve this.

--=20
Matthew

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/nldt3m%24onh%241%40ger.gmane.org.

.

On segunda-feira, 4 de julho de 2016 12:52:41 PDT Ville Voutilainen wrote:
> With NDSMIs, this is what I'd do:
>
> class X
> {
>     string data;
> public:
>     const string& cdata = data;
> };
>
> I don't think the suggested problem is so common that we need to
> invent a new kind of an access specifier
> to cater for it.

What is the size of class X? Is it the same as class Y

class Y
{
 string data;
public:
 string cdata() const { return data; }
};

If it isn't guaranteed to be so by the standard in all implementations, then I
can't use your syntax to replace Y with X.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/12871812.eFz8c1onGI%40tjmaciei-mobl1.

.