------=_Part_2132_31054517.1401996233760
Content-Type: text/plain; charset=UTF-8

I know this has been discussed many times before with blocked results; but
I truly feel if C++ is going to continue outstanding support and popularity
into the future it needs to offer the basic idea of a "property".  There
are many benefits to properties and the only arguments against them are
ideological from a don't want to change point of view.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I know this has been discussed many times before with bloc=
ked results; but I truly feel if C++ is going to continue outstanding suppo=
rt and popularity into the future it needs to offer the basic idea of a "pr=
operty".&nbsp; There are many benefits to properties and the only arguments=
 against them are ideological from a don't want to change point of view.<br=
></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2132_31054517.1401996233760--

.

Em qui 05 jun 2014, =E0s 12:23:53, tgit28@gmail.com escreveu:
> I know this has been discussed many times before with blocked results; bu=
t=20
> I truly feel if C++ is going to continue outstanding support and populari=
ty=20
> into the future it needs to offer the basic idea of a "property".  There
> are many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.

I think you're generalising the problems and completely dismissing the vali=
d=20
concerns raised. Your post above does not help improve the introduction of=
=20
properties into the language.

If you want to do that, write a proposal that provides the syntax and=20
mechanics of how properties would work. In that proposal, make sure you=20
address most of the concerns that people have raised.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_5_22338962.1402001093211
Content-Type: text/plain; charset=UTF-8

There's a lot and love and hate about properties. I think you're very wrong
to write off the arguments against them so simply.

But since people do call for properties quite often, to entertain the idea
for a bit, how about:

// Map assignment to any unknown member x into a function call to member
set_x
// Map references to any unknown member x into a function named get_x

// Mapping could be done by default or opt/in out by prefix/pattern or
individually.

// Example assume a default mapping.
class X
{
public:
    void set_x(int x);
    int get_x();
};

X x;
x.x = 100; // becomes x.set_x(100)
auto x = x.x; // becomes x = x.get_x();

// Allow explicit mapping
class X
{
public:
    void SetY(int x) get(y); // alias y
    int GetY() set(y); // alias y
};

x.y = 100; // becomes x.SetY(100)
auto y = x.y; // becomes x = x.GetY();


// Lots of potential issues to overcome, but that's the basic idea.


If this could work, perhaps existing code bases could be extended to
support properties, some possibly fairly trivially.


On Friday, June 6, 2014 7:23:53 AM UTC+12, tgi...@gmail.com wrote:
>
> I know this has been discussed many times before with blocked results; but
> I truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property".  There
> are many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>There's a lot&nbsp;and love and hate about properties=
.. I&nbsp;think you're&nbsp;very wrong to write off&nbsp;the arguments again=
st&nbsp;them so simply.</div><div><br></div><div>But since people do call f=
or properties quite often, to entertain the idea for a bit, how about:</div=
><div><br>// Map assignment to any unknown member x into a function call to=
 member set_x<br>// Map references to any unknown member x into a function =
named get_x</div><div><br></div><div>// Mapping could be&nbsp;done by defau=
lt or opt/in out by prefix/pattern or individually.</div><div><br></div><di=
v>// Example assume a default mapping.<br>class X<br>{</div><div>public:<br=
>&nbsp;&nbsp;&nbsp; void set_x(int x);<br>&nbsp;&nbsp;&nbsp; int get_x();<b=
r>};</div><div><br></div><div>X x;<br>x.x =3D 100; // becomes x.set_x(100)<=
br>auto x =3D x.x; // becomes x =3D x.get_x();</div><div><br>// Allow expli=
cit mapping</div><div>class X<br>{<br>public:<br>&nbsp;&nbsp;&nbsp; void Se=
tY(int x) get(y); // alias y<br>&nbsp;&nbsp;&nbsp; int GetY() set(y); // al=
ias y<br>};</div><div><br>x.y =3D 100; // becomes x.SetY(100)<br>auto y =3D=
 x.y; // becomes x =3D x.GetY();</div><div><br></div><div><br></div><div>//=
 Lots of potential issues to overcome, but that's the basic idea.</div><div=
><br></div><div><br></div><div>If this could work, perhaps existing code ba=
ses could be extended to support properties, some possibly fairly trivially=
..</div><br><br>On Friday, June 6, 2014 7:23:53 AM UTC+12, tgi...@gmail.com =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex;=
 padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-widt=
h: 1px; border-left-style: solid;"><div dir=3D"ltr">I know this has been di=
scussed many times before with blocked results; but I truly feel if C++ is =
going to continue outstanding support and popularity into the future it nee=
ds to offer the basic idea of a "property".&nbsp; There are many benefits t=
o properties and the only arguments against them are ideological from a don=
't want to change point of view.<br></div></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5_22338962.1402001093211--

.

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


I=C2=B4m concerned about this for a while, and since someone touched the=20
subject, let-me share few thoughts about what is wanted from properties:


1 - rule of "assignment" : given a object x from a class X that has a=20
property p of type P, one should be able to attribute to x.p:

P z;
X x;
x.p =3D z;

2 - rule of "expression" : given a object x from a class X that has a=20
property p of type P, one should be able to use x.p in any context where an=
=20
expression of type Z is possible to appear:

P z;
X x;
z =3D x.p;

3 - rule of "underline value": given a object x from a class X that has a=
=20
property p of type P, the value of p has outside of class X may be=20
calculated at the time of use, and may or may not have a representation=20
inside X;

4 - rule of "notification" : for every "assignment" or "use in an=20
expression", a function (member or not) may be called to set or get the=20
underline value of it.

5 - rule of "array" : given a object x from a class X that has an array=20
property p of type P and a independent object q of type Q, one may write=20
assignment and expressions using element q of x.p
P z1, z2;
X x;
Q q;
....
z1 =3D x.p[q];
x.p[q] =3D z2;

6 - rule of "default" : given a object x from a class X that has a (at most=
=20
one) default property p of type P, one may omit it=C2=B4s the name of the=
=20
property p in it=C2=B4s use ( this i think may be achieved using just cast=
=20
operators )

P z;
X x;
Q q;
....
x.p =3D z; // is the same as=20
x =3D z;   // because p is a default property


and try not use any other keyword like @property or __property or prop. :)



=20

> If you want to do that, write a proposal that provides the syntax and=20
> mechanics of how properties would work.=20

=20
With the help of community I might do that in a near future.



--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div><br></div><div>I=C2=B4m concerned about this for a wh=
ile, and since someone touched the subject, let-me share few thoughts about=
 what is wanted from properties:</div><div><br></div><div><br></div><div>1 =
- rule of "assignment" : given a object x from a class X that has a propert=
y p of type P, one should be able to attribute to x.p:<br></div><div><br></=
div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187=
, 187); word-wrap: break-word; background-color: rgb(250, 250, 250);"><code=
 class=3D"prettyprint"><div class=3D"subprettyprint"><font color=3D"#660066=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">P z</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>X x</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br>x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">p </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an></font></div></code></div><br><div>2 - rule of "expression" : given a ob=
ject x from a class X that has a property p of type P, one should be able t=
o use x.p in any context where an expression of type Z is possible to appea=
r:</div></div><div><br></div><div><div class=3D"prettyprint" style=3D"borde=
r: 1px solid rgb(187, 187, 187); word-wrap: break-word; background-color: r=
gb(250, 250, 250);"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #000;" class=3D"styled-by-prettify">P z</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>X x</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>z </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify">p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span></div></code></div><br><div>3 - rule of "underline value": given a ob=
ject x from a class X that has a property p of type P, the value of p has o=
utside of class X may be calculated at the time of use, and may or may not =
have a representation inside X;</div><div><br></div>4 - rule of "notificati=
on" : for every "assignment" or "use in an expression", a function (member =
or not) may be called to set or get the underline value of it.</div><div><b=
r></div><div>5 - rule of "array" : given a object x from a class X that has=
 an array property p of type P and a independent object q of type Q, one ma=
y write assignment and expressions using element q of x.p</div><div><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; background-color: rgb(250, 250, 250);"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">P z1</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> z2</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>X x</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>Q q</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>z1 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
p</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">q</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">];</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>x</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">p</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">[</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">q</span><span style=3D"color: #660;" class=3D"styled-by-prettify">]=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> z2</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div></div><div><=
br></div><div>6 - rule of "default" : given a object x from a class X that =
has a (at most one) default property p of type P, one may omit it=C2=B4s th=
e name of the property p in it=C2=B4s use&nbsp;( this i think may be achiev=
ed using just cast operators )</div><div><br></div><div><div class=3D"prett=
yprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-wor=
d; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">P z</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>X x<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br>Q q</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>x</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">p </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> z</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">// is the same as </span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>x </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> z</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> &nbsp; </span><span style=3D"color: #800;" c=
lass=3D"styled-by-prettify">// because p is a default property</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code=
></div><br><br></div><div>and try not use any other keyword like @property =
or __property or prop. :)<br></div><div><br></div><div><br></div><div><br><=
/div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If you w=
ant to do that, write a proposal that provides the syntax and=20
<br>mechanics of how properties would work.&nbsp;</blockquote><div>&nbsp;</=
div><div>With the help of community I might do that in a near future.</div>=
<div><br></div><div><br></div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1438_19624696.1402001381403--

.

------=_Part_36_30897528.1402002274285
Content-Type: text/plain; charset=UTF-8

Yes as many have posted while I've written this the general idea is well
known.
If ( Object.Property == 34) { something } //Retrieve and compare value vs.
Object.Property = 34   //Set the attribute.

As for valid concerns I've have read; mostly composed of looped logic.

1) Knowing if something is being processed before setting the actual value.
OOP objects should work abstractly.  There shouldn't be direct access to
internal variables and validation should occur when making "settings" to
the object w/o having to validate outside the object.  If in the slightest
bad case scenario one was to set a variable directly it should have syntax
on the direct setting and not the interface (IE. Object.DirectVariable vs
Object.Property).  I consider the first bad practice.  Think of this as a
real physical object.  Does a car allow a rotation of 1200-degrees on the
steering wheel?  It has limits applied directly on the wheel (human
interface) itself.  From an abstraction level the idea that one can rotate
a tire on the ground 1200-degrees doesn't seem like a legitimate concern
for standard use interfaces.

2) Properties encourage a re-active scenario where an application re-acts
to a property setting vs being told to re-act
This seems like looped logic.  Whether it be a property setting or a
function call the application should re-act to changes.  That is what makes
applications useful.  An application that "does" automatically what it
needs to is what makes OOP applications powerful.

3) setters/getters does this.
Yes it does do the exact same thing except it doubles and clutters the API
for no-known good reason.  Typical usage on set/get in C++ is
Object.setField(3) and Object.getField().  Properties not only simplify
this general case scenario (settings a single value to a single setting)
but also from my perspective make single argument settings more readable as
we know this same syntax is used on base data type settings.

Consider the following

using Person;
   Name = "John Doe"l
   Address = "Johns Road";

vs

using Person;
   setName("John Doe");
   setAddress("Johns Road");

I feel the gets/set syntax is over kill in single attribute/value settings
and makes items less legible as well as clutters the API.  That's all there
is to my proposal.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div style=3D"opacity: 0.5;" class=3D"GKA2MROCBUB" id=3D"p=
-b-0">Yes as many have posted while I've written this the general idea is w=
ell known.<br>If ( Object.Property =3D=3D 34) { something } //Retrieve and =
compare value vs.<br>Object.Property =3D 34&nbsp;&nbsp; //Set the attribute=
..<br><br>As for valid concerns I've have read; mostly composed of looped lo=
gic.<br><br>1) Knowing if something is being processed before setting the a=
ctual value.<br>OOP
 objects should work abstractly.&nbsp; There shouldn't be direct access to=
=20
internal variables and validation should occur when making "settings" to
 the object w/o having to validate outside the object.&nbsp; If in the=20
slightest bad case scenario one was to set a variable directly it should
 have syntax on the direct setting and not the interface (IE.=20
Object.DirectVariable vs Object.Property).&nbsp; I consider the first bad=
=20
practice.&nbsp; Think of this as a real physical object.&nbsp; Does a car a=
llow a=20
rotation of 1200-degrees on the steering wheel?&nbsp; It has limits applied=
=20
directly on the wheel (human interface) itself.&nbsp; From an abstraction=
=20
level the idea that one can rotate a tire on the ground 1200-degrees=20
doesn't seem like a legitimate concern for standard use interfaces.<br><br>=
2) Properties encourage a re-active scenario where an application re-acts t=
o a property setting vs being told to re-act<br>This
 seems like looped logic.&nbsp; Whether it be a property setting or a=20
function call the application should re-act to changes.&nbsp; That is what=
=20
makes applications useful.&nbsp; An application that "does" automatically=
=20
what it needs to is what makes OOP applications powerful.<br><br>3) setters=
/getters does this.<br>Yes
 it does do the exact same thing except it doubles and clutters the API=20
for no-known good reason.&nbsp; Typical usage on set/get in C++ is=20
Object.setField(3) and Object.getField().&nbsp; Properties not only simplif=
y=20
this general case scenario (settings a single value to a single setting)
 but also from my perspective make single argument settings more=20
readable as we know this same syntax is used on base data type settings.<br=
><br>Consider the following<br><br>using Person;<br>&nbsp;&nbsp; Name =3D "=
John Doe"l<br>&nbsp;&nbsp; Address =3D "Johns Road";<br><br>vs<br><br>using=
 Person;<br>&nbsp;&nbsp; setName("John Doe");<br>&nbsp;&nbsp; setAddress("J=
ohns Road");<br><br>I feel the gets/set syntax is over kill in single attri=
bute/value settings and makes items less legible as well as clutters the AP=
I.&nbsp; That's all there is to my proposal.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_36_30897528.1402002274285--

.

--001a11c32c5654af1e04fb2300c9
Content-Type: text/plain; charset=UTF-8

In C#, the core language feature called Properties works as follows:

class TimePeriod
{
    private double seconds;

    public double Hours
    {
        get { return seconds / 3600; }
        set { seconds = value * 3600; }
    }
}


We already have this in C++:

class TimePeriod
{
    double seconds;

public:

   struct {
       operator double() { return seconds / 3600; }
       void operator=(double value) { seconds = value * 3600; }
   } Hours;
};

In Java, Properties are a standard library feature which we can also
replicate even easier.

So please give us an example of a language that offers "the basic idea of a
"property"".  As far as I can see, properties are already a feature of C++.


On Thu, Jun 5, 2014 at 9:23 PM, <tgit28@gmail.com> wrote:

> I know this has been discussed many times before with blocked results; but
> I truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property".  There
> are many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c32c5654af1e04fb2300c9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">In C#, the core language feature called Properties works a=
s follows:<div><br></div><div><pre style=3D"padding:5px;margin-top:0px;marg=
in-bottom:0px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);font-size:13p=
x;line-height:17.549999237060547px;font-family:Consolas,Courier,monospace!i=
mportant">
<span style=3D"color:blue">class</span> TimePeriod
{
    <span style=3D"color:blue">private</span>=C2=A0<span style=3D"color:blu=
e">double</span> seconds;

    <span style=3D"color:blue">public</span>=C2=A0<span style=3D"color:blue=
">double</span> Hours
    {
        <span style=3D"color:blue">get</span> { <span style=3D"color:blue">=
return</span> seconds / 3600; }
        <span style=3D"color:blue">set</span> { seconds =3D value * 3600; }
    }
}
</pre><div><br></div><div>We already have this in C++:</div><div><br></div>=
<div>class TimePeriod</div><div>{</div><div>=C2=A0 =C2=A0 double seconds;</=
div><div><br></div><div>public:</div><div><br></div><div>=C2=A0 =C2=A0struc=
t {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0operator double() { return seconds=
 / 3600; }</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0void operator=3D(double value) { seconds =
=3D value * 3600; }</div><div>=C2=A0 =C2=A0} Hours;</div><div>};</div><div>=
<br></div><div>In Java, Properties are a standard library feature which we =
can also replicate even easier.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So please g=
ive us an example of a language that offers &quot;the basic idea of a &quot=
;property&quot;&quot;. =C2=A0As far as I can see, properties are already a =
feature of C++.</div>
<div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu, Jun 5=
, 2014 at 9:23 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:tgit28@gmail.co=
m" target=3D"_blank">tgit28@gmail.com</a>&gt;</span> wrote:<br><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1=
px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:=
1ex">
<div dir=3D"ltr">I know this has been discussed many times before with bloc=
ked results; but I truly feel if C++ is going to continue outstanding suppo=
rt and popularity into the future it needs to offer the basic idea of a &qu=
ot;property&quot;.=C2=A0 There are many benefits to properties and the only=
 arguments against them are ideological from a don&#39;t want to change poi=
nt of view.<span class=3D""><font color=3D"#888888"><br>
</font></span></div><span class=3D""><font color=3D"#888888">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></blockquote></div><br></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c32c5654af1e04fb2300c9--

.

Am 06.06.2014 06:07, schrieb Andrew Tomazos:
> We already have this in C++:
>
> class TimePeriod
> {
>     double seconds;
>
> public:
>
>    struct {
>        operator double() { return seconds / 3600; }
>        void operator=(double value) { seconds = value * 3600; }
>    } Hours;
> };
>
>
This will not compile as the nested struct cannot access non-static
members of its enclosing type.

Miro

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b3a9b583d987a04fb233a3d
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 6, 2014 at 6:13 AM, Miro Knejp <miro@knejp.de> wrote:

>
> Am 06.06.2014 06:07, schrieb Andrew Tomazos:
>
>  We already have this in C++:
>>
>> class TimePeriod
>> {
>>     double seconds;
>>
>> public:
>>
>>    struct {
>>        operator double() { return seconds / 3600; }
>>        void operator=(double value) { seconds = value * 3600; }
>>    } Hours;
>> };
>>
>>
>>  This will not compile as the nested struct cannot access non-static
> members of its enclosing type.
>
>
Yes, you're right of course.  You need to store the this pointer in the
Hours object and make it a friend.  A little more boilerplate and maybe a
little less efficient than what the compiler could do for you - but I still
argue we basically have properties.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b3a9b583d987a04fb233a3d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jun 6, 2014 at 6:13 AM, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:miro@knejp.de" target=3D"_blank">miro@knejp.de</a>&gt;</span> wrote:<br=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">
<br>
Am 06.06.2014 06:07, schrieb Andrew Tomazos:<div class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">
We already have this in C++:<br>
<br>
class TimePeriod<br>
{<br>
=C2=A0 =C2=A0 double seconds;<br>
<br>
public:<br>
<br>
=C2=A0 =C2=A0struct {<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0operator double() { return seconds / 3600; }<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0void operator=3D(double value) { seconds =3D val=
ue * 3600; }<br>
=C2=A0 =C2=A0} Hours;<br>
};<br>
<br>
<br>
</blockquote></div>
This will not compile as the nested struct cannot access non-static members=
 of its enclosing type.<br><span class=3D""><font color=3D"#888888"><br></f=
ont></span></blockquote><div><br></div><div>Yes, you&#39;re right of course=
.. =C2=A0You need to store the this pointer in the Hours object and make it =
a friend. =C2=A0A little more boilerplate and maybe a little less efficient=
 than what the compiler could do for you - but I still argue we basically h=
ave properties.</div>
<div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><br></=
div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a9b583d987a04fb233a3d--

.

Am 06.06.2014 06:23, schrieb Andrew Tomazos:
> (...) A little more boilerplate and maybe a little less efficient than
> what the compiler could do for you (...)
>
To me this statement is an indication that maybe language support might
be worth considering, as a portable "zero cost" library solution is not
possible for something that could be done with no overhead by the
compiler. That being said I'm myself not sure whether properties in
general are a good idea as something that looks like an innocent member
access could be hiding an expensive operation without the user being
aware of its implication. The function call syntax at least makes the
reader aware that "something's possibly happening". And that being said
I can't remember how many times I wished I could give a member variable
public read access without having to boilerplate a getter every time.
I'm really not sure on which side of the fence I am here.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 6 June 2014 07:23, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
>> This will not compile as the nested struct cannot access non-static
>> members of its enclosing type.
> Yes, you're right of course.  You need to store the this pointer in the
> Hours object and make it a friend.  A little more boilerplate and maybe a

You don't need to make it a friend, a nested class has access rights to the
members of the enclosing class.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bd6be028611b104fb246209
Content-Type: text/plain; charset=UTF-8

On Fri, Jun 6, 2014 at 7:43 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 6 June 2014 07:23, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> >> This will not compile as the nested struct cannot access non-static
> >> members of its enclosing type.
> > Yes, you're right of course.  You need to store the this pointer in the
> > Hours object and make it a friend.  A little more boilerplate and maybe a
>
> You don't need to make it a friend, a nested class has access rights to the
> members of the enclosing class.
>
> Even better.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd6be028611b104fb246209
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jun 6, 2014 at 7:43 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 6 June 2014 07:23, Andrew=
 Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewtomazos@gmail=
..com</a>&gt; wrote:<br>

&gt;&gt; This will not compile as the nested struct cannot access non-stati=
c<br>
&gt;&gt; members of its enclosing type.<br>
&gt; Yes, you&#39;re right of course. =C2=A0You need to store the this poin=
ter in the<br>
&gt; Hours object and make it a friend. =C2=A0A little more boilerplate and=
 maybe a<br>
<br>
</div>You don&#39;t need to make it a friend, a nested class has access rig=
hts to the<br>
members of the enclosing class.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br></div></div></blockquote><div>E=
ven better.</div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd6be028611b104fb246209--

.

--Apple-Mail-6C01FA14-E053-4390-8266-F536FF833B6E
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Il giorno 06/giu/2014, alle ore 06:07, Andrew Tomazos <andrewtomazos@gmail.=
com> ha scritto:
>=20
> In C#, the core language feature called Properties works as follows:
>=20
> class TimePeriod
> {
>     private double seconds;
>=20
>     public double Hours
>     {
>         get { return seconds / 3600; }
>         set { seconds =3D value * 3600; }
>     }
> }
>=20
> We already have this in C++:
>=20
> class TimePeriod
> {
>     double seconds;
>=20
> public:
>=20
>    struct {
>        operator double() { return seconds / 3600; }
>        void operator=3D(double value) { seconds =3D value * 3600; }
>    } Hours;
> };
>=20

The boilerplate of passing the this pointer is quite annoying (you have to =
do it in each constructor, for each property of the class), but to me is no=
t the major drawback. The critical point here is memory: if you have 10 emp=
ty struct simulating 10 properties, you have 10 bytes =3D 1 byte for each s=
truct, because of how empty members are handled. Of course this is even wor=
se if the structs are not empty but each one contains a redundant this poin=
ter. And no, the compiler is not allowed to optimize away this storage. To =
me that's not a solution good enough to say that C++ have properties. It do=
esn't.=20

Then of course we could see _if_ we want them, which is not obvious (I'm my=
self skeptic about this proposal), but at least one have to start the discu=
ssion facing the truth.

My two cents.=20

Greetings,
Nicola

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail-6C01FA14-E053-4390-8266-F536FF833B6E
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html><head><meta http-equiv=3D"content-type" content=3D"text/html; charset=
=3Dutf-8"></head><body dir=3D"auto"><div>Il giorno 06/giu/2014, alle ore 06=
:07, Andrew Tomazos &lt;<a href=3D"mailto:andrewtomazos@gmail.com">andrewto=
mazos@gmail.com</a>&gt; ha scritto:</div><div><br></div><blockquote type=3D=
"cite"><div><div dir=3D"ltr">In C#, the core language feature called Proper=
ties works as follows:<div><br></div><div><pre style=3D"padding:5px;margin-=
top:0px;margin-bottom:0px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);f=
ont-size:13px;line-height:17.549999237060547px;font-family:Consolas,Courier=
,monospace!important"><span style=3D"color:blue">class</span> TimePeriod
{
    <span style=3D"color:blue">private</span>&nbsp;<span style=3D"color:blu=
e">double</span> seconds;

    <span style=3D"color:blue">public</span>&nbsp;<span style=3D"color:blue=
">double</span> Hours
    {
        <span style=3D"color:blue">get</span> { <span style=3D"color:blue">=
return</span> seconds / 3600; }
        <span style=3D"color:blue">set</span> { seconds =3D value * 3600; }
    }
}
</pre><div><br></div><div>We already have this in C++:</div><div><br></div>=
<div>class TimePeriod</div><div>{</div><div>&nbsp; &nbsp; double seconds;</=
div><div><br></div><div>public:</div><div><br></div><div>&nbsp; &nbsp;struc=
t {</div><div>&nbsp; &nbsp; &nbsp; &nbsp;operator double() { return seconds=
 / 3600; }</div>
<div>&nbsp; &nbsp; &nbsp; &nbsp;void operator=3D(double value) { seconds =
=3D value * 3600; }</div><div>&nbsp; &nbsp;} Hours;</div><div>};</div><div>=
<br></div></div></div></div></blockquote><div><br></div><div>The boilerplat=
e of passing the this pointer is quite annoying (you have to do it in each =
constructor, for each property of the class), but to me is not the major dr=
awback. The critical point here is memory: if you have 10 empty struct simu=
lating 10 properties, you have 10 bytes =3D 1 byte for each struct, because=
 of how empty members are handled. Of course this is even worse if the stru=
cts are not empty but each one contains a redundant this pointer. And no, t=
he compiler is not allowed to optimize away this storage. To me that's not =
a solution good enough to say that C++ have properties. It doesn't.&nbsp;</=
div><div><br></div><div>Then of course we could see _if_ we want them, whic=
h is not obvious (I'm myself skeptic about this proposal), but at least one=
 have to start the discussion facing the truth.</div><div><br></div><div>My=
 two cents.&nbsp;</div><div><br></div><div>Greetings,</div><div>Nicola</div=
></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail-6C01FA14-E053-4390-8266-F536FF833B6E--

.

On 6 June 2014 10:38, Nicola Gigante <nicola.gigante@gmail.com> wrote:
> Then of course we could see _if_ we want them, which is not obvious (I'm
> myself skeptic about this proposal), but at least one have to start the
> discussion facing the truth.


I would like to more or less echo what Thiago said. If people wish to discuss
properties and come up with a new proposal for properties, they should first
do their homework and see why the earlier proposals were rejected, and
address those concerns. I would also like to point out that possible comments
like "I don't think that's a valid concern" are a waste of time. ;)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_28CE9BBC-9CDF-4191-AA1A-E1E98A0D5240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-06, at 3:43 PM, Ville Voutilainen <ville.voutilainen@gmail.com> =
wrote:

> On 6 June 2014 10:38, Nicola Gigante <nicola.gigante@gmail.com> wrote:
>> Then of course we could see _if_ we want them, which is not obvious (I'm
>> myself skeptic about this proposal), but at least one have to start the
>> discussion facing the truth.
>=20
>=20
> I would like to more or less echo what Thiago said. If people wish to dis=
cuss
> properties and come up with a new proposal for properties, they should fi=
rst
> do their homework and see why the earlier proposals were rejected, and
> address those concerns. I would also like to point out that possible comm=
ents
> like "I don't think that's a valid concern" are a waste of time. ;)

For what it's worth, my upcoming inline variables proposal should help impl=
ement properties, although it may not be a complete solution. As of the las=
t discussion on this list, it should eliminate the overhead of the proxy bu=
t not all the boilerplate, unless you forgo the setter. (With no setter, wh=
ich may be quite reasonable, then an inline member variable should work per=
fectly.)

The main problem with properties is that a setter member access subexpressi=
on (e.g. x.prop in x.prop =3D 4) does not have a type. The RHS just magical=
ly plugs into the setter function parameter. Untyped subexpressions are a r=
ough edge that the language tends to avoid. Even unqualified overloaded fun=
ction names, including those of nonstatic member functions, have types, des=
pite being unusable for anything besides a call. The way out is to introduc=
e a proxy type, which is the ugly solution we already have.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_28CE9BBC-9CDF-4191-AA1A-E1E98A0D5240
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;06, at 3:43 PM, Ville Voutilainen &lt;<a href=3D"mailto:vill=
e.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:</div><b=
r class=3D"Apple-interchange-newline"><blockquote type=3D"cite">On 6 June 2=
014 10:38, Nicola Gigante &lt;<a href=3D"mailto:nicola.gigante@gmail.com">n=
icola.gigante@gmail.com</a>&gt; wrote:<br><blockquote type=3D"cite">Then of=
 course we could see _if_ we want them, which is not obvious (I'm<br>myself=
 skeptic about this proposal), but at least one have to start the<br>discus=
sion facing the truth.<br></blockquote><br><br>I would like to more or less=
 echo what Thiago said. If people wish to discuss<br>properties and come up=
 with a new proposal for properties, they should first<br>do their homework=
 and see why the earlier proposals were rejected, and<br>address those conc=
erns. I would also like to point out that possible comments<br>like "I don'=
t think that's a valid concern" are a waste of time. ;)<br></blockquote></d=
iv><br><div>For what it&rsquo;s worth, my upcoming inline variables proposa=
l should help implement properties, although it may not be a complete solut=
ion. As of the last discussion on this list, it should eliminate the overhe=
ad of the proxy but not all the boilerplate, unless you forgo the setter. (=
With no setter, which may be quite reasonable, then an inline member variab=
le should work perfectly.)</div><div><br></div><div>The main problem with p=
roperties is that a setter member access subexpression (e.g. <font face=3D"=
Courier">x.prop</font> in <font face=3D"Courier">x.prop =3D 4</font>) does =
not have a type. The RHS just magically plugs into the setter function para=
meter. Untyped subexpressions are a rough edge that the language tends to a=
void. Even unqualified overloaded function names, including those of nonsta=
tic member functions, have types, despite being unusable for anything besid=
es a call. The way out is to introduce a proxy type, which is the ugly solu=
tion we already have.</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_28CE9BBC-9CDF-4191-AA1A-E1E98A0D5240--

.

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

Lets just lay it out simple.  Almost every programming language under the=
=20
sun short of C and C++ is supporting the idea of "properties".  If it's=20
such a bad thing why is it so openly supported by most all other competing=
=20
languages?  One just needs to google "How to make C# like properties in=20
C++".  People are trying wacky ways to get this support by overloading the=
=20
'=3D' operator and other listed here.

If the C++ ISO committee blocks this yet again; it's not a hit to anything=
=20
but C++.  People have requested it; many want it.  It does not change any=
=20
of the previous support/power of C++ so really not having original support=
=20
is just telling the community who wants them that "we" have another reason=
=20
to stop you from wanting to using C++.

On Friday, June 6, 2014 2:02:02 AM UTC-6, David Krauss wrote:
>
>
> On 2014=E2=80=9306=E2=80=9306, at 3:43 PM, Ville Voutilainen <ville.vo...=
@gmail.com=20
> <javascript:>> wrote:
>
> On 6 June 2014 10:38, Nicola Gigante <nicola....@gmail.com <javascript:>>=
=20
> wrote:
>
> Then of course we could see _if_ we want them, which is not obvious (I'm
> myself skeptic about this proposal), but at least one have to start the
> discussion facing the truth.
>
>
>
> I would like to more or less echo what Thiago said. If people wish to=20
> discuss
> properties and come up with a new proposal for properties, they should=20
> first
> do their homework and see why the earlier proposals were rejected, and
> address those concerns. I would also like to point out that possible=20
> comments
> like "I don't think that's a valid concern" are a waste of time. ;)
>
>
> For what it=E2=80=99s worth, my upcoming inline variables proposal should=
 help=20
> implement properties, although it may not be a complete solution. As of t=
he=20
> last discussion on this list, it should eliminate the overhead of the pro=
xy=20
> but not all the boilerplate, unless you forgo the setter. (With no setter=
,=20
> which may be quite reasonable, then an inline member variable should work=
=20
> perfectly.)
>
> The main problem with properties is that a setter member access=20
> subexpression (e.g. x.prop in x.prop =3D 4) does not have a type. The RHS=
=20
> just magically plugs into the setter function parameter. Untyped=20
> subexpressions are a rough edge that the language tends to avoid. Even=20
> unqualified overloaded function names, including those of nonstatic membe=
r=20
> functions, have types, despite being unusable for anything besides a call=
..=20
> The way out is to introduce a proxy type, which is the ugly solution we=
=20
> already have.
>
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Lets just lay it out simple.&nbsp; Almost every programmin=
g language under the sun short of C and C++ is supporting the idea of "prop=
erties".&nbsp; If it's such a bad thing why is it so openly supported by mo=
st all other competing languages?&nbsp; One just needs to google "How to ma=
ke C# like properties in C++".&nbsp; People are trying wacky ways to get th=
is support by overloading the '=3D' operator and other listed here.<br><br>=
If the C++ ISO committee blocks this yet again; it's not a hit to anything =
but C++.&nbsp; People have requested it; many want it.&nbsp; It does not ch=
ange any of the previous support/power of C++ so really not having original=
 support is just telling the community who wants them that "we" have anothe=
r reason to stop you from wanting to using C++.<br><br>On Friday, June 6, 2=
014 2:02:02 AM UTC-6, David Krauss wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;"><div style=3D"word-wrap:break-word"><br><div><div>On 2014=E2=80=
=9306=E2=80=9306, at 3:43 PM, Ville Voutilainen &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"Ag0aL9rdwRAJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">ville.vo...@gmail.com</a>&gt; wrote:</div><br><blockquote typ=
e=3D"cite">On 6 June 2014 10:38, Nicola Gigante &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"Ag0aL9rdwRAJ" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';=
return true;">nicola....@gmail.com</a>&gt; wrote:<br><blockquote type=3D"ci=
te">Then of course we could see _if_ we want them, which is not obvious (I'=
m<br>myself skeptic about this proposal), but at least one have to start th=
e<br>discussion facing the truth.<br></blockquote><br><br>I would like to m=
ore or less echo what Thiago said. If people wish to discuss<br>properties =
and come up with a new proposal for properties, they should first<br>do the=
ir homework and see why the earlier proposals were rejected, and<br>address=
 those concerns. I would also like to point out that possible comments<br>l=
ike "I don't think that's a valid concern" are a waste of time. ;)<br></blo=
ckquote></div><br><div>For what it=E2=80=99s worth, my upcoming inline vari=
ables proposal should help implement properties, although it may not be a c=
omplete solution. As of the last discussion on this list, it should elimina=
te the overhead of the proxy but not all the boilerplate, unless you forgo =
the setter. (With no setter, which may be quite reasonable, then an inline =
member variable should work perfectly.)</div><div><br></div><div>The main p=
roblem with properties is that a setter member access subexpression (e.g. <=
font face=3D"Courier">x.prop</font> in <font face=3D"Courier">x.prop =3D 4<=
/font>) does not have a type. The RHS just magically plugs into the setter =
function parameter. Untyped subexpressions are a rough edge that the langua=
ge tends to avoid. Even unqualified overloaded function names, including th=
ose of nonstatic member functions, have types, despite being unusable for a=
nything besides a call. The way out is to introduce a proxy type, which is =
the ugly solution we already have.</div><div><br></div></div></blockquote><=
/div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_465_31193369.1402045298251--

.

On 6 June 2014 12:01,  <tgit28@gmail.com> wrote:
> Lets just lay it out simple.  Almost every programming language under the
> sun short of C and C++ is supporting the idea of "properties".  If it's such

[citation needed]. I have no trouble finding very popular languages that don't.

> a bad thing why is it so openly supported by most all other competing
> languages?  One just needs to google "How to make C# like properties in
> C++".  People are trying wacky ways to get this support by overloading the
> '=' operator and other listed here.

Yes? People are trying wacky ways to support all sorts of features that
are available in other programming languages, and vice versa for c++
features.

> If the C++ ISO committee blocks this yet again; it's not a hit to anything
> but C++.  People have requested it; many want it.  It does not change any of

Apparently many enough don't, since it has been rejected.

> the previous support/power of C++ so really not having original support is
> just telling the community who wants them that "we" have another reason to
> stop you from wanting to using C++.

Well, if the lack of properties is preventing some people from using c++,
good riddance.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

Le vendredi 6 juin 2014 11:28:55 UTC+2, Ville Voutilainen a =C3=A9crit :
>
>
> Apparently many enough don't, since it has been rejected.=20
>

Did it go that far?  I found no paper in the last 10 years excepted N1600=
=20
which begins by "The purpose of this document is to inform WG21 (and the=20
related national bodies) of the direction taken by the C++/CLI work in this=
=20
area. This document is neither a proposal to include this extension in=20
standard C++, nor an endorsement of this extension by the author."

Yours,

--=20
Jean-Marc

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Le vendredi 6 juin 2014 11:28:55 UTC+2, Ville Voutilainen =
a =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><br>Apparen=
tly many enough don't, since it has been rejected.
<br></blockquote><div><br></div><div>Did it go that far? &nbsp;I found no p=
aper in the last 10 years excepted N1600 which begins by<span style=3D"font=
-size: small;">&nbsp;"</span><span style=3D"font-size: small; color: rgb(0,=
 0, 0);">The purpose of this document is to inform WG21 (and the related na=
tional bodies) of the direction taken by the C++/CLI work in this area. Thi=
s document is neither a proposal to include this extension in standard C++,=
 nor an endorsement of this extension by the author."</span></div><div><br>=
</div><div>Yours,</div><div><br></div><div>--&nbsp;</div><div>Jean-Marc</di=
v></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_52_3674992.1402047468622--

.

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

Le vendredi 6 juin 2014 11:01:38 UTC+2, tgi...@gmail.com a =C3=A9crit :
>
> Lets just lay it out simple.  Almost every programming language under the=
=20
> sun short of C and C++ is supporting the idea of "properties".
>

If unbaked assumptions are allowed, I'll state that most languages don't=20
have such a notion.

  If it's such a bad thing why is it so openly supported by most all other=
=20
> competing languages?  One just needs to google "How to make C# like=20
> properties in C++".  People are trying wacky ways to get this support by=
=20
> overloading the '=3D' operator and other listed here.
>
> If the C++ ISO committee blocks this yet again; it's not a hit to anythin=
g=20
> but C++.  People have requested it; many want it.  It does not change any=
=20
> of the previous support/power of C++ so really not having original suppor=
t=20
> is just telling the community who wants them that "we" have another reaso=
n=20
> to stop you from wanting to using C++.
>

There is currently nothing to block.  I'm not sure if there was ever=20
something to block.  If I didn't mess up my look up, the latest related=20
paper is one by David in 2004 which starts by "The purpose of this document=
=20
is to inform WG21 (and the related national bodies) of the direction taken=
=20
by the C++/CLI work in this area. This document is neither a proposal to=20
include this extension in standard C++, nor an endorsement of this=20
extension by the author."

Properties is something which come up informally quite often but nobody=20
apparently want them enough to do the work of coming up with something more=
=20
than raw ideas.

--=20
Jean-Marc

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">Le vendredi 6 juin 2014 11:01:38 UTC+2, tgi...@gmail.com a=
 =C3=A9crit&nbsp;:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr">Lets just lay it out simple.&nbsp; Almost every programming language u=
nder the sun short of C and C++ is supporting the idea of "properties".</di=
v></blockquote><div><br></div><div>If unbaked assumptions are allowed, I'll=
 state that most languages don't have such a notion.<br></div><div><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">&nbsp; If i=
t's such a bad thing why is it so openly supported by most all other compet=
ing languages?&nbsp; One just needs to google "How to make C# like properti=
es in C++".&nbsp; People are trying wacky ways to get this support by overl=
oading the '=3D' operator and other listed here.<br><br>If the C++ ISO comm=
ittee blocks this yet again; it's not a hit to anything but C++.&nbsp; Peop=
le have requested it; many want it.&nbsp; It does not change any of the pre=
vious support/power of C++ so really not having original support is just te=
lling the community who wants them that "we" have another reason to stop yo=
u from wanting to using C++.</div></blockquote><div><font size=3D"2"><br></=
font></div><div><font size=3D"2">There is currently nothing to block. &nbsp=
;I'm not sure if there was ever something to block. &nbsp;If I didn't mess =
up my look up, the latest related paper is one by David in 2004 which start=
s by "<span style=3D"color: rgb(0, 0, 0);">The purpose of this document is =
to inform WG21 (and the related national bodies) of the direction taken by =
the C++/CLI work in this area. This document is neither a proposal to inclu=
de this extension in standard C++, nor an endorsement of this extension by =
the author."</span></font></div><div><span style=3D"color: rgb(0, 0, 0);"><=
font size=3D"2"><br></font></span></div><div><span style=3D"color: rgb(0, 0=
, 0);"><font size=3D"2">Properties is something which come up informally qu=
ite often but nobody apparently want them enough to do the work of coming u=
p with something more than raw ideas.</font></span></div><div><br></div><di=
v><span style=3D"color: rgb(0, 0, 0);"><font size=3D"2">--&nbsp;</font></sp=
an></div><div><span style=3D"color: rgb(0, 0, 0);"><font size=3D"2">Jean-Ma=
rc</font></span></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_492_22968478.1402047312263--

.

On 6 June 2014 12:37, Jean-Marc Bourguet <jm.bourguet@gmail.com> wrote:
> Le vendredi 6 juin 2014 11:28:55 UTC+2, Ville Voutilainen a =C3=A9crit :
>>
>>
>> Apparently many enough don't, since it has been rejected.
>
>
> Did it go that far?  I found no paper in the last 10 years excepted N1600
> which begins by "The purpose of this document is to inform WG21 (and the
> related national bodies) of the direction taken by the C++/CLI work in th=
is
> area. This document is neither a proposal to include this extension in
> standard C++, nor an endorsement of this extension by the author."

Try http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf
and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_272_22058756.1402059191408
Content-Type: text/plain; charset=UTF-8

There is also N1611:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf

It is not about "properties", but about "implicit functions". In short,
function that could be called without operator(). The original purpose was
to hide constants in functions, but it can also be used for properties.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">There is also N1611: http://www.open-std.org/jtc1/sc22/wg2=
1/docs/papers/2004/n1611.pdf<br><br>It is not about "properties", but about=
 "implicit functions". In short, function that could be called without oper=
ator(). The original purpose was to hide constants in functions, but it can=
 also be used for properties.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_272_22058756.1402059191408--

.

------=_Part_278_4322182.1402060229394
Content-Type: text/plain; charset=UTF-8

There have also been some discussion on this very proposals forum:

https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HMyJqb3UIq0

There were some ideas to "extend functions syntax" instead of "adding
properties", which is close to implicit functions. The advantage is that
adding "implicit" to a function, would still allow to write it with the
parenthesis. Therefore, we could "upgrade" some getters and setters to
properties while the old code would still work.

On 28 August 2013 10:47, Bengt Gustafsson <bengt.gu...@beamways.com> wrote:

> How about doing the change in the other end:
>
> Don't change anything in the class head, but allow an implicit
> transformation:
>
> object.property = value;
>
> to
>
> object.property(value);
>
> IFF property is a function which has an overload that can be called with a
> single parameter of value's type.
>
> As function pointers and functions are different I don't see that this can
> interfer with an assignment that is allowed today. Also this is consistent
> with what is already allowed at construction time!
>
> The getter case is a little harder to accept for me, but I think it would
> be possible to allow:
>
> int value = object.property;
>
> IFF property is a method which has a 0-ary overload.
>
> I am not positive but at least I think that using the address of a method
> without a leading & is not allowed when you really want to get at the
> method pointer, so this should not be ambiguous. In contrast, it would not
> be possible to omit the trailing () for a global function as (due to
> feature inheritance from C) this means the address of the function (correct
> me if I'm wrong on this).
>

One of the ideas I agreed with in this discussion was: "maybe we need
properties, maybe we don't. But if we want them, let's not make them
second-class members with a poor library solution, let's make them a proper
part of the language". That's true: nobody would be happy with
"half-properties" and nobody ever found any proper way to implement them
without drawbacks as a simple library feature.

One of the core concern was to find a way to make the difference between
the property getter/setter and the returned value. Consider an int
property. Would sizeof(instance.some_property) return sizeof(int) ot
sizeof(int (*)()) ? That's a real concern and could be problematic in
generic code. In Python, type(instance.some_property) would be int, but
Python's properties (the functions themselves) can still be accessed via
reflection. Reflection may be a way to "solve" this problem.

Overall, I have grown to like properties, but there are still some rather
serious core problems to resolve. What I said was pretty unstructured, but
it sums up what was said in the old discussions.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">There have also been some discussion on this very proposal=
s forum:<br><br>https://groups.google.com/a/isocpp.org/forum/#!topic/std-pr=
oposals/HMyJqb3UIq0<br><br>There were some ideas to "extend functions synta=
x" instead of "adding properties", which is close to implicit functions. Th=
e advantage is that adding "implicit" to a function, would still allow to w=
rite it with the parenthesis. Therefore, we could "upgrade" some getters an=
d setters to properties while the old code would still work.<br><br>On 28 A=
ugust 2013 10:47, Bengt Gustafsson <span dir=3D"ltr">&lt;<a target=3D"_blan=
k">bengt.gu...@beamways.com</a><wbr>&gt;</span> wrote:<br><blockquote style=
=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); p=
adding-left: 1ex;" class=3D"gmail_quote">
How about doing the change in the other end:<br>
<br>
Don't change anything in the class head, but allow an implicit transformati=
on:<br>
<br>
object.property =3D value;<br>
<br>
to<br>
<br>
object.property(value);<br>
<br>
IFF property is a function which has an overload that can be called with a =
single parameter of value's type.<br>
<br>
As function pointers and functions are different I don't see that this=20
can interfer with an assignment that is allowed today. Also this is=20
consistent with what is already allowed at construction time!<br>
<br>
The getter case is a little harder to accept for me, but I think it would b=
e possible to allow:<br>
<br>
int value =3D object.property;<br>
<br>
IFF property is a method which has a 0-ary overload.<br>
<br>
I am not positive but at least I think that using the address of a=20
method without a leading &amp; is not allowed when you really want to=20
get at the method pointer, so this should not be ambiguous. In contrast,
 it would not be possible to omit the trailing () for a global function=20
as (due to feature inheritance from C) this means the address of the=20
function (correct me if I'm wrong on this).<br></blockquote><div><br>One of=
 the ideas I agreed with in this discussion was: "maybe we need properties,=
 maybe we don't. But if we want them, let's not make them second-class memb=
ers with a poor library solution, let's make them a proper part of the lang=
uage". That's true: nobody would be happy with "half-properties" and nobody=
 ever found any proper way to implement them without drawbacks as a simple =
library feature.<br><br>One of the core concern was to find a way to make t=
he difference between the property getter/setter and the returned value. Co=
nsider an int property. Would sizeof(instance.some_property) return sizeof(=
int) ot sizeof(int (*)()) ? That's a real concern and could be problematic =
in generic code. In Python, type(instance.some_property) would be int, but =
Python's properties (the functions themselves) can still be accessed via re=
flection. Reflection may be a way to "solve" this problem.<br></div><div><b=
r>Overall, I have grown to like properties, but there are still some rather=
 serious core problems to resolve. What I said was pretty unstructured, but=
 it sums up what was said in the old discussions.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_278_4322182.1402060229394--

.

------=_Part_135_5043263.1402066799468
Content-Type: text/plain; charset=UTF-8

Does C++ really need properties? It would make it very difficult to tell
what's going on, and every instance of an implicit function call currently
in the language has caused problems, such as implicit conversion operators,
which make "auto" not quite do what you expect, break std::swap, complicate
overload resolution, etc. Luckily these have been so far kept to a minimum,
so I've always found it much easier to write less buggy code quickly in C++
than other languages, because it's very clear and precise - I can know that
assigning to some field is not going to go and invoke some event handler
which then breaks the invariants of my function, and so I don't have to go
trawling through the (possible non-existent) documentation of whatever
library I'm using to figure out whether my code might have unexpected
side-effects.

I think the main problem is the tediousness of declaring the setters and
getters, rather than any issue with having to use them (does anyone really
care whether they have to use ".setXXX(y)" instead of "XXX = y", as long as
they can get rid of all the boilerplate code used to declare those
properties?) and that can be solved just be introducing a shorter syntax
for declaring setters and getters with no side-effects.

On Friday, 6 June 2014 14:10:29 UTC+1, morw...@gmail.com wrote:
>
> There have also been some discussion on this very proposals forum:
>
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HMyJqb3UIq0
>
> There were some ideas to "extend functions syntax" instead of "adding
> properties", which is close to implicit functions. The advantage is that
> adding "implicit" to a function, would still allow to write it with the
> parenthesis. Therefore, we could "upgrade" some getters and setters to
> properties while the old code would still work.
>
> On 28 August 2013 10:47, Bengt Gustafsson <bengt.gu...@beamways.com>
> wrote:
>
>> How about doing the change in the other end:
>>
>> Don't change anything in the class head, but allow an implicit
>> transformation:
>>
>> object.property = value;
>>
>> to
>>
>> object.property(value);
>>
>> IFF property is a function which has an overload that can be called with
>> a single parameter of value's type.
>>
>> As function pointers and functions are different I don't see that this
>> can interfer with an assignment that is allowed today. Also this is
>> consistent with what is already allowed at construction time!
>>
>> The getter case is a little harder to accept for me, but I think it would
>> be possible to allow:
>>
>> int value = object.property;
>>
>> IFF property is a method which has a 0-ary overload.
>>
>> I am not positive but at least I think that using the address of a method
>> without a leading & is not allowed when you really want to get at the
>> method pointer, so this should not be ambiguous. In contrast, it would not
>> be possible to omit the trailing () for a global function as (due to
>> feature inheritance from C) this means the address of the function (correct
>> me if I'm wrong on this).
>>
>
> One of the ideas I agreed with in this discussion was: "maybe we need
> properties, maybe we don't. But if we want them, let's not make them
> second-class members with a poor library solution, let's make them a proper
> part of the language". That's true: nobody would be happy with
> "half-properties" and nobody ever found any proper way to implement them
> without drawbacks as a simple library feature.
>
> One of the core concern was to find a way to make the difference between
> the property getter/setter and the returned value. Consider an int
> property. Would sizeof(instance.some_property) return sizeof(int) ot
> sizeof(int (*)()) ? That's a real concern and could be problematic in
> generic code. In Python, type(instance.some_property) would be int, but
> Python's properties (the functions themselves) can still be accessed via
> reflection. Reflection may be a way to "solve" this problem.
>
> Overall, I have grown to like properties, but there are still some rather
> serious core problems to resolve. What I said was pretty unstructured, but
> it sums up what was said in the old discussions.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Does C++ really need properties? It would make it very dif=
ficult to tell what's going on, and every instance of an implicit function =
call currently in the language has caused problems, such as implicit conver=
sion operators, which make "auto" not quite do what you expect, break std::=
swap, complicate overload resolution, etc. Luckily these have been so far k=
ept to a minimum, so I've always found it much easier to write less buggy c=
ode quickly in C++ than other languages, because it's very clear and precis=
e - I can know that assigning to some field is not going to go and invoke s=
ome event handler which then breaks the invariants of my function, and so I=
 don't have to go trawling through the (possible non-existent) documentatio=
n of whatever library I'm using to figure out whether my code might have un=
expected side-effects.<br><br>I think the main problem is the tediousness o=
f declaring the setters and getters, rather than any issue with having to u=
se them (does anyone really care whether they have to use ".setXXX(y)" inst=
ead of "XXX =3D y", as long as they can get rid of all the boilerplate code=
 used to declare those properties?) and that can be solved just be introduc=
ing a shorter syntax for declaring setters and getters with no side-effects=
..<br><br>On Friday, 6 June 2014 14:10:29 UTC+1, morw...@gmail.com  wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">There have also=
 been some discussion on this very proposals forum:<br><br><a href=3D"https=
://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/HMyJqb3UIq0" =
target=3D"_blank" onmousedown=3D"this.href=3D'https://groups.google.com/a/i=
socpp.org/forum/#!topic/std-proposals/HMyJqb3UIq0';return true;" onclick=3D=
"this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-prop=
osals/HMyJqb3UIq0';return true;">https://groups.google.com/a/<wbr>isocpp.or=
g/forum/#!topic/std-<wbr>proposals/HMyJqb3UIq0</a><br><br>There were some i=
deas to "extend functions syntax" instead of "adding properties", which is =
close to implicit functions. The advantage is that adding "implicit" to a f=
unction, would still allow to write it with the parenthesis. Therefore, we =
could "upgrade" some getters and setters to properties while the old code w=
ould still work.<br><br>On 28 August 2013 10:47, Bengt Gustafsson <span dir=
=3D"ltr">&lt;<a>bengt.gu...@beamways.com</a>&gt;</span> wrote:<br><blockquo=
te style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex" class=3D"gmail_quote">
How about doing the change in the other end:<br>
<br>
Don't change anything in the class head, but allow an implicit transformati=
on:<br>
<br>
object.property =3D value;<br>
<br>
to<br>
<br>
object.property(value);<br>
<br>
IFF property is a function which has an overload that can be called with a =
single parameter of value's type.<br>
<br>
As function pointers and functions are different I don't see that this=20
can interfer with an assignment that is allowed today. Also this is=20
consistent with what is already allowed at construction time!<br>
<br>
The getter case is a little harder to accept for me, but I think it would b=
e possible to allow:<br>
<br>
int value =3D object.property;<br>
<br>
IFF property is a method which has a 0-ary overload.<br>
<br>
I am not positive but at least I think that using the address of a=20
method without a leading &amp; is not allowed when you really want to=20
get at the method pointer, so this should not be ambiguous. In contrast,
 it would not be possible to omit the trailing () for a global function=20
as (due to feature inheritance from C) this means the address of the=20
function (correct me if I'm wrong on this).<br></blockquote><div><br>One of=
 the ideas I agreed with in this discussion was: "maybe we need properties,=
 maybe we don't. But if we want them, let's not make them second-class memb=
ers with a poor library solution, let's make them a proper part of the lang=
uage". That's true: nobody would be happy with "half-properties" and nobody=
 ever found any proper way to implement them without drawbacks as a simple =
library feature.<br><br>One of the core concern was to find a way to make t=
he difference between the property getter/setter and the returned value. Co=
nsider an int property. Would sizeof(instance.some_property) return sizeof(=
int) ot sizeof(int (*)()) ? That's a real concern and could be problematic =
in generic code. In Python, type(instance.some_property) would be int, but =
Python's properties (the functions themselves) can still be accessed via re=
flection. Reflection may be a way to "solve" this problem.<br></div><div><b=
r>Overall, I have grown to like properties, but there are still some rather=
 serious core problems to resolve. What I said was pretty unstructured, but=
 it sums up what was said in the old discussions.<br></div></div></blockquo=
te></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_135_5043263.1402066799468--

.

Em sex 06 jun 2014, =E0s 02:01:37, tgit28@gmail.com escreveu:
> Lets just lay it out simple.  Almost every programming language under the=
=20
> sun short of C and C++ is supporting the idea of "properties".  If it's=
=20
> such a bad thing why is it so openly supported by most all other competin=
g=20
> languages?

Most of those programming languages also got rid of pointers and use automa=
tic=20
garbage collection. Are you also proposing we do the same for C++?

Just because other people do it does not imply we should do it.

That said, I'm going to stop this reply here and repeat what I said before:=
=20
write the paper proposing the feature. There's nothing to be discussed or=
=20
blocked until such a paper appears.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

What I don't like about C#-like properties in C++, is the interaction with how
the language works in general.

For example, suppose "property" here is a property of type T:

auto x = obj.property;
should translate to auto x = obj.getProperty(), right?

But then you want this:
obj.property = 42;
to be translated to obj.setProperty(42);

So what should be the mechanism of this translation? In the first case the property is "used",
so we call the getter, while in the second is "assigned", so we call the setter?
But what if T provides operator=()? Should we "override" the operator=() with the setter?

But then if I do:

obj.property += 42;

what happens? Do we call the getter, since it's not an assignment, and call operator+=() on the getter's
result? It would be quite unexpected. Or do you want a different "setter" for each compound assignment
operator?

In C#, this mechanism works well because you can't overload operator= on ref-types. It always assigns
references to objects. And compound assignment operators like += are always automatically implemented
based on binary operators like +. So the behavior of operations on a property is consistent with the behavior
of operations on a member field. In C++ it's quite more difficult.

Also, we have references. obj.property can't be an lvalue if the getter doesn't return a reference, but
obj.property definitely looks like an lvalue. People are going to write:

void func(T &v)
{
   v = 42;
}

func(obj.property);

It won't compile. Or, worse, it would compile if the getter returns a reference, but doing something entirely different
from obj.property = 42; which IMHO is very bad. In C#, again, this problem doesn't exist because we always have references
to objects.

And then if aren't lucky you get this bonus misbehavior:

obj.property = 42; // call the setter
(obj.property) = 42; // call the getter and operator=()

It makes me screaming.

So no, I don't think properties fit in C++.

My two cents,

Greetings,
Nicola


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2014-06-06 01:02, Miro Knejp wrote:
> I can't remember how many times I wished I could give a member variable
> public read access without having to boilerplate a getter every time.

Amen to that.

Historically, I've actually done this:

  public:
    const T& x = mutable_x;
  protected:
    T mutable_x;

However this isn't necessarily the exact same thing as properties.

It might be nice to be able to write instead:

  public:
    using const x;
    // or 'using const x = mutable_x'

  protected:
    T x;

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7b10ca9da78d3c04fb2e7426
Content-Type: text/plain; charset=UTF-8

Just wanted to add that MSVC has addressed these issues somehow with
their compiler.  I'm not sure how they handle it since I'm actually
rather a newbie to C++.

After reading N1384
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf it
appears this could be a user implemented design; but I feel most are
going to want some standard langauge / library to make use of it.


__declspec( property( get=get_func_name ) ) declarator
__declspec( property( put=put_func_name ) ) declarator
__declspec( property( get=get_func_name, put=put_func_name ) ) declarator



On Fri, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <
mw_triad@users.sourceforge.net> wrote:

> On 2014-06-06 01:02, Miro Knejp wrote:
> > I can't remember how many times I wished I could give a member variable
> > public read access without having to boilerplate a getter every time.
>
> Amen to that.
>
> Historically, I've actually done this:
>
>   public:
>     const T& x = mutable_x;
>   protected:
>     T mutable_x;
>
> However this isn't necessarily the exact same thing as properties.
>
> It might be nice to be able to write instead:
>
>   public:
>     using const x;
>     // or 'using const x = mutable_x'
>
>   protected:
>     T x;
>
> --
> Matthew
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b10ca9da78d3c04fb2e7426
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><pre>Just wanted to add that MSVC has addressed these issu=
es somehow with their compiler.  I&#39;m not sure how they handle it since =
I&#39;m actually rather a newbie to C++.<br></pre><pre>After reading N1384 =
<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pd=
f">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf</a> it=
 appears this could be a user implemented design; but I feel most are going=
 to want some standard langauge / library to make use of it.<br>
</pre><pre><br>__declspec( property(=C2=A0get=3Dget_func_name=C2=A0) )=C2=
=A0declarator=C2=A0
__declspec( property(=C2=A0put=3Dput_func_name=C2=A0) )=C2=A0declarator=C2=
=A0
__declspec( property(=C2=A0get=3Dget_func_name, put=3Dput_func_name=C2=A0) =
)=C2=A0declarator</pre></div><div class=3D"gmail_extra"><br><br><div class=
=3D"gmail_quote">On Fri, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mw_triad@users.sourceforge.net" target=3D"_b=
lank">mw_triad@users.sourceforge.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 2014-06-06 01:02, Miro Kn=
ejp wrote:<br>
&gt; I can&#39;t remember how many times I wished I could give a member var=
iable<br>
&gt; public read access without having to boilerplate a getter every time.<=
br>
<br>
</div>Amen to that.<br>
<br>
Historically, I&#39;ve actually done this:<br>
<br>
=C2=A0 public:<br>
=C2=A0 =C2=A0 const T&amp; x =3D mutable_x;<br>
=C2=A0 protected:<br>
=C2=A0 =C2=A0 T mutable_x;<br>
<br>
However this isn&#39;t necessarily the exact same thing as properties.<br>
<br>
It might be nice to be able to write instead:<br>
<br>
=C2=A0 public:<br>
=C2=A0 =C2=A0 using const x;<br>
=C2=A0 =C2=A0 // or &#39;using const x =3D mutable_x&#39;<br>
<br>
=C2=A0 protected:<br>
=C2=A0 =C2=A0 T x;<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b10ca9da78d3c04fb2e7426--

.

On 2014-06-06 09:10, morwenn29@gmail.com wrote:
> Would sizeof(instance.some_property) return sizeof(int) ot
> sizeof(int (*)()) ?

I'd have to lean strongly toward the former... in the case of implicit
functions, the above is "clearly" equivalent to:

  sizeof(instance.some_getter())

....so the answer clearly is 'sizeof(int)'.

And anyway, you forgot a third option; 'sizeof(void (*)(int))'. Given
that ambiguity, I'd feel strongly that if you want the size of the
getter or setter, there would be some special syntax to indicate that
(and also if you want the get or the set).

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_661_33190019.1402097032392
Content-Type: text/plain; charset=UTF-8

"properties" is a vague notion, I'm no sure it's really necessary to bring
such concept to C++, here's what I've seen properties being used for:

1. auto-generating getters and setters

That would be something like declaring "property int n" and we'd get "void
set_n(int)" and "int get_n() const" generated because the property is
private. Honestly I don't really see how this could get interesting, if
you're going to have a public getter and setter why not make your member
public already? The syntax will be much easier to type and read with "x.n =
42" than "x.get_n()", and the compiler will generate a call to a generated
"set_n" method. Saying that the underlying implementation of the class may
change but not the public interface so we don't want to expose member
variables is invalid in this case, since changing the class internals would
require to re-compile the program and unless the variables type, names and
layout didn't change that would break existing code.
The only place where I'd see this be useful would be if the setter and
getters are virtual, because a sub-class implementation could be hidden and
in that case it wouldn't break code using objects through the base type...
I'm not sure that's a very relevant use case.

2. implicitly called functions

Some languages allow for nice looking syntax with implicit function calls
(Python, Ruby... ), where functions that do little more than accessing a
field of a sub object. You can write things like "x.n = 42" and that
implicitly calls a method of the object, so we can do checks on the
variable type for example... most languages I know that use this kind of
approaches are dynamically typed and these kind of tricks allow for runtime
type checking. But C++ already has a powerful type system so this isn't a
use case.
Some other times, the implicitly called functions are used to check the
runtime value of parameters or modify the values, for example, storing
things internally with a different type than the one exposed in the public
interface or making sure an integer stays within a certain range. These
problems can easily be solved with library code and operator overloading, I
don't think there's a need for a new language feature for this case.

3. Read-only or Write-only fields

So you make your class members public, but you want to make sure they are
accessed in a read-only fashioned. First of all, if your objects are used
through constant references this will be implicitly enforced, so the only
case this is necessary would be when the object is available through a
non-constant type.
You could make the fields constant but you can't assign instances of your
class since it contains constant non-static members. So instead you could
write some template "property" template class that wraps around the actual
type and would provide read-only or write-only operations through operator
overloading, until someone writes such a library to solve some real-world
problems and shows which are the limitations enforced by the current C++
standard I don't think it's worth wasting time thinking about how to
introduce a new syntax to support this use case.


Left aside issues like getting a pointer to member which happens to be a
property... what would be the type of "&A::x" if x is a property of class A?
In the end I feel like there's very little interesting use-cases for
properties in C++, and most of these problems could be solved with library
code.


On Friday, June 6, 2014 10:47:33 AM UTC-7, Tom Joe wrote:
>
> Just wanted to add that MSVC has addressed these issues somehow with their compiler.  I'm not sure how they handle it since I'm actually rather a newbie to C++.
>
> After reading N1384 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf it appears this could be a user implemented design; but I feel most are going to want some standard langauge / library to make use of it.
>
>
> __declspec( property( get=get_func_name ) ) declarator
> __declspec( property( put=put_func_name ) ) declarator
> __declspec( property( get=get_func_name, put=put_func_name ) ) declarator
>
>
>
> On Fri, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <
> mw_t...@users.sourceforge.net <javascript:>> wrote:
>
>> On 2014-06-06 01:02, Miro Knejp wrote:
>> > I can't remember how many times I wished I could give a member variable
>> > public read access without having to boilerplate a getter every time.
>>
>> Amen to that.
>>
>> Historically, I've actually done this:
>>
>>   public:
>>     const T& x = mutable_x;
>>   protected:
>>     T mutable_x;
>>
>> However this isn't necessarily the exact same thing as properties.
>>
>> It might be nice to be able to write instead:
>>
>>   public:
>>     using const x;
>>     // or 'using const x = mutable_x'
>>
>>   protected:
>>     T x;
>>
>> --
>> Matthew
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposal...@isocpp.org <javascript:>.
>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">"properties" is a vague notion, I'm no sure it's really ne=
cessary to bring such concept to C++, here's what I've seen properties bein=
g used for:<br><br>1. auto-generating getters and setters<br><br>That would=
 be something like declaring "property int n" and we'd get "void set_n(int)=
" and "int get_n() const" generated because the property is private. Honest=
ly I don't really see how this could get interesting, if you're going to ha=
ve a public getter and setter why not make your member public already? The =
syntax will be much easier to type and read with "x.n =3D 42" than "x.get_n=
()", and the compiler will generate a call to a generated "set_n" method. S=
aying that the underlying implementation of the class may change but not th=
e public interface so we don't want to expose member variables is invalid i=
n this case, since changing the class internals would require to re-compile=
 the program and unless the variables type, names and layout didn't change =
that would break existing code.<br>The only place where I'd see this be use=
ful would be if the setter and getters are virtual, because a sub-class imp=
lementation could be hidden and in that case it wouldn't break code using o=
bjects through the base type... I'm not sure that's a very relevant use cas=
e.<br><br>2. implicitly called functions<br><br>Some languages allow for ni=
ce looking syntax with implicit function calls (Python, Ruby... ), where fu=
nctions that do little more than accessing a field of a sub object. You can=
 write things like "x.n =3D 42" and that implicitly calls a method of the o=
bject, so we can do checks on the variable type for example... most languag=
es I know that use this kind of approaches are dynamically typed and these =
kind of tricks allow for runtime type checking. But C++ already has a power=
ful type system so this isn't a use case.<br>Some other times, the implicit=
ly called functions are used to check the runtime value of parameters or mo=
dify the values, for example, storing things internally with a different ty=
pe than the one exposed in the public interface or making sure an integer s=
tays within a certain range. These problems can easily be solved with libra=
ry code and operator overloading, I don't think there's a need for a new la=
nguage feature for this case.<br><br>3. Read-only or Write-only fields<br><=
br>So you make your class members public, but you want to make sure they ar=
e accessed in a read-only fashioned. First of all, if your objects are used=
 through constant references this will be implicitly enforced, so the only =
case this is necessary would be when the object is available through a non-=
constant type.<br>You could make the fields constant but you can't assign i=
nstances of your class since it contains constant non-static members. So in=
stead you could write some template "property" template class that wraps ar=
ound the actual type and would provide read-only or write-only operations t=
hrough operator overloading, until someone writes such a library to solve s=
ome real-world problems and shows which are the limitations enforced by the=
 current C++ standard I don't think it's worth wasting time thinking about =
how to introduce a new syntax to support this use case.<br><br><br>Left asi=
de issues like getting a pointer to member which happens to be a property..=
.. what would be the type of "&amp;A::x" if x is a property of class A?<br>I=
n the end I feel like there's very little interesting use-cases for propert=
ies in C++, and most of these problems could be solved with library code.<b=
r><br><br>On Friday, June 6, 2014 10:47:33 AM UTC-7, Tom Joe wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><pre>Just wanted to a=
dd that MSVC has addressed these issues somehow with their compiler.  I'm n=
ot sure how they handle it since I'm actually rather a newbie to C++.<br></=
pre><pre>After reading N1384 <a href=3D"http://www.open-std.org/jtc1/sc22/w=
g21/docs/papers/2002/n1384.pdf" target=3D"_blank" onmousedown=3D"this.href=
=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc=
22%2Fwg21%2Fdocs%2Fpapers%2F2002%2Fn1384.pdf\46sa\75D\46sntz\0751\46usg\75A=
FQjCNHEKQB5kd4a8jekKFTnKI78tuJxsA';return true;" onclick=3D"this.href=3D'ht=
tp://www.google.com/url?q\75http%3A%2F%2Fwww.open-std.org%2Fjtc1%2Fsc22%2Fw=
g21%2Fdocs%2Fpapers%2F2002%2Fn1384.pdf\46sa\75D\46sntz\0751\46usg\75AFQjCNH=
EKQB5kd4a8jekKFTnKI78tuJxsA';return true;">http://www.open-std.org/jtc1/<wb=
r>sc22/wg21/docs/papers/2002/<wbr>n1384.pdf</a> it appears this could be a =
user implemented design; but I feel most are going to want some standard la=
ngauge / library to make use of it.<br>
</pre><pre><br>__declspec( property(&nbsp;get=3Dget_func_name&nbsp;) )&nbsp=
;declarator&nbsp;
__declspec( property(&nbsp;put=3Dput_func_name&nbsp;) )&nbsp;declarator&nbs=
p;
__declspec( property(&nbsp;get=3Dget_func_name, put=3Dput_func_name&nbsp;) =
)&nbsp;declarator</pre></div><div><br><br><div class=3D"gmail_quote">On Fri=
, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=3D=
"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"SXrt3ufpmyAJ" onmo=
usedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=3D'=
javascript:';return true;">mw_t...@users.sourceforge.<wbr>net</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div>On 2014-06-06 01:02, Miro Knejp wrote:<=
br>
&gt; I can't remember how many times I wished I could give a member variabl=
e<br>
&gt; public read access without having to boilerplate a getter every time.<=
br>
<br>
</div>Amen to that.<br>
<br>
Historically, I've actually done this:<br>
<br>
&nbsp; public:<br>
&nbsp; &nbsp; const T&amp; x =3D mutable_x;<br>
&nbsp; protected:<br>
&nbsp; &nbsp; T mutable_x;<br>
<br>
However this isn't necessarily the exact same thing as properties.<br>
<br>
It might be nice to be able to write instead:<br>
<br>
&nbsp; public:<br>
&nbsp; &nbsp; using const x;<br>
&nbsp; &nbsp; // or 'using const x =3D mutable_x'<br>
<br>
&nbsp; protected:<br>
&nbsp; &nbsp; T x;<br>
<span><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div><div><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp.org/d/top=
ic/std-proposals/n0QcD_K5dBY/unsubscribe';return true;" onclick=3D"this.hre=
f=3D'https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5d=
BY/unsubscribe';return true;">https://groups.google.com/a/<wbr>isocpp.org/d=
/topic/std-<wbr>proposals/n0QcD_K5dBY/<wbr>unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"SXrt3ufpmyAJ" o=
nmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"this.href=
=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"SXrt3ufpmyAJ" onmousedown=3D"this.href=3D'java=
script:';return true;" onclick=3D"this.href=3D'javascript:';return true;">s=
td-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups=
..google.com/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"thi=
s.href=3D'http://groups.google.com/a/isocpp.org/group/std-proposals/';retur=
n true;">http://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposal=
s/</a>.<br>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_661_33190019.1402097032392--

.

--e89a8ff2569ca2fc7904fb342336
Content-Type: text/plain; charset=UTF-8

I would say it is correct to say that it isn't necessary to bring the
"properties" concept to C++; but there's a lot of nice things about C++
that aren't absolutely "necessary".

Agree; I also feel with a really good implementation that it could be
introduced as a library, but also like to say properties it is an OO
concept so I'm not sure that is a wise approach.

Just to summarize:
Pros:
1) read / write access definition
2) auto getters/setters routing
3) smaller API footprint     IMHO; this is the BIGGEST of all; whereas
setThis(), getThis() does the same except it DOUBLES the object API.
4) More openly compatible with other OO languages and OO design concepts

Cons:
1) Hiding "notions" of a direct object variable access.

Am I missing any?


On Fri, Jun 6, 2014 at 5:23 PM, Achille Roussel <achille.roussel@gmail.com>
wrote:

> "properties" is a vague notion, I'm no sure it's really necessary to bring
> such concept to C++, here's what I've seen properties being used for:
>
> 1. auto-generating getters and setters
>
> That would be something like declaring "property int n" and we'd get "void
> set_n(int)" and "int get_n() const" generated because the property is
> private. Honestly I don't really see how this could get interesting, if
> you're going to have a public getter and setter why not make your member
> public already? The syntax will be much easier to type and read with "x.n =
> 42" than "x.get_n()", and the compiler will generate a call to a generated
> "set_n" method. Saying that the underlying implementation of the class may
> change but not the public interface so we don't want to expose member
> variables is invalid in this case, since changing the class internals would
> require to re-compile the program and unless the variables type, names and
> layout didn't change that would break existing code.
> The only place where I'd see this be useful would be if the setter and
> getters are virtual, because a sub-class implementation could be hidden and
> in that case it wouldn't break code using objects through the base type...
> I'm not sure that's a very relevant use case.
>
> 2. implicitly called functions
>
> Some languages allow for nice looking syntax with implicit function calls
> (Python, Ruby... ), where functions that do little more than accessing a
> field of a sub object. You can write things like "x.n = 42" and that
> implicitly calls a method of the object, so we can do checks on the
> variable type for example... most languages I know that use this kind of
> approaches are dynamically typed and these kind of tricks allow for runtime
> type checking. But C++ already has a powerful type system so this isn't a
> use case.
> Some other times, the implicitly called functions are used to check the
> runtime value of parameters or modify the values, for example, storing
> things internally with a different type than the one exposed in the public
> interface or making sure an integer stays within a certain range. These
> problems can easily be solved with library code and operator overloading, I
> don't think there's a need for a new language feature for this case.
>
> 3. Read-only or Write-only fields
>
> So you make your class members public, but you want to make sure they are
> accessed in a read-only fashioned. First of all, if your objects are used
> through constant references this will be implicitly enforced, so the only
> case this is necessary would be when the object is available through a
> non-constant type.
> You could make the fields constant but you can't assign instances of your
> class since it contains constant non-static members. So instead you could
> write some template "property" template class that wraps around the actual
> type and would provide read-only or write-only operations through operator
> overloading, until someone writes such a library to solve some real-world
> problems and shows which are the limitations enforced by the current C++
> standard I don't think it's worth wasting time thinking about how to
> introduce a new syntax to support this use case.
>
>
> Left aside issues like getting a pointer to member which happens to be a
> property... what would be the type of "&A::x" if x is a property of class A?
> In the end I feel like there's very little interesting use-cases for
> properties in C++, and most of these problems could be solved with library
> code.
>
>
>
> On Friday, June 6, 2014 10:47:33 AM UTC-7, Tom Joe wrote:
>
>> Just wanted to add that MSVC has addressed these issues somehow with their compiler.  I'm not sure how they handle it since I'm actually rather a newbie to C++.
>>
>> After reading N1384 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf it appears this could be a user implemented design; but I feel most are going to want some standard langauge / library to make use of it.
>>
>>
>> __declspec( property( get=get_func_name ) ) declarator
>> __declspec( property( put=put_func_name ) ) declarator
>> __declspec( property( get=get_func_name, put=put_func_name ) ) declarator
>>
>>
>>
>> On Fri, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <
>> mw_t...@users.sourceforge.net> wrote:
>>
>>> On 2014-06-06 01:02, Miro Knejp wrote:
>>> > I can't remember how many times I wished I could give a member variable
>>> > public read access without having to boilerplate a getter every time.
>>>
>>> Amen to that.
>>>
>>> Historically, I've actually done this:
>>>
>>>   public:
>>>     const T& x = mutable_x;
>>>   protected:
>>>     T mutable_x;
>>>
>>> However this isn't necessarily the exact same thing as properties.
>>>
>>> It might be nice to be able to write instead:
>>>
>>>   public:
>>>     using const x;
>>>     // or 'using const x = mutable_x'
>>>
>>>   protected:
>>>     T x;
>>>
>>> --
>>> Matthew
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/
>>> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposal...@isocpp.org.
>>> To post to this group, send email to std-pr...@isocpp.org.
>>>
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div>I would say i=
t is correct to say that it isn&#39;t necessary to bring the &quot;properti=
es&quot; concept to C++; but there&#39;s a lot of nice things about C++ tha=
t aren&#39;t absolutely &quot;necessary&quot;.<br>
<br></div>Agree; I also feel with a really good implementation that it coul=
d be introduced as a library, but also like to say properties it is an OO c=
oncept so I&#39;m not sure that is a wise approach.<br><br></div>Just to su=
mmarize:<br>
</div>Pros:<br></div>1) read / write access definition<br></div>2) auto get=
ters/setters routing<br></div>3) smaller API footprint=C2=A0=C2=A0=C2=A0=C2=
=A0 IMHO; this is the BIGGEST of all; whereas setThis(), getThis() does the=
 same except it DOUBLES the object API.<br>
</div><div>4) More openly compatible with other OO languages and OO design =
concepts<br></div><div><br></div>Cons:<br></div>1) Hiding &quot;notions&quo=
t; of a direct object variable access.<br><br></div><div>Am I missing any?<=
br>
</div><div><div><div><div><div><div><div><div><div><div><div class=3D"gmail=
_extra"><br><br><div class=3D"gmail_quote">On Fri, Jun 6, 2014 at 5:23 PM, =
Achille Roussel <span dir=3D"ltr">&lt;<a href=3D"mailto:achille.roussel@gma=
il.com" target=3D"_blank">achille.roussel@gmail.com</a>&gt;</span> wrote:<b=
r>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">&quot;properties&quot; is a=
 vague notion, I&#39;m no sure it&#39;s really necessary to bring such conc=
ept to C++, here&#39;s what I&#39;ve seen properties being used for:<br>
<br>1. auto-generating getters and setters<br><br>That would be something l=
ike declaring &quot;property int n&quot; and we&#39;d get &quot;void set_n(=
int)&quot; and &quot;int get_n() const&quot; generated because the property=
 is private. Honestly I don&#39;t really see how this could get interesting=
, if you&#39;re going to have a public getter and setter why not make your =
member public already? The syntax will be much easier to type and read with=
 &quot;x.n =3D 42&quot; than &quot;x.get_n()&quot;, and the compiler will g=
enerate a call to a generated &quot;set_n&quot; method. Saying that the und=
erlying implementation of the class may change but not the public interface=
 so we don&#39;t want to expose member variables is invalid in this case, s=
ince changing the class internals would require to re-compile the program a=
nd unless the variables type, names and layout didn&#39;t change that would=
 break existing code.<br>
The only place where I&#39;d see this be useful would be if the setter and =
getters are virtual, because a sub-class implementation could be hidden and=
 in that case it wouldn&#39;t break code using objects through the base typ=
e... I&#39;m not sure that&#39;s a very relevant use case.<br>
<br>2. implicitly called functions<br><br>Some languages allow for nice loo=
king syntax with implicit function calls (Python, Ruby... ), where function=
s that do little more than accessing a field of a sub object. You can write=
 things like &quot;x.n =3D 42&quot; and that implicitly calls a method of t=
he object, so we can do checks on the variable type for example... most lan=
guages I know that use this kind of approaches are dynamically typed and th=
ese kind of tricks allow for runtime type checking. But C++ already has a p=
owerful type system so this isn&#39;t a use case.<br>
Some other times, the implicitly called functions are used to check the run=
time value of parameters or modify the values, for example, storing things =
internally with a different type than the one exposed in the public interfa=
ce or making sure an integer stays within a certain range. These problems c=
an easily be solved with library code and operator overloading, I don&#39;t=
 think there&#39;s a need for a new language feature for this case.<br>
<br>3. Read-only or Write-only fields<br><br>So you make your class members=
 public, but you want to make sure they are accessed in a read-only fashion=
ed. First of all, if your objects are used through constant references this=
 will be implicitly enforced, so the only case this is necessary would be w=
hen the object is available through a non-constant type.<br>
You could make the fields constant but you can&#39;t assign instances of yo=
ur class since it contains constant non-static members. So instead you coul=
d write some template &quot;property&quot; template class that wraps around=
 the actual type and would provide read-only or write-only operations throu=
gh operator overloading, until someone writes such a library to solve some =
real-world problems and shows which are the limitations enforced by the cur=
rent C++ standard I don&#39;t think it&#39;s worth wasting time thinking ab=
out how to introduce a new syntax to support this use case.<br>
<br><br>Left aside issues like getting a pointer to member which happens to=
 be a property... what would be the type of &quot;&amp;A::x&quot; if x is a=
 property of class A?<br>In the end I feel like there&#39;s very little int=
eresting use-cases for properties in C++, and most of these problems could =
be solved with library code.<div class=3D"">
<br><br><br>On Friday, June 6, 2014 10:47:33 AM UTC-7, Tom Joe wrote:</div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;borde=
r-left:1px #ccc solid;padding-left:1ex"><div class=3D""><div dir=3D"ltr"><p=
re>Just wanted to add that MSVC has addressed these issues somehow with the=
ir compiler.  I&#39;m not sure how they handle it since I&#39;m actually ra=
ther a newbie to C++.<br>
</pre><pre>After reading N1384 <a href=3D"http://www.open-std.org/jtc1/sc22=
/wg21/docs/papers/2002/n1384.pdf" target=3D"_blank">http://www.open-std.org=
/jtc1/<u></u>sc22/wg21/docs/papers/2002/<u></u>n1384.pdf</a> it appears thi=
s could be a user implemented design; but I feel most are going to want som=
e standard langauge / library to make use of it.<br>

</pre><pre><br>__declspec( property(=C2=A0get=3Dget_func_name=C2=A0) )=C2=
=A0declarator=C2=A0
__declspec( property(=C2=A0put=3Dput_func_name=C2=A0) )=C2=A0declarator=C2=
=A0
__declspec( property(=C2=A0get=3Dget_func_name, put=3Dput_func_name=C2=A0) =
)=C2=A0declarator</pre></div></div><div><br><br><div class=3D"gmail_quote">=
<div class=3D"">On Fri, Jun 6, 2014 at 11:07 AM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a>mw_t...@users.sourceforge.<u></u>net</a>&gt;</span> wrote:<=
br>

</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div class=3D""><div>On 2014-06-06 01:=
02, Miro Knejp wrote:<br>
&gt; I can&#39;t remember how many times I wished I could give a member var=
iable<br>
&gt; public read access without having to boilerplate a getter every time.<=
br>
<br>
</div>Amen to that.<br>
<br>
Historically, I&#39;ve actually done this:<br>
<br>
=C2=A0 public:<br>
=C2=A0 =C2=A0 const T&amp; x =3D mutable_x;<br>
=C2=A0 protected:<br>
=C2=A0 =C2=A0 T mutable_x;<br>
<br>
However this isn&#39;t necessarily the exact same thing as properties.<br>
<br>
It might be nice to be able to write instead:<br>
<br>
=C2=A0 public:<br>
=C2=A0 =C2=A0 using const x;<br>
=C2=A0 =C2=A0 // or &#39;using const x =3D mutable_x&#39;<br>
<br>
=C2=A0 protected:<br>
=C2=A0 =C2=A0 T x;<br>
<span><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span></div><div><div><div class=3D""><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>
</div>

To unsubscribe from this group and all its topics, send an email to <a>std-=
proposal...@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a>std-pr...@isocpp.org</a>.<div class=
=3D""><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></div></blockquote></div><br></div>
</blockquote></div></blockquote></div><br></div></div></div></div></div></d=
iv></div></div></div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8ff2569ca2fc7904fb342336--

.

FWIW,

   some (5?) years ago, I did a proof-of-concept of a library version
of properties, with 0 overhead.
The use case: https://code.google.com/p/mili/source/browse/examples/example=
_properties.cpp

The implementation:
https://code.google.com/p/mili/source/browse/mili/properties.h

I barely recall the details, but the main trick was to place all the
properties in a union at the beginning of the class, so "this" was
both the pointer of the property class and the container class.

I would probably implement it differently nowadays, too many things
changed, and I don't want to get into this discussion too deeply, just
to mention this idea.

Maybe a more general approach would be the ability to "embed" (or
enclose) classes into other classes, as a sibling flavor of
nesting-relationship, where "this" is shared. IOW, each embedded class
has access to the contained class' "this" ptr.

Hope this adds some value to the discussion.

   Daniel.

On Thu, Jun 5, 2014 at 4:23 PM,  <tgit28@gmail.com> wrote:
> I know this has been discussed many times before with blocked results; bu=
t I
> truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property".  There =
are
> many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--=20
Who=E2=80=99s got the sweetest disposition?
One guess, that=E2=80=99s who?
Who=E2=80=99d never, ever start an argument?
Who never shows a bit of temperament?
Who's never wrong but always right?
Who'd never dream of starting a fight?
Who get stuck with all the bad luck?

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_206_29929228.1402306261320
Content-Type: text/plain; charset=UTF-8

A convention used in quite a few places (Boost among others) is to write
"properties" with a getter a nullary member function (usually const) and a
setter a unary member function, both with the same name; foo(), foo(x), not
getFoo(), setFoo(x).

This suggests a fairly conservative language extension to sugar
property-style access to member functions following that convention:

1. Add to [lex.name] Table 3 an identifier with special meaning: property.
 This can be written after nullary and unary member functions, and
indicates that property-style access to that member function is enabled.
2. In the [expr.ref] rules for class member access where E1.E2 is a
non-static member function, add the following:
If E2 is marked with property and the expression E1.E2 is the (possibly
parenthesized) left-hand operand of an assignment expression, the
assignment expression E1.E2 = E3 is rewritten to (E1.E2)(E3);
Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand of a
member function call, then [the current rules apply];
Otherwise, if E2 is marked with property, the expression E1.E2 is rewritten
to (E1.E2)();
Otherwise, the expression is ill-formed.

Here we're completely sidestepping the issue of the type and value category
of a property access expression by presenting it as a syntactic rewrite.
This means that we don't need to worry about pointers and references to
member properties; other than their enhanced class member access rules
properties are just member functions, and property doesn't affect their
type at all.

Note that it is still possible to call the member function with usual
(member function call) syntax. This is essential for being able to access
overloads with higher arity. It also offers a pain-free adoption pathway
for libraries that already use the suggested convention; just use a macro
that expands to property on versions of C++ that offer the facility and
expands to nothing on older versions.

Example:

struct S {
    int foo() const property;
    void foo(int i) property;
};
S s;
s.foo = 42;    // rewritten to s.foo(42);
std::cout << s.foo << '\n';    // rewritten to s.foo()

One remaining issue is compound assignment operators (and
increment/decrement). I'm not sure whether to expand them or ban them
entirely; one can see an argument for allowing employee.salary *= 1.05
e.g., expanding to employee.salary(employee.salary() * 1.05), but on the
other hand for types with memory allocation such a rule could result in
unexpected copies.

Regards, Ed

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">A convention used in quite a few places (Boost among other=
s) is to write "properties" with a getter a nullary member function (usuall=
y const) and a setter a unary member function, both with the same name; <fo=
nt face=3D"courier new, monospace">foo()</font>, <font face=3D"courier new,=
 monospace">foo(x)</font>, not <font face=3D"courier new, monospace">getFoo=
()</font>, <font face=3D"courier new, monospace">setFoo(x)</font>.<div><br>=
</div><div>This suggests a fairly conservative language extension to sugar =
property-style access to member functions following that convention:</div><=
div><br></div><div>1. Add to [lex.name] Table 3 an identifier with special =
meaning: <font face=3D"courier new, monospace">property</font>. &nbsp;This =
can be written after nullary and unary member functions, and indicates that=
 property-style access to that member function is enabled.</div><div>2. In =
the [expr.ref] rules for class member access where <font face=3D"courier ne=
w, monospace">E1.E2</font>&nbsp;is a non-static member function, add the fo=
llowing:</div><div>If <font face=3D"courier new, monospace">E2</font> is ma=
rked with <font face=3D"courier new, monospace">property</font> and the exp=
ression <font face=3D"courier new, monospace">E1.E2</font> is the (possibly=
 parenthesized) left-hand operand of an assignment expression, the assignme=
nt expression <font face=3D"courier new, monospace">E1.E2 =3D E3</font> is =
rewritten to <font face=3D"courier new, monospace">(E1.E2)(E3)</font>;</div=
><div>Otherwise, if <font face=3D"courier new, monospace">E1.E2</font> is t=
he&nbsp;(possibly parenthesized)&nbsp;left-hand operand of a member functio=
n call, then [the current rules apply];</div><div>Otherwise, if <font face=
=3D"courier new, monospace">E2</font> is marked with <font face=3D"courier =
new, monospace">property</font>, the expression <font face=3D"courier new, =
monospace">E1.E2</font> is rewritten to <font face=3D"courier new, monospac=
e">(E1.E2)()</font>;</div><div>Otherwise, the expression is ill-formed.</di=
v><div><br></div><div>Here we're completely sidestepping the issue of the t=
ype and value category of a property access expression by presenting it as =
a syntactic rewrite. This means that we don't need to worry about pointers =
and references to member properties; other than their enhanced class member=
 access rules properties are just member functions, and <font face=3D"couri=
er new, monospace">property</font> doesn't affect their type at all.</div><=
div><br></div><div>Note that it is still possible to call the member functi=
on with usual (member function call) syntax. This is essential for being ab=
le to access overloads with higher arity. It also offers a pain-free adopti=
on pathway for libraries that already use the suggested convention; just us=
e a macro that expands to <font face=3D"courier new, monospace">property</f=
ont> on versions of C++ that offer the facility and expands to nothing on o=
lder versions.</div><div><br></div><div>Example:</div><div><br></div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wr=
ap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D=
"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> S </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> foo</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> property</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> foo</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> i</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> property</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>S s</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>s</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">foo </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-prett=
ify">42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbs=
p;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">// rewri=
tten to s.foo(42);</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br>std</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">cou=
t </span><span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;&lt;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> s</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">foo </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;&lt;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;=
" class=3D"styled-by-prettify">'\n'</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> &nbsp; &nbsp;</span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">// rewritten to s.foo()</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span></div></code></div><div><br>One=
 remaining issue is compound assignment operators (and increment/decrement)=
.. I'm not sure whether to expand them or ban them entirely; one can see an =
argument for allowing <font face=3D"courier new, monospace">employee.salary=
 *=3D 1.05</font> e.g., expanding to <font face=3D"courier new, monospace">=
employee.salary(employee.salary() * 1.05)</font>, but on the other hand for=
 types with memory allocation such a rule could result in unexpected copies=
..</div><div><br></div><div>Regards, Ed</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_206_29929228.1402306261320--

.

--047d7bd6c514a39b0c04fb643660
Content-Type: text/plain; charset=UTF-8

I link this idea, it requires only minimal modifications to the grammar.
One (mostly philosophical) objection would be that it overloads the meaning
of the assignment operator.
Concerning compound assignment, I'd ban them for now. C++ doesn't require
compound assignment to have the same meaning as binary operator +
assignment, and a rewriting rule for properties would enforce such a rule
and would make it harder to reason about what is actually happening.
A minor inconvenience is that, for mutable reference return types, the
expression o.p++ would be invalid, but o.p()++ would be valid.

On Mon Jun 09 2014 at 11:31:02, Edward Catmur <ed@catmur.co.uk> wrote:

> A convention used in quite a few places (Boost among others) is to write
> "properties" with a getter a nullary member function (usually const) and a
> setter a unary member function, both with the same name; foo(), foo(x),
> not getFoo(), setFoo(x).
>
> This suggests a fairly conservative language extension to sugar
> property-style access to member functions following that convention:
>
> 1. Add to [lex.name] Table 3 an identifier with special meaning: property.
>  This can be written after nullary and unary member functions, and
> indicates that property-style access to that member function is enabled.
> 2. In the [expr.ref] rules for class member access where E1.E2 is a
> non-static member function, add the following:
> If E2 is marked with property and the expression E1.E2 is the (possibly
> parenthesized) left-hand operand of an assignment expression, the
> assignment expression E1.E2 = E3 is rewritten to (E1.E2)(E3);
> Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand of
> a member function call, then [the current rules apply];
> Otherwise, if E2 is marked with property, the expression E1.E2 is
> rewritten to (E1.E2)();
> Otherwise, the expression is ill-formed.
>
> Here we're completely sidestepping the issue of the type and value
> category of a property access expression by presenting it as a syntactic
> rewrite. This means that we don't need to worry about pointers and
> references to member properties; other than their enhanced class member
> access rules properties are just member functions, and property doesn't
> affect their type at all.
>
> Note that it is still possible to call the member function with usual
> (member function call) syntax. This is essential for being able to access
> overloads with higher arity. It also offers a pain-free adoption pathway
> for libraries that already use the suggested convention; just use a macro
> that expands to property on versions of C++ that offer the facility and
> expands to nothing on older versions.
>
> Example:
>
> struct S {
>     int foo() const property;
>     void foo(int i) property;
> };
> S s;
> s.foo = 42;    // rewritten to s.foo(42);
> std::cout << s.foo << '\n';    // rewritten to s.foo()
>
> One remaining issue is compound assignment operators (and
> increment/decrement). I'm not sure whether to expand them or ban them
> entirely; one can see an argument for allowing employee.salary *= 1.05
> e.g., expanding to employee.salary(employee.salary() * 1.05), but on the
> other hand for types with memory allocation such a rule could result in
> unexpected copies.
>
> Regards, Ed
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd6c514a39b0c04fb643660
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I link this idea, it requires only minimal modifications to the grammar.<br=
>One (mostly philosophical) objection would be that it overloads the meanin=
g of the assignment operator.<div>Concerning compound assignment, I&#39;d b=
an them for now. C++ doesn&#39;t require compound assignment to have the sa=
me meaning as binary operator=C2=A0+ assignment, and a rewriting rule for p=
roperties would enforce such a rule and would make it harder to reason abou=
t what is actually happening.</div>
<div>A minor inconvenience is that, for mutable reference return types, the=
 expression o.p++ would be invalid, but o.p()++ would be valid.</div><br><d=
iv>On Mon Jun 09 2014 at 11:31:02, Edward Catmur &lt;<a href=3D"mailto:ed@c=
atmur.co.uk">ed@catmur.co.uk</a>&gt; wrote:</div>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">A convention used in quite =
a few places (Boost among others) is to write &quot;properties&quot; with a=
 getter a nullary member function (usually const) and a setter a unary memb=
er function, both with the same name; <font face=3D"courier new, monospace"=
>foo()</font>, <font face=3D"courier new, monospace">foo(x)</font>, not <fo=
nt face=3D"courier new, monospace">getFoo()</font>, <font face=3D"courier n=
ew, monospace">setFoo(x)</font>.<div>
<br></div><div>This suggests a fairly conservative language extension to su=
gar property-style access to member functions following that convention:</d=
iv><div><br></div><div>1. Add to [<a href=3D"http://lex.name" target=3D"_bl=
ank">lex.name</a>] Table 3 an identifier with special meaning: <font face=
=3D"courier new, monospace">property</font>. =C2=A0This can be written afte=
r nullary and unary member functions, and indicates that property-style acc=
ess to that member function is enabled.</div>
<div>2. In the [expr.ref] rules for class member access where <font face=3D=
"courier new, monospace">E1.E2</font>=C2=A0is a non-static member function,=
 add the following:</div><div>If <font face=3D"courier new, monospace">E2</=
font> is marked with <font face=3D"courier new, monospace">property</font> =
and the expression <font face=3D"courier new, monospace">E1.E2</font> is th=
e (possibly parenthesized) left-hand operand of an assignment expression, t=
he assignment expression <font face=3D"courier new, monospace">E1.E2 =3D E3=
</font> is rewritten to <font face=3D"courier new, monospace">(E1.E2)(E3)</=
font>;</div>
<div>Otherwise, if <font face=3D"courier new, monospace">E1.E2</font> is th=
e=C2=A0(possibly parenthesized)=C2=A0left-hand operand of a member function=
 call, then [the current rules apply];</div><div>Otherwise, if <font face=
=3D"courier new, monospace">E2</font> is marked with <font face=3D"courier =
new, monospace">property</font>, the expression <font face=3D"courier new, =
monospace">E1.E2</font> is rewritten to <font face=3D"courier new, monospac=
e">(E1.E2)()</font>;</div>
<div>Otherwise, the expression is ill-formed.</div><div><br></div><div>Here=
 we&#39;re completely sidestepping the issue of the type and value category=
 of a property access expression by presenting it as a syntactic rewrite. T=
his means that we don&#39;t need to worry about pointers and references to =
member properties; other than their enhanced class member access rules prop=
erties are just member functions, and <font face=3D"courier new, monospace"=
>property</font> doesn&#39;t affect their type at all.</div>
<div><br></div><div>Note that it is still possible to call the member funct=
ion with usual (member function call) syntax. This is essential for being a=
ble to access overloads with higher arity. It also offers a pain-free adopt=
ion pathway for libraries that already use the suggested convention; just u=
se a macro that expands to <font face=3D"courier new, monospace">property</=
font> on versions of C++ that offer the facility and expands to nothing on =
older versions.</div>
<div><br></div><div>Example:</div><div><br></div><div style=3D"border:1px s=
olid rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250=
)"><code><div><span style=3D"color:#008">struct</span><span style=3D"color:=
#000"> S </span><span style=3D"color:#660">{</span><span style=3D"color:#00=
0"><br>
=C2=A0 =C2=A0 </span><span style=3D"color:#008">int</span><span style=3D"co=
lor:#000"> foo</span><span style=3D"color:#660">()</span><span style=3D"col=
or:#000"> </span><span style=3D"color:#008">const</span><span style=3D"colo=
r:#000"> property</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"><br>
=C2=A0 =C2=A0 </span><span style=3D"color:#008">void</span><span style=3D"c=
olor:#000"> foo</span><span style=3D"color:#660">(</span><span style=3D"col=
or:#008">int</span><span style=3D"color:#000"> i</span><span style=3D"color=
:#660">)</span><span style=3D"color:#000"> property</span><span style=3D"co=
lor:#660">;</span><span style=3D"color:#000"><br>
</span><span style=3D"color:#660">};</span><span style=3D"color:#000"><br>S=
 s</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
s</span><span style=3D"color:#660">.</span><span style=3D"color:#000">foo <=
/span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#066">42</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"> =C2=A0 =C2=A0</span><span style=3D"color:#800">/=
/ rewritten to s.foo(42);</span><span style=3D"color:#000"><br>
std</span><span style=3D"color:#660">::</span><span style=3D"color:#000">co=
ut </span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#0=
00"> s</span><span style=3D"color:#660">.</span><span style=3D"color:#000">=
foo </span><span style=3D"color:#660">&lt;&lt;</span><span style=3D"color:#=
000"> </span><span style=3D"color:#080">&#39;\n&#39;</span><span style=3D"c=
olor:#660">;</span><span style=3D"color:#000"> =C2=A0 =C2=A0</span><span st=
yle=3D"color:#800">// rewritten to s.foo()</span><span style=3D"color:#000"=
><br>
</span></div></code></div><div><br>One remaining issue is compound assignme=
nt operators (and increment/decrement). I&#39;m not sure whether to expand =
them or ban them entirely; one can see an argument for allowing <font face=
=3D"courier new, monospace">employee.salary *=3D 1.05</font> e.g., expandin=
g to <font face=3D"courier new, monospace">employee.salary(employee.salary(=
) * 1.05)</font>, but on the other hand for types with memory allocation su=
ch a rule could result in unexpected copies.</div>
<div><br></div><div>Regards, Ed</div></div>

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd6c514a39b0c04fb643660--

.

Maybe it'd be simpeler to not rewrite 's.foo = 42;' to 's.foo(42);',
but just to 's.foo() = 42;'. That way, there is nothing special about
the assignment operator, just that .foo is implicitly called. That
way, we can support-read only properties by just returning by value or
reference-to-const, read/write by returning a reference-to-non-const,
and support more advanced stuff (with value checking, etc.) by
returning an object of a type with (compound) assignment operator(s)
overloaded.

2014-06-09 11:31 GMT+02:00 Edward Catmur <ed@catmur.co.uk>:
> A convention used in quite a few places (Boost among others) is to write
> "properties" with a getter a nullary member function (usually const) and a
> setter a unary member function, both with the same name; foo(), foo(x), not
> getFoo(), setFoo(x).
>
> This suggests a fairly conservative language extension to sugar
> property-style access to member functions following that convention:
>
> 1. Add to [lex.name] Table 3 an identifier with special meaning: property.
> This can be written after nullary and unary member functions, and indicates
> that property-style access to that member function is enabled.
> 2. In the [expr.ref] rules for class member access where E1.E2 is a
> non-static member function, add the following:
> If E2 is marked with property and the expression E1.E2 is the (possibly
> parenthesized) left-hand operand of an assignment expression, the assignment
> expression E1.E2 = E3 is rewritten to (E1.E2)(E3);
> Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand of a
> member function call, then [the current rules apply];
> Otherwise, if E2 is marked with property, the expression E1.E2 is rewritten
> to (E1.E2)();
> Otherwise, the expression is ill-formed.
>
> Here we're completely sidestepping the issue of the type and value category
> of a property access expression by presenting it as a syntactic rewrite.
> This means that we don't need to worry about pointers and references to
> member properties; other than their enhanced class member access rules
> properties are just member functions, and property doesn't affect their type
> at all.
>
> Note that it is still possible to call the member function with usual
> (member function call) syntax. This is essential for being able to access
> overloads with higher arity. It also offers a pain-free adoption pathway for
> libraries that already use the suggested convention; just use a macro that
> expands to property on versions of C++ that offer the facility and expands
> to nothing on older versions.
>
> Example:
>
> struct S {
>     int foo() const property;
>     void foo(int i) property;
> };
> S s;
> s.foo = 42;    // rewritten to s.foo(42);
> std::cout << s.foo << '\n';    // rewritten to s.foo()
>
> One remaining issue is compound assignment operators (and
> increment/decrement). I'm not sure whether to expand them or ban them
> entirely; one can see an argument for allowing employee.salary *= 1.05 e.g.,
> expanding to employee.salary(employee.salary() * 1.05), but on the other
> hand for types with memory allocation such a rule could result in unexpected
> copies.
>
> Regards, Ed
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_487_4729011.1402312170296
Content-Type: text/plain; charset=UTF-8

On Monday, 9 June 2014 11:11:16 UTC+1, Maurice Bos wrote:
>
> Maybe it'd be simpeler to not rewrite 's.foo = 42;' to 's.foo(42);',
> but just to 's.foo() = 42;'. That way, there is nothing special about
> the assignment operator, just that .foo is implicitly called. That
> way, we can support-read only properties by just returning by value or
> reference-to-const, read/write by returning a reference-to-non-const,
> and support more advanced stuff (with value checking, etc.) by
> returning an object of a type with (compound) assignment operator(s)
> overloaded.
>

That's what David Krauss's inline variables proposal would enable. I think
it's elegant, but there's quite a bit of conceptual and syntactic overhead
with the proxy object:

struct S {
    inline int foo() const { return ... }
    inline rw_property<int> foo() {
        return {
            [this]() { return ...; },    // getter
            [this](int i) { ... }    // setter
        };
    }
};

Note that you have to provide a separate const accessor, which increases
the potential for code duplication and resultant errors.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, 9 June 2014 11:11:16 UTC+1, Maurice Bos wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border=
-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style:=
 solid; padding-left: 1ex;">Maybe it'd be simpeler to not rewrite 's.foo =
=3D 42;' to 's.foo(42);',&nbsp;<br>but just to 's.foo() =3D 42;'. That way,=
 there is nothing special about&nbsp;<br>the assignment operator, just that=
 .foo is implicitly called. That&nbsp;<br>way, we can support-read only pro=
perties by just returning by value or&nbsp;<br>reference-to-const, read/wri=
te by returning a reference-to-non-const,&nbsp;<br>and support more advance=
d stuff (with value checking, etc.) by&nbsp;<br>returning an object of a ty=
pe with (compound) assignment operator(s)&nbsp;<br>overloaded.&nbsp;<br></b=
lockquote><div><br></div><div>That's what David Krauss's inline variables p=
roposal would enable. I think it's elegant, but there's quite a bit of conc=
eptual and syntactic overhead with the proxy object:</div><div><br></div><d=
iv class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); wor=
d-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> S </span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"><br>&nbsp; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-=
by-prettify">inline</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
int</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> rw_property</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">&lt;int&gt;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> foo</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">()</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; </span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">]()</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">...;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">},</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> &nbsp; &nbsp;</span=
><span style=3D"color: #800;" class=3D"styled-by-prettify">// getter</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp;=
 &nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">[</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">this</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> i</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> &nbs=
p; &nbsp;</span><span style=3D"color: #800;" class=3D"styled-by-prettify">/=
/ setter</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>&nbsp; &nbsp; &nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>&nbsp; &nbsp; </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">};</span></div></code></div><div><br></div><div>Note that you have to =
provide a separate const accessor, which increases the potential for code d=
uplication and resultant errors.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_487_4729011.1402312170296--

.

--001a1133b4a47a24cd04fb6a0cb6
Content-Type: text/plain; charset=UTF-8

However, the more advanced case with value checking will come up quite
often because often it's the reason why properties are used in the first
place instead of data members. I think this case should be kept as simple
as possible, without requiring proxy objects.

On Mon Jun 09 2014 at 12:11:16, Maurice Bos <m-ou.se@m-ou.se> wrote:

> Maybe it'd be simpeler to not rewrite 's.foo = 42;' to 's.foo(42);',
> but just to 's.foo() = 42;'. That way, there is nothing special about
> the assignment operator, just that .foo is implicitly called. That
> way, we can support-read only properties by just returning by value or
> reference-to-const, read/write by returning a reference-to-non-const,
> and support more advanced stuff (with value checking, etc.) by
> returning an object of a type with (compound) assignment operator(s)
> overloaded.
>
> 2014-06-09 11:31 GMT+02:00 Edward Catmur <ed@catmur.co.uk>:
> > A convention used in quite a few places (Boost among others) is to write
> > "properties" with a getter a nullary member function (usually const) and
> a
> > setter a unary member function, both with the same name; foo(), foo(x),
> not
> > getFoo(), setFoo(x).
> >
> > This suggests a fairly conservative language extension to sugar
> > property-style access to member functions following that convention:
> >
> > 1. Add to [lex.name] Table 3 an identifier with special meaning:
> property.
> > This can be written after nullary and unary member functions, and
> indicates
> > that property-style access to that member function is enabled.
> > 2. In the [expr.ref] rules for class member access where E1.E2 is a
> > non-static member function, add the following:
> > If E2 is marked with property and the expression E1.E2 is the (possibly
> > parenthesized) left-hand operand of an assignment expression, the
> assignment
> > expression E1.E2 = E3 is rewritten to (E1.E2)(E3);
> > Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand of
> a
> > member function call, then [the current rules apply];
> > Otherwise, if E2 is marked with property, the expression E1.E2 is
> rewritten
> > to (E1.E2)();
> > Otherwise, the expression is ill-formed.
> >
> > Here we're completely sidestepping the issue of the type and value
> category
> > of a property access expression by presenting it as a syntactic rewrite.
> > This means that we don't need to worry about pointers and references to
> > member properties; other than their enhanced class member access rules
> > properties are just member functions, and property doesn't affect their
> type
> > at all.
> >
> > Note that it is still possible to call the member function with usual
> > (member function call) syntax. This is essential for being able to access
> > overloads with higher arity. It also offers a pain-free adoption pathway
> for
> > libraries that already use the suggested convention; just use a macro
> that
> > expands to property on versions of C++ that offer the facility and
> expands
> > to nothing on older versions.
> >
> > Example:
> >
> > struct S {
> >     int foo() const property;
> >     void foo(int i) property;
> > };
> > S s;
> > s.foo = 42;    // rewritten to s.foo(42);
> > std::cout << s.foo << '\n';    // rewritten to s.foo()
> >
> > One remaining issue is compound assignment operators (and
> > increment/decrement). I'm not sure whether to expand them or ban them
> > entirely; one can see an argument for allowing employee.salary *= 1.05
> e.g.,
> > expanding to employee.salary(employee.salary() * 1.05), but on the other
> > hand for types with memory allocation such a rule could result in
> unexpected
> > copies.
> >
> > Regards, Ed
> >
> > --
> >
> > ---
> > 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.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> 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.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1133b4a47a24cd04fb6a0cb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

However, the more advanced case with value checking will come up quite ofte=
n because often it&#39;s the reason why properties are used in the first pl=
ace instead of data members. I think this case should be kept as simple as =
possible, without requiring proxy objects.<br>
<br><div>On Mon Jun 09 2014 at 12:11:16, Maurice Bos &lt;<a href=3D"mailto:=
m-ou.se@m-ou.se">m-ou.se@m-ou.se</a>&gt; wrote:</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
Maybe it&#39;d be simpeler to not rewrite &#39;s.foo =3D 42;&#39; to &#39;s=
..foo(42);&#39;,<br>
but just to &#39;s.foo() =3D 42;&#39;. That way, there is nothing special a=
bout<br>
the assignment operator, just that .foo is implicitly called. That<br>
way, we can support-read only properties by just returning by value or<br>
reference-to-const, read/write by returning a reference-to-non-const,<br>
and support more advanced stuff (with value checking, etc.) by<br>
returning an object of a type with (compound) assignment operator(s)<br>
overloaded.<br>
<br>
2014-06-09 11:31 GMT+02:00 Edward Catmur &lt;<a href=3D"mailto:ed@catmur.co=
..uk" target=3D"_blank">ed@catmur.co.uk</a>&gt;:<br>
&gt; A convention used in quite a few places (Boost among others) is to wri=
te<br>
&gt; &quot;properties&quot; with a getter a nullary member function (usuall=
y const) and a<br>
&gt; setter a unary member function, both with the same name; foo(), foo(x)=
, not<br>
&gt; getFoo(), setFoo(x).<br>
&gt;<br>
&gt; This suggests a fairly conservative language extension to sugar<br>
&gt; property-style access to member functions following that convention:<b=
r>
&gt;<br>
&gt; 1. Add to [<a href=3D"http://lex.name" target=3D"_blank">lex.name</a>]=
 Table 3 an identifier with special meaning: property.<br>
&gt; This can be written after nullary and unary member functions, and indi=
cates<br>
&gt; that property-style access to that member function is enabled.<br>
&gt; 2. In the [expr.ref] rules for class member access where E1.E2 is a<br=
>
&gt; non-static member function, add the following:<br>
&gt; If E2 is marked with property and the expression E1.E2 is the (possibl=
y<br>
&gt; parenthesized) left-hand operand of an assignment expression, the assi=
gnment<br>
&gt; expression E1.E2 =3D E3 is rewritten to (E1.E2)(E3);<br>
&gt; Otherwise, if E1.E2 is the (possibly parenthesized) left-hand operand =
of a<br>
&gt; member function call, then [the current rules apply];<br>
&gt; Otherwise, if E2 is marked with property, the expression E1.E2 is rewr=
itten<br>
&gt; to (E1.E2)();<br>
&gt; Otherwise, the expression is ill-formed.<br>
&gt;<br>
&gt; Here we&#39;re completely sidestepping the issue of the type and value=
 category<br>
&gt; of a property access expression by presenting it as a syntactic rewrit=
e.<br>
&gt; This means that we don&#39;t need to worry about pointers and referenc=
es to<br>
&gt; member properties; other than their enhanced class member access rules=
<br>
&gt; properties are just member functions, and property doesn&#39;t affect =
their type<br>
&gt; at all.<br>
&gt;<br>
&gt; Note that it is still possible to call the member function with usual<=
br>
&gt; (member function call) syntax. This is essential for being able to acc=
ess<br>
&gt; overloads with higher arity. It also offers a pain-free adoption pathw=
ay for<br>
&gt; libraries that already use the suggested convention; just use a macro =
that<br>
&gt; expands to property on versions of C++ that offer the facility and exp=
ands<br>
&gt; to nothing on older versions.<br>
&gt;<br>
&gt; Example:<br>
&gt;<br>
&gt; struct S {<br>
&gt; =C2=A0 =C2=A0 int foo() const property;<br>
&gt; =C2=A0 =C2=A0 void foo(int i) property;<br>
&gt; };<br>
&gt; S s;<br>
&gt; s.foo =3D 42; =C2=A0 =C2=A0// rewritten to s.foo(42);<br>
&gt; std::cout &lt;&lt; s.foo &lt;&lt; &#39;\n&#39;; =C2=A0 =C2=A0// rewrit=
ten to s.foo()<br>
&gt;<br>
&gt; One remaining issue is compound assignment operators (and<br>
&gt; increment/decrement). I&#39;m not sure whether to expand them or ban t=
hem<br>
&gt; entirely; one can see an argument for allowing employee.salary *=3D 1.=
05 e.g.,<br>
&gt; expanding to employee.salary(employee.<u></u>salary() * 1.05), but on =
the other<br>
&gt; hand for types with memory allocation such a rule could result in unex=
pected<br>
&gt; copies.<br>
&gt;<br>
&gt; Regards, Ed<br>
&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to the Google Gro=
ups<br>
&gt; &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this group and stop receiving emails from it, send=
 an<br>
&gt; email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" tar=
get=3D"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at<br>
&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
 target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.org/group/std-<=
u></u>proposals/</a>.<br>
<br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</blockquote>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1133b4a47a24cd04fb6a0cb6--

.

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



What happens when you copy a class that has properties ?



Em sexta-feira, 6 de junho de 2014 22h32min26s UTC-3, dgutson . escreveu:
>
> FWIW,=20
>
>    some (5?) years ago, I did a proof-of-concept of a library version=20
> of properties, with 0 overhead.=20
> The use case:=20
> https://code.google.com/p/mili/source/browse/examples/example_properties.=
cpp=20
>
> The implementation:=20
> https://code.google.com/p/mili/source/browse/mili/properties.h=20
>
> I barely recall the details, but the main trick was to place all the=20
> properties in a union at the beginning of the class, so "this" was=20
> both the pointer of the property class and the container class.=20
>
> I would probably implement it differently nowadays, too many things=20
> changed, and I don't want to get into this discussion too deeply, just=20
> to mention this idea.=20
>
> Maybe a more general approach would be the ability to "embed" (or=20
> enclose) classes into other classes, as a sibling flavor of=20
> nesting-relationship, where "this" is shared. IOW, each embedded class=20
> has access to the contained class' "this" ptr.=20
>
> Hope this adds some value to the discussion.=20
>
>    Daniel.=20
>
> On Thu, Jun 5, 2014 at 4:23 PM,  <tgi...@gmail.com <javascript:>> wrote:=
=20
> > I know this has been discussed many times before with blocked results;=
=20
> but I=20
> > truly feel if C++ is going to continue outstanding support and=20
> popularity=20
> > into the future it needs to offer the basic idea of a "property".  Ther=
e=20
> are=20
> > many benefits to properties and the only arguments against them are=20
> > ideological from a don't want to change point of view.=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
>
>
>
> --=20
> Who=E2=80=99s got the sweetest disposition?=20
> One guess, that=E2=80=99s who?=20
> Who=E2=80=99d never, ever start an argument?=20
> Who never shows a bit of temperament?=20
> Who's never wrong but always right?=20
> Who'd never dream of starting a fight?=20
> Who get stuck with all the bad luck?=20
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div><br></div><div><br></div>What happens when you copy a=
 class that has properties ?<div><br></div><div><br><br>Em sexta-feira, 6 d=
e junho de 2014 22h32min26s UTC-3, dgutson .  escreveu:<blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">FWIW,
<br>
<br>&nbsp; &nbsp;some (5?) years ago, I did a proof-of-concept of a library=
 version
<br>of properties, with 0 overhead.
<br>The use case: <a href=3D"https://code.google.com/p/mili/source/browse/e=
xamples/example_properties.cpp" target=3D"_blank" onmousedown=3D"this.href=
=3D'https://code.google.com/p/mili/source/browse/examples/example_propertie=
s.cpp';return true;" onclick=3D"this.href=3D'https://code.google.com/p/mili=
/source/browse/examples/example_properties.cpp';return true;">https://code.=
google.com/p/<wbr>mili/source/browse/examples/<wbr>example_properties.cpp</=
a>
<br>
<br>The implementation:
<br><a href=3D"https://code.google.com/p/mili/source/browse/mili/properties=
..h" target=3D"_blank" onmousedown=3D"this.href=3D'https://code.google.com/p=
/mili/source/browse/mili/properties.h';return true;" onclick=3D"this.href=
=3D'https://code.google.com/p/mili/source/browse/mili/properties.h';return =
true;">https://code.google.com/p/<wbr>mili/source/browse/mili/<wbr>properti=
es.h</a>
<br>
<br>I barely recall the details, but the main trick was to place all the
<br>properties in a union at the beginning of the class, so "this" was
<br>both the pointer of the property class and the container class.
<br>
<br>I would probably implement it differently nowadays, too many things
<br>changed, and I don't want to get into this discussion too deeply, just
<br>to mention this idea.
<br>
<br>Maybe a more general approach would be the ability to "embed" (or
<br>enclose) classes into other classes, as a sibling flavor of
<br>nesting-relationship, where "this" is shared. IOW, each embedded class
<br>has access to the contained class' "this" ptr.
<br>
<br>Hope this adds some value to the discussion.
<br>
<br>&nbsp; &nbsp;Daniel.
<br>
<br>On Thu, Jun 5, 2014 at 4:23 PM, &nbsp;&lt;<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"nENytGXdd_wJ" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">tgi...@gmail.com</a>&gt; wrote:
<br>&gt; I know this has been discussed many times before with blocked resu=
lts; but I
<br>&gt; truly feel if C++ is going to continue outstanding support and pop=
ularity
<br>&gt; into the future it needs to offer the basic idea of a "property". =
&nbsp;There are
<br>&gt; many benefits to properties and the only arguments against them ar=
e
<br>&gt; ideological from a don't want to change point of view.
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to the Google=
 Groups
<br>&gt; "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this group and stop receiving emails from it, =
send an
<br>&gt; email to <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"nENytGXdd_wJ" onmousedown=3D"this.href=3D'javascript:';return tru=
e;" onclick=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr=
>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"nENytGXdd_wJ" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups.google.com=
/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=3D'h=
ttp://groups.google.com/a/isocpp.org/group/std-proposals/';return true;">ht=
tp://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Who=E2=80=99s got the sweetest disposition?
<br>One guess, that=E2=80=99s who?
<br>Who=E2=80=99d never, ever start an argument?
<br>Who never shows a bit of temperament?
<br>Who's never wrong but always right?
<br>Who'd never dream of starting a fight?
<br>Who get stuck with all the bad luck?
<br></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_1187_19708433.1402431067728--

.

--Apple-Mail=_199DA1E5-7A8E-4FB3-83E0-83D7B75FB5ED
Content-Type: text/plain; charset=ISO-8859-1

Gutson's system adds no state, so copyability isn't harmed. Unions are copyable as long as all the members are trivially copyable, IIRC.

However, I think it's a non-starter because it only works as long as this is equal to the address of the first member, which is only guaranteed for standard layout types. Adding a non-empty base or a virtual function kills it in practice.

It's still very very clever though, and it definitely clears any lingering doubt that anything separates current C++ from properties besides the ability to get this from a nested class member function.


On 2014-06-11, at 4:11 AM, Cleiton Santoia <cleitonsantoia@gmail.com> wrote:

> What happens when you copy a class that has properties ?
>
>
>
> Em sexta-feira, 6 de junho de 2014 22h32min26s UTC-3, dgutson . escreveu:
> FWIW,
>
>    some (5?) years ago, I did a proof-of-concept of a library version
> of properties, with 0 overhead.
> The use case: https://code.google.com/p/mili/source/browse/examples/example_properties.cpp
>
> The implementation:
> https://code.google.com/p/mili/source/browse/mili/properties.h

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_199DA1E5-7A8E-4FB3-83E0-83D7B75FB5ED
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><div>Gutson&rsquo;s sy=
stem adds no state, so copyability isn&rsquo;t harmed. Unions are copyable =
as long as all the members are trivially copyable, IIRC.</div><div><br></di=
v><div>However, I think it&rsquo;s a non-starter because it only works as l=
ong as this is equal to the address of the first member, which is only guar=
anteed for standard layout types. Adding a non-empty base or a virtual func=
tion kills it in practice.</div><div><br></div><div>It&rsquo;s still very v=
ery clever though, and it definitely clears any lingering doubt that anythi=
ng separates current C++ from properties besides the ability to get <font f=
ace=3D"Courier">this</font> from a nested class member function.</div><div>=
<br></div><br><div><div>On 2014&ndash;06&ndash;11, at 4:11 AM, Cleiton Sant=
oia &lt;<a href=3D"mailto:cleitonsantoia@gmail.com">cleitonsantoia@gmail.co=
m</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><blockquote t=
ype=3D"cite"><div dir=3D"ltr" style=3D"font-family: Helvetica; font-size: 1=
2px; font-style: normal; font-variant: normal; font-weight: normal; letter-=
spacing: normal; line-height: normal; orphans: auto; text-align: start; tex=
t-indent: 0px; text-transform: none; white-space: normal; widows: auto; wor=
d-spacing: 0px; -webkit-text-stroke-width: 0px;"><div>What happens when you=
 copy a class that has properties ?</div><div><br></div><div><br><br>Em sex=
ta-feira, 6 de junho de 2014 22h32min26s UTC-3, dgutson . escreveu:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-w=
idth: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid;=
 padding-left: 1ex; position: static; z-index: auto;">FWIW,<span class=3D"A=
pple-converted-space">&nbsp;</span><br><br>&nbsp; &nbsp;some (5?) years ago=
, I did a proof-of-concept of a library version<span class=3D"Apple-convert=
ed-space">&nbsp;</span><br>of properties, with 0 overhead.<span class=3D"Ap=
ple-converted-space">&nbsp;</span><br>The use case:<span class=3D"Apple-con=
verted-space">&nbsp;</span><a href=3D"https://code.google.com/p/mili/source=
/browse/examples/example_properties.cpp" target=3D"_blank">https://code.goo=
gle.com/p/<wbr>mili/source/browse/examples/<wbr>example_properties.cpp</a><=
span class=3D"Apple-converted-space">&nbsp;</span><br><br>The implementatio=
n:<span class=3D"Apple-converted-space">&nbsp;</span><br><a href=3D"https:/=
/code.google.com/p/mili/source/browse/mili/properties.h" target=3D"_blank">=
https://code.google.com/p/<wbr>mili/source/browse/mili/<wbr>properties.h</a=
><span class=3D"Apple-converted-space">&nbsp;</span><br></blockquote></div>=
</div></blockquote></div><br></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_199DA1E5-7A8E-4FB3-83E0-83D7B75FB5ED--

.

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

On Tuesday, 10 June 2014 23:10:53 UTC+1, David Krauss wrote:
>
> Gutson=E2=80=99s system adds no state, so copyability isn=E2=80=99t harme=
d. Unions are=20
> copyable as long as all the members are trivially copyable, IIRC.
>
> However, I think it=E2=80=99s a non-starter because it only works as long=
 as this=20
> is equal to the address of the first member, which is only guaranteed for=
=20
> standard layout types. Adding a non-empty base or a virtual function kill=
s=20
> it in practice.
>

Adding a known named member into the union allows locating it within the=20
class:

struct property_tag {};
....
    union {
        property_tag properties;
....
    T& self() { return *(T*)((char*)(this) - ((char*)&(((T*)this)->
properties) - (char*)this)); }


Example: http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97
=20

> It=E2=80=99s still very very clever though, and it definitely clears any =
lingering=20
> doubt that anything separates current C++ from properties besides the=20
> ability to get this from a nested class member function.
>

Perhaps what we need is a way to specify that an empty member shares the=20
footprint of its class - something like EBCO for empty members?

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Tuesday, 10 June 2014 23:10:53 UTC+1, David Krauss  wro=
te:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:bre=
ak-word"><div>Gutson=E2=80=99s system adds no state, so copyability isn=E2=
=80=99t harmed. Unions are copyable as long as all the members are triviall=
y copyable, IIRC.</div><div><br></div><div>However, I think it=E2=80=99s a =
non-starter because it only works as long as this is equal to the address o=
f the first member, which is only guaranteed for standard layout types. Add=
ing a non-empty base or a virtual function kills it in practice.</div></div=
></blockquote><div><br></div><div>Adding a known named member into the unio=
n allows locating it within the class:</div><div><br></div><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wrap: break-=
word; background-color: rgb(250, 250, 250);"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> property_tag </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{};</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">..=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp=
; &nbsp; </span><span style=3D"color: #008;" class=3D"styled-by-prettify">u=
nion</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbsp; &nbsp; &nbsp;=
 &nbsp; property_tag properties</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">...</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>&nbsp; &nbsp; T</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">self</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">return</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">*(</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify">T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=
)((</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*)(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">((</span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>*)&amp;(((</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*)</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)-&gt;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">properties</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">char</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
*)</span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br><br></span></div></code></div><di=
v><br></div><div>Example:&nbsp;http://coliru.stacked-crooked.com/a/9f95d3cf=
76fc8b97</div><div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div style=3D"word-wrap:break-word"><div>It=E2=80=99s still very very clev=
er though, and it definitely clears any lingering doubt that anything separ=
ates current C++ from properties besides the ability to get <font face=3D"C=
ourier">this</font> from a nested class member function.</div></div></block=
quote><div><br></div><div>Perhaps what we need is a way to specify that an =
empty member shares the footprint of its class - something like EBCO for em=
pty members?<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_155_1847868.1402482029153--

.

--Apple-Mail=_2C87596F-D7B7-4805-9DBB-BC3A1D3E94A3
Content-Type: text/plain; charset=ISO-8859-1


On 2014-06-11, at 6:20 PM, Edward Catmur <ed@catmur.co.uk> wrote:

>
>     T& self() { return *(T*)((char*)(this) - ((char*)&(((T*)this)->properties) - (char*)this)); }
>
>
> Example: http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97

But, (((T*)this)->properties doesn't really exist, so you get UB if its address happens to overflow the allocation block.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_2C87596F-D7B7-4805-9DBB-BC3A1D3E94A3
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;06&ndash;11, at 6:20 PM, Edward Catmur &lt;<a href=3D"mailto:ed@catmu=
r.co.uk">ed@catmur.co.uk</a>&gt; wrote:</div><br class=3D"Apple-interchange=
-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); word-wra=
p: break-word; background-color: rgb(250, 250, 250); position: static; z-in=
dex: auto;"><code class=3D"prettyprint">&nbsp; &nbsp; T<span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span> <span style=3D"color: #0=
08;" class=3D"styled-by-prettify">self</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">()</span> <span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span> <span style=3D"color: #008;" class=3D"styled-=
by-prettify">return</span> <span style=3D"color: #660;" class=3D"styled-by-=
prettify">*(</span>T<span style=3D"color: #660;" class=3D"styled-by-prettif=
y">*)((</span><span style=3D"color: #008;" class=3D"styled-by-prettify">cha=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*)(</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span> <span style=
=3D"color: #660;" class=3D"styled-by-prettify">-</span> <span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">((</span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">char</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">*)&amp;(((</span>T<span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">*)</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">this</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">)-&gt;</span>properties<span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span> <span style=3D"color: #660;" class=3D"styled-by-=
prettify">-</span> <span style=3D"color: #660;" class=3D"styled-by-prettify=
">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">char</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">*)</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">));</span> <span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">}</span><br><br></code></div><div=
><br></div><div>Example:&nbsp;<a href=3D"http://coliru.stacked-crooked.com/=
a/9f95d3cf76fc8b97">http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97</a=
></div></div></blockquote><div><br></div>But,&nbsp;<font face=3D"Courier">(=
((T*)this)-&gt;properties</font> doesn&rsquo;t really exist, so you get UB =
if its address happens to overflow the allocation block.</div><div><br></di=
v></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_2C87596F-D7B7-4805-9DBB-BC3A1D3E94A3--

.

--047d7b343236b8b9a604fb9403fe
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jun 11, 2014 at 3:26 AM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014=E2=80=9306=E2=80=9311, at 6:20 PM, Edward Catmur <ed@catmur.co.uk=
> wrote:
>
>
>     T& self() { return *(T*)((char*)(this) - ((char*)&(((T*)this)->
> properties) - (char*)this)); }
>
>
> Example: http://coliru.stacked-crooked.com/a/9f95d3cf76fc8b97
>
>
> But, (((T*)this)->properties doesn=E2=80=99t really exist, so you get UB =
if its
> address happens to overflow the allocation block.
>

You get UB regardless, for calling a member function on an object that
doesn't exist.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b343236b8b9a604fb9403fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Jun 11, 2014 at 3:26 AM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"=
mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9306=E2=80=9311, at 6:20 PM, Edward Cat=
mur &lt;<a href=3D"mailto:ed@catmur.co.uk" target=3D"_blank">ed@catmur.co.u=
k</a>&gt; wrote:</div>
<br><blockquote type=3D"cite"><div dir=3D"ltr"><div><br></div><div style=3D=
"border:1px solid rgb(187,187,187);word-wrap:break-word;background-color:rg=
b(250,250,250)"><code>=C2=A0 =C2=A0 T<span style=3D"color:#660">&amp;</span=
> <span style=3D"color:#008">self</span><span style=3D"color:#660">()</span=
> <span style=3D"color:#660">{</span> <span style=3D"color:#008">return</sp=
an> <span style=3D"color:#660">*(</span>T<span style=3D"color:#660">*)((</s=
pan><span style=3D"color:#008">char</span><span style=3D"color:#660">*)(</s=
pan><span style=3D"color:#008">this</span><span style=3D"color:#660">)</spa=
n> <span style=3D"color:#660">-</span> <span style=3D"color:#660">((</span>=
<span style=3D"color:#008">char</span><span style=3D"color:#660">*)&amp;(((=
</span>T<span style=3D"color:#660">*)</span><span style=3D"color:#008">this=
</span><span style=3D"color:#660">)-&gt;</span>properties<span style=3D"col=
or:#660">)</span> <span style=3D"color:#660">-</span> <span style=3D"color:=
#660">(</span><span style=3D"color:#008">char</span><span style=3D"color:#6=
60">*)</span><span style=3D"color:#008">this</span><span style=3D"color:#66=
0">));</span> <span style=3D"color:#660">}</span><br>
<br></code></div><div><br></div><div>Example:=C2=A0<a href=3D"http://coliru=
..stacked-crooked.com/a/9f95d3cf76fc8b97" target=3D"_blank">http://coliru.st=
acked-crooked.com/a/9f95d3cf76fc8b97</a></div></div></blockquote><div><br><=
/div>
</div>But,=C2=A0<font face=3D"Courier">(((T*)this)-&gt;properties</font> do=
esn=E2=80=99t really exist, so you get UB if its address happens to overflo=
w the allocation block.</div></div></blockquote><div><br></div><div>You get=
 UB regardless, for calling a member function on an object that doesn&#39;t=
 exist.=C2=A0</div>
</div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b343236b8b9a604fb9403fe--

.

------=_Part_355_11529783.1402840796836
Content-Type: text/plain; charset=UTF-8

On Saturday, June 7, 2014 1:23:52 AM UTC+2, Achille Roussel wrote:
>
> In the end I feel like there's very little interesting use-cases for
> properties in C++, and most of these problems could be solved with library
> code.
>

That's no argument for not standardizing such library code is it?

IMO public const access to fields would be very useful and trivial to
implement.
Proper properties support is much harder to get right.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Saturday, June 7, 2014 1:23:52 AM UTC+2, Achille Rousse=
l wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">In th=
e end I feel like there's very little interesting use-cases for properties =
in C++, and most of these problems could be solved with library code.</div>=
</blockquote><div><br></div><div>That's no argument for not standardizing s=
uch library code is it?</div><div><br></div><div>IMO public const access to=
 fields would be very useful and trivial to implement.</div><div>Proper pro=
perties support is much harder to get right.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_355_11529783.1402840796836--

.

--001a113625bca7e35a04fd053a64
Content-Type: text/plain; charset=UTF-8

Instead of the "what for" approach maybe a "why not" would make a more
constructive argument.

Anyhow; I don't feel I have the severely needed C++ expertise to write and
submit an informative and proper legitimate proposal short of stating it
should mimic MSVC++ approach for compatibility.  If anyone feels up to it;
jump in. :).


On Sun, Jun 15, 2014 at 7:59 AM, Olaf van der Spek <olafvdspek@gmail.com>
wrote:

> On Saturday, June 7, 2014 1:23:52 AM UTC+2, Achille Roussel wrote:
>>
>> In the end I feel like there's very little interesting use-cases for
>> properties in C++, and most of these problems could be solved with library
>> code.
>>
>
> That's no argument for not standardizing such library code is it?
>
> IMO public const access to fields would be very useful and trivial to
> implement.
> Proper properties support is much harder to get right.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113625bca7e35a04fd053a64
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Instead of the &quot;what for&quot; approach maybe a =
&quot;why not&quot; would make a more constructive argument.<br><br></div>A=
nyhow; I don&#39;t feel I have the severely needed C++ expertise to write a=
nd submit an informative and proper legitimate proposal short of stating it=
 should mimic MSVC++ approach for compatibility.=C2=A0 If anyone feels up t=
o it; jump in. :).<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sun,=
 Jun 15, 2014 at 7:59 AM, Olaf van der Spek <span dir=3D"ltr">&lt;<a href=
=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdspek@gmail.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On Saturday=
, June 7, 2014 1:23:52 AM UTC+2, Achille Roussel wrote:<blockquote class=3D=
"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div dir=3D"ltr">In the end I feel like there&#39;s very little interesting=
 use-cases for properties in C++, and most of these problems could be solve=
d with library code.</div></blockquote><div><br></div></div><div>That&#39;s=
 no argument for not standardizing such library code is it?</div>
<div><br></div><div>IMO public const access to fields would be very useful =
and trivial to implement.</div><div>Proper properties support is much harde=
r to get right.<br></div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113625bca7e35a04fd053a64--

.

------=_Part_959_33462764.1404771806725
Content-Type: text/plain; charset=UTF-8

I'm not convinced.  Properties can be extraordinarily expensive completely
hidden calls.  This could be argued for any other kind of operator
overloading, but in particular it is an affliction of getter properties
which do a lot of processing in what looks like a no-op.

int x = test.size;

size could easily iterate over a million elements.  It looks like a simple
assignment to an int.  There would be no indication you're actually doing a
ton of work.

Here is a very real example of a problematic property I encountered in C#
(using Unity) recently:

for( int i = 0; i < meshData.Vertices.Count; i++){
 ...
}

Over the course of iterating over the vertices about 8 megabytes of copying
was occuring which in C# land means a lot of garbage.  Can you spot why?

meshData.Vertices returned a copy of the vertex array, and then .Count was
called on that copy.  The allocations caused by looping in this manner
created an extra ~2 second frame spikes while the garbage collector cleaned
up on an iPhone.

Calling this, however, is basically free:

for( int i = 0; i < meshData.VertexCount; i++){
 ...
}

So, what was my take-away?  Properties are Evil(TM) they encourage unsafe
and difficult to detect incorrect usage patterns.  If I were working in C++
I might have seen:

for( int i = 0; i < meshData.Vertices().Count; i++){
 ...
}

At this point the () triggers a very visual cue that something is up beyond
simple member access.  Count appears to be cached, Vertices() is obviously
a function call, and if I see that I can start to dig in.  Now, C++ doesn't
have a garbage collector to worry about, and is way less liberal about
unnecessary copies... But to say "there are many benefits to properties and
the only arguments against them are ideological" is simply wrong.
 Properties have absolutely been treated as second-class citizens in C#,
and in Unity for sure, and they are a source of difficult to detect
performance issues.

As an alternative idiom to properties I've adopted the following convenient
syntax:

#include <iostream>

class MyClass {
public:
int x() const{
return m_x;
}

MyClass& x(int a_x){
m_x = a_x;
return *this;
}

int y() const{
return m_y;
}

MyClass& y(int a_y){
m_y = a_y;
return *this;
}
private:
int m_x = 0;
int m_y = 0;
};

int main(){
MyClass point;
point.x(5).y(10);

std::cout << point.x() << ", " << point.y() << std::endl;
}

On Thursday, June 5, 2014 12:23:53 PM UTC-7, tgi...@gmail.com wrote:
>
> I know this has been discussed many times before with blocked results; but
> I truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property".  There
> are many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I'm not convinced. &nbsp;Properties can be extraordinarily=
 expensive completely hidden calls. &nbsp;This could be argued for any othe=
r kind of operator overloading, but in particular it is an affliction of ge=
tter properties which do a lot of processing in what looks like a no-op.<di=
v><br></div><div>int x =3D test.size;</div><div><br></div><div>size could e=
asily iterate over a million elements. &nbsp;It looks like a simple assignm=
ent to an int. &nbsp;There would be no indication you're actually doing a t=
on of work.</div><div><br></div><div>Here is a very real example of a probl=
ematic property I encountered in C# (using Unity) recently:</div><div><br><=
/div><div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  <=
/span>for( int i =3D 0; i &lt; meshData.Vertices.Count; i++){</div></div><d=
iv><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span><spa=
n class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>...<br></di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>=
}<br></div><div><br></div><div>Over the course of iterating over the vertic=
es about 8 megabytes of copying was occuring which in C# land means a lot o=
f garbage. &nbsp;Can you spot why?</div><div><br></div><div>meshData.Vertic=
es returned a copy of the vertex array, and then .Count was called on that =
copy. &nbsp;The allocations caused by looping in this manner created an ext=
ra ~2 second frame spikes while the garbage collector cleaned up on an iPho=
ne.</div><div><br></div><div>Calling this, however, is basically free:</div=
><div><br></div><div><div><span class=3D"Apple-tab-span" style=3D"white-spa=
ce: pre;">  </span>for( int i =3D 0; i &lt; meshData.VertexCount; i++){</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>=
<span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>...<br>=
</div><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </s=
pan>}</div></div><div><br></div><div>So, what was my take-away? &nbsp;Prope=
rties are Evil(TM) they encourage unsafe and difficult to detect incorrect =
usage patterns. &nbsp;If I were working in C++ I might have seen:</div><div=
><br></div><div><div><span class=3D"Apple-tab-span" style=3D"white-space: p=
re;">  </span>for( int i =3D 0; i &lt; meshData.Vertices().Count; i++){</di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>=
<span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </span>...<br>=
</div><div><span class=3D"Apple-tab-span" style=3D"white-space: pre;">  </s=
pan>}</div></div><div><br></div><div>At this point the () triggers a very v=
isual cue that something is up beyond simple member access. &nbsp;Count app=
ears to be cached, Vertices() is obviously a function call, and if I see th=
at I can start to dig in. &nbsp;Now, C++ doesn't have a garbage collector t=
o worry about, and is way less liberal about unnecessary copies... But to s=
ay "there are many benefits to properties and the only arguments against th=
em are ideological" is simply wrong. &nbsp;Properties have absolutely been =
treated as second-class citizens in C#, and in Unity for sure, and they are=
 a source of difficult to detect performance issues.</div><div><br></div><d=
iv>As an alternative idiom to properties I've adopted the following conveni=
ent syntax:</div><div><br></div><div><div>#include &lt;iostream&gt;</div><d=
iv><br></div><div>class MyClass {</div><div>public:</div><div><span class=
=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int x() const{</div><=
div><span class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>retur=
n m_x;</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> =
</span>}</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"w=
hite-space:pre"> </span>MyClass&amp; x(int a_x){</div><div><span class=3D"A=
pple-tab-span" style=3D"white-space:pre">  </span>m_x =3D a_x;</div><div><s=
pan class=3D"Apple-tab-span" style=3D"white-space:pre">  </span>return *thi=
s;</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </sp=
an>}</div><div><br></div><div><span class=3D"Apple-tab-span" style=3D"white=
-space:pre"> </span>int y() const{</div><div><span class=3D"Apple-tab-span"=
 style=3D"white-space:pre">  </span>return m_y;</div><div><span class=3D"Ap=
ple-tab-span" style=3D"white-space:pre"> </span>}</div><div><br></div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>MyClass&am=
p; y(int a_y){</div><div><span class=3D"Apple-tab-span" style=3D"white-spac=
e:pre">  </span>m_y =3D a_y;</div><div><span class=3D"Apple-tab-span" style=
=3D"white-space:pre">  </span>return *this;</div><div><span class=3D"Apple-=
tab-span" style=3D"white-space:pre"> </span>}</div><div>private:</div><div>=
<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int m_x =
=3D 0;<span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span></di=
v><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>int=
 m_y =3D 0;</div><div>};</div><div><br></div><div>int main(){</div><div><sp=
an class=3D"Apple-tab-span" style=3D"white-space:pre"> </span>MyClass point=
;</div><div><span class=3D"Apple-tab-span" style=3D"white-space:pre"> </spa=
n>point.x(5).y(10);</div><div><br></div><div><span class=3D"Apple-tab-span"=
 style=3D"white-space:pre"> </span>std::cout &lt;&lt; point.x() &lt;&lt; ",=
 " &lt;&lt; point.y() &lt;&lt; std::endl;</div><div>}</div></div><div><br>O=
n Thursday, June 5, 2014 12:23:53 PM UTC-7, tgi...@gmail.com wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">I know this has been =
discussed many times before with blocked results; but I truly feel if C++ i=
s going to continue outstanding support and popularity into the future it n=
eeds to offer the basic idea of a "property".&nbsp; There are many benefits=
 to properties and the only arguments against them are ideological from a d=
on't want to change point of view.<br></div></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_959_33462764.1404771806725--

.

On Monday 07 July 2014 15:23:26 maxmike@gmail.com wrote:
> So, what was my take-away?  Properties are Evil(TM) they encourage unsafe
> and difficult to detect incorrect usage patterns.  If I were working in C++
> I might have seen:
>
> for( int i = 0; i < meshData.Vertices().Count; i++){
>  ...
> }

It might have been:

  for (int i = 0; i < meshData.Vertices->Count; ++i)

And you may not realise that Vertices is not a pointer, but an object that
overloaded operator->() and does expensive stuff there.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bf0e352b5be5e04fda57ed4
Content-Type: text/plain; charset=UTF-8

I guess it depends on what language one has learned to begin with.

As for myself; I have never assumed that within an OOP methodology that
data access is direct.  Not that it couldn't be; but that it shouldn't be
expected to be.  I've always thought of properties as being an
abstraction-level part of OOP where data access within an object instance
is correctly error validated and handled correctly by it's creator while
treated externally the same as a variable/"property" access.

I do see very well Micheal's point though.  Even though the set/get doubles
the API of everything; it also supplies at that API level more internal
visibility (less abstraction) and by all accounts that can be taken as a
very good benefit in many cases even if it does generally require a little
more 'texty' code for the same task.

I think the most disturbing part of not having "properties" in C++ from
someone who starts learning C++ is along the doubled API & texty points
made above.  Which seems to beg the question; could there be a syntax that
would flag visibly to the user the difference between a direct access
variable and a re-directed one while still offering the syntactical sugar
of general data access??  ( Object.DataSlot = 3.0; and If Object.DataSlot =
3.0 ).

I couldn't help but wonder if a "#" syntax could be used as
Object.DataSlot# = 3.0 would be visible enough to think "That has property
access routines" whereas Object.DataSlot = 3.0 "That's direct access".  To
me that would be a beautiful feature even in languages like C#.  Although;
I fear it would be a new language concept and would break and probably
disturb a lot of MSVC programming code.

I guess when it all comes out in the wash; I'd like to think, "Making it
available doesn't mean it has to be used." and I feel that making it
available has enough benefits for the work involved for those who don't
expect direct variable access in an OOP language.


On Mon, Jul 7, 2014 at 5:57 PM, Thiago Macieira <thiago@macieira.org> wrote:

> On Monday 07 July 2014 15:23:26 maxmike@gmail.com wrote:
> > So, what was my take-away?  Properties are Evil(TM) they encourage unsafe
> > and difficult to detect incorrect usage patterns.  If I were working in
> C++
> > I might have seen:
> >
> > for( int i = 0; i < meshData.Vertices().Count; i++){
> >  ...
> > }
>
> It might have been:
>
>   for (int i = 0; i < meshData.Vertices->Count; ++i)
>
> And you may not realise that Vertices is not a pointer, but an object that
> overloaded operator->() and does expensive stuff there.
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>    Software Architect - Intel Open Source Technology Center
>       PGP/GPG: 0x6EF45358; fingerprint:
>       E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bf0e352b5be5e04fda57ed4
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I guess it depends on what language one has learned t=
o begin with.=C2=A0 <br><br>As for myself; I have never assumed that within=
 an OOP methodology that data access is direct.=C2=A0 Not that it couldn&#3=
9;t be; but that it shouldn&#39;t be expected to be.=C2=A0 I&#39;ve always =
thought of properties as being an abstraction-level part of OOP where data =
access within an object instance is correctly error validated and handled c=
orrectly by it&#39;s creator while treated externally the same as a variabl=
e/&quot;property&quot; access.<br>
<br></div><div>I do see very well Micheal&#39;s point though.=C2=A0 Even th=
ough the set/get doubles the API of everything; it also supplies at that AP=
I level more internal visibility (less abstraction) and by all accounts tha=
t can be taken as a very good benefit in many cases even if it does general=
ly require a little more &#39;texty&#39; code for the same task.<br>
<br></div><div>I think the most disturbing part of not having &quot;propert=
ies&quot; in C++ from someone who starts learning C++ is along the doubled =
API &amp; texty points made above.=C2=A0 Which seems to beg the question; c=
ould there be a syntax that would flag visibly to the user the difference b=
etween a direct access variable and a re-directed one while still offering =
the syntactical sugar of general data access??=C2=A0 ( Object.DataSlot =3D =
3.0; and If Object.DataSlot =3D 3.0 ).<br>
<br></div><div>I couldn&#39;t help but wonder if a &quot;#&quot; syntax cou=
ld be used as Object.DataSlot# =3D 3.0 would be visible enough to think &qu=
ot;That has property access routines&quot; whereas Object.DataSlot =3D 3.0 =
&quot;That&#39;s direct access&quot;.=C2=A0 To me that would be a beautiful=
 feature even in languages like C#.=C2=A0 Although; I fear it would be a ne=
w language concept and would break and probably disturb a lot of MSVC progr=
amming code.<br>
<br></div><div>I guess when it all comes out in the wash; I&#39;d like to t=
hink, &quot;Making it available doesn&#39;t mean it has to be used.&quot; a=
nd I feel that making it available has enough benefits for the work involve=
d for those who don&#39;t expect direct variable access in an OOP language.=
<br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Mon, Jul 7, 2014 at 5:57 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&=
gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Monday 07 July 2014 15:23=
:26 <a href=3D"mailto:maxmike@gmail.com">maxmike@gmail.com</a> wrote:<br>
&gt; So, what was my take-away? =C2=A0Properties are Evil(TM) they encourag=
e unsafe<br>
&gt; and difficult to detect incorrect usage patterns. =C2=A0If I were work=
ing in C++<br>
&gt; I might have seen:<br>
&gt;<br>
&gt; for( int i =3D 0; i &lt; meshData.Vertices().Count; i++){<br>
&gt; =C2=A0...<br>
&gt; }<br>
<br>
</div>It might have been:<br>
<br>
=C2=A0 for (int i =3D 0; i &lt; meshData.Vertices-&gt;Count; ++i)<br>
<br>
And you may not realise that Vertices is not a pointer, but an object that<=
br>
overloaded operator-&gt;() and does expensive stuff there.<br>
<div class=3D"im HOEnZb">--<br>
Thiago Macieira - thiago (AT) <a href=3D"http://macieira.info" target=3D"_b=
lank">macieira.info</a> - thiago (AT) <a href=3D"http://kde.org" target=3D"=
_blank">kde.org</a><br>
=C2=A0 =C2=A0Software Architect - Intel Open Source Technology Center<br>
=C2=A0 =C2=A0 =C2=A0 PGP/GPG: 0x6EF45358; fingerprint:<br>
=C2=A0 =C2=A0 =C2=A0 E067 918B B660 DBD1 105C =C2=A0966C 33F5 F005 6EF4 535=
8<br>
<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0e352b5be5e04fda57ed4--

.

--089e0122efac2a58c604fdac3efc
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 8, 2014 at 12:23 AM, <maxmike@gmail.com> wrote:

> size could easily iterate over a million elements.  It looks like a simple
> assignment to an int.  There would be no indication you're actually doing a
> ton of work.
>

It's true for almost any abstraction and this argument can be used against
any improvements.
I don't consider this argument helpful to this discussion.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0122efac2a58c604fdac3efc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Tue, Jul 8, 2014 at 12:23 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:m=
axmike@gmail.com" target=3D"_blank">maxmike@gmail.com</a>&gt;</span> wrote:=
<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div>size could easily iterate over a million elements. =C2=A0It looks like=
 a simple assignment to an int. =C2=A0There would be no indication you&#39;=
re actually doing a ton of work.</div><div></div></blockquote></div><br>It&=
#39;s true for almost any abstraction and this argument can be used against=
 any improvements.</div>
<div class=3D"gmail_extra">I don&#39;t consider this argument helpful to th=
is discussion.</div><div class=3D"gmail_extra"><br></div><div class=3D"gmai=
l_extra"><br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122efac2a58c604fdac3efc--

.

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

On Tuesday, July 8, 2014 3:42:07 AM UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:

> On Tue, Jul 8, 2014 at 12:23 AM, <max...@gmail.com <javascript:>> wrote:
>
>> size could easily iterate over a million elements.  It looks like a=20
>> simple assignment to an int.  There would be no indication you're actual=
ly=20
>> doing a ton of work.
>>
>
> It's true for almost any abstraction and this argument can be used agains=
t=20
> any improvements.
> I don't consider this argument helpful to this discussion.
>


There is a very real different between most C++ abstractions and their=20
hidden costs and allowing properties. One example is operator->. A key bit=
=20
here is that foo->bar and foo->baz will always have the same cost=20
associated with operator->. You won't have foo->bar be cheap and foo->baz=
=20
be heinously expensive. Going with the previous C# example, it's unlikely=
=20
for Foo.Vertices.Count to be completely different than Foo.VertexCount from=
=20
Foo's perspective in C++ since Foo.Whatever has a uniform behavior (access=
=20
the member variable named Whatever in object Foo).

Yes, any abstraction can introduce hidden costs. Not all abstractions are=
=20
equal, though. There's a lot of value in allowing overloads of + or * (for=
=20
math types like complex, SIMD types, etc.) making the potential nonsense=20
some users do a worthwhile risk. Likewise, some abstractions still provide=
=20
clear points to watch out for, unless generic properties which allow two=20
otherwise identical-looking constructs to have wildly different behaviors.

These two points combined, for me, damn properties. They don't actually=20
make any difficult problems trivial and because they have low utility,=20
their high cost is too much. From the context of C++, getters and setters=
=20
work just fine. The point at which properties become important (even in C#)=
=20
is during serialization and other metadata/introspection operations; that=
=20
is, they're useful when interacting with external code or features and not=
=20
the code itself. And then they're just an in-language syntax for grouping=
=20
getters and setters in a way that easily exposes them to those=20
introspection capabilities. However, there are other way of achieving that=
=20
goal, ranging from more capable introspection that can group=20
getters/setters, introspection with user-defined-attribute support that=20
groups them, or markup facilities that construct a conceptual property that=
=20
is used only by introspection and not C++ code itself (which is the=20
status-quo for C++ metadata/introspection facilities today).

I would suggest that properties proponents come up with a solid set of use=
=20
cases of things that you cannot do or cannot do easily in C++ today that=20
properties would solve and try to very clearly illustrate their utility. As=
=20
it stands today, I can't see any reason for properties besides "C# has=20
them." C# has a lot of good ideas worth taking, a lot of bad ideas worth=20
avoiding, and a lot of ideas that are just different ways of doing things=
=20
and aren't worth the effort of "porting." Properties fall into the last=20
category by every measure I can come up with personally, and almost=20
certainly by every measure the committee and other knowledgeable C++=20
experts have. If you disagree, you're gonna have to prove us all wrong.

Short version: properties do not add significant value and can potentially=
=20
do some harm so the benefit/cost ratio is just too low to make them worth=
=20
adding to the language.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><div>On Tuesday, July 8, 2014 3:42:07 AM UTC-7, Klaim - Jo=
=C3=ABl Lamotte wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 1=
2:23 AM,  <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" g=
df-obfuscated-mailto=3D"9aVIuxz0PcQJ" onmousedown=3D"this.href=3D'javascrip=
t:';return true;" onclick=3D"this.href=3D'javascript:';return true;">max...=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>size could easily iterate over a million elements. &nbsp;It looks like=
 a simple assignment to an int. &nbsp;There would be no indication you're a=
ctually doing a ton of work.</div><div></div></blockquote></div><br>It's tr=
ue for almost any abstraction and this argument can be used against any imp=
rovements.</div>
<div>I don't consider this argument helpful to this discussion.</div></div>=
</blockquote><div><br></div><div><br></div><div>There is a very real differ=
ent between most C++ abstractions and their hidden costs and allowing prope=
rties. One example is operator-&gt;. A key bit here is that foo-&gt;bar and=
 foo-&gt;baz will always have the same cost associated with operator-&gt;. =
You won't have foo-&gt;bar be cheap and foo-&gt;baz be heinously expensive.=
 Going with the previous C# example, it's unlikely for Foo.Vertices.Count t=
o be completely different than Foo.VertexCount from Foo's perspective in C+=
+ since Foo.Whatever has a uniform behavior (access the member variable nam=
ed Whatever in object Foo).</div><div><br></div><div>Yes, any abstraction c=
an introduce hidden costs. Not all abstractions are equal, though. There's =
a lot of value in allowing overloads of + or * (for math types like complex=
, SIMD types, etc.) making the potential nonsense some users do a worthwhil=
e risk. Likewise, some abstractions still provide clear points to watch out=
 for, unless generic properties which allow two otherwise identical-looking=
 constructs to have wildly different behaviors.</div><div><br></div><div>Th=
ese two points combined, for me, damn properties. They don't actually make =
any difficult problems trivial and because they have low utility, their hig=
h cost is too much. From the context of C++, getters and setters work just =
fine. The point at which properties become important (even in C#) is during=
 serialization and other metadata/introspection operations; that is, they'r=
e useful when interacting with external code or features and not the code i=
tself. And then they're just an in-language syntax for grouping getters and=
 setters in a way that easily exposes them to those introspection capabilit=
ies. However, there are other way of achieving that goal, ranging from more=
 capable introspection that can group getters/setters, introspection with u=
ser-defined-attribute support that groups them, or markup facilities that c=
onstruct a conceptual property that is used only by introspection and not C=
++ code itself (which is the status-quo for C++ metadata/introspection faci=
lities today).</div><div><br></div><div>I would suggest that properties pro=
ponents come up with a solid set of use cases of things that you cannot do =
or cannot do easily in C++ today that properties would solve and try to ver=
y clearly illustrate their utility. As it stands today, I can't see any rea=
son for properties besides "C# has them." C# has a lot of good ideas worth =
taking, a lot of bad ideas worth avoiding, and a lot of ideas that are just=
 different ways of doing things and aren't worth the effort of "porting." P=
roperties fall into the last category by every measure I can come up with p=
ersonally, and almost certainly by every measure the committee and other kn=
owledgeable C++ experts have. If you disagree, you're gonna have to prove u=
s all wrong.</div><div><br></div><div>Short version: properties do not add =
significant value and can potentially do some harm so the benefit/cost rati=
o is just too low to make them worth adding to the language.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_32_29936329.1404861519390--

.

--089e01227f04e3d65f04fdb70bae
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 9, 2014 at 1:18 AM, Sean Middleditch <sean.middleditch@gmail.co=
m
> wrote:

> On Tuesday, July 8, 2014 3:42:07 AM UTC-7, Klaim - Jo=C3=ABl Lamotte wrot=
e:
>
>> On Tue, Jul 8, 2014 at 12:23 AM, <max...@gmail.com> wrote:
>>
>>> size could easily iterate over a million elements.  It looks like a
>>> simple assignment to an int.  There would be no indication you're actua=
lly
>>> doing a ton of work.
>>>
>>
>> It's true for almost any abstraction and this argument can be used
>> against any improvements.
>> I don't consider this argument helpful to this discussion.
>>
>
>
> There is a very real different between most C++ abstractions and their
> hidden costs and allowing properties. One example is operator->. A key bi=
t
> here is that foo->bar and foo->baz will always have the same cost
> associated with operator->. You won't have foo->bar be cheap and foo->baz
> be heinously expensive. Going with the previous C# example, it's unlikely
> for Foo.Vertices.Count to be completely different than Foo.VertexCount fr=
om
> Foo's perspective in C++ since Foo.Whatever has a uniform behavior (acces=
s
> the member variable named Whatever in object Foo).
>
>
Are you ignoring custom "smart" pointers here? Because as someone else
pointed, you don't know the cost of calling ->. It totally depends on the
implementation and it can change.


> Yes, any abstraction can introduce hidden costs. Not all abstractions are
> equal, though. There's a lot of value in allowing overloads of + or * (fo=
r
> math types like complex, SIMD types, etc.) making the potential nonsense
> some users do a worthwhile risk. Likewise, some abstractions still provid=
e
> clear points to watch out for, unless generic properties which allow two
> otherwise identical-looking constructs to have wildly different behaviors=
..
>
>
To clarify, I'm not against properties, I think it can help in a lot of
situations. However I think that focusing on the cost of an arbitrary
implementation of a useful abstraction is not helpful to the discussion.
Basically, it's like saying that properties (whatever the form it takes)
seems useful for stabilizing interfaces with accessors, but can also be
used to do some dumb stuffs, as any powerful abstraction tool.


> These two points combined, for me, damn properties. They don't actually
> make any difficult problems trivial and because they have low utility,
> their high cost is too much. From the context of C++, getters and setters
> work just fine. The point at which properties become important (even in C=
#)
> is during serialization and other metadata/introspection operations; that
> is, they're useful when interacting with external code or features and no=
t
> the code itself. And then they're just an in-language syntax for grouping
> getters and setters in a way that easily exposes them to those
> introspection capabilities. However, there are other way of achieving tha=
t
> goal, ranging from more capable introspection that can group
> getters/setters, introspection with user-defined-attribute support that
> groups them, or markup facilities that construct a conceptual property th=
at
> is used only by introspection and not C++ code itself (which is the
> status-quo for C++ metadata/introspection facilities today).
>
>
I think that introspection don't solve the main problem that properties
solve: being able to switch from a public member (from a raw struct) to an
accessor function, without breaking user's code.
Maybe gathering data on properties use through time would be better than
discussing unknown performance implication, and making the discussion going
full circle.
Anyway I don't think I've seen any properties proposal being published in
the end. Such proposal should, in my opinion, point to some data.


> I would suggest that properties proponents come up with a solid set of us=
e
> cases of things that you cannot do or cannot do easily in C++ today that
> properties would solve and try to very clearly illustrate their utility. =
As
> it stands today, I can't see any reason for properties besides "C# has
> them." C# has a lot of good ideas worth taking, a lot of bad ideas worth
> avoiding, and a lot of ideas that are just different ways of doing things
> and aren't worth the effort of "porting." Properties fall into the last
> category by every measure I can come up with personally, and almost
> certainly by every measure the committee and other knowledgeable C++
> experts have. If you disagree, you're gonna have to prove us all wrong.
>
>
Short version: properties do not add significant value and can potentially
> do some harm so the benefit/cost ratio is just too low to make them worth
> adding to the language.
>


I don't totally agree with the conclusion because I've seen some use cases
(evolution from public member to accessor function)
but I don't have a strong opinion on including properties as one solution
to avoid this case is to never expose public member.

I think a properties system that enforce that the returned object is a
member of the type would be a good start, instead of allowing anything to
be generated as output of the property.
That way:
 1. properties address would be valid;
 2. properties providing a temporary would be forbidden;
 3. checks and other side-effects on accessing a member would still be
possible;
 4. from this restricted version, evolution would still be possible;
And as you say, such a proposal should provide use cases.


>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--089e01227f04e3d65f04fdb70bae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 9, 2014 at 1:18 AM, Sean Middleditch <span dir=3D"ltr">=
&lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.mi=
ddleditch@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex"><div dir=3D"ltr"><div>On Tuesday, July 8, 2014 3:42:07 AM =
UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:<br>
</div><div class=3D""><blockquote class=3D"gmail_quote" style=3D"margin:0px=
 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);bor=
der-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"=
gmail_quote">
On Tue, Jul 8, 2014 at 12:23 AM,  <span dir=3D"ltr">&lt;<a>max...@gmail.com=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204)=
;border-left-style:solid;padding-left:1ex">

<div>size could easily iterate over a million elements. =C2=A0It looks like=
 a simple assignment to an int. =C2=A0There would be no indication you&#39;=
re actually doing a ton of work.</div><div></div></blockquote></div><br>It&=
#39;s true for almost any abstraction and this argument can be used against=
 any improvements.</div>

<div>I don&#39;t consider this argument helpful to this discussion.</div></=
div></blockquote><div><br></div><div><br></div></div><div>There is a very r=
eal different between most C++ abstractions and their hidden costs and allo=
wing properties. One example is operator-&gt;. A key bit here is that foo-&=
gt;bar and foo-&gt;baz will always have the same cost associated with opera=
tor-&gt;. You won&#39;t have foo-&gt;bar be cheap and foo-&gt;baz be heinou=
sly expensive. Going with the previous C# example, it&#39;s unlikely for Fo=
o.Vertices.Count to be completely different than Foo.VertexCount from Foo&#=
39;s perspective in C++ since Foo.Whatever has a uniform behavior (access t=
he member variable named Whatever in object Foo).</div>
<div><br></div></div></blockquote><div><br></div><div>Are you ignoring cust=
om &quot;smart&quot; pointers here? Because as someone else pointed, you do=
n&#39;t know the cost of calling -&gt;. It totally depends on the implement=
ation and it can change.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Yes, any=
 abstraction can introduce hidden costs. Not all abstractions are equal, th=
ough. There&#39;s a lot of value in allowing overloads of + or * (for math =
types like complex, SIMD types, etc.) making the potential nonsense some us=
ers do a worthwhile risk. Likewise, some abstractions still provide clear p=
oints to watch out for, unless generic properties which allow two otherwise=
 identical-looking constructs to have wildly different behaviors.</div>
<div><br></div></div></blockquote><div><br></div><div>To clarify, I&#39;m n=
ot against properties, I think it can help in a lot of situations. However =
I think that focusing on the cost of an arbitrary implementation of a usefu=
l abstraction is not helpful to the discussion.</div>
<div>Basically, it&#39;s like saying that properties (whatever the form it =
takes) seems useful for stabilizing interfaces with accessors, but can also=
 be used to do some dumb stuffs, as any powerful abstraction tool.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>These tw=
o points combined, for me, damn properties. They don&#39;t actually make an=
y difficult problems trivial and because they have low utility, their high =
cost is too much. From the context of C++, getters and setters work just fi=
ne. The point at which properties become important (even in C#) is during s=
erialization and other metadata/introspection operations; that is, they&#39=
;re useful when interacting with external code or features and not the code=
 itself. And then they&#39;re just an in-language syntax for grouping gette=
rs and setters in a way that easily exposes them to those introspection cap=
abilities. However, there are other way of achieving that goal, ranging fro=
m more capable introspection that can group getters/setters, introspection =
with user-defined-attribute support that groups them, or markup facilities =
that construct a conceptual property that is used only by introspection and=
 not C++ code itself (which is the status-quo for C++ metadata/introspectio=
n facilities today).</div>
<div><br></div></div></blockquote><div><br></div><div>I think that introspe=
ction don&#39;t solve the main problem that properties solve: being able to=
 switch from a public member (from a raw struct) to an accessor function, w=
ithout breaking user&#39;s code.</div>
<div>Maybe gathering data on properties use through time would be better th=
an discussing=C2=A0unknown=C2=A0performance implication, and making the dis=
cussion going full circle.</div><div>Anyway I don&#39;t think I&#39;ve seen=
 any properties proposal being published in the end. Such proposal should, =
in my opinion, point to some data.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>I would =
suggest that properties proponents come up with a solid set of use cases of=
 things that you cannot do or cannot do easily in C++ today that properties=
 would solve and try to very clearly illustrate their utility. As it stands=
 today, I can&#39;t see any reason for properties besides &quot;C# has them=
..&quot; C# has a lot of good ideas worth taking, a lot of bad ideas worth a=
voiding, and a lot of ideas that are just different ways of doing things an=
d aren&#39;t worth the effort of &quot;porting.&quot; Properties fall into =
the last category by every measure I can come up with personally, and almos=
t certainly by every measure the committee and other knowledgeable C++ expe=
rts have. If you disagree, you&#39;re gonna have to prove us all wrong.</di=
v>
<div>=C2=A0<br></div></div></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rg=
b(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><=
div></div>
<div>Short version: properties do not add significant value and can potenti=
ally do some harm so the benefit/cost ratio is just too low to make them wo=
rth adding to the language.</div></div></blockquote><div><br></div><div>
<br></div><div>I don&#39;t totally agree with the conclusion because I&#39;=
ve seen some use cases (evolution from public member to accessor function)=
=C2=A0</div><div>but I don&#39;t have a strong opinion on including propert=
ies as one solution to avoid this case is to never expose public member.</d=
iv>
<div><br></div><div>I think a properties system that enforce that the retur=
ned object is a member of the type would be a good start, instead of allowi=
ng anything to be generated as output of the property.</div><div>That way:<=
/div>
<div>=C2=A01. properties address would be valid;</div><div>=C2=A02. propert=
ies providing a temporary would be forbidden;</div><div>=C2=A03. checks and=
 other side-effects on accessing a member would still be possible;</div><di=
v>=C2=A04. from this restricted version, evolution would still be possible;=
</div>
<div>And as you say, such a proposal should provide use cases.</div><div>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
..8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-s=
tyle:solid;padding-left:1ex">
<div class=3D""><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01227f04e3d65f04fdb70bae--

.

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

On Tuesday, July 8, 2014 4:35:29 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:
>
>
>>
>> There is a very real different between most C++ abstractions and their=
=20
>> hidden costs and allowing properties. One example is operator->. A key b=
it=20
>> here is that foo->bar and foo->baz will always have the same cost=20
>> associated with operator->. You won't have foo->bar be cheap and foo->ba=
z=20
>> be heinously expensive. Going with the previous C# example, it's unlikel=
y=20
>> for Foo.Vertices.Count to be completely different than Foo.VertexCount f=
rom=20
>> Foo's perspective in C++ since Foo.Whatever has a uniform behavior (acce=
ss=20
>> the member variable named Whatever in object Foo).
>>
>>
> Are you ignoring custom "smart" pointers here? Because as someone else=20
> pointed, you don't know the cost of calling ->. It totally depends on the=
=20
> implementation and it can change.
>

I don't think you're seeing what I said. Say foo is a smart pointer. What=
=20
is the smart pointer's cost for the following?

  foo->bar.gar

vs.

  foo->baz.gar
=20
The answer is that the cost is identical, as both are calling the exact=20
same decltype(foo)::operator->, and then invoking the built-in -> and .=20
operators to access member variables.

With properties, however, what is the cost difference between these?

   foo.bar.gar

vs

   foo.baz.gar

The answer is "you have no idea" because either could be calling two=20
different hidden getters.

This is a subtle difference, but it's a difference.

=20
>
>> Yes, any abstraction can introduce hidden costs. Not all abstractions ar=
e=20
>> equal, though. There's a lot of value in allowing overloads of + or * (f=
or=20
>> math types like complex, SIMD types, etc.) making the potential nonsense=
=20
>> some users do a worthwhile risk. Likewise, some abstractions still provi=
de=20
>> clear points to watch out for, unless generic properties which allow two=
=20
>> otherwise identical-looking constructs to have wildly different behavior=
s.
>>
>>
> To clarify, I'm not against properties, I think it can help in a lot of=
=20
> situations. However I think that focusing on the cost of an arbitrary=20
> implementation of a useful abstraction is not helpful to the discussion.
> Basically, it's like saying that properties (whatever the form it takes)=
=20
> seems useful for stabilizing interfaces with accessors, but can also be=
=20
> used to do some dumb stuffs, as any powerful abstraction tool.
>

And to clarify, I am very much against properties.
=20

> These two points combined, for me, damn properties. They don't actually=
=20
>> make any difficult problems trivial and because they have low utility,=
=20
>> their high cost is too much. From the context of C++, getters and setter=
s=20
>> work just fine. The point at which properties become important (even in =
C#)=20
>> is during serialization and other metadata/introspection operations; tha=
t=20
>> is, they're useful when interacting with external code or features and n=
ot=20
>> the code itself. And then they're just an in-language syntax for groupin=
g=20
>> getters and setters in a way that easily exposes them to those=20
>> introspection capabilities. However, there are other way of achieving th=
at=20
>> goal, ranging from more capable introspection that can group=20
>> getters/setters, introspection with user-defined-attribute support that=
=20
>> groups them, or markup facilities that construct a conceptual property t=
hat=20
>> is used only by introspection and not C++ code itself (which is the=20
>> status-quo for C++ metadata/introspection facilities today).
>>
>>
> I think that introspection don't solve the main problem that properties=
=20
> solve: being able to switch from a public member (from a raw struct) to a=
n=20
> accessor function, without breaking user's code.
>

Depending on user's code, that change violates all kinds of API contracts=
=20
like "this is just a memory dereference" or "it's just a member I can=20
access via a pointer-to-member" which is actually important in all kinds of=
=20
use cases and performance-sensitive industries like embedded, HPC, and=20
games. It also still breaks ABIs for users of shared libraries exposing the=
=20
change, too. It introduces a lot of pitfalls for what I still assert is=20
very little actual benefit.

If you're changing from a simple struct (implying a small, simple=20
semantically-"tagged" collection of data) to something with logic and=20
run-time overhead in member gets or sets then you are fundamentally=20
changing the type and its characteristics. Trying to pretend that you are=
=20
not fundamentally changing it is far more damaging to code maintainability=
=20
than users needing to update their API usage occasionally, IMO.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Tuesday, July 8, 2014 4:35:29 PM UTC-7, Klaim - Jo=C3=
=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;mar=
gin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D=
"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(=
204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><div><br></div><div><br></div></div><div>There is a very real different b=
etween most C++ abstractions and their hidden costs and allowing properties=
.. One example is operator-&gt;. A key bit here is that foo-&gt;bar and foo-=
&gt;baz will always have the same cost associated with operator-&gt;. You w=
on't have foo-&gt;bar be cheap and foo-&gt;baz be heinously expensive. Goin=
g with the previous C# example, it's unlikely for Foo.Vertices.Count to be =
completely different than Foo.VertexCount from Foo's perspective in C++ sin=
ce Foo.Whatever has a uniform behavior (access the member variable named Wh=
atever in object Foo).</div>
<div><br></div></div></blockquote><div><br></div><div>Are you ignoring cust=
om "smart" pointers here? Because as someone else pointed, you don't know t=
he cost of calling -&gt;. It totally depends on the implementation and it c=
an change.</div></div></div></div></blockquote><div><br></div><div>I don't =
think you're seeing what I said. Say foo is a smart pointer. What is the sm=
art pointer's cost for the following?</div><div><br></div><div>&nbsp; foo-&=
gt;bar.gar</div><div><br></div><div>vs.</div><div><br></div><div>&nbsp; foo=
-&gt;baz.gar</div><div>&nbsp;</div><div>The answer is that the cost is iden=
tical, as both are calling the exact same decltype(foo)::operator-&gt;, and=
 then invoking the built-in -&gt; and . operators to access member variable=
s.</div><div><br></div><div>With properties, however, what is the cost diff=
erence between these?</div><div><br></div><div>&nbsp; &nbsp;foo.bar.gar</di=
v><div><br></div><div>vs</div><div><br></div><div>&nbsp; &nbsp;foo.baz.gar<=
/div><div><br></div><div>The answer is "you have no idea" because either co=
uld be calling two different hidden getters.</div><div><br></div><div>This =
is a subtle difference, but it's a difference.</div><div><br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gm=
ail_quote">
<div>&nbsp;</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Yes, any=
 abstraction can introduce hidden costs. Not all abstractions are equal, th=
ough. There's a lot of value in allowing overloads of + or * (for math type=
s like complex, SIMD types, etc.) making the potential nonsense some users =
do a worthwhile risk. Likewise, some abstractions still provide clear point=
s to watch out for, unless generic properties which allow two otherwise ide=
ntical-looking constructs to have wildly different behaviors.</div>
<div><br></div></div></blockquote><div><br></div><div>To clarify, I'm not a=
gainst properties, I think it can help in a lot of situations. However I th=
ink that focusing on the cost of an arbitrary implementation of a useful ab=
straction is not helpful to the discussion.</div>
<div>Basically, it's like saying that properties (whatever the form it take=
s) seems useful for stabilizing interfaces with accessors, but can also be =
used to do some dumb stuffs, as any powerful abstraction tool.</div></div><=
/div></div></blockquote><div><br></div><div>And to clarify, I am very much =
against properties.</div><div>&nbsp;</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px=
;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1e=
x"><div dir=3D"ltr"><div></div><div>These two points combined, for me, damn=
 properties. They don't actually make any difficult problems trivial and be=
cause they have low utility, their high cost is too much. From the context =
of C++, getters and setters work just fine. The point at which properties b=
ecome important (even in C#) is during serialization and other metadata/int=
rospection operations; that is, they're useful when interacting with extern=
al code or features and not the code itself. And then they're just an in-la=
nguage syntax for grouping getters and setters in a way that easily exposes=
 them to those introspection capabilities. However, there are other way of =
achieving that goal, ranging from more capable introspection that can group=
 getters/setters, introspection with user-defined-attribute support that gr=
oups them, or markup facilities that construct a conceptual property that i=
s used only by introspection and not C++ code itself (which is the status-q=
uo for C++ metadata/introspection facilities today).</div>
<div><br></div></div></blockquote><div><br></div><div>I think that introspe=
ction don't solve the main problem that properties solve: being able to swi=
tch from a public member (from a raw struct) to an accessor function, witho=
ut breaking user's code.</div></div></div></div></blockquote><div><br></div=
><div>Depending on user's code, that change violates all kinds of API contr=
acts like "this is just a memory dereference" or "it's just a member I can =
access via a pointer-to-member" which is actually important in all kinds of=
 use cases and performance-sensitive industries like embedded, HPC, and gam=
es. It also still breaks ABIs for users of shared libraries exposing the ch=
ange, too. It introduces a lot of pitfalls for what I still assert is very =
little actual benefit.</div><div><br></div><div>If you're changing from a s=
imple struct (implying a small, simple semantically-"tagged" collection of =
data) to something with logic and run-time overhead in member gets or sets =
then you are fundamentally changing the type and its characteristics. Tryin=
g to pretend that you are not fundamentally changing it is far more damagin=
g to code maintainability than users needing to update their API usage occa=
sionally, IMO.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3079_23787300.1404865547262--

.

--001a11c20cf4295e9c04fdb98fba
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I would suggest that properties proponents come up with a solid set of use
cases of things that you cannot do or cannot do easily in C++ today that
properties would solve and try to very clearly illustrate their utility

- Actually I think you already answered the same question  you requested.

The point at which properties become important (even in C#) is during
serialization and other metadata/introspection operations; that is, they're
useful when interacting with external code or features and not the code
itself. And then they're just an in-language syntax for grouping getters
and setters in a way that easily exposes them to those introspection
capabilities. However, there are other way of achieving that goal, ranging
from more capable introspection that can group getters/setters,
introspection with user-defined-attribute support that groups them, or
markup facilities that construct a conceptual property that is used only by
introspection and not C++ code itself (which is the status-quo for C++
metadata/introspection facilities today).

- Certainly you can hobnob all the above using some other lengthy
home-baked process; but the real question is why would you want to?

Likewise, some abstractions still provide clear points to watch out for,
unless generic properties which allow two otherwise identical-looking
constructs to have wildly different behaviors.

- I gather this is the "real" debate here.  Programmers who have become use
to associating object data with direct access variables.  It's a valid
point to be considered but it's also a valid point that properties general
cut the user-API of a class in half (due to not requiring a set/get for
every data member that isn't direct access).

As mentioned before it makes the class interface more abstract to the user
while also simplifying it for general usage.  For example what is the real
difference between "Object.SetData(3);, Object.GetData()" and Object.Data.
Currently; two can have code and one never does however there's 2-Public
Class function calls vs only one with properties.  But with that "one" we
loose the ability to know if it's direct-access or if something else is
happening but we also gain the ability to do both or all three(coded
direct) with one caller an the class create gets to determine that.  Either
one is comfortable with that or they are not.  By all means it is an
abstraction level that "looks" like and somewhat operates like a variable.

I can relate to the concerns as I can't count the number of times I've seen
programmers dump a bunch of un-necessary functionality code into a
get-property and thought to myself why would they do that there knowing the
outside world may be calling that multiple times - at the very least put a
'DoOnce' wrapper around it if the value is still the same; but as much as
could be said about any other part of programming.  This is where OOP
methodology learning I think causes the debate.  I think for some of us the
OOP idea of direct-data-access is a bad-practice.  With this other OOP
methodology the idea is the class variables are all private and any access
to it's "internal" data is held hostage by the class creator who allows
special public access to the data but only under the class creators "OK"
and verification that what needs to be taken into consideration on a data
change is taken into consideration.  With that as a best practice the
direct-access isn't an option and property abstraction is inevitable.




On Tue, Jul 8, 2014 at 6:25 PM, Sean Middleditch <sean.middleditch@gmail.co=
m
> wrote:

> On Tuesday, July 8, 2014 4:35:29 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wrot=
e:
>>
>>
>>>
>>> There is a very real different between most C++ abstractions and their
>>> hidden costs and allowing properties. One example is operator->. A key =
bit
>>> here is that foo->bar and foo->baz will always have the same cost
>>> associated with operator->. You won't have foo->bar be cheap and foo->b=
az
>>> be heinously expensive. Going with the previous C# example, it's unlike=
ly
>>> for Foo.Vertices.Count to be completely different than Foo.VertexCount =
from
>>> Foo's perspective in C++ since Foo.Whatever has a uniform behavior (acc=
ess
>>> the member variable named Whatever in object Foo).
>>>
>>>
>> Are you ignoring custom "smart" pointers here? Because as someone else
>> pointed, you don't know the cost of calling ->. It totally depends on th=
e
>> implementation and it can change.
>>
>
> I don't think you're seeing what I said. Say foo is a smart pointer. What
> is the smart pointer's cost for the following?
>
>   foo->bar.gar
>
> vs.
>
>   foo->baz.gar
>
> The answer is that the cost is identical, as both are calling the exact
> same decltype(foo)::operator->, and then invoking the built-in -> and .
> operators to access member variables.
>
> With properties, however, what is the cost difference between these?
>
>    foo.bar.gar
>
> vs
>
>    foo.baz.gar
>
> The answer is "you have no idea" because either could be calling two
> different hidden getters.
>
> This is a subtle difference, but it's a difference.
>
>
>>
>>> Yes, any abstraction can introduce hidden costs. Not all abstractions
>>> are equal, though. There's a lot of value in allowing overloads of + or=
 *
>>> (for math types like complex, SIMD types, etc.) making the potential
>>> nonsense some users do a worthwhile risk. Likewise, some abstractions s=
till
>>> provide clear points to watch out for, unless generic properties which
>>> allow two otherwise identical-looking constructs to have wildly differe=
nt
>>> behaviors.
>>>
>>>
>> To clarify, I'm not against properties, I think it can help in a lot of
>> situations. However I think that focusing on the cost of an arbitrary
>> implementation of a useful abstraction is not helpful to the discussion.
>> Basically, it's like saying that properties (whatever the form it takes)
>> seems useful for stabilizing interfaces with accessors, but can also be
>> used to do some dumb stuffs, as any powerful abstraction tool.
>>
>
> And to clarify, I am very much against properties.
>
>
>> These two points combined, for me, damn properties. They don't actually
>>> make any difficult problems trivial and because they have low utility,
>>> their high cost is too much. From the context of C++, getters and sette=
rs
>>> work just fine. The point at which properties become important (even in=
 C#)
>>> is during serialization and other metadata/introspection operations; th=
at
>>> is, they're useful when interacting with external code or features and =
not
>>> the code itself. And then they're just an in-language syntax for groupi=
ng
>>> getters and setters in a way that easily exposes them to those
>>> introspection capabilities. However, there are other way of achieving t=
hat
>>> goal, ranging from more capable introspection that can group
>>> getters/setters, introspection with user-defined-attribute support that
>>> groups them, or markup facilities that construct a conceptual property =
that
>>> is used only by introspection and not C++ code itself (which is the
>>> status-quo for C++ metadata/introspection facilities today).
>>>
>>>
>> I think that introspection don't solve the main problem that properties
>> solve: being able to switch from a public member (from a raw struct) to =
an
>> accessor function, without breaking user's code.
>>
>
> Depending on user's code, that change violates all kinds of API contracts
> like "this is just a memory dereference" or "it's just a member I can
> access via a pointer-to-member" which is actually important in all kinds =
of
> use cases and performance-sensitive industries like embedded, HPC, and
> games. It also still breaks ABIs for users of shared libraries exposing t=
he
> change, too. It introduces a lot of pitfalls for what I still assert is
> very little actual benefit.
>
> If you're changing from a simple struct (implying a small, simple
> semantically-"tagged" collection of data) to something with logic and
> run-time overhead in member gets or sets then you are fundamentally
> changing the type and its characteristics. Trying to pretend that you are
> not fundamentally changing it is far more damaging to code maintainabilit=
y
> than users needing to update their API usage occasionally, IMO.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c20cf4295e9c04fdb98fba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I would suggest that properties proponents come up wi=
th a solid set of=20
use cases of things that you cannot do or cannot do easily in C++ today=20
that properties would solve and try to very clearly illustrate their=20
utility<br><br></div>- Actually I think you already answered the same quest=
ion=C2=A0 you requested.<br><br><div>The point at which properties become i=
mportant (even in C#) is during=20
serialization and other metadata/introspection operations; that is,=20
they&#39;re useful when interacting with external code or features and not=
=20
the code itself. And then they&#39;re just an in-language syntax for=20
grouping getters and setters in a way that easily exposes them to those=20
introspection capabilities. However, there are other way of achieving=20
that goal, ranging from more capable introspection that can group=20
getters/setters, introspection with user-defined-attribute support that=20
groups them, or markup facilities that construct a conceptual property=20
that is used only by introspection and not C++ code itself (which is the
 status-quo for C++ metadata/introspection facilities today).<br><br></div>=
<div>- Certainly you can hobnob all the above using some other lengthy home=
-baked process; but the real question is why would you want to?<br><br>
 Likewise, some abstractions still provide clear points to watch out=20
for, unless generic properties which allow two otherwise=20
identical-looking constructs to have wildly different behaviors.<br><br></d=
iv><div>- I gather this is the &quot;real&quot; debate here.=C2=A0 Programm=
ers who have become use to associating object data with direct access varia=
bles.=C2=A0 It&#39;s a valid point to be considered but it&#39;s also a val=
id point that properties general cut the user-API of a class in half (due t=
o not requiring a set/get for every data member that isn&#39;t direct acces=
s).=C2=A0 <br>
<br>As mentioned before it makes the class interface more abstract to the u=
ser while also simplifying it for general usage.=C2=A0 For example what is =
the real difference between &quot;Object.SetData(3);, Object.GetData()&quot=
; and Object.Data.=C2=A0 Currently; two can have code and one never does ho=
wever there&#39;s 2-Public Class function calls vs only one with properties=
..=C2=A0 But with that &quot;one&quot; we loose the ability to know if it&#3=
9;s direct-access or if something else is happening but we also gain the ab=
ility to do both or all three(coded direct) with one caller an the class cr=
eate gets to determine that.=C2=A0 Either one is comfortable with that or t=
hey are not.=C2=A0 By all means it is an abstraction level that &quot;looks=
&quot; like and somewhat operates like a variable.=C2=A0 <br>
<br>I can relate to the concerns as I can&#39;t count the number of times I=
&#39;ve seen programmers dump a bunch of un-necessary functionality code in=
to a get-property and thought to myself why would they do that there knowin=
g the outside world may be calling that multiple times - at the very least =
put a &#39;DoOnce&#39; wrapper around it if the value is still the same; bu=
t as much as could be said about any other part of programming.=C2=A0 This =
is where OOP methodology learning I think causes the debate.=C2=A0 I think =
for some of us the OOP idea of direct-data-access is a bad-practice.=C2=A0 =
With this other OOP methodology the idea is the class variables are all pri=
vate and any access to it&#39;s &quot;internal&quot; data is held hostage b=
y the class creator who allows special public access to the data but only u=
nder the class creators &quot;OK&quot; and verification that what needs to =
be taken into consideration on a data change is taken into consideration.=
=C2=A0 With that as a best practice the direct-access isn&#39;t an option a=
nd property abstraction is inevitable.<br>
<br><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_=
quote">On Tue, Jul 8, 2014 at 6:25 PM, Sean Middleditch <span dir=3D"ltr">&=
lt;<a href=3D"mailto:sean.middleditch@gmail.com" target=3D"_blank">sean.mid=
dleditch@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On Tuesday,=
 July 8, 2014 4:35:29 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:<blockquote=
 class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px =
#ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">
<div><div><br></div><div><br></div></div><div>There is a very real differen=
t between most C++ abstractions and their hidden costs and allowing propert=
ies. One example is operator-&gt;. A key bit here is that foo-&gt;bar and f=
oo-&gt;baz will always have the same cost associated with operator-&gt;. Yo=
u won&#39;t have foo-&gt;bar be cheap and foo-&gt;baz be heinously expensiv=
e. Going with the previous C# example, it&#39;s unlikely for Foo.Vertices.C=
ount to be completely different than Foo.VertexCount from Foo&#39;s perspec=
tive in C++ since Foo.Whatever has a uniform behavior (access the member va=
riable named Whatever in object Foo).</div>

<div><br></div></div></blockquote><div><br></div><div>Are you ignoring cust=
om &quot;smart&quot; pointers here? Because as someone else pointed, you do=
n&#39;t know the cost of calling -&gt;. It totally depends on the implement=
ation and it can change.</div>
</div></div></div></blockquote><div><br></div></div><div>I don&#39;t think =
you&#39;re seeing what I said. Say foo is a smart pointer. What is the smar=
t pointer&#39;s cost for the following?</div><div><br></div><div>=C2=A0 foo=
-&gt;bar.gar</div>
<div><br></div><div>vs.</div><div><br></div><div>=C2=A0 foo-&gt;baz.gar</di=
v><div>=C2=A0</div><div>The answer is that the cost is identical, as both a=
re calling the exact same decltype(foo)::operator-&gt;, and then invoking t=
he built-in -&gt; and . operators to access member variables.</div>
<div><br></div><div>With properties, however, what is the cost difference b=
etween these?</div><div><br></div><div>=C2=A0 =C2=A0foo.bar.gar</div><div><=
br></div><div>vs</div><div><br></div><div>=C2=A0 =C2=A0foo.baz.gar</div><di=
v><br></div><div>
The answer is &quot;you have no idea&quot; because either could be calling =
two different hidden getters.</div><div><br></div><div>This is a subtle dif=
ference, but it&#39;s a difference.</div><div class=3D""><div><br></div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Yes, any=
 abstraction can introduce hidden costs. Not all abstractions are equal, th=
ough. There&#39;s a lot of value in allowing overloads of + or * (for math =
types like complex, SIMD types, etc.) making the potential nonsense some us=
ers do a worthwhile risk. Likewise, some abstractions still provide clear p=
oints to watch out for, unless generic properties which allow two otherwise=
 identical-looking constructs to have wildly different behaviors.</div>

<div><br></div></div></blockquote><div><br></div><div>To clarify, I&#39;m n=
ot against properties, I think it can help in a lot of situations. However =
I think that focusing on the cost of an arbitrary implementation of a usefu=
l abstraction is not helpful to the discussion.</div>

<div>Basically, it&#39;s like saying that properties (whatever the form it =
takes) seems useful for stabilizing interfaces with accessors, but can also=
 be used to do some dumb stuffs, as any powerful abstraction tool.</div>
</div></div></div></blockquote><div><br></div></div><div>And to clarify, I =
am very much against properties.</div><div class=3D""><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">
<div></div><div>These two points combined, for me, damn properties. They do=
n&#39;t actually make any difficult problems trivial and because they have =
low utility, their high cost is too much. From the context of C++, getters =
and setters work just fine. The point at which properties become important =
(even in C#) is during serialization and other metadata/introspection opera=
tions; that is, they&#39;re useful when interacting with external code or f=
eatures and not the code itself. And then they&#39;re just an in-language s=
yntax for grouping getters and setters in a way that easily exposes them to=
 those introspection capabilities. However, there are other way of achievin=
g that goal, ranging from more capable introspection that can group getters=
/setters, introspection with user-defined-attribute support that groups the=
m, or markup facilities that construct a conceptual property that is used o=
nly by introspection and not C++ code itself (which is the status-quo for C=
++ metadata/introspection facilities today).</div>

<div><br></div></div></blockquote><div><br></div><div>I think that introspe=
ction don&#39;t solve the main problem that properties solve: being able to=
 switch from a public member (from a raw struct) to an accessor function, w=
ithout breaking user&#39;s code.</div>
</div></div></div></blockquote><div><br></div></div><div>Depending on user&=
#39;s code, that change violates all kinds of API contracts like &quot;this=
 is just a memory dereference&quot; or &quot;it&#39;s just a member I can a=
ccess via a pointer-to-member&quot; which is actually important in all kind=
s of use cases and performance-sensitive industries like embedded, HPC, and=
 games. It also still breaks ABIs for users of shared libraries exposing th=
e change, too. It introduces a lot of pitfalls for what I still assert is v=
ery little actual benefit.</div>
<div><br></div><div>If you&#39;re changing from a simple struct (implying a=
 small, simple semantically-&quot;tagged&quot; collection of data) to somet=
hing with logic and run-time overhead in member gets or sets then you are f=
undamentally changing the type and its characteristics. Trying to pretend t=
hat you are not fundamentally changing it is far more damaging to code main=
tainability than users needing to update their API usage occasionally, IMO.=
</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c20cf4295e9c04fdb98fba--

.

--047d7b3392a9ce4e2d04fdbc95a5
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Just another summary; Since I feel I keep repeating the same things over
and over again.

The root decision that needs to be made;

1) Should a C++ programmer be "allowed" (Allowed being the keyword) to use
an ISO "standard" property abstraction.

    In Favor say;      Smaller API - that replaces the need for both a
set/get function in order to wrap for abstraction easily in a widely
accepted standard.
    Against say;      Limits visibility; user difference between direct
access and abstracted access is not readily demanded/determined by syntax.

Frankly; Why couldn't their be a syntax that had both benefits of a
property but the clarity of abstraction?  Even a 'best notation practice'
could be used like, "Any direct access member should be ended with an
'_'".  Not that it's a good idea to use '_'; but point being why can't both
sides have a favorable/acceptable return?  If C++ standard should enforce a
syntax making surface-visible direct-access notification possible; I'm
actually very much in favor of it.  But to just block a property usage
standard all-together I find ... well "blocking" progress minded.



On Tue, Jul 8, 2014 at 8:35 PM, Tom Joe <tgit28@gmail.com> wrote:

> I would suggest that properties proponents come up with a solid set of us=
e
> cases of things that you cannot do or cannot do easily in C++ today that
> properties would solve and try to very clearly illustrate their utility
>
> - Actually I think you already answered the same question  you requested.
>
>
> The point at which properties become important (even in C#) is during
> serialization and other metadata/introspection operations; that is, they'=
re
> useful when interacting with external code or features and not the code
> itself. And then they're just an in-language syntax for grouping getters
> and setters in a way that easily exposes them to those introspection
> capabilities. However, there are other way of achieving that goal, rangin=
g
> from more capable introspection that can group getters/setters,
> introspection with user-defined-attribute support that groups them, or
> markup facilities that construct a conceptual property that is used only =
by
> introspection and not C++ code itself (which is the status-quo for C++
> metadata/introspection facilities today).
>
> - Certainly you can hobnob all the above using some other lengthy
> home-baked process; but the real question is why would you want to?
>
>
> Likewise, some abstractions still provide clear points to watch out for,
> unless generic properties which allow two otherwise identical-looking
> constructs to have wildly different behaviors.
>
> - I gather this is the "real" debate here.  Programmers who have become
> use to associating object data with direct access variables.  It's a vali=
d
> point to be considered but it's also a valid point that properties genera=
l
> cut the user-API of a class in half (due to not requiring a set/get for
> every data member that isn't direct access).
>
> As mentioned before it makes the class interface more abstract to the use=
r
> while also simplifying it for general usage.  For example what is the rea=
l
> difference between "Object.SetData(3);, Object.GetData()" and Object.Data=
..
> Currently; two can have code and one never does however there's 2-Public
> Class function calls vs only one with properties.  But with that "one" we
> loose the ability to know if it's direct-access or if something else is
> happening but we also gain the ability to do both or all three(coded
> direct) with one caller an the class create gets to determine that.  Eith=
er
> one is comfortable with that or they are not.  By all means it is an
> abstraction level that "looks" like and somewhat operates like a variable=
..
>
> I can relate to the concerns as I can't count the number of times I've
> seen programmers dump a bunch of un-necessary functionality code into a
> get-property and thought to myself why would they do that there knowing t=
he
> outside world may be calling that multiple times - at the very least put =
a
> 'DoOnce' wrapper around it if the value is still the same; but as much as
> could be said about any other part of programming.  This is where OOP
> methodology learning I think causes the debate.  I think for some of us t=
he
> OOP idea of direct-data-access is a bad-practice.  With this other OOP
> methodology the idea is the class variables are all private and any acces=
s
> to it's "internal" data is held hostage by the class creator who allows
> special public access to the data but only under the class creators "OK"
> and verification that what needs to be taken into consideration on a data
> change is taken into consideration.  With that as a best practice the
> direct-access isn't an option and property abstraction is inevitable.
>
>
>
>
> On Tue, Jul 8, 2014 at 6:25 PM, Sean Middleditch <
> sean.middleditch@gmail.com> wrote:
>
>> On Tuesday, July 8, 2014 4:35:29 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wro=
te:
>>>
>>>
>>>>
>>>> There is a very real different between most C++ abstractions and their
>>>> hidden costs and allowing properties. One example is operator->. A key=
 bit
>>>> here is that foo->bar and foo->baz will always have the same cost
>>>> associated with operator->. You won't have foo->bar be cheap and foo->=
baz
>>>> be heinously expensive. Going with the previous C# example, it's unlik=
ely
>>>> for Foo.Vertices.Count to be completely different than Foo.VertexCount=
 from
>>>> Foo's perspective in C++ since Foo.Whatever has a uniform behavior (ac=
cess
>>>> the member variable named Whatever in object Foo).
>>>>
>>>>
>>> Are you ignoring custom "smart" pointers here? Because as someone else
>>> pointed, you don't know the cost of calling ->. It totally depends on t=
he
>>> implementation and it can change.
>>>
>>
>> I don't think you're seeing what I said. Say foo is a smart pointer. Wha=
t
>> is the smart pointer's cost for the following?
>>
>>   foo->bar.gar
>>
>> vs.
>>
>>   foo->baz.gar
>>
>> The answer is that the cost is identical, as both are calling the exact
>> same decltype(foo)::operator->, and then invoking the built-in -> and .
>> operators to access member variables.
>>
>> With properties, however, what is the cost difference between these?
>>
>>    foo.bar.gar
>>
>> vs
>>
>>    foo.baz.gar
>>
>> The answer is "you have no idea" because either could be calling two
>> different hidden getters.
>>
>> This is a subtle difference, but it's a difference.
>>
>>
>>>
>>>> Yes, any abstraction can introduce hidden costs. Not all abstractions
>>>> are equal, though. There's a lot of value in allowing overloads of + o=
r *
>>>> (for math types like complex, SIMD types, etc.) making the potential
>>>> nonsense some users do a worthwhile risk. Likewise, some abstractions =
still
>>>> provide clear points to watch out for, unless generic properties which
>>>> allow two otherwise identical-looking constructs to have wildly differ=
ent
>>>> behaviors.
>>>>
>>>>
>>> To clarify, I'm not against properties, I think it can help in a lot of
>>> situations. However I think that focusing on the cost of an arbitrary
>>> implementation of a useful abstraction is not helpful to the discussion=
..
>>> Basically, it's like saying that properties (whatever the form it takes=
)
>>> seems useful for stabilizing interfaces with accessors, but can also be
>>> used to do some dumb stuffs, as any powerful abstraction tool.
>>>
>>
>> And to clarify, I am very much against properties.
>>
>>
>>>  These two points combined, for me, damn properties. They don't
>>>> actually make any difficult problems trivial and because they have low
>>>> utility, their high cost is too much. From the context of C++, getters=
 and
>>>> setters work just fine. The point at which properties become important
>>>> (even in C#) is during serialization and other metadata/introspection
>>>> operations; that is, they're useful when interacting with external cod=
e or
>>>> features and not the code itself. And then they're just an in-language
>>>> syntax for grouping getters and setters in a way that easily exposes t=
hem
>>>> to those introspection capabilities. However, there are other way of
>>>> achieving that goal, ranging from more capable introspection that can =
group
>>>> getters/setters, introspection with user-defined-attribute support tha=
t
>>>> groups them, or markup facilities that construct a conceptual property=
 that
>>>> is used only by introspection and not C++ code itself (which is the
>>>> status-quo for C++ metadata/introspection facilities today).
>>>>
>>>>
>>> I think that introspection don't solve the main problem that properties
>>> solve: being able to switch from a public member (from a raw struct) to=
 an
>>> accessor function, without breaking user's code.
>>>
>>
>> Depending on user's code, that change violates all kinds of API contract=
s
>> like "this is just a memory dereference" or "it's just a member I can
>> access via a pointer-to-member" which is actually important in all kinds=
 of
>> use cases and performance-sensitive industries like embedded, HPC, and
>> games. It also still breaks ABIs for users of shared libraries exposing =
the
>> change, too. It introduces a lot of pitfalls for what I still assert is
>> very little actual benefit.
>>
>> If you're changing from a simple struct (implying a small, simple
>> semantically-"tagged" collection of data) to something with logic and
>> run-time overhead in member gets or sets then you are fundamentally
>> changing the type and its characteristics. Trying to pretend that you ar=
e
>> not fundamentally changing it is far more damaging to code maintainabili=
ty
>> than users needing to update their API usage occasionally, IMO.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b3392a9ce4e2d04fdbc95a5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>Just another summary; Since I feel I keep r=
epeating the same things over and over again.<br><br></div>The root decisio=
n that needs to be made;<br><br></div>1) Should a C++ programmer be &quot;a=
llowed&quot; (Allowed being the keyword) to use an ISO &quot;standard&quot;=
 property abstraction.<br>
<br>=C2=A0 =C2=A0 In Favor say;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Smaller API -=
 that replaces the need for both a set/get function in order to wrap for ab=
straction easily in a widely accepted standard.<br></div>=C2=A0=C2=A0=C2=A0=
 Against say;=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Limits visibility; user differe=
nce between direct access and abstracted access is not readily demanded/det=
ermined by syntax.<br>
<div><br></div><div>Frankly; Why couldn&#39;t their be a syntax that had bo=
th benefits of a property but the clarity of abstraction?=C2=A0 Even a &#39=
;best notation practice&#39; could be used like, &quot;Any direct access me=
mber should be ended with an=C2=A0 &#39;_&#39;&quot;.=C2=A0 Not that it&#39=
;s a good idea to use &#39;_&#39;; but point being why can&#39;t both sides=
 have a favorable/acceptable return?=C2=A0 If C++ standard should enforce a=
 syntax making surface-visible direct-access notification possible; I&#39;m=
 actually very much in favor of it.=C2=A0 But to just block a property usag=
e standard all-together I find ... well &quot;blocking&quot; progress minde=
d.<br>
</div><div><br></div></div><div class=3D"gmail_extra"><br><br><div class=3D=
"gmail_quote">On Tue, Jul 8, 2014 at 8:35 PM, Tom Joe <span dir=3D"ltr">&lt=
;<a href=3D"mailto:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.com</a>=
&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><div>I woul=
d suggest that properties proponents come up with a solid set of=20
use cases of things that you cannot do or cannot do easily in C++ today=20
that properties would solve and try to very clearly illustrate their=20
utility<br><br></div></div>- Actually I think you already answered the same=
 question=C2=A0 you requested.<div class=3D""><br><br><div>The point at whi=
ch properties become important (even in C#) is during=20
serialization and other metadata/introspection operations; that is,=20
they&#39;re useful when interacting with external code or features and not=
=20
the code itself. And then they&#39;re just an in-language syntax for=20
grouping getters and setters in a way that easily exposes them to those=20
introspection capabilities. However, there are other way of achieving=20
that goal, ranging from more capable introspection that can group=20
getters/setters, introspection with user-defined-attribute support that=20
groups them, or markup facilities that construct a conceptual property=20
that is used only by introspection and not C++ code itself (which is the
 status-quo for C++ metadata/introspection facilities today).<br><br></div>=
</div><div>- Certainly you can hobnob all the above using some other length=
y home-baked process; but the real question is why would you want to?<div c=
lass=3D"">
<br><br>
 Likewise, some abstractions still provide clear points to watch out=20
for, unless generic properties which allow two otherwise=20
identical-looking constructs to have wildly different behaviors.<br><br></d=
iv></div><div>- I gather this is the &quot;real&quot; debate here.=C2=A0 Pr=
ogrammers who have become use to associating object data with direct access=
 variables.=C2=A0 It&#39;s a valid point to be considered but it&#39;s also=
 a valid point that properties general cut the user-API of a class in half =
(due to not requiring a set/get for every data member that isn&#39;t direct=
 access).=C2=A0 <br>

<br>As mentioned before it makes the class interface more abstract to the u=
ser while also simplifying it for general usage.=C2=A0 For example what is =
the real difference between &quot;Object.SetData(3);, Object.GetData()&quot=
; and Object.Data.=C2=A0 Currently; two can have code and one never does ho=
wever there&#39;s 2-Public Class function calls vs only one with properties=
..=C2=A0 But with that &quot;one&quot; we loose the ability to know if it&#3=
9;s direct-access or if something else is happening but we also gain the ab=
ility to do both or all three(coded direct) with one caller an the class cr=
eate gets to determine that.=C2=A0 Either one is comfortable with that or t=
hey are not.=C2=A0 By all means it is an abstraction level that &quot;looks=
&quot; like and somewhat operates like a variable.=C2=A0 <br>

<br>I can relate to the concerns as I can&#39;t count the number of times I=
&#39;ve seen programmers dump a bunch of un-necessary functionality code in=
to a get-property and thought to myself why would they do that there knowin=
g the outside world may be calling that multiple times - at the very least =
put a &#39;DoOnce&#39; wrapper around it if the value is still the same; bu=
t as much as could be said about any other part of programming.=C2=A0 This =
is where OOP methodology learning I think causes the debate.=C2=A0 I think =
for some of us the OOP idea of direct-data-access is a bad-practice.=C2=A0 =
With this other OOP methodology the idea is the class variables are all pri=
vate and any access to it&#39;s &quot;internal&quot; data is held hostage b=
y the class creator who allows special public access to the data but only u=
nder the class creators &quot;OK&quot; and verification that what needs to =
be taken into consideration on a data change is taken into consideration.=
=C2=A0 With that as a best practice the direct-access isn&#39;t an option a=
nd property abstraction is inevitable.<br>

<br><br></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"g=
mail_extra"><br><br><div class=3D"gmail_quote">On Tue, Jul 8, 2014 at 6:25 =
PM, Sean Middleditch <span dir=3D"ltr">&lt;<a href=3D"mailto:sean.middledit=
ch@gmail.com" target=3D"_blank">sean.middleditch@gmail.com</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>On Tuesday, July 8, 20=
14 4:35:29 PM UTC-7, Klaim - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"g=
mail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;=
padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">

<div><div><br></div><div><br></div></div><div>There is a very real differen=
t between most C++ abstractions and their hidden costs and allowing propert=
ies. One example is operator-&gt;. A key bit here is that foo-&gt;bar and f=
oo-&gt;baz will always have the same cost associated with operator-&gt;. Yo=
u won&#39;t have foo-&gt;bar be cheap and foo-&gt;baz be heinously expensiv=
e. Going with the previous C# example, it&#39;s unlikely for Foo.Vertices.C=
ount to be completely different than Foo.VertexCount from Foo&#39;s perspec=
tive in C++ since Foo.Whatever has a uniform behavior (access the member va=
riable named Whatever in object Foo).</div>


<div><br></div></div></blockquote><div><br></div><div>Are you ignoring cust=
om &quot;smart&quot; pointers here? Because as someone else pointed, you do=
n&#39;t know the cost of calling -&gt;. It totally depends on the implement=
ation and it can change.</div>

</div></div></div></blockquote><div><br></div></div><div>I don&#39;t think =
you&#39;re seeing what I said. Say foo is a smart pointer. What is the smar=
t pointer&#39;s cost for the following?</div><div><br></div><div>=C2=A0 foo=
-&gt;bar.gar</div>

<div><br></div><div>vs.</div><div><br></div><div>=C2=A0 foo-&gt;baz.gar</di=
v><div>=C2=A0</div><div>The answer is that the cost is identical, as both a=
re calling the exact same decltype(foo)::operator-&gt;, and then invoking t=
he built-in -&gt; and . operators to access member variables.</div>

<div><br></div><div>With properties, however, what is the cost difference b=
etween these?</div><div><br></div><div>=C2=A0 =C2=A0foo.bar.gar</div><div><=
br></div><div>vs</div><div><br></div><div>=C2=A0 =C2=A0foo.baz.gar</div><di=
v><br></div><div>

The answer is &quot;you have no idea&quot; because either could be calling =
two different hidden getters.</div><div><br></div><div>This is a subtle dif=
ference, but it&#39;s a difference.</div><div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #cc=
c solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote">
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><div dir=3D"ltr"><div></div><div>Yes, any=
 abstraction can introduce hidden costs. Not all abstractions are equal, th=
ough. There&#39;s a lot of value in allowing overloads of + or * (for math =
types like complex, SIMD types, etc.) making the potential nonsense some us=
ers do a worthwhile risk. Likewise, some abstractions still provide clear p=
oints to watch out for, unless generic properties which allow two otherwise=
 identical-looking constructs to have wildly different behaviors.</div>


<div><br></div></div></blockquote><div><br></div><div>To clarify, I&#39;m n=
ot against properties, I think it can help in a lot of situations. However =
I think that focusing on the cost of an arbitrary implementation of a usefu=
l abstraction is not helpful to the discussion.</div>


<div>Basically, it&#39;s like saying that properties (whatever the form it =
takes) seems useful for stabilizing interfaces with accessors, but can also=
 be used to do some dumb stuffs, as any powerful abstraction tool.</div>

</div></div></div></blockquote><div><br></div></div><div>And to clarify, I =
am very much against properties.</div><div><div>=C2=A0</div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc=
 solid;padding-left:1ex">

<div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left=
-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">

<div></div><div>These two points combined, for me, damn properties. They do=
n&#39;t actually make any difficult problems trivial and because they have =
low utility, their high cost is too much. From the context of C++, getters =
and setters work just fine. The point at which properties become important =
(even in C#) is during serialization and other metadata/introspection opera=
tions; that is, they&#39;re useful when interacting with external code or f=
eatures and not the code itself. And then they&#39;re just an in-language s=
yntax for grouping getters and setters in a way that easily exposes them to=
 those introspection capabilities. However, there are other way of achievin=
g that goal, ranging from more capable introspection that can group getters=
/setters, introspection with user-defined-attribute support that groups the=
m, or markup facilities that construct a conceptual property that is used o=
nly by introspection and not C++ code itself (which is the status-quo for C=
++ metadata/introspection facilities today).</div>


<div><br></div></div></blockquote><div><br></div><div>I think that introspe=
ction don&#39;t solve the main problem that properties solve: being able to=
 switch from a public member (from a raw struct) to an accessor function, w=
ithout breaking user&#39;s code.</div>

</div></div></div></blockquote><div><br></div></div><div>Depending on user&=
#39;s code, that change violates all kinds of API contracts like &quot;this=
 is just a memory dereference&quot; or &quot;it&#39;s just a member I can a=
ccess via a pointer-to-member&quot; which is actually important in all kind=
s of use cases and performance-sensitive industries like embedded, HPC, and=
 games. It also still breaks ABIs for users of shared libraries exposing th=
e change, too. It introduces a lot of pitfalls for what I still assert is v=
ery little actual benefit.</div>

<div><br></div><div>If you&#39;re changing from a simple struct (implying a=
 small, simple semantically-&quot;tagged&quot; collection of data) to somet=
hing with logic and run-time overhead in member gets or sets then you are f=
undamentally changing the type and its characteristics. Trying to pretend t=
hat you are not fundamentally changing it is far more damaging to code main=
tainability than users needing to update their API usage occasionally, IMO.=
</div>

</div><div><div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3392a9ce4e2d04fdbc95a5--

.

--047d7b10cbb95c610e04fdbd78e0
Content-Type: text/plain; charset=UTF-8

>
> > Lets just lay it out simple.  Almost every programming language under the
> > sun short of C and C++ is supporting the idea of "properties".  If it's
> such
>
> [citation needed]. I have no trouble finding very popular languages that
> don't.
>

In particular: I would be quite interested in "every programming language"
goitng through a standardization process.



>
> > a bad thing why is it so openly supported by most all other competing
> > languages?  One just needs to google "How to make C# like properties in
> > C++".  People are trying wacky ways to get this support by overloading
> the
> > '=' operator and other listed here.
>
> Yes? People are trying wacky ways to support all sorts of features that
> are available in other programming languages, and vice versa for c++
> features.
>
> > If the C++ ISO committee blocks this yet again; it's not a hit to
> anything
> > but C++.  People have requested it; many want it.  It does not change
> any of
>
> Apparently many enough don't, since it has been rejected.
>
> > the previous support/power of C++ so really not having original support
> is
> > just telling the community who wants them that "we" have another reason
> to
> > stop you from wanting to using C++.
>
> Well, if the lack of properties is preventing some people from using c++,
> good riddance.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b10cbb95c610e04fdbd78e0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div class=3D"">&gt; Lets just lay it out simple=
.. =C2=A0Almost every programming language under the<br>


&gt; sun short of C and C++ is supporting the idea of &quot;properties&quot=
;. =C2=A0If it&#39;s such<br>
<br>
</div>[citation needed]. I have no trouble finding very popular languages t=
hat don&#39;t.<br></blockquote><div><br></div><div>In particular: I would b=
e quite interested in &quot;every programming language&quot; goitng through=
 a standardization process.</div>

<div><br></div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=3D""><br>
&gt; a bad thing why is it so openly supported by most all other competing<=
br>
&gt; languages? =C2=A0One just needs to google &quot;How to make C# like pr=
operties in<br>
&gt; C++&quot;. =C2=A0People are trying wacky ways to get this support by o=
verloading the<br>
&gt; &#39;=3D&#39; operator and other listed here.<br>
<br>
</div>Yes? People are trying wacky ways to support all sorts of features th=
at<br>
are available in other programming languages, and vice versa for c++<br>
features.<br>
<div class=3D""><br>
&gt; If the C++ ISO committee blocks this yet again; it&#39;s not a hit to =
anything<br>
&gt; but C++. =C2=A0People have requested it; many want it. =C2=A0It does n=
ot change any of<br>
<br>
</div>Apparently many enough don&#39;t, since it has been rejected.<br>
<div class=3D""><br>
&gt; the previous support/power of C++ so really not having original suppor=
t is<br>
&gt; just telling the community who wants them that &quot;we&quot; have ano=
ther reason to<br>
&gt; stop you from wanting to using C++.<br>
<br>
</div>Well, if the lack of properties is preventing some people from using =
c++,<br>
good riddance.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b10cbb95c610e04fdbd78e0--

.

On Wed, Jul 9, 2014 at 2:25 AM, Sean Middleditch
<sean.middleditch@gmail.com> wrote:
> I don't think you're seeing what I said. Say foo is a smart pointer. What is
> the smart pointer's cost for the following?

I think he does, but you don't get what he's saying. ;)
Suppose we've got a->b vs c->b with a and c being two different types
of pointers. What's the cost of doing -> ?
They're two different hidden functions...

> With properties, however, what is the cost difference between these?

> The answer is "you have no idea" because either could be calling two
> different hidden getters.
>
> This is a subtle difference, but it's a difference.

Hidden function calls are everywhere in C++, if you don't want such
hidden calls C might be a better language for you.

> Depending on user's code, that change violates all kinds of API contracts
> like "this is just a memory dereference" or "it's just a member I can access
> via a pointer-to-member" which is actually important in all kinds of use
> cases and performance-sensitive industries like embedded, HPC, and games. It
> also still breaks ABIs for users of shared libraries exposing the change,
> too. It introduces a lot of pitfalls for what I still assert is very little
> actual benefit.

I'm not sure that's entirely right. Moving from a simple property
(with trivial get/set) to one with a user-defined get/set doesn't have
to change the ABI.
Sure, performance etc are important but that's no argument to deny all
users a feature is it?



--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e0122f2aaa90e9004fdc39fc0
Content-Type: text/plain; charset=UTF-8

On 9 July 2014 03:08, Olaf van der Spek <olafvdspek@gmail.com> wrote:

> Sure, performance etc are important but that's no argument to deny all
> users a feature is it?
>

That argument cuts both ways.  After all, one of the rationales presented
in this very thread is:

On 6 June 2014 00:02, Miro Knejp <miro@knejp.de> wrote:

>
> Am 06.06.2014 06:23, schrieb Andrew Tomazos:
>
>> (...) A little more boilerplate and maybe a little less efficient than
>> what the compiler could do for you (...)
>>
>>  To me this statement is an indication that maybe language support might
> be worth considering, as a portable "zero cost" library solution is not
> possible for something that could be done with no overhead by the compiler.


 So, should we be considering performance or not?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0122f2aaa90e9004fdc39fc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 9 July 2014 03:08, Olaf van der Spek=C2=A0<span dir=3D"=
ltr">&lt;<a href=3D"mailto:olafvdspek@gmail.com" target=3D"_blank">olafvdsp=
ek@gmail.com</a>&gt;</span>=C2=A0wrote:<br><div><div class=3D"gmail_quote">=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;p=
adding-left:1ex">

<div id=3D":4gn" class=3D"" style=3D"overflow:hidden">Sure, performance etc=
 are important but that&#39;s no argument to deny all<br>users a feature is=
 it?</div></blockquote><div><br></div><div>That argument cuts both ways. =
=C2=A0After all, one of the rationales presented in this very thread is:</d=
iv>

</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 6 =
June 2014 00:02, Miro Knejp <span dir=3D"ltr">&lt;<a href=3D"mailto:miro@kn=
ejp.de" target=3D"_blank">miro@knejp.de</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">

<br>
Am 06.06.2014 06:23, schrieb Andrew Tomazos:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
(...) A little more boilerplate and maybe a little less efficient than what=
 the compiler could do for you (...)<br>
<br>
</blockquote>
To me this statement is an indication that maybe language support might be =
worth considering, as a portable &quot;zero cost&quot; library solution is =
not possible for something that could be done with no overhead by the compi=
ler.=C2=A0</blockquote>

<div><br></div><div>=C2=A0So, should we be considering performance or not?<=
/div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a hre=
f=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.co=
m</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122f2aaa90e9004fdc39fc0--

.

On 2014-07-09, at 10:35 PM, Nevin Liber <nevin@eviloverlord.com> wrote:

> So, should we be considering performance or not?

That ship sailed with implicit conversions.

Implicit conversions can be used to implement properties. A properties exte=
nsion wouldn't add any fundamentally new capabilities. It would only provid=
e something convenient and efficient enough to be less frowned upon.

IMHO, we're arguing over micro-optimization of programs written by boilerpl=
ate-happy, ignorant, and superstitious users. Their programs will tend to b=
e slow because they do various other unnecessary things besides getter func=
tions, but not careful selection of algorithms.

Fact is, most programs are going to run fast enough no matter what you do, =
because computers are fast. Slowness due to complex getters is as fixable a=
s any other performance issue.

You just have to trust folks to write whatever they want to write. Occasion=
ally a raw, exposed member should be refactored with a getter. Although it'=
s far less common than OO zealots would have you believe, there's no reason=
 the language should make it so difficult.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

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



On Wednesday, July 9, 2014 1:35:29 AM UTC+2, Klaim - Jo=C3=ABl Lamotte wrot=
e:
>
>
>
> I think that introspection don't solve the main problem that properties=
=20
> solve: being able to switch from a public member (from a raw struct) to a=
n=20
> accessor function, without breaking user's code.
>

I do no think properties does solve this problem either. Even in C#, if you=
=20
change a class member into a property, then the user code gets broken and a=
=20
recompilation of the dependend code is required to make things works again.=
=20
The difference I see here is that you don't need to change the code. You=20
just need to recompile. (Is that what you meant?)

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br><br>On Wednesday, July 9, 2014 1:35:29 AM UTC+2, Klaim=
 - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><br><div><div class=3D"gmail_quote"><br><div>I think that int=
rospection don't solve the main problem that properties solve: being able t=
o switch from a public member (from a raw struct) to an accessor function, =
without breaking user's code.</div></div></div></div></blockquote><div><br>=
I do no think properties does solve this problem either. Even in C#, if=20
you change a class member into a property, then the user code gets=20
broken and a recompilation of the dependend code is required to make=20
things works again. <br>The difference I see here is that you don't need to=
 change the code. You just need to recompile. (Is that what you meant?)<br>=
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_79_27854745.1404921160282--

.

--089e0122f2aa45c87404fdc4dbad
Content-Type: text/plain; charset=UTF-8

On 9 July 2014 10:03, David Krauss <potswa@gmail.com> wrote:

> Fact is, most programs are going to run fast enough no matter what you do,
> because computers are fast.
>

Fact?

Maybe that is true in your particular domain, but for those of us who have
to deal with latency, throughput, power consumption, etc., performance is
definitely important.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0122f2aa45c87404fdc4dbad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 9 July 2014 10:03, David Krauss <span dir=3D"ltr">&lt;<=
a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

<div class=3D"">Fact is, most programs are going to run fast enough no matt=
er what you do, because computers are fast.<br></div></blockquote><div><br>=
</div><div>Fact?</div><div><br></div><div>Maybe that is true in your partic=
ular domain, but for those of us who have to deal with latency, throughput,=
 power consumption, etc., performance is definitely important.</div>

</div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0122f2aa45c87404fdc4dbad--

.

--001a11c20afa3252eb04fdc559de
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Jul 9, 2014 at 5:52 PM, <masse.nicolas@gmail.com> wrote:

>
>
> On Wednesday, July 9, 2014 1:35:29 AM UTC+2, Klaim - Jo=C3=ABl Lamotte wr=
ote:
>>
>>
>>
>> I think that introspection don't solve the main problem that properties
>> solve: being able to switch from a public member (from a raw struct) to =
an
>> accessor function, without breaking user's code.
>>
>
> I do no think properties does solve this problem either. Even in C#, if
> you change a class member into a property, then the user code gets broken
> and a recompilation of the dependend code is required to make things work=
s
> again.
> The difference I see here is that you don't need to change the code. You
> just need to recompile. (Is that what you meant?)
>

Yes, recompiling is fine, like for any change in a header anyway. (I'm
ignoring ABI issues for the moment).


>  --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c20afa3252eb04fdc559de
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Jul 9, 2014 at 5:52 PM,  <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:masse.nicolas@gmail.com" target=3D"_blank">masse.nicolas@gmail.com</a=
>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><br><br>On =
Wednesday, July 9, 2014 1:35:29 AM UTC+2, Klaim - Jo=C3=ABl Lamotte wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border=
-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><br><div><div class=3D"gmail_quote"><br><div>I think that =
introspection don&#39;t solve the main problem that properties solve: being=
 able to switch from a public member (from a raw struct) to an accessor fun=
ction, without breaking user&#39;s code.</div>
</div></div></div></blockquote></div><div><br>I do no think properties does=
 solve this problem either. Even in C#, if=20
you change a class member into a property, then the user code gets=20
broken and a recompilation of the dependend code is required to make=20
things works again. <br>The difference I see here is that you don&#39;t nee=
d to change the code. You just need to recompile. (Is that what you meant?)=
<br></div></div></blockquote><div><br></div><div>Yes, recompiling is fine, =
like for any change in a header anyway. (I&#39;m ignoring ABI issues for th=
e moment).</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div></div=
></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c20afa3252eb04fdc559de--

.

--047d7b2e48024c8acf04fdc562ee
Content-Type: text/plain; charset=UTF-8

On Wed, Jul 9, 2014 at 5:03 PM, David Krauss <potswa@gmail.com> wrote:

> Fact is, most programs are going to run fast enough no matter what you do,
> because computers are fast.


Not if the target platform is slow whatever you wish from it. Not all
computers are fast.
I'm thinking about several cases in my experience where it's totally wrong
to think that way, like most embedded software excluding smartphones.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b2e48024c8acf04fdc562ee
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Wed, Jul 9, 2014 at 5:03 PM, David Krauss <span dir=3D"ltr">&lt;<a href=
=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</sp=
an> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Fact is, most programs are going to run fast=
 enough no matter what you do, because computers are fast.</blockquote></di=
v>
<br>Not if the target platform is slow whatever you wish from it. Not all c=
omputers are fast.=C2=A0</div><div class=3D"gmail_extra">I&#39;m thinking a=
bout several cases in my experience where it&#39;s totally wrong to think t=
hat way, like most embedded software excluding smartphones.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b2e48024c8acf04fdc562ee--

.

--f46d043893555f351d04fdc70a91
Content-Type: text/plain; charset=UTF-8

On 6 June 2014 08:10, <morwenn29@gmail.com> wrote:

> One of the ideas I agreed with in this discussion was: "maybe we need
> properties, maybe we don't. But if we want them, let's not make them
> second-class members with a poor library solution, let's make them a proper
> part of the language". That's true: nobody would be happy with
> "half-properties" and nobody ever found any proper way to implement them
> without drawbacks as a simple library feature.
>

That may be, but another feature, lambdas, got its start as a library
(Boost.Lambda is one example) and it showed the drawbacks of a library
based solution.  (Note:  some of this is speculation on my part, as I was
not on the Committee when lambdas were deliberated.)  Yet it was widely
adopted and people used it, despite the pain.

Why isn't there a widely adopted properties library?
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra">On 6 June 2014 08:10,  <span di=
r=3D"ltr">&lt;<a href=3D"mailto:morwenn29@gmail.com" target=3D"_blank">morw=
enn29@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_quote"><blockq=
uote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc =
solid;padding-left:1ex">

<div>One of the ideas I agreed with in this discussion was: &quot;maybe we =
need properties, maybe we don&#39;t. But if we want them, let&#39;s not mak=
e them second-class members with a poor library solution, let&#39;s make th=
em a proper part of the language&quot;. That&#39;s true: nobody would be ha=
ppy with &quot;half-properties&quot; and nobody ever found any proper way t=
o implement them without drawbacks as a simple library feature.<br>

</div></blockquote></div><br>That may be, but another feature, lambdas, got=
 its start as a library (Boost.Lambda is one example) and it showed the dra=
wbacks of a library based solution. =C2=A0(Note: =C2=A0some of this is spec=
ulation on my part, as I was not on the Committee when lambdas were deliber=
ated.) =C2=A0Yet it was widely adopted and people used it, despite the pain=
..</div>

<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Why isn&#39=
;t there a widely adopted properties library?<br>-- <br>=C2=A0Nevin &quot;:=
-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" t=
arget=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d043893555f351d04fdc70a91--

.

--f46d0442848438717a04fdc745a6
Content-Type: text/plain; charset=UTF-8

"Why isn't there a widely adopted properties library?"

I completely agree with Nevin.

I believe making a "boost properties" module would be a good first step to
a serious proposal.  I am not in favor of properties, but that's personal
taste.  Let adoption dictate the desire.

Honestly though, the issue with adding any feature to the language is that
you cannot suggest: "don't use it if you don't want it."

My issue with properties came directly from a third party library doing
something unexpected.  Unity does other helpful things like:

myMesh.sharedMesh vs myMesh.mesh one of these deep copies, the other
returns a shared reference.

I don't get to opt-in or opt-out of this in a work environment, it is just
one more thing I need to know.  Adding this to C++ would have a similar
impact on everyone as they begin to propogate.

It would be like arguing "well, const correctness is completely optional"
(I love const correctness, don't get me wrong, but it is a similar thing in
how it propagates through code-bases.)  It's also like saying "shared_ptr
is just another feature you can choose to use or not."  But in reality a
lot of libraries return+require shared_ptr handles to things which forces
system-wide adoption (for those types at least).

When you add something new to a language, everyone ends up eating it one
way or another.


On Wed, Jul 9, 2014 at 11:39 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> On 6 June 2014 08:10, <morwenn29@gmail.com> wrote:
>
>> One of the ideas I agreed with in this discussion was: "maybe we need
>> properties, maybe we don't. But if we want them, let's not make them
>> second-class members with a poor library solution, let's make them a proper
>> part of the language". That's true: nobody would be happy with
>> "half-properties" and nobody ever found any proper way to implement them
>> without drawbacks as a simple library feature.
>>
>
> That may be, but another feature, lambdas, got its start as a library
> (Boost.Lambda is one example) and it showed the drawbacks of a library
> based solution.  (Note:  some of this is speculation on my part, as I was
> not on the Committee when lambdas were deliberated.)  Yet it was widely
> adopted and people used it, despite the pain.
>
> Why isn't there a widely adopted properties library?
>
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>&quot;<span style=3D"font-family:arial,sans-serif;fon=
t-size:13px">Why isn&#39;t there a widely adopted properties library?&quot;=
</span></div><div><br></div>I completely agree with Nevin.<div><br></div><d=
iv>
I believe making a &quot;boost properties&quot; module would be a good firs=
t step to a serious proposal. =C2=A0I am not in favor of properties, but th=
at&#39;s personal taste. =C2=A0Let adoption dictate the desire.=C2=A0</div>=
<div><br></div>
<div>Honestly though, the issue with adding any feature to the language is =
that you cannot suggest: &quot;don&#39;t use it if you don&#39;t want it.&q=
uot;</div><div><br></div><div>My issue with properties came directly from a=
 third party library doing something unexpected. =C2=A0Unity does other hel=
pful things like:</div>
<div><br></div><div>myMesh.sharedMesh vs myMesh.mesh one of these deep copi=
es, the other returns a shared reference.</div><div><br></div><div>I don&#3=
9;t get to opt-in or opt-out of this in a work environment, it is just one =
more thing I need to know. =C2=A0Adding this to C++ would have a similar im=
pact on everyone as they begin to propogate.</div>
<div><br></div><div>It would be like arguing &quot;well, const correctness =
is completely optional&quot; (I love const correctness, don&#39;t get me wr=
ong, but it is a similar thing in how it propagates through code-bases.) =
=C2=A0It&#39;s also like saying &quot;shared_ptr is just another feature yo=
u can choose to use or not.&quot; =C2=A0But in reality a lot of libraries r=
eturn+require shared_ptr handles to things which forces system-wide adoptio=
n (for those types at least).</div>
<div><br></div><div>When you add something new to a language, everyone ends=
 up eating it one way or another.</div></div><div class=3D"gmail_extra"><br=
><br><div class=3D"gmail_quote">On Wed, Jul 9, 2014 at 11:39 AM, Nevin Libe=
r <span dir=3D"ltr">&lt;<a href=3D"mailto:nevin@eviloverlord.com" target=3D=
"_blank">nevin@eviloverlord.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
On 6 June 2014 08:10,  <span dir=3D"ltr">&lt;<a href=3D"mailto:morwenn29@gm=
ail.com" target=3D"_blank">morwenn29@gmail.com</a>&gt;</span> wrote:<br>
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>One of the ideas I agreed with in this discussion was: &quot;maybe we =
need properties, maybe we don&#39;t. But if we want them, let&#39;s not mak=
e them second-class members with a poor library solution, let&#39;s make th=
em a proper part of the language&quot;. That&#39;s true: nobody would be ha=
ppy with &quot;half-properties&quot; and nobody ever found any proper way t=
o implement them without drawbacks as a simple library feature.<br>


</div></blockquote></div><br>That may be, but another feature, lambdas, got=
 its start as a library (Boost.Lambda is one example) and it showed the dra=
wbacks of a library based solution. =C2=A0(Note: =C2=A0some of this is spec=
ulation on my part, as I was not on the Committee when lambdas were deliber=
ated.) =C2=A0Yet it was widely adopted and people used it, despite the pain=
..</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Why isn&#39=
;t there a widely adopted properties library?<div class=3D""><br>-- <br>=C2=
=A0Nevin &quot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@evi=
loverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a hr=
ef=3D"tel:%28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(8=
47) 691-1404</a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d0442848438717a04fdc745a6--

.

--f46d04428484f964f304fdc75702
Content-Type: text/plain; charset=UTF-8

I'd like to add one more thought to my previous post.

Properties make interfaces easy to use incorrectly.  I believe implicit
casting is similar in this regard (and widely it is frowned upon.  The fact
that properties can be implemented in C++ with implicit casting is actually
pretty telling.)

I feel like this is a very C# way of doing things.  C# enjoys making users
of libraries leak non-memory resources unless they *know* the library
writer intended them to wrap something in a "using" block, for example.
 This is the kind of thing C libraries do with begin/end pairs being
required, but modern C++ has moved away from with more idiomatic use of
RAII.

Just a thought on differing language philosophies.


On Wed, Jul 9, 2014 at 11:56 AM, Michael Hamilton <mike@m2tm.net> wrote:

> "Why isn't there a widely adopted properties library?"
>
> I completely agree with Nevin.
>
> I believe making a "boost properties" module would be a good first step to
> a serious proposal.  I am not in favor of properties, but that's personal
> taste.  Let adoption dictate the desire.
>
> Honestly though, the issue with adding any feature to the language is that
> you cannot suggest: "don't use it if you don't want it."
>
> My issue with properties came directly from a third party library doing
> something unexpected.  Unity does other helpful things like:
>
> myMesh.sharedMesh vs myMesh.mesh one of these deep copies, the other
> returns a shared reference.
>
> I don't get to opt-in or opt-out of this in a work environment, it is just
> one more thing I need to know.  Adding this to C++ would have a similar
> impact on everyone as they begin to propogate.
>
> It would be like arguing "well, const correctness is completely optional"
> (I love const correctness, don't get me wrong, but it is a similar thing in
> how it propagates through code-bases.)  It's also like saying "shared_ptr
> is just another feature you can choose to use or not."  But in reality a
> lot of libraries return+require shared_ptr handles to things which forces
> system-wide adoption (for those types at least).
>
> When you add something new to a language, everyone ends up eating it one
> way or another.
>
>
> On Wed, Jul 9, 2014 at 11:39 AM, Nevin Liber <nevin@eviloverlord.com>
> wrote:
>
>> On 6 June 2014 08:10, <morwenn29@gmail.com> wrote:
>>
>>> One of the ideas I agreed with in this discussion was: "maybe we need
>>> properties, maybe we don't. But if we want them, let's not make them
>>> second-class members with a poor library solution, let's make them a proper
>>> part of the language". That's true: nobody would be happy with
>>> "half-properties" and nobody ever found any proper way to implement them
>>> without drawbacks as a simple library feature.
>>>
>>
>> That may be, but another feature, lambdas, got its start as a library
>> (Boost.Lambda is one example) and it showed the drawbacks of a library
>> based solution.  (Note:  some of this is speculation on my part, as I was
>> not on the Committee when lambdas were deliberated.)  Yet it was widely
>> adopted and people used it, despite the pain.
>>
>> Why isn't there a widely adopted properties library?
>>
>> --
>>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">I&#39;d like to add one more thought to my previous post.<=
div><br></div><div>Properties make interfaces easy to use incorrectly. =C2=
=A0I believe implicit casting is similar in this regard (and widely it is f=
rowned upon. =C2=A0The fact that properties can be implemented in C++ with =
implicit casting is actually pretty telling.)</div>
<div><br></div><div>I feel like this is a very C# way of doing things. =C2=
=A0C# enjoys making users of libraries leak non-memory resources unless the=
y *know* the library writer intended them to wrap something in a &quot;usin=
g&quot; block, for example. =C2=A0This is the kind of thing C libraries do =
with begin/end pairs being required, but modern C++ has moved away from wit=
h more idiomatic use of RAII.</div>
<div><br></div><div>Just a thought on differing language philosophies.</div=
></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Wed=
, Jul 9, 2014 at 11:56 AM, Michael Hamilton <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mike@m2tm.net" target=3D"_blank">mike@m2tm.net</a>&gt;</span> wr=
ote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><div>&quot;=
<span style=3D"font-family:arial,sans-serif;font-size:13px">Why isn&#39;t t=
here a widely adopted properties library?&quot;</span></div>
<div><br></div></div>I completely agree with Nevin.<div><br></div><div>
I believe making a &quot;boost properties&quot; module would be a good firs=
t step to a serious proposal. =C2=A0I am not in favor of properties, but th=
at&#39;s personal taste. =C2=A0Let adoption dictate the desire.=C2=A0</div>=
<div><br></div>

<div>Honestly though, the issue with adding any feature to the language is =
that you cannot suggest: &quot;don&#39;t use it if you don&#39;t want it.&q=
uot;</div><div><br></div><div>My issue with properties came directly from a=
 third party library doing something unexpected. =C2=A0Unity does other hel=
pful things like:</div>

<div><br></div><div>myMesh.sharedMesh vs myMesh.mesh one of these deep copi=
es, the other returns a shared reference.</div><div><br></div><div>I don&#3=
9;t get to opt-in or opt-out of this in a work environment, it is just one =
more thing I need to know. =C2=A0Adding this to C++ would have a similar im=
pact on everyone as they begin to propogate.</div>

<div><br></div><div>It would be like arguing &quot;well, const correctness =
is completely optional&quot; (I love const correctness, don&#39;t get me wr=
ong, but it is a similar thing in how it propagates through code-bases.) =
=C2=A0It&#39;s also like saying &quot;shared_ptr is just another feature yo=
u can choose to use or not.&quot; =C2=A0But in reality a lot of libraries r=
eturn+require shared_ptr handles to things which forces system-wide adoptio=
n (for those types at least).</div>

<div><br></div><div>When you add something new to a language, everyone ends=
 up eating it one way or another.</div></div><div class=3D"HOEnZb"><div cla=
ss=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Wed, Jul 9, 2014 at 11:39 AM, Nevin Liber <span dir=3D"ltr">&lt;<a href=3D"=
mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>=
&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
On 6 June 2014 08:10,  <span dir=3D"ltr">&lt;<a href=3D"mailto:morwenn29@gm=
ail.com" target=3D"_blank">morwenn29@gmail.com</a>&gt;</span> wrote:<br>

<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div>One of the ideas I agreed with in this discussion was: &quot;maybe we =
need properties, maybe we don&#39;t. But if we want them, let&#39;s not mak=
e them second-class members with a poor library solution, let&#39;s make th=
em a proper part of the language&quot;. That&#39;s true: nobody would be ha=
ppy with &quot;half-properties&quot; and nobody ever found any proper way t=
o implement them without drawbacks as a simple library feature.<br>



</div></blockquote></div><br>That may be, but another feature, lambdas, got=
 its start as a library (Boost.Lambda is one example) and it showed the dra=
wbacks of a library based solution. =C2=A0(Note: =C2=A0some of this is spec=
ulation on my part, as I was not on the Committee when lambdas were deliber=
ated.) =C2=A0Yet it was widely adopted and people used it, despite the pain=
..</div>



<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Why isn&#39=
;t there a widely adopted properties library?<div><br>-- <br>=C2=A0Nevin &q=
uot;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.c=
om" target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%=
28847%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-140=
4</a>
</div></div></div>

<p></p>

-- <br><div><div>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--f46d04428484f964f304fdc75702--

.

On 9 July 2014 21:56, Michael Hamilton <mike@m2tm.net> wrote:
> "Why isn't there a widely adopted properties library?"
>
> I completely agree with Nevin.
>
> I believe making a "boost properties" module would be a good first step to a
> serious proposal.  I am not in favor of properties, but that's personal
> taste.  Let adoption dictate the desire.

Funny, this reminds me of
https://groups.google.com/a/isocpp.org/d/msg/std-proposals/HMyJqb3UIq0/tWAwN20E1hQJ

It still seems to me that properties don't quite cross the bar of a
language feature; all discussions
seem to boil down to being able to refactor direct member accesses to
actually be function
calls without modifying the clients, and then there's a discussion
meltdown on what "the right"
thing for properties supposedly is. The resulting lack of
agreement/consensus then kills
the idea. Personally, yes, I suppose it would be nice to be able to
refactor member access into
a function call, but I would _never_ leave it at that. At some point I
would change those
member accesses to actually _look_ like function calls, since that's
what they are. I do
think it would be somewhat funny, philosophically, to let people
refactor design mistakes
by "papering over" them, with a language feature.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_C3DA00DF-7836-46EA-9CD1-372644B1F214
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


> On 9 July 2014 10:03, David Krauss <potswa@gmail.com> wrote:
> Fact is, most programs are going to run fast enough no matter what you do=
, because computers are fast.

On 2014-07-10, at 12:03 AM, Nevin Liber <nevin@eviloverlord.com> wrote:

> Fact?
>=20
> Maybe that is true in your particular domain, but for those of us who hav=
e to deal with latency, throughput, power consumption, etc., performance is=
 definitely important.


On 2014-07-10, at 12:41 AM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrot=
e:

> Not if the target platform is slow whatever you wish from it. Not all com=
puters are fast.=20
> I'm thinking about several cases in my experience where it's totally wron=
g to think that way, like most embedded software excluding smartphones.


Programmers who program actually-slow computers are a different breed. The =
programs run by such computers fall outside the "most programs" of my claim=
..

Implicitly-called functions with significant complexity, be they accessors =
or implicit conversions, are a stupid thing to write and a good way to get =
fired. Programs will not get slower because the language has such a facilit=
y. It will not be tempting to embedded programmers, who should live by the =
rule: You don't pay for what you don't use.

There is a subculture of OO superstition propagated by awful Java teachers.=
 It is probably the worst thing ever to befall software engineering. Howeve=
r, its disciples will just invariably write accessor functions anyway, "jus=
t in case" the complexity needs to be added later. Native properties suppor=
t would just give them a cushion, so their code could look more reasonable.

People will tend to express whatever they like in a given language. Censors=
hip by grammar doesn't work.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_C3DA00DF-7836-46EA-9CD1-372644B1F214
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><blockquote t=
ype=3D"cite"><div dir=3D"ltr">On 9 July 2014 10:03, David Krauss <span dir=
=3D"ltr">&lt;<a href=3D"mailto:potswa@gmail.com" target=3D"_blank">potswa@g=
mail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"=
gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">

<div class=3D"">Fact is, most programs are going to run fast enough no matt=
er what you do, because computers are fast.</div></blockquote></div></div><=
/div></blockquote><div><br></div><div>On 2014&ndash;07&ndash;10, at 12:03 A=
M, Nevin Liber &lt;<a href=3D"mailto:nevin@eviloverlord.com">nevin@evilover=
lord.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><block=
quote type=3D"cite"></blockquote><blockquote type=3D"cite"><div dir=3D"ltr"=
><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div>Fact?</div><div=
><br></div><div>Maybe that is true in your particular domain, but for those=
 of us who have to deal with latency, throughput, power consumption, etc., =
performance is definitely important.</div></div></div></div></blockquote><d=
iv><br></div><div><br></div><div><div>On 2014&ndash;07&ndash;10, at 12:41 A=
M, Klaim - Jo=EBl Lamotte &lt;<a href=3D"mailto:mjklaim@gmail.com">mjklaim@=
gmail.com</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bloc=
kquote type=3D"cite"><div dir=3D"ltr"><div class=3D"gmail_extra">Not if the=
 target platform is slow whatever you wish from it. Not all computers are f=
ast.&nbsp;</div><div class=3D"gmail_extra">I'm thinking about several cases=
 in my experience where it's totally wrong to think that way, like most emb=
edded software excluding smartphones.</div></div></blockquote><div><div dir=
=3D"ltr"><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><b=
r></div><div class=3D"gmail_extra">Programmers who program actually-slow co=
mputers are a different breed. The programs run by such computers fall outs=
ide the &ldquo;most programs&rdquo; of my claim.</div><div class=3D"gmail_e=
xtra"><br></div><div class=3D"gmail_extra">Implicitly-called functions with=
 significant complexity, be they accessors or implicit conversions, are a s=
tupid thing to write and a good way to get fired. Programs will not get slo=
wer because the language has such a facility. It will not be tempting to em=
bedded programmers, who should live by the rule: You don&rsquo;t pay for wh=
at you don&rsquo;t use.</div><div class=3D"gmail_extra"><br></div><div clas=
s=3D"gmail_extra">There is a subculture of OO superstition propagated by aw=
ful Java teachers. It is probably the worst thing ever to befall software e=
ngineering. However, its disciples will just invariably write accessor func=
tions anyway, &ldquo;just in case&rdquo; the complexity needs to be added l=
ater. Native properties support would just give them a cushion, so their co=
de could look more reasonable.</div><div class=3D"gmail_extra"><br></div><d=
iv class=3D"gmail_extra">People will tend to express whatever they like in =
a given language. Censorship by grammar doesn&rsquo;t work.</div><div class=
=3D"gmail_extra"><br></div></div></div></div></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_C3DA00DF-7836-46EA-9CD1-372644B1F214--

.

On 2014-07-10, at 7:39 AM, David Krauss <potswa@gmail.com> wrote:

> People will tend to express whatever they like in a given language. Censo=
rship by grammar doesn't work.

Put another way: properties extend the expressive power of a language by al=
lowing segregation of fast accessors (according to program architecture, "f=
ast" may vary from a few instructions to O(lg N) ) from potentially slow on=
es. Without properties, everything looks potentially slow. What's the benef=
it in that?

To be sure, in reality everything truly is potentially slow. A simple membe=
r access may cause a page fault. Only a profiler will really tell; the lang=
uage can only express intent.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

------=_Part_757_12048669.1405017144030
Content-Type: text/plain; charset=UTF-8

Is there a way we can do this as a library solution?

In C++1y, uncompiled:

   // is_invokable:
   template<class> using sink_t=void;
   template<typename Sig, typename=void>
   sturct is_invokable:std::false_type{};
   template<typename R, typename... Args>
   struct is_invokable< R(Args...), sink_t< std::result_of_t< R(Args...) >
> >:std::true_type{};
   template<typename Sig>using is_invokable_t=typename
is_invokable<Sig>::type;

   // get/set object with cast and assign overriden:
   template<typename Get, typename Set>
   struct property_t {
     Set set; Get get;
     template<typename T, typename=std::enable_if_t< std::is_convertible<
std::result_of_t< Get() >, T >::value >>
     operator T() && { return get(); }
     template<typename T, typename=is_invokable_t<Set(T)>> //
is_invokable_t left as exercise
     property_t operator=( T&& t ) && {
       set(std::forward<T>(t));
       return std::move(*this);
     }
    };

   // helper to let you pass lambdas in:
   template<typename Get, typename Set>
   property_t<Get,Set> property( Get&& get, Set&& set ) { return {
std::forward<Get>(get), std::forward<Set>(set); }; }

   // sample use:
   struct Square {
      double width;
      auto area() const { return property(
          [=]() {return width*width;},
          [=](double area) {width = sqrt(area);}
        );
     }
   };

  int main
At point of use, this can act nearly identical to C# style properties,
except the user has to add ().

Syntax wise, it isn't much heavier than the get() set() syntax of C# style
properties.  It is a bit ... generous ... with the types it will cast to.

Am I missing something?

- Adam

On Thursday, June 5, 2014 3:23:53 PM UTC-4, tgi...@gmail.com wrote:
>
> I know this has been discussed many times before with blocked results; but
> I truly feel if C++ is going to continue outstanding support and popularity
> into the future it needs to offer the basic idea of a "property".  There
> are many benefits to properties and the only arguments against them are
> ideological from a don't want to change point of view.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Is there a way we can do this as a library solution?<br><b=
r>In C++1y, uncompiled:<br><br>&nbsp;&nbsp; // is_invokable:<br>&nbsp;&nbsp=
; template&lt;class&gt; using sink_t=3Dvoid;<br>&nbsp;&nbsp; template&lt;ty=
pename Sig, typename=3Dvoid&gt;<br>&nbsp;&nbsp; sturct is_invokable:std::fa=
lse_type{};<br>&nbsp;&nbsp; template&lt;typename R, typename... Args&gt;<br=
>&nbsp;&nbsp; struct is_invokable&lt; R(Args...), sink_t&lt; std::result_of=
_t&lt; R(Args...) &gt; &gt; &gt;:std::true_type{};<br>&nbsp;&nbsp; template=
&lt;typename Sig&gt;using is_invokable_t=3Dtypename is_invokable&lt;Sig&gt;=
::type;<br><br>&nbsp;&nbsp; // get/set object with cast and assign override=
n:<br>&nbsp;&nbsp; template&lt;typename Get, typename Set&gt;<br>&nbsp;&nbs=
p; struct property_t {<br>&nbsp;&nbsp;&nbsp;&nbsp; Set set; Get get;<br>&nb=
sp;&nbsp;&nbsp;&nbsp; template&lt;typename T, typename=3Dstd::enable_if_t&l=
t; std::is_convertible&lt; std::result_of_t&lt; Get() &gt;, T &gt;::value &=
gt;&gt;<br>&nbsp;&nbsp;&nbsp;&nbsp; operator T() &amp;&amp; { return get();=
 }<br>&nbsp;&nbsp;&nbsp;&nbsp; template&lt;typename T, typename=3Dis_invoka=
ble_t&lt;Set(T)&gt;&gt; // is_invokable_t left as exercise<br>&nbsp; &nbsp;=
&nbsp; property_t operator=3D( T&amp;&amp; t ) &amp;&amp; {<br>&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;&nbsp; set(std::forward&lt;T&gt;(t));<br>&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp; return std::move(*this);<br>&nbsp;&nbsp;&nbsp;&nbsp; }=
<br>&nbsp;&nbsp;&nbsp; };<br><br>&nbsp;&nbsp; // helper to let you pass lam=
bdas in:<br>&nbsp;&nbsp; template&lt;typename Get, typename Set&gt;<br>&nbs=
p;&nbsp; property_t&lt;Get,Set&gt; property( Get&amp;&amp; get, Set&amp;&am=
p; set ) { return { std::forward&lt;Get&gt;(get), std::forward&lt;Set&gt;(s=
et); }; }<br><br>&nbsp;&nbsp; // sample use:<br>&nbsp;&nbsp; struct Square =
{<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; double width;<br>&nbsp; &nbsp; &nbsp; a=
uto area() const { return property(<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp; [=3D]() {return width*width;},<br>&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [=3D](double area) {width =3D sqrt(area);}=
<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; );<br>&nbsp;&nbsp;&nbsp;&nbs=
p; }<br>&nbsp;&nbsp; };<br><br>&nbsp; int main<br>At point of use, this can=
 act nearly identical to C# style properties, except the user has to add ()=
..<br><br>Syntax wise, it isn't much heavier than the get() set() syntax of =
C# style properties.&nbsp; It is a bit ... generous ... with the types it w=
ill cast to.<br><br>Am I missing something?<br><br>- Adam<br><br>On Thursda=
y, June 5, 2014 3:23:53 PM UTC-4, tgi...@gmail.com wrote:<blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><div dir=3D"ltr">I know this has been discussed=
 many times before with blocked results; but I truly feel if C++ is going t=
o continue outstanding support and popularity into the future it needs to o=
ffer the basic idea of a "property".&nbsp; There are many benefits to prope=
rties and the only arguments against them are ideological from a don't want=
 to change point of view.<br></div></blockquote><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_757_12048669.1405017144030--

.

--001a11c119e2aeb75504fddb61e5
Content-Type: text/plain; charset=UTF-8

On 10 July 2014 13:32, Adam Nevraumont <afn@theorem.ca> wrote:

> Is there a way we can do this as a library solution?
>

My question still stands:

Why isn't there a widely adopted properties library?

Now, if you design a properties library AND it becomes widely adopted, IMO
it would then be appropriate to revisit the question of standardizing it
(either as a library or a language feature).

Until then, such a proposal is unlikely to go anywhere.  IMHO, of course.
--
 Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c119e2aeb75504fddb61e5
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On 10 July 2014 13:32, Adam Nevraumont <span dir=3D"ltr">&=
lt;<a href=3D"mailto:afn@theorem.ca" target=3D"_blank">afn@theorem.ca</a>&g=
t;</span> wrote:<br><div class=3D"gmail_extra"><div class=3D"gmail_quote"><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;pa=
dding-left:1ex">

<div dir=3D"ltr">Is there a way we can do this as a library solution?<br></=
div></blockquote><div><br></div><div>My question still stands:</div><div><b=
r></div><span style=3D"font-family:arial,sans-serif;font-size:13px">Why isn=
&#39;t there a widely adopted properties library?</span><div class=3D"" sty=
le=3D"font-family:arial,sans-serif;font-size:13px">

</div><div><br></div><div>Now, if you design a properties library AND it be=
comes widely adopted, IMO it would then be appropriate to revisit the quest=
ion of standardizing it (either as a library or a language feature).</div>

<div><br></div><div>Until then, such a proposal is unlikely to go anywhere.=
 =C2=A0IMHO, of course.</div></div>-- <br>=C2=A0Nevin &quot;:-)&quot; Liber=
=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com" target=3D"_blan=
k">nevin@eviloverlord.com</a>&gt;=C2=A0 (847) 691-1404
</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c119e2aeb75504fddb61e5--

.

--047d7b6788beb2191f04fddc3c49
Content-Type: text/plain; charset=UTF-8

My question still stands:

Why isn't there a widely adopted properties library?

I would imagine some of the answer to that would probably have to do with
there not having a standard one for anyone to refer too yet.  It seems to
be typically half-baked-implemented by code and called "good-enough".
However, If one googles it there does exist many non-standardized and
fluctuating implementations of properties as well as a plethora of code
implementations samples (Even on Wikipedia).

http://en.wikipedia.org/wiki/Property_%28programming%29
http://www.cplusplus.com/forum/general/8147/
http://how-bazaar.blogspot.com/2011/07/properties-in-c.html
http://www.codeproject.com/Articles/3900/Implementing-Properties-In-C
http://psl.sourceforge.net/
http://www.boost.org/doc/libs/1_44_0/boost/test/utils/class_properties.hpp


On Thu, Jul 10, 2014 at 12:55 PM, Nevin Liber <nevin@eviloverlord.com>
wrote:

> On 10 July 2014 13:32, Adam Nevraumont <afn@theorem.ca> wrote:
>
>> Is there a way we can do this as a library solution?
>>
>
> My question still stands:
>
> Why isn't there a widely adopted properties library?
>
> Now, if you design a properties library AND it becomes widely adopted, IMO
> it would then be appropriate to revisit the question of standardizing it
> (either as a library or a language feature).
>
> Until then, such a proposal is unlikely to go anywhere.  IMHO, of course.
> --
>  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b6788beb2191f04fddc3c49
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>My question still stands:</div><div><br></d=
iv><span style=3D"font-family:arial,sans-serif;font-size:13px">Why isn&#39;=
t there a widely adopted properties library?<br><br></span></div><span styl=
e=3D"font-family:arial,sans-serif;font-size:13px">I would imagine some of t=
he answer to that would probably have to do with there not having a standar=
d one for anyone to refer too yet.=C2=A0 It seems to be typically half-bake=
d-implemented by code and called &quot;good-enough&quot;.<br>
</span></div><span style=3D"font-family:arial,sans-serif;font-size:13px">Ho=
wever, If one googles it there does exist many non-standardized and fluctua=
ting implementations of properties as well as a plethora of code implementa=
tions samples (Even on Wikipedia).<br>
<br><a href=3D"http://en.wikipedia.org/wiki/Property_%28programming%29">htt=
p://en.wikipedia.org/wiki/Property_%28programming%29</a><br><a href=3D"http=
://www.cplusplus.com/forum/general/8147/">http://www.cplusplus.com/forum/ge=
neral/8147/</a><br>
<a href=3D"http://how-bazaar.blogspot.com/2011/07/properties-in-c.html">htt=
p://how-bazaar.blogspot.com/2011/07/properties-in-c.html</a><br><a href=3D"=
http://www.codeproject.com/Articles/3900/Implementing-Properties-In-C">http=
://www.codeproject.com/Articles/3900/Implementing-Properties-In-C</a><br>
<a href=3D"http://psl.sourceforge.net/">http://psl.sourceforge.net/</a><br>=
<a href=3D"http://www.boost.org/doc/libs/1_44_0/boost/test/utils/class_prop=
erties.hpp">http://www.boost.org/doc/libs/1_44_0/boost/test/utils/class_pro=
perties.hpp</a><br>
</span></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Thu, Jul 10, 2014 at 12:55 PM, Nevin Liber <span dir=3D"ltr">&lt;<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"">On 10 July =
2014 13:32, Adam Nevraumont <span dir=3D"ltr">&lt;<a href=3D"mailto:afn@the=
orem.ca" target=3D"_blank">afn@theorem.ca</a>&gt;</span> wrote:<br>
</div><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div class=3D""=
><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border=
-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;=
padding-left:1ex">


<div dir=3D"ltr">Is there a way we can do this as a library solution?<br></=
div></blockquote><div><br></div></div><div>My question still stands:</div><=
div class=3D""><div><br></div><span style=3D"font-family:arial,sans-serif;f=
ont-size:13px">Why isn&#39;t there a widely adopted properties library?</sp=
an><div style=3D"font-family:arial,sans-serif;font-size:13px">


</div><div><br></div></div><div>Now, if you design a properties library AND=
 it becomes widely adopted, IMO it would then be appropriate to revisit the=
 question of standardizing it (either as a library or a language feature).<=
/div>


<div><br></div><div>Until then, such a proposal is unlikely to go anywhere.=
 =C2=A0IMHO, of course.</div></div><div class=3D"">-- <br>=C2=A0Nevin &quot=
;:-)&quot; Liber=C2=A0 &lt;mailto:<a href=3D"mailto:nevin@eviloverlord.com"=
 target=3D"_blank">nevin@eviloverlord.com</a>&gt;=C2=A0 <a href=3D"tel:%288=
47%29%20691-1404" value=3D"+18476911404" target=3D"_blank">(847) 691-1404</=
a>
</div></div></div>

<p></p>

-- <br><div class=3D"HOEnZb"><div class=3D"h5">
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6788beb2191f04fddc3c49--

.

On 2014-07-11, at 2:32 AM, Adam Nevraumont <afn@theorem.ca> wrote:

> Is there a way we can do this as a library solution?
>=20
> Am I missing something?

You got it!

There are a few potential rough edges in that implementation, but perhaps t=
hat's an argument in favor of adding a vetted, safe library to the standard=
..

Effectively, the only thing stopping everyone from using properties in the =
past was the difficulty of writing a metaprogram as you just did. If improv=
ements to ease of metaprogramming have brought this within reach to more us=
ers, then the Standard should get off its high horse and respond to demand.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 11 July 2014 01:10, David Krauss <potswa@gmail.com> wrote:
> Effectively, the only thing stopping everyone from using properties in th=
e past was the difficulty of writing a metaprogram as you just did. If impr=
ovements to ease of metaprogramming have brought this within reach to more =
users, then the Standard should get off its high horse and respond to deman=
d.


I'm sure it will, if there ever is such demand in sufficient quantities.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7b33c8040b714704fde5c79b
Content-Type: text/plain; charset=UTF-8

With the number of property proposals in this very forum as well as the
countless adhoc implementations posted in various places around the net and
the multiple dis-appointed user comments one gets when googling "properties
in C++" I'm rather curious as to what number would qualify as "sufficient
quantities"?

I think the demand is there and that one of ISO C++'s larger "sore-thumb's"
is the lack of such support.  It appears, to me, accurate to say that ISO
C++ is one of the very few largely accepted languages missing support
(Which isn't even true of MSVC or C++/CLI but specifically to GCC ISO
collection).  Even the Qt library developers speak of how they had to "work
around" not having native C++ property support.  Whether support is a
blessing or a curse appears to be up in the air; but I do believe the
demand is well established and visible.


On Thu, Jul 10, 2014 at 4:27 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 11 July 2014 01:10, David Krauss <potswa@gmail.com> wrote:
> > Effectively, the only thing stopping everyone from using properties in
> the past was the difficulty of writing a metaprogram as you just did. If
> improvements to ease of metaprogramming have brought this within reach to
> more users, then the Standard should get off its high horse and respond to
> demand.
>
>
> I'm sure it will, if there ever is such demand in sufficient quantities.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b33c8040b714704fde5c79b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">With the number of property proposals in this very forum a=
s well as the countless adhoc implementations posted in various places arou=
nd the net and the multiple dis-appointed user comments one gets when googl=
ing &quot;properties in C++&quot; I&#39;m rather curious as to what number =
would qualify as &quot;sufficient quantities&quot;?=C2=A0 <br>
<br>I think the demand is there and that one of ISO C++&#39;s larger &quot;=
sore-thumb&#39;s&quot; is the lack of such support.=C2=A0 It appears, to me=
, accurate to say that ISO C++ is one of the very few largely accepted lang=
uages missing support (Which isn&#39;t even true of MSVC or C++/CLI but spe=
cifically to GCC ISO collection).=C2=A0 Even the Qt library developers spea=
k of how they had to &quot;work around&quot; not having native C++ property=
 support.=C2=A0 Whether support is a blessing or a curse appears to be up i=
n the air; but I do believe the demand is well established and visible.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Thu,=
 Jul 10, 2014 at 4:27 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 11 July 2014 01:10, David=
 Krauss &lt;<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>&gt; wr=
ote:<br>

&gt; Effectively, the only thing stopping everyone from using properties in=
 the past was the difficulty of writing a metaprogram as you just did. If i=
mprovements to ease of metaprogramming have brought this within reach to mo=
re users, then the Standard should get off its high horse and respond to de=
mand.<br>

<br>
<br>
</div>I&#39;m sure it will, if there ever is such demand in sufficient quan=
tities.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b33c8040b714704fde5c79b--

.

On 11 July 2014 10:20, Tom Joe <tgit28@gmail.com> wrote:
> With the number of property proposals in this very forum as well as the
> countless adhoc implementations posted in various places around the net and
> the multiple dis-appointed user comments one gets when googling "properties
> in C++" I'm rather curious as to what number would qualify as "sufficient
> quantities"?


A majority number of WG21 members voting in an actual proposal for properties.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bf0d2f6d3952c04fde5f746
Content-Type: text/plain; charset=UTF-8

Awe yes; very good point.  I was actually under the assumption that this
forum was monitored/read by WG21 members;  If so, I'd like to propose a
vote at the next meeting.  Guess I had assumed that's what this forum was
for.


On Fri, Jul 11, 2014 at 1:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 11 July 2014 10:20, Tom Joe <tgit28@gmail.com> wrote:
> > With the number of property proposals in this very forum as well as the
> > countless adhoc implementations posted in various places around the net
> and
> > the multiple dis-appointed user comments one gets when googling
> "properties
> > in C++" I'm rather curious as to what number would qualify as "sufficient
> > quantities"?
>
>
> A majority number of WG21 members voting in an actual proposal for
> properties.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bf0d2f6d3952c04fde5f746
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Awe yes; very good point.=C2=A0 I was actually under the a=
ssumption that this forum was monitored/read by WG21 members;=C2=A0 If so, =
I&#39;d like to propose a vote at the next meeting.=C2=A0 Guess I had assum=
ed that&#39;s what this forum was for.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Jul 11, 2014 at 1:25 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 11 July 2014 10:20, Tom J=
oe &lt;<a href=3D"mailto:tgit28@gmail.com">tgit28@gmail.com</a>&gt; wrote:<=
br>
&gt; With the number of property proposals in this very forum as well as th=
e<br>
&gt; countless adhoc implementations posted in various places around the ne=
t and<br>
&gt; the multiple dis-appointed user comments one gets when googling &quot;=
properties<br>
&gt; in C++&quot; I&#39;m rather curious as to what number would qualify as=
 &quot;sufficient<br>
&gt; quantities&quot;?<br>
<br>
<br>
</div>A majority number of WG21 members voting in an actual proposal for pr=
operties.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0d2f6d3952c04fde5f746--

.

On 11 July 2014 10:34, Tom Joe <tgit28@gmail.com> wrote:
> Awe yes; very good point.  I was actually under the assumption that this
> forum was monitored/read by WG21 members;  If so, I'd like to propose a vote

It is; I, for example, am a WG21 member.

> at the next meeting.  Guess I had assumed that's what this forum was for.

You need a proposal (an actual paper) to get a motion to vote on. That proposal,
if it is a language extension, needs to be accepted by both EWG (for the design)
and CWG (for the wording) (or LEWG and LWG, for a library addition)
before it'll have a chance to get voted on by the full committee.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c318d015dd8b04fde6ff3f
Content-Type: text/plain; charset=UTF-8

Excellent; Guess my assumptions were pretty close.  As stated previously
I'm really not a seasonal-ed C++ programmer with the equipment necessary to
write a decent proposal so if anyone wants to jump in and take these
discussions to the next level I'd be more than happy to be of any but
likely no-assistance help at all :)..

That said as a seasoned programming across multiple languages; I think
Michaels and Seans arguments are substantial and I can see a huge benefit
of having syntactical flaggers between the differences of a property and
field (direct-access).  It may break all previous standards in other
languages but it may be the tipping innovation that makes properties
happier for all programmers to use.  Be it Object.Property# or
Object-|Property vs Object->Field.  Thoughts?


On Fri, Jul 11, 2014 at 1:38 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 11 July 2014 10:34, Tom Joe <tgit28@gmail.com> wrote:
> > Awe yes; very good point.  I was actually under the assumption that this
> > forum was monitored/read by WG21 members;  If so, I'd like to propose a
> vote
>
> It is; I, for example, am a WG21 member.
>
> > at the next meeting.  Guess I had assumed that's what this forum was for.
>
> You need a proposal (an actual paper) to get a motion to vote on. That
> proposal,
> if it is a language extension, needs to be accepted by both EWG (for the
> design)
> and CWG (for the wording) (or LEWG and LWG, for a library addition)
> before it'll have a chance to get voted on by the full committee.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c318d015dd8b04fde6ff3f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Excellent; Guess my assumptions were pretty close.=C2=
=A0 As stated previously I&#39;m really not a seasonal-ed C++ programmer wi=
th the equipment necessary to write a decent proposal so if anyone wants to=
 jump in and take these discussions to the next level I&#39;d be more than =
happy to be of any but likely no-assistance help at all :).. <br>
<br></div>That said as a seasoned programming across multiple languages; I =
think Michaels and Seans arguments are substantial and I can see a huge ben=
efit of having syntactical flaggers between the differences of a property a=
nd field (direct-access).=C2=A0 It may break all previous standards in othe=
r languages but it may be the tipping innovation that makes properties happ=
ier for all programmers to use.=C2=A0 Be it Object.Property# or Object-|Pro=
perty vs Object-&gt;Field.=C2=A0 Thoughts?<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Jul 11, 2014 at 1:38 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a href=
=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilainen=
@gmail.com</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On 11 July 2014 10:34, Tom J=
oe &lt;<a href=3D"mailto:tgit28@gmail.com">tgit28@gmail.com</a>&gt; wrote:<=
br>
&gt; Awe yes; very good point. =C2=A0I was actually under the assumption th=
at this<br>
&gt; forum was monitored/read by WG21 members; =C2=A0If so, I&#39;d like to=
 propose a vote<br>
<br>
</div>It is; I, for example, am a WG21 member.<br>
<div class=3D""><br>
&gt; at the next meeting. =C2=A0Guess I had assumed that&#39;s what this fo=
rum was for.<br>
<br>
</div>You need a proposal (an actual paper) to get a motion to vote on. Tha=
t proposal,<br>
if it is a language extension, needs to be accepted by both EWG (for the de=
sign)<br>
and CWG (for the wording) (or LEWG and LWG, for a library addition)<br>
before it&#39;ll have a chance to get voted on by the full committee.<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c318d015dd8b04fde6ff3f--

.

Tom Joe skrev 2014-07-11 10:47:
> Excellent; Guess my assumptions were pretty close.  As stated previously
> I'm really not a seasonal-ed C++ programmer with the equipment necessary
> to write a decent proposal so if anyone wants to jump in and take these
> discussions to the next level I'd be more than happy to be of any but
> likely no-assistance help at all :)..
>
> That said as a seasoned programming across multiple languages; I think
> Michaels and Seans arguments are substantial and I can see a huge
> benefit of having syntactical flaggers between the differences of a
> property and field (direct-access).  It may break all previous standards
> in other languages but it may be the tipping innovation that makes
> properties happier for all programmers to use.  Be it Object.Property#
> or Object-|Property vs Object->Field.  Thoughts?
>

Being able to use Object.Property# instead of Object.Accessor() doesn't
seem like an improvement to me.


Bo Persson





--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bf10a1ce358c704fdf39a85
Content-Type: text/plain; charset=UTF-8

I feel like postfixing isn't really what you want here (it's too similar to
a function syntax anyway):

something = object~property;
something = objectPtr~>property;

object~property = something;
objectPtr~>property = something;

Something like that would be fine with me.  A visual indication in a
similar way to function call vs member call is in order certainly.  This
also keeps the same number of characters as regular . or -> syntax so the
purpose of the property (convenience) is maintained.

My primary complaint about properties is their invisible nature at the call
site, this would erase that concern.

In terms of declaration syntax I don't care so much *shrug*:

class MyClass{
public:
     int bar~ {
          get: {return bar * 2;}
          set: {bar = value / 2;}
     }
private:
     int bar;
};




On Fri, Jul 11, 2014 at 12:26 PM, Bo Persson <bop@gmb.dk> wrote:

> Tom Joe skrev 2014-07-11 10:47:
>
>  Excellent; Guess my assumptions were pretty close.  As stated previously
>> I'm really not a seasonal-ed C++ programmer with the equipment necessary
>> to write a decent proposal so if anyone wants to jump in and take these
>> discussions to the next level I'd be more than happy to be of any but
>> likely no-assistance help at all :)..
>>
>> That said as a seasoned programming across multiple languages; I think
>> Michaels and Seans arguments are substantial and I can see a huge
>> benefit of having syntactical flaggers between the differences of a
>> property and field (direct-access).  It may break all previous standards
>> in other languages but it may be the tipping innovation that makes
>> properties happier for all programmers to use.  Be it Object.Property#
>> or Object-|Property vs Object->Field.  Thoughts?
>>
>>
> Being able to use Object.Property# instead of Object.Accessor() doesn't
> seem like an improvement to me.
>
>
> Bo Persson
>
>
>
>
>
>
> --
>
> --- You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bf10a1ce358c704fdf39a85
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>I feel like postfixing isn&#39;t really what you want=
 here (it&#39;s too similar to a function syntax anyway):<br></div><div><br=
></div><div>something =3D object~property;<br></div><div>something =3D obje=
ctPtr~&gt;property;<br>
</div><div><br></div>object~property =3D something;<div>objectPtr~&gt;prope=
rty =3D something;</div><div><div><br></div><div>Something like that would =
be fine with me. =C2=A0A visual indication in a similar way to function cal=
l vs member call is in order certainly. =C2=A0This also keeps the same numb=
er of characters as regular . or -&gt; syntax so the purpose of the propert=
y (convenience) is maintained.</div>
</div><div><br></div><div>My primary complaint about properties is their in=
visible nature at the call site, this would erase that concern.</div><div><=
br></div><div>In terms of declaration syntax I don&#39;t care so much *shru=
g*:</div>
<div><br></div><div>class MyClass{</div><div>public:</div><div>=C2=A0 =C2=
=A0 =C2=A0int bar~ {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 get: {ret=
urn bar * 2;}</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set: {bar =3D va=
lue / 2;}</div><div>=C2=A0 =C2=A0 =C2=A0}</div><div>private:</div><div>=C2=
=A0 =C2=A0 =C2=A0int bar;</div>
<div>};</div><div><br></div><div><br></div></div><div class=3D"gmail_extra"=
><br><br><div class=3D"gmail_quote">On Fri, Jul 11, 2014 at 12:26 PM, Bo Pe=
rsson <span dir=3D"ltr">&lt;<a href=3D"mailto:bop@gmb.dk" target=3D"_blank"=
>bop@gmb.dk</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Tom Joe skrev 2014-07-11 10:47:<div class=3D=
""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Excellent; Guess my assumptions were pretty close. =C2=A0As stated previous=
ly<br>
I&#39;m really not a seasonal-ed C++ programmer with the equipment necessar=
y<br>
to write a decent proposal so if anyone wants to jump in and take these<br>
discussions to the next level I&#39;d be more than happy to be of any but<b=
r>
likely no-assistance help at all :)..<br>
<br>
That said as a seasoned programming across multiple languages; I think<br>
Michaels and Seans arguments are substantial and I can see a huge<br>
benefit of having syntactical flaggers between the differences of a<br>
property and field (direct-access). =C2=A0It may break all previous standar=
ds<br>
in other languages but it may be the tipping innovation that makes<br>
properties happier for all programmers to use. =C2=A0Be it Object.Property#=
<br>
or Object-|Property vs Object-&gt;Field. =C2=A0Thoughts?<br>
<br>
</blockquote>
<br></div>
Being able to use Object.Property# instead of Object.Accessor() doesn&#39;t=
 seem like an improvement to me.<span class=3D"HOEnZb"><font color=3D"#8888=
88"><br>
<br>
<br>
Bo Persson</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf10a1ce358c704fdf39a85--

.

--e89a8f2356bd7f014504fdf3ac7b
Content-Type: text/plain; charset=UTF-8

class MyClass{
public:
     int bar~ {
          const get: {return bar * 2;}
          set: {bar = value / 2;}
     }
private:
     int bar;
};


On Fri, Jul 11, 2014 at 4:50 PM, Michael Hamilton <mike@m2tm.net> wrote:

> I feel like postfixing isn't really what you want here (it's too similar
> to a function syntax anyway):
>
> something = object~property;
> something = objectPtr~>property;
>
> object~property = something;
> objectPtr~>property = something;
>
> Something like that would be fine with me.  A visual indication in a
> similar way to function call vs member call is in order certainly.  This
> also keeps the same number of characters as regular . or -> syntax so the
> purpose of the property (convenience) is maintained.
>
> My primary complaint about properties is their invisible nature at the
> call site, this would erase that concern.
>
> In terms of declaration syntax I don't care so much *shrug*:
>
> class MyClass{
> public:
>      int bar~ {
>           get: {return bar * 2;}
>           set: {bar = value / 2;}
>      }
> private:
>      int bar;
> };
>
>
>
>
> On Fri, Jul 11, 2014 at 12:26 PM, Bo Persson <bop@gmb.dk> wrote:
>
>> Tom Joe skrev 2014-07-11 10:47:
>>
>>  Excellent; Guess my assumptions were pretty close.  As stated previously
>>> I'm really not a seasonal-ed C++ programmer with the equipment necessary
>>> to write a decent proposal so if anyone wants to jump in and take these
>>> discussions to the next level I'd be more than happy to be of any but
>>> likely no-assistance help at all :)..
>>>
>>> That said as a seasoned programming across multiple languages; I think
>>> Michaels and Seans arguments are substantial and I can see a huge
>>> benefit of having syntactical flaggers between the differences of a
>>> property and field (direct-access).  It may break all previous standards
>>> in other languages but it may be the tipping innovation that makes
>>> properties happier for all programmers to use.  Be it Object.Property#
>>> or Object-|Property vs Object->Field.  Thoughts?
>>>
>>>
>> Being able to use Object.Property# instead of Object.Accessor() doesn't
>> seem like an improvement to me.
>>
>>
>> Bo Persson
>>
>>
>>
>>
>>
>>
>> --
>>
>> --- You received this message because you are subscribed to a topic in
>> the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/
>> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>> proposals/.
>>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div style=3D"font-family:arial,sans-serif;font-size:13px"=
>class MyClass{</div><div style=3D"font-family:arial,sans-serif;font-size:1=
3px">public:</div><div style=3D"font-family:arial,sans-serif;font-size:13px=
">=C2=A0 =C2=A0 =C2=A0int bar~ {</div>
<div style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 const get: {return bar * 2;}</div><div style=3D"font-f=
amily:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s=
et: {bar =3D value / 2;}</div><div style=3D"font-family:arial,sans-serif;fo=
nt-size:13px">
=C2=A0 =C2=A0 =C2=A0}</div><div style=3D"font-family:arial,sans-serif;font-=
size:13px">private:</div><div style=3D"font-family:arial,sans-serif;font-si=
ze:13px">=C2=A0 =C2=A0 =C2=A0int bar;</div><div style=3D"font-family:arial,=
sans-serif;font-size:13px">};</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Fri,=
 Jul 11, 2014 at 4:50 PM, Michael Hamilton <span dir=3D"ltr">&lt;<a href=3D=
"mailto:mike@m2tm.net" target=3D"_blank">mike@m2tm.net</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I feel like postfixing isn&#39;t really what you want=
 here (it&#39;s too similar to a function syntax anyway):<br></div><div><br=
></div><div>something =3D object~property;<br></div><div>something =3D obje=
ctPtr~&gt;property;<br>

</div><div><br></div>object~property =3D something;<div>objectPtr~&gt;prope=
rty =3D something;</div><div><div><br></div><div>Something like that would =
be fine with me. =C2=A0A visual indication in a similar way to function cal=
l vs member call is in order certainly. =C2=A0This also keeps the same numb=
er of characters as regular . or -&gt; syntax so the purpose of the propert=
y (convenience) is maintained.</div>

</div><div><br></div><div>My primary complaint about properties is their in=
visible nature at the call site, this would erase that concern.</div><div><=
br></div><div>In terms of declaration syntax I don&#39;t care so much *shru=
g*:</div>

<div><br></div><div>class MyClass{</div><div>public:</div><div>=C2=A0 =C2=
=A0 =C2=A0int bar~ {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 get: {ret=
urn bar * 2;}</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set: {bar =3D va=
lue / 2;}</div><div>=C2=A0 =C2=A0 =C2=A0}</div><div>private:</div><div>=C2=
=A0 =C2=A0 =C2=A0int bar;</div>

<div>};</div><div><br></div><div><br></div></div><div class=3D"HOEnZb"><div=
 class=3D"h5"><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote"=
>On Fri, Jul 11, 2014 at 12:26 PM, Bo Persson <span dir=3D"ltr">&lt;<a href=
=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<b=
r>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Tom Joe skrev 2014-07-11 10:47:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Excellent; Guess my assumptions were pretty close. =C2=A0As stated previous=
ly<br>
I&#39;m really not a seasonal-ed C++ programmer with the equipment necessar=
y<br>
to write a decent proposal so if anyone wants to jump in and take these<br>
discussions to the next level I&#39;d be more than happy to be of any but<b=
r>
likely no-assistance help at all :)..<br>
<br>
That said as a seasoned programming across multiple languages; I think<br>
Michaels and Seans arguments are substantial and I can see a huge<br>
benefit of having syntactical flaggers between the differences of a<br>
property and field (direct-access). =C2=A0It may break all previous standar=
ds<br>
in other languages but it may be the tipping innovation that makes<br>
properties happier for all programmers to use. =C2=A0Be it Object.Property#=
<br>
or Object-|Property vs Object-&gt;Field. =C2=A0Thoughts?<br>
<br>
</blockquote>
<br></div>
Being able to use Object.Property# instead of Object.Accessor() doesn&#39;t=
 seem like an improvement to me.<span><font color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div><div><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--e89a8f2356bd7f014504fdf3ac7b--

.

--001a1132ed063cc22a04fdf764bb
Content-Type: text/plain; charset=UTF-8

I feel like post-fixing isn't really what you want here (it's too similar
to a function syntax anyway):

something = object~property;
something = objectPtr~>property;

---
Visually; I prefer the operator identifier also.  But one concern I had
with this route was how IDE tools with intellisense would differentiate the
"." from the "~" list.  If only properties are shown with a "~" is that
going to hide important API discovery?  If both are shown but only
properties can be used is that going to be upsetting in natural usage?
Also wondered if the implementation would be stickier.  Seems minor but
something to consider.

Post-fixing certainly looks more like a hack job but carries the same
syntax identifier location as functions ( # for properties; () for
functions ); which I'd actually relate to a positive instead of a
negative.  Wonder if the rule, "Any identifier with a '#' post-fix is
identified by C++ as a property" would be a solution.  I also was thinking
the 3.0 CLI syntax may be a nice advantage.

object.property# = 0;
object.field = 3;
If (object.property#) then object.property# = object.property# + 1

class MyClass{
public:
    // CLI 3.0 syntax - compiler auto creates standard assignment vs
written out ones - just like a field but has access-or wrappers for those
who believe this is good practice to kill off a little speed :)
    int property# { const get; set; }

    // Written out
    int property#{
            get: {return property;}
            set: {property = value;}
private:
    int proeprty;
};


On Fri, Jul 11, 2014 at 5:55 PM, Michael Hamilton <mike@m2tm.net> wrote:

> class MyClass{
> public:
>      int bar~ {
>           const get: {return bar * 2;}
>           set: {bar = value / 2;}
>      }
> private:
>      int bar;
> };
>
>
> On Fri, Jul 11, 2014 at 4:50 PM, Michael Hamilton <mike@m2tm.net> wrote:
>
>> I feel like postfixing isn't really what you want here (it's too similar
>> to a function syntax anyway):
>>
>> something = object~property;
>> something = objectPtr~>property;
>>
>> object~property = something;
>> objectPtr~>property = something;
>>
>> Something like that would be fine with me.  A visual indication in a
>> similar way to function call vs member call is in order certainly.  This
>> also keeps the same number of characters as regular . or -> syntax so the
>> purpose of the property (convenience) is maintained.
>>
>> My primary complaint about properties is their invisible nature at the
>> call site, this would erase that concern.
>>
>> In terms of declaration syntax I don't care so much *shrug*:
>>
>> class MyClass{
>> public:
>>      int bar~ {
>>           get: {return bar * 2;}
>>           set: {bar = value / 2;}
>>      }
>> private:
>>      int bar;
>> };
>>
>>
>>
>>
>> On Fri, Jul 11, 2014 at 12:26 PM, Bo Persson <bop@gmb.dk> wrote:
>>
>>> Tom Joe skrev 2014-07-11 10:47:
>>>
>>>  Excellent; Guess my assumptions were pretty close.  As stated previously
>>>> I'm really not a seasonal-ed C++ programmer with the equipment necessary
>>>> to write a decent proposal so if anyone wants to jump in and take these
>>>> discussions to the next level I'd be more than happy to be of any but
>>>> likely no-assistance help at all :)..
>>>>
>>>> That said as a seasoned programming across multiple languages; I think
>>>> Michaels and Seans arguments are substantial and I can see a huge
>>>> benefit of having syntactical flaggers between the differences of a
>>>> property and field (direct-access).  It may break all previous standards
>>>> in other languages but it may be the tipping innovation that makes
>>>> properties happier for all programmers to use.  Be it Object.Property#
>>>> or Object-|Property vs Object->Field.  Thoughts?
>>>>
>>>>
>>> Being able to use Object.Property# instead of Object.Accessor() doesn't
>>> seem like an improvement to me.
>>>
>>>
>>> Bo Persson
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --- You received this message because you are subscribed to a topic in
>>> the Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/
>>> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1132ed063cc22a04fdf764bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>I feel like post-fixing=
 isn&#39;t really what you want here (it&#39;s too similar to a function sy=
ntax anyway):<br></div><div><br></div><div>something =3D object~property;<b=
r>
</div>something =3D objectPtr~&gt;property;<br><br>---<br></div>Visually; I=
 prefer the operator identifier also.=C2=A0 But one concern I had with this=
 route was how IDE tools with intellisense would differentiate the &quot;.&=
quot; from the &quot;~&quot; list.=C2=A0 If only properties are shown with =
a &quot;~&quot; is that going to hide important API discovery?=C2=A0 If bot=
h are shown but only properties can be used is that going to be upsetting i=
n natural usage?=C2=A0 Also wondered if the implementation would be stickie=
r.=C2=A0 Seems minor but something to consider.<br>
<br></div>Post-fixing certainly looks more like a hack job but carries the =
same syntax identifier location as functions ( # for properties; () for fun=
ctions ); which I&#39;d actually relate to a positive instead of a negative=
..=C2=A0 Wonder if the rule, &quot;Any identifier with a &#39;#&#39; post-fi=
x is identified by C++ as a property&quot; would be a solution.=C2=A0 I als=
o was thinking the 3.0 CLI syntax may be a nice advantage.<br>
<br></div></div></div><div>object.property# =3D 0;<br></div><div>object.fie=
ld =3D 3;<br></div>If (object.property#) then object.property# =3D object.p=
roperty# + 1<br><br></div><div>class MyClass{<br></div><div>public:<br></di=
v>
<div>=C2=A0=C2=A0=C2=A0 // CLI 3.0 syntax - compiler auto creates standard =
assignment vs written out ones - just like a field but has access-or wrappe=
rs for those who believe this is good practice to kill off a little speed :=
)<br></div>
<div>=C2=A0=C2=A0=C2=A0 int property# { const get; set; }=C2=A0=C2=A0=C2=A0=
=C2=A0 <br><br></div><div>=C2=A0=C2=A0=C2=A0 // Written out<br></div><div>=
=C2=A0=C2=A0=C2=A0 int property#{<br></div><div>=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 get: {return property;}<br></div><d=
iv>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 set: =
{property =3D value;}<br>
</div><div>private:<br></div><div>=C2=A0=C2=A0=C2=A0 int proeprty;<br>};<br=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Fri, Jul 11, 2014 at 5:55 PM, Michael Hamilton <span dir=3D"ltr">&lt;<a =
href=3D"mailto:mike@m2tm.net" target=3D"_blank">mike@m2tm.net</a>&gt;</span=
> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D""><div style=
=3D"font-family:arial,sans-serif;font-size:13px">class MyClass{</div><div s=
tyle=3D"font-family:arial,sans-serif;font-size:13px">
public:</div><div style=3D"font-family:arial,sans-serif;font-size:13px">=C2=
=A0 =C2=A0 =C2=A0int bar~ {</div>
</div><div style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 const get: {return bar * 2;}</div><div class=3D"">=
<div style=3D"font-family:arial,sans-serif;font-size:13px">=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 set: {bar =3D value / 2;}</div><div style=3D"font-fami=
ly:arial,sans-serif;font-size:13px">

=C2=A0 =C2=A0 =C2=A0}</div><div style=3D"font-family:arial,sans-serif;font-=
size:13px">private:</div><div style=3D"font-family:arial,sans-serif;font-si=
ze:13px">=C2=A0 =C2=A0 =C2=A0int bar;</div><div style=3D"font-family:arial,=
sans-serif;font-size:13px">};</div>

</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">On Fri, Jul 11, 2014 at 4:50 PM, Mic=
hael Hamilton <span dir=3D"ltr">&lt;<a href=3D"mailto:mike@m2tm.net" target=
=3D"_blank">mike@m2tm.net</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I feel like postfixing isn&#39;t really what you want=
 here (it&#39;s too similar to a function syntax anyway):<br></div><div><br=
></div><div>something =3D object~property;<br></div><div>something =3D obje=
ctPtr~&gt;property;<br>


</div><div><br></div>object~property =3D something;<div>objectPtr~&gt;prope=
rty =3D something;</div><div><div><br></div><div>Something like that would =
be fine with me. =C2=A0A visual indication in a similar way to function cal=
l vs member call is in order certainly. =C2=A0This also keeps the same numb=
er of characters as regular . or -&gt; syntax so the purpose of the propert=
y (convenience) is maintained.</div>


</div><div><br></div><div>My primary complaint about properties is their in=
visible nature at the call site, this would erase that concern.</div><div><=
br></div><div>In terms of declaration syntax I don&#39;t care so much *shru=
g*:</div>


<div><br></div><div>class MyClass{</div><div>public:</div><div>=C2=A0 =C2=
=A0 =C2=A0int bar~ {</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 get: {ret=
urn bar * 2;}</div><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 set: {bar =3D va=
lue / 2;}</div><div>=C2=A0 =C2=A0 =C2=A0}</div><div>private:</div><div>=C2=
=A0 =C2=A0 =C2=A0int bar;</div>


<div>};</div><div><br></div><div><br></div></div><div><div><div class=3D"gm=
ail_extra"><br><br><div class=3D"gmail_quote">On Fri, Jul 11, 2014 at 12:26=
 PM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:bop@gmb.dk" target=
=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br>


<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Tom Joe skrev 2014-07-11 10:47:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Excellent; Guess my assumptions were pretty close. =C2=A0As stated previous=
ly<br>
I&#39;m really not a seasonal-ed C++ programmer with the equipment necessar=
y<br>
to write a decent proposal so if anyone wants to jump in and take these<br>
discussions to the next level I&#39;d be more than happy to be of any but<b=
r>
likely no-assistance help at all :)..<br>
<br>
That said as a seasoned programming across multiple languages; I think<br>
Michaels and Seans arguments are substantial and I can see a huge<br>
benefit of having syntactical flaggers between the differences of a<br>
property and field (direct-access). =C2=A0It may break all previous standar=
ds<br>
in other languages but it may be the tipping innovation that makes<br>
properties happier for all programmers to use. =C2=A0Be it Object.Property#=
<br>
or Object-|Property vs Object-&gt;Field. =C2=A0Thoughts?<br>
<br>
</blockquote>
<br></div>
Being able to use Object.Property# instead of Object.Accessor() doesn&#39;t=
 seem like an improvement to me.<span><font color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div><div><br>
<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>



To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1132ed063cc22a04fdf764bb--

.

This is a multi-part message in MIME format.
--------------070400010201040507080809
Content-Type: text/plain; charset=UTF-8

On 30/06/14 06:26, Tom Joe wrote:
> Instead of the "what for" approach maybe a "why not" would make a more
> constructive argument.
>
C++ is currently a very complex language. In an attempt not to have its
age show in terms of capabilities, the language carries a whole bunch of
rules few people really understand. Never mind Koenig lookup, multiple
inheritance constructor calling order and semantics or SFINAE. The
average job candidate for senior C++ development positions doesn't know
about stuff in C++ that might kill you even if you don't know about
them, such as when it is dangerous to throw an exception or why is
"explicit" important.

Lately, I'm asking a couple of very simple C++ questions in job
interviews. I ask what methods the following class has:

class A {};

I also ask what does adding "virtual" to the destructor does and when it
is important.

Very few of the *senior* and *experienced* C++ candidates know the
answer to those two questions. I don't recall a single confident,
correct answer by anyone.

I've had a candidate implement diamond inheritance in his previous job.
I asked him about virtual inheritance. He didn't know how it worked. I
asked him what they did when they needed it. They, more or less, added
"virtual" everywhere until things sort of worked.

Back to your question of "why not?", the answer is "not to make the
language any more complicated". If there is no good reason for a change,
leave things as they are.

Shachar

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------070400010201040507080809
Content-Type: text/html; charset=UTF-8

<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0.2cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="UTF-8" bgcolor="#FFFFFF"
    text="#000000">
    <div class="moz-cite-prefix">On 30/06/14 06:26, Tom Joe wrote:<br>
    </div>
    <blockquote
cite="mid:CAPusOMb7GQXoUaowZ6kr9ZhRopxu3M4WS1uiJpe+7OmREPdutg@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div>Instead of the "what for" approach maybe a "why not" would
          make a more constructive argument.<br>
          <br>
        </div>
      </div>
    </blockquote>
    C++ is currently a very complex language. In an attempt not to have
    its age show in terms of capabilities, the language carries a whole
    bunch of rules few people really understand. Never mind Koenig
    lookup, multiple inheritance constructor calling order and semantics
    or SFINAE. The average job candidate for senior C++ development
    positions doesn't know about stuff in C++ that might kill you even
    if you don't know about them, such as when it is dangerous to throw
    an exception or why is "explicit" important.<br>
    <br>
    Lately, I'm asking a couple of very simple C++ questions in job
    interviews. I ask what methods the following class has:<br>
    <br>
    class A {};<br>
    <br>
    I also ask what does adding "virtual" to the destructor does and
    when it is important.<br>
    <br>
    Very few of the <b>senior</b> and <b>experienced</b> C++
    candidates know the answer to those two questions. I don't recall a
    single confident, correct answer by anyone.<br>
    <br>
    I've had a candidate implement diamond inheritance in his previous
    job. I asked him about virtual inheritance. He didn't know how it
    worked. I asked him what they did when they needed it. They, more or
    less, added "virtual" everywhere until things sort of worked.<br>
    <br>
    Back to your question of "why not?", the answer is "not to make the
    language any more complicated". If there is no good reason for a
    change, leave things as they are.<br>
    <br>
    Shachar<br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------070400010201040507080809--

.

--Apple-Mail=_AA013332-1BBD-4805-B305-B1361948B3D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-12, at 2:09 PM, Shachar Shemesh <shachar@lingnu.com> wrote:

> C++ is currently a very complex language. In an attempt not to have its a=
ge show in terms of capabilities, the language carries a whole bunch of rul=
es few people really understand. Never mind Koenig lookup, multiple inherit=
ance constructor calling order and semantics or SFINAE.

None of those capabilities are legacy. Most languages are hard to formally =
understand. Have you looked at the JavaScript spec lately?

> Very few of the senior and experienced C++ candidates know the answer to =
those two questions. I don't recall a single confident, correct answer by a=
nyone.

Nobody reads the job requirements, and "experience" sounds fuzzy anyway. Pr=
ogrammer opportunities attract a random assortment of freeloading riffraff,=
 that's just the nature of the game.

> Back to your question of "why not?", the answer is "not to make the langu=
age any more complicated". If there is no good reason for a change, leave t=
hings as they are.

Aside from the last few suggestions regarding new punctuation, which I don'=
t really see the motivation of, this discussion was starting to center on l=
ibrary-only solutions. Such would add nothing to the core language, and onl=
y simplify and normalize something that many folks hack through (or search =
for a copy-pastable hack).

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_AA013332-1BBD-4805-B305-B1361948B3D0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;12, at 2:09 PM, Shachar Shemesh &lt;<a href=3D"mailto:shacha=
r@lingnu.com">shachar@lingnu.com</a>&gt; wrote:</div><br class=3D"Apple-int=
erchange-newline"><blockquote type=3D"cite"><div bidimailui-detected-decodi=
ng-type=3D"UTF-8" bgcolor=3D"#FFFFFF" text=3D"#000000" style=3D"font-family=
: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; fon=
t-weight: normal; letter-spacing: normal; line-height: normal; orphans: aut=
o; text-align: start; text-indent: 0px; text-transform: none; white-space: =
normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; di=
rection: ltr;"><div class=3D"moz-cite-prefix">C++ is currently a very compl=
ex language. In an attempt not to have its age show in terms of capabilitie=
s, the language carries a whole bunch of rules few people really understand=
.. Never mind Koenig lookup, multiple inheritance constructor calling order =
and semantics or SFINAE.</div></div></blockquote><div><br></div><div>None o=
f those capabilities are legacy. Most languages are hard to formally unders=
tand. Have you looked at the JavaScript spec lately?</div><br><blockquote t=
ype=3D"cite"><div bidimailui-detected-decoding-type=3D"UTF-8" bgcolor=3D"#F=
FFFFF" text=3D"#000000" style=3D"font-family: Helvetica; font-size: 12px; f=
ont-style: normal; font-variant: normal; font-weight: normal; letter-spacin=
g: normal; line-height: normal; orphans: auto; text-align: start; text-inde=
nt: 0px; text-transform: none; white-space: normal; widows: auto; word-spac=
ing: 0px; -webkit-text-stroke-width: 0px; direction: ltr;">Very few of the<=
span class=3D"Apple-converted-space">&nbsp;</span><b>senior</b><span class=
=3D"Apple-converted-space">&nbsp;</span>and<span class=3D"Apple-converted-s=
pace">&nbsp;</span><b>experienced</b><span class=3D"Apple-converted-space">=
&nbsp;</span>C++ candidates know the answer to those two questions. I don't=
 recall a single confident, correct answer by anyone.<br></div></blockquote=
><div><br></div><div>Nobody reads the job requirements, and &ldquo;experien=
ce&rdquo; sounds fuzzy anyway. Programmer opportunities attract a random as=
sortment of freeloading riffraff, that&rsquo;s just the nature of the game.=
</div><br><blockquote type=3D"cite"><div bidimailui-detected-decoding-type=
=3D"UTF-8" bgcolor=3D"#FFFFFF" text=3D"#000000" style=3D"font-family: Helve=
tica; font-size: 12px; font-style: normal; font-variant: normal; font-weigh=
t: normal; letter-spacing: normal; line-height: normal; orphans: auto; text=
-align: start; text-indent: 0px; text-transform: none; white-space: normal;=
 widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; direction=
: ltr;">Back to your question of "why not?", the answer is "not to make the=
 language any more complicated". If there is no good reason for a change, l=
eave things as they are.<br></div></blockquote></div><br><div>Aside from th=
e last few suggestions regarding new punctuation, which I don&rsquo;t reall=
y see the motivation of, this discussion was starting to center on library-=
only solutions. Such would add nothing to the core language, and only simpl=
ify and normalize something that many folks hack through (or search for a c=
opy-pastable hack).</div><div><br></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_AA013332-1BBD-4805-B305-B1361948B3D0--

.

--047d7bf0d2f64b66f004fdf9c535
Content-Type: text/plain; charset=UTF-8

"If there is no good reason for a change, leave things as they are."

Yes; agreed.  But "no good reason" is a matter of view point.
C++ typical access-or implementation has historically been with functions
SetValue() GetValue().  And once again it must be pointed out that
Properties only simply the status quo.

For Example a library object has:
DoThis()                            DoThis()
DoThat()                            DoThat()
SetXPos()                          XPos#
SetYPos()                         YPos#
SetZPos()                          ZPos#
GetXPos()
GetYPos()
GetZPos()

There's always the overloading that is probably the easiest way to
"simulate" properties
int YPos(int Y){YPos = Y;}
int YPos(){return Y;}

but this really makes source code evaluation even the all the more confusing
if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather
confusing
vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#' YPos
is an access-or and therefore may be a point of heavy processing

Just another thought to the posting; Ask experienced C++ applicants, "Do
you know what a property is?"


On Sat, Jul 12, 2014 at 12:09 AM, Shachar Shemesh <shachar@lingnu.com>
wrote:

>  On 30/06/14 06:26, Tom Joe wrote:
>
>  Instead of the "what for" approach maybe a "why not" would make a more
> constructive argument.
>
>   C++ is currently a very complex language. In an attempt not to have its
> age show in terms of capabilities, the language carries a whole bunch of
> rules few people really understand. Never mind Koenig lookup, multiple
> inheritance constructor calling order and semantics or SFINAE. The average
> job candidate for senior C++ development positions doesn't know about stuff
> in C++ that might kill you even if you don't know about them, such as when
> it is dangerous to throw an exception or why is "explicit" important.
>
> Lately, I'm asking a couple of very simple C++ questions in job
> interviews. I ask what methods the following class has:
>
> class A {};
>
> I also ask what does adding "virtual" to the destructor does and when it
> is important.
>
> Very few of the *senior* and *experienced* C++ candidates know the answer
> to those two questions. I don't recall a single confident, correct answer
> by anyone.
>
> I've had a candidate implement diamond inheritance in his previous job. I
> asked him about virtual inheritance. He didn't know how it worked. I asked
> him what they did when they needed it. They, more or less, added "virtual"
> everywhere until things sort of worked.
>
> Back to your question of "why not?", the answer is "not to make the
> language any more complicated". If there is no good reason for a change,
> leave things as they are.
>
> Shachar
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
>
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bf0d2f64b66f004fdf9c535
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div><div><di=
v><div><div><div><div><div><div>&quot;If there is no good reason for a
    change, leave things as they are.&quot;<br><br></div>Yes; agreed.=C2=A0=
 But &quot;no good reason&quot; is a matter of view point.<br></div>C++ typ=
ical access-or implementation has historically been with functions=C2=A0 Se=
tValue() GetValue().=C2=A0 And once again it must be pointed out that Prope=
rties only simply the status quo.<br>
<br></div>For Example a library object has:<br></div>DoThis()=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 DoThis()<br></div>DoThat()=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 DoThat()<br></div>SetXPos()=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 XPos#=
<br></div>SetYPos()=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 YPos#<br>
</div>SetZPos()=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 ZPos#<br></div>GetXPos()<br></div>GetYPos()<br></div>GetZPo=
s()<br><br></div>There&#39;s always the overloading that is probably the ea=
siest way to &quot;simulate&quot; properties<br>
</div>int YPos(int Y){YPos =3D Y;}<br></div>int YPos(){return Y;}<br><br></=
div>but this really makes source code evaluation even the all the more conf=
using<br></div>if (Ypos()) { YPos(YPos() + 1);}=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // Vi=
sually rather confusing<br>
</div>vs if (YPos#) { YPos# =3D YPos# + 1;}=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 // We know from syntax &#39;#&#39; YPos is an access-or =
and therefore may be a point of heavy processing<br><br></div>Just another =
thought to the posting; Ask experienced C++ applicants, &quot;Do you know w=
hat a property is?&quot;<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Sat,=
 Jul 12, 2014 at 12:09 AM, Shachar Shemesh <span dir=3D"ltr">&lt;<a href=3D=
"mailto:shachar@lingnu.com" target=3D"_blank">shachar@lingnu.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
 =20
   =20
   =20
 =20
  <div style=3D"direction:ltr" bgcolor=3D"#FFFFFF" text=3D"#000000"><div cl=
ass=3D"">
    <div>On 30/06/14 06:26, Tom Joe wrote:<br>
    </div>
    <blockquote type=3D"cite">
      <div dir=3D"ltr">
        <div>Instead of the &quot;what for&quot; approach maybe a &quot;why=
 not&quot; would
          make a more constructive argument.<br>
          <br>
        </div>
      </div>
    </blockquote></div>
    C++ is currently a very complex language. In an attempt not to have
    its age show in terms of capabilities, the language carries a whole
    bunch of rules few people really understand. Never mind Koenig
    lookup, multiple inheritance constructor calling order and semantics
    or SFINAE. The average job candidate for senior C++ development
    positions doesn&#39;t know about stuff in C++ that might kill you even
    if you don&#39;t know about them, such as when it is dangerous to throw
    an exception or why is &quot;explicit&quot; important.<br>
    <br>
    Lately, I&#39;m asking a couple of very simple C++ questions in job
    interviews. I ask what methods the following class has:<br>
    <br>
    class A {};<br>
    <br>
    I also ask what does adding &quot;virtual&quot; to the destructor does =
and
    when it is important.<br>
    <br>
    Very few of the <b>senior</b> and <b>experienced</b> C++
    candidates know the answer to those two questions. I don&#39;t recall a
    single confident, correct answer by anyone.<br>
    <br>
    I&#39;ve had a candidate implement diamond inheritance in his previous
    job. I asked him about virtual inheritance. He didn&#39;t know how it
    worked. I asked him what they did when they needed it. They, more or
    less, added &quot;virtual&quot; everywhere until things sort of worked.=
<br>
    <br>
    Back to your question of &quot;why not?&quot;, the answer is &quot;not =
to make the
    language any more complicated&quot;. If there is no good reason for a
    change, leave things as they are.<br>
    <br>
    Shachar<br>
  </div><div class=3D"">


<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
</div>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<div class=3D"HOEnZb">=
<div class=3D"h5"><br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bf0d2f64b66f004fdf9c535--

.

Tom Joe skrev 2014-07-12 09:11:
> "If there is no good reason for a change, leave things as they are."
>
> Yes; agreed.  But "no good reason" is a matter of view point.
> C++ typical access-or implementation has historically been with
> functions  SetValue() GetValue().

Not really. How many getX and setX do you find in the standard library?

I see it more common to have pairs of functions, like

int value() const;
void value(int);

if you allow changing the value.


> And once again it must be pointed out
> that Properties only simply the status quo.
>
> For Example a library object has:
> DoThis()                            DoThis()
> DoThat()                            DoThat()
> SetXPos()                          XPos#
> SetYPos()                         YPos#
> SetZPos()                          ZPos#
> GetXPos()
> GetYPos()
> GetZPos()
>
> There's always the overloading that is probably the easiest way to
> "simulate" properties
> int YPos(int Y){YPos = Y;}
> int YPos(){return Y;}
>
> but this really makes source code evaluation even the all the more confusing
> if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather
> confusing
> vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#'
> YPos is an access-or and therefore may be a point of heavy processing

I would do this

if (YPos())
    MoveUp(1);

which is even shorter and hides the internal representation better.


Bo Persson




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--Apple-Mail=_8A3AF7A7-7A08-4578-8CCE-1695E02CFC54
Content-Type: text/plain; charset=ISO-8859-1


On 2014-07-12, at 6:00 PM, Bo Persson <bop@gmb.dk> wrote:

> Tom Joe skrev 2014-07-12 09:11:
>> "If there is no good reason for a change, leave things as they are."
>>
>> Yes; agreed.  But "no good reason" is a matter of view point.
>> C++ typical access-or implementation has historically been with
>> functions  SetValue() GetValue().
>
> Not really. How many getX and setX do you find in the standard library?

The standard library is not a typical C++ library XvD

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--Apple-Mail=_8A3AF7A7-7A08-4578-8CCE-1695E02CFC54
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07&ndash;12, at 6:00 PM, Bo Persson &lt;<a href=3D"mailto:bop@gmb.dk"=
>bop@gmb.dk</a>&gt; wrote:</div><br class=3D"Apple-interchange-newline"><bl=
ockquote type=3D"cite"><div style=3D"font-size: 12px; font-style: normal; f=
ont-variant: normal; font-weight: normal; letter-spacing: normal; line-heig=
ht: normal; orphans: auto; text-align: start; text-indent: 0px; text-transf=
orm: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-te=
xt-stroke-width: 0px;">Tom Joe skrev 2014-07-12 09:11:<br><blockquote type=
=3D"cite">"If there is no good reason for a change, leave things as they ar=
e."<br><br>Yes; agreed. &nbsp;But "no good reason" is a matter of view poin=
t.<br>C++ typical access-or implementation has historically been with<br>fu=
nctions &nbsp;SetValue() GetValue().<br></blockquote><br>Not really. How ma=
ny getX and setX do you find in the standard library?<br></div></blockquote=
><div><br></div><div>The standard library is not a typical C++ library XvD<=
/div></div><br></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_8A3AF7A7-7A08-4578-8CCE-1695E02CFC54--

.

--001a1136734466dad804fdfe91be
Content-Type: text/plain; charset=UTF-8

Not to bring out the point that MoveUp() is completely blind to it's
association of the YPos memory since it is not named the same (this was an
example context - so point made).  I'll be honest; when starting out
learning C++ I had instantly lock-thought "properties" and researching
produced a plethora of hacks that were dis-heartening.  Only till some time
later I saw a post say "overloading" at which point was a slap in the head
*duh*.  Which by all means I feel is a "good-enough" straight forward
properties substitute.

That said; along the same lines as properties being dis-liked for being
confused with fields;  Using functions can also be confused with wider than
memory adjustment functionality.  For some, it may be a dilluted process to
think that one function definition gets something while its overload does
the exactly the opposite (inverse) and sets it.  This may be thought of as
"un-wildly" different behavior.  I think for now though I'm won over as a
"good-enough" approach.  I should've become more familiar with C++ before
getting all upset about, "Where's the darn properties" :)..


On Sat, Jul 12, 2014 at 4:00 AM, Bo Persson <bop@gmb.dk> wrote:

> Tom Joe skrev 2014-07-12 09:11:
>
>  "If there is no good reason for a change, leave things as they are."
>>
>> Yes; agreed.  But "no good reason" is a matter of view point.
>> C++ typical access-or implementation has historically been with
>> functions  SetValue() GetValue().
>>
>
> Not really. How many getX and setX do you find in the standard library?
>
> I see it more common to have pairs of functions, like
>
> int value() const;
> void value(int);
>
> if you allow changing the value.
>
>
>
>  And once again it must be pointed out
>> that Properties only simply the status quo.
>>
>> For Example a library object has:
>> DoThis()                            DoThis()
>> DoThat()                            DoThat()
>> SetXPos()                          XPos#
>> SetYPos()                         YPos#
>> SetZPos()                          ZPos#
>> GetXPos()
>> GetYPos()
>> GetZPos()
>>
>> There's always the overloading that is probably the easiest way to
>> "simulate" properties
>> int YPos(int Y){YPos = Y;}
>> int YPos(){return Y;}
>>
>> but this really makes source code evaluation even the all the more
>> confusing
>> if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather
>> confusing
>> vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#'
>> YPos is an access-or and therefore may be a point of heavy processing
>>
>
> I would do this
>
> if (YPos())
>    MoveUp(1);
>
> which is even shorter and hides the internal representation better.
>
>
> Bo Persson
>
>
>
>
>
> --
>
> --- You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit https://groups.google.com/a/
> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
> proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1136734466dad804fdfe91be
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Not to bring out the point that MoveUp() is completel=
y blind to it&#39;s association of the YPos memory since it is not named th=
e same (this was an example context - so point made).=C2=A0 I&#39;ll be hon=
est; when starting out learning C++ I had instantly lock-thought &quot;prop=
erties&quot; and researching produced a plethora of hacks that were dis-hea=
rtening.=C2=A0 Only till some time later I saw a post say &quot;overloading=
&quot; at which point was a slap in the head *duh*.=C2=A0 Which by all mean=
s I feel is a &quot;good-enough&quot; straight forward properties substitut=
e.<br>
<br></div><div>That said; along the same lines as properties being dis-like=
d for being confused with fields;=C2=A0 Using functions can also be confuse=
d with wider than memory adjustment functionality.=C2=A0 For some, it may b=
e a dilluted process to think that one function definition gets something w=
hile its overload does the exactly the opposite (inverse) and sets it.=C2=
=A0 This may be thought of as &quot;un-wildly&quot; different behavior.=C2=
=A0 I think for now though I&#39;m won over as a &quot;good-enough&quot; ap=
proach.=C2=A0 I should&#39;ve become more familiar with C++ before getting =
all upset about, &quot;Where&#39;s the darn properties&quot; :).. <br>
</div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">O=
n Sat, Jul 12, 2014 at 4:00 AM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D=
"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">
Tom Joe skrev 2014-07-12 09:11:<div class=3D""><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
&quot;If there is no good reason for a change, leave things as they are.&qu=
ot;<br>
<br>
Yes; agreed. =C2=A0But &quot;no good reason&quot; is a matter of view point=
..<br>
C++ typical access-or implementation has historically been with<br>
functions =C2=A0SetValue() GetValue().<br>
</blockquote>
<br></div>
Not really. How many getX and setX do you find in the standard library?<br>
<br>
I see it more common to have pairs of functions, like<br>
<br>
int value() const;<br>
void value(int);<br>
<br>
if you allow changing the value.<div class=3D""><br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And once again it must be pointed out<br>
that Properties only simply the status quo.<br>
<br>
For Example a library object has:<br>
DoThis() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThis()<br>
DoThat() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThat()<br>
SetXPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0XPos#<br>
SetYPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 YPos#<br>
SetZPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0ZPos#<br>
GetXPos()<br>
GetYPos()<br>
GetZPos()<br>
<br>
There&#39;s always the overloading that is probably the easiest way to<br>
&quot;simulate&quot; properties<br>
int YPos(int Y){YPos =3D Y;}<br>
int YPos(){return Y;}<br>
<br>
but this really makes source code evaluation even the all the more confusin=
g<br>
if (Ypos()) { YPos(YPos() + 1);} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // Visually rather<br>
confusing<br>
vs if (YPos#) { YPos# =3D YPos# + 1;} =C2=A0 =C2=A0 =C2=A0 =C2=A0 // We kno=
w from syntax &#39;#&#39;<br>
YPos is an access-or and therefore may be a point of heavy processing<br>
</blockquote>
<br></div>
I would do this<br>
<br>
if (YPos())<br>
=C2=A0 =C2=A0MoveUp(1);<br>
<br>
which is even shorter and hides the internal representation better.<span cl=
ass=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1136734466dad804fdfe91be--

.

--089e013d115e5c61a904fe0294e8
Content-Type: text/plain; charset=UTF-8

MoveUp is a great method.  Most good method names increase the level of
abstraction while allowing the user to express intent rather than focus on
twiddling variables.

Part of the reason I don't care too much about properties is that they are
a pretty low-level concept that can be over-used to break encapsulation by
tying an object's interface too closely to its internal representation.

Obviously I don't think "because it can be misused it shouldn't be in the
language".  But I do want to bring this up.

"But one concern I had with this route was how IDE tools with intellisense
would differentiate the "." from the "~" list.  If only properties are
shown with a "~" is that going to hide important API discovery?" -Tom Joe

I think this is a non-issue.  Vendors would have *more* flexibility in
exposing properties and methods and variables as separate concepts than
ever before.  It's a common tool behavior to automatically dereference a
pointer variable when you type "." by replacing it with "->".  What makes
you think a compiler vendor or tool vendor would be incapable of parsing
object~ any more than object. or object->?

Given the following class:

class Class {
public:
    int Member~ {
        get: {return Member}
    }
    void Method(){}
    void Method(int param){}
    int MemberPublic;
private:
    int Member;
};

If I were to type:

Class object;
object.M------

The intellisense could easily check all members and offer such a list:

(Method) void Method()
(Method) void Method(int)
(Property:Get) Member
(Variable) int MemberPublic
(Private)-----
(Variable) int Member

Then if you were to select the Member get it could easily substitute the .
for ~

I think you vastly underestimate tool vendors and compiler vendors.  They
have access to all the information, it's just a matter of presentation.
 While not free to implement (nothing is), it certainly wouldn't be
impossible or ambiguous.



On Sat, Jul 12, 2014 at 5:55 AM, Tom Joe <tgit28@gmail.com> wrote:

> Not to bring out the point that MoveUp() is completely blind to it's
> association of the YPos memory since it is not named the same (this was an
> example context - so point made).  I'll be honest; when starting out
> learning C++ I had instantly lock-thought "properties" and researching
> produced a plethora of hacks that were dis-heartening.  Only till some time
> later I saw a post say "overloading" at which point was a slap in the head
> *duh*.  Which by all means I feel is a "good-enough" straight forward
> properties substitute.
>
> That said; along the same lines as properties being dis-liked for being
> confused with fields;  Using functions can also be confused with wider than
> memory adjustment functionality.  For some, it may be a dilluted process to
> think that one function definition gets something while its overload does
> the exactly the opposite (inverse) and sets it.  This may be thought of as
> "un-wildly" different behavior.  I think for now though I'm won over as a
> "good-enough" approach.  I should've become more familiar with C++ before
> getting all upset about, "Where's the darn properties" :)..
>
>
> On Sat, Jul 12, 2014 at 4:00 AM, Bo Persson <bop@gmb.dk> wrote:
>
>> Tom Joe skrev 2014-07-12 09:11:
>>
>>  "If there is no good reason for a change, leave things as they are."
>>>
>>> Yes; agreed.  But "no good reason" is a matter of view point.
>>> C++ typical access-or implementation has historically been with
>>> functions  SetValue() GetValue().
>>>
>>
>> Not really. How many getX and setX do you find in the standard library?
>>
>> I see it more common to have pairs of functions, like
>>
>> int value() const;
>> void value(int);
>>
>> if you allow changing the value.
>>
>>
>>
>>  And once again it must be pointed out
>>> that Properties only simply the status quo.
>>>
>>> For Example a library object has:
>>> DoThis()                            DoThis()
>>> DoThat()                            DoThat()
>>> SetXPos()                          XPos#
>>> SetYPos()                         YPos#
>>> SetZPos()                          ZPos#
>>> GetXPos()
>>> GetYPos()
>>> GetZPos()
>>>
>>> There's always the overloading that is probably the easiest way to
>>> "simulate" properties
>>> int YPos(int Y){YPos = Y;}
>>> int YPos(){return Y;}
>>>
>>> but this really makes source code evaluation even the all the more
>>> confusing
>>> if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather
>>> confusing
>>> vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#'
>>> YPos is an access-or and therefore may be a point of heavy processing
>>>
>>
>> I would do this
>>
>> if (YPos())
>>    MoveUp(1);
>>
>> which is even shorter and hides the internal representation better.
>>
>>
>> Bo Persson
>>
>>
>>
>>
>>
>> --
>>
>> --- You received this message because you are subscribed to a topic in
>> the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit https://groups.google.com/a/
>> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>> proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e013d115e5c61a904fe0294e8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">MoveUp is a great method. =C2=A0Most good method names inc=
rease the level of abstraction while allowing the user to express intent ra=
ther than focus on twiddling variables.<div><br></div><div>Part of the reas=
on I don&#39;t care too much about properties is that they are a pretty low=
-level concept that can be over-used to break encapsulation by tying an obj=
ect&#39;s interface too closely to its internal representation.</div>
<div><br></div><div>Obviously I don&#39;t think &quot;because it can be mis=
used it shouldn&#39;t be in the language&quot;. =C2=A0But I do want to brin=
g this up.</div><div><br></div><div>&quot;<span style=3D"font-family:arial,=
sans-serif;font-size:13px">But one concern I had with this route was how ID=
E tools with intellisense would differentiate the &quot;.&quot; from the &q=
uot;~&quot; list.=C2=A0 If only properties are shown with a &quot;~&quot; i=
s that going to hide important API discovery?&quot; -Tom Joe</span></div>
<div><br></div><div>I think this is a non-issue. =C2=A0Vendors would have *=
more* flexibility in exposing properties and methods and variables as separ=
ate concepts than ever before. =C2=A0It&#39;s a common tool behavior to aut=
omatically dereference a pointer variable when you type &quot;.&quot; by re=
placing it with &quot;-&gt;&quot;. =C2=A0What makes you think a compiler ve=
ndor or tool vendor would be incapable of parsing object~ any more than obj=
ect. or object-&gt;?</div>
<div><br></div><div>Given the following class:</div><div><br></div><div>cla=
ss Class {</div><div>public:</div><div><div>=C2=A0 =C2=A0 int Member~ {</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 get: {return Member}</div><div>=C2=A0 =
=C2=A0 }</div></div><div>=C2=A0 =C2=A0 void Method(){}</div>
<div>=C2=A0 =C2=A0 void Method(int param){}</div><div>=C2=A0 =C2=A0 int Mem=
berPublic;</div><div>private:</div><div>=C2=A0 =C2=A0 int Member;<br></div>=
<div>};</div><div><br></div><div>If I were to type:</div><div><br></div><di=
v>Class object;</div><div>
object.M------</div><div><br></div><div>The intellisense could easily check=
 all members and offer such a list:</div><div><br></div><div>(Method) void =
Method()</div><div>(Method) void Method(int)</div><div>(Property:Get) Membe=
r</div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px">(Variable)=
 int MemberPublic</span></div><div>(Private)-----</div><div>(Variable) int =
Member</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px=
"><br>
</span></div><div><font face=3D"arial, sans-serif">Then if you were to sele=
ct the Member get it could easily substitute the . for ~</font></div><div><=
font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, =
sans-serif">I think you vastly underestimate tool vendors and compiler vend=
ors. =C2=A0They have access to all the information, it&#39;s just a matter =
of presentation. =C2=A0While not free to implement (nothing is), it certain=
ly wouldn&#39;t be impossible or ambiguous.</font></div>
<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">=
On Sat, Jul 12, 2014 at 5:55 AM, Tom Joe <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.com</a>&gt;</span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Not to bring out the p=
oint that MoveUp() is completely blind to it&#39;s association of the YPos =
memory since it is not named the same (this was an example context - so poi=
nt made).=C2=A0 I&#39;ll be honest; when starting out learning C++ I had in=
stantly lock-thought &quot;properties&quot; and researching produced a plet=
hora of hacks that were dis-heartening.=C2=A0 Only till some time later I s=
aw a post say &quot;overloading&quot; at which point was a slap in the head=
 *duh*.=C2=A0 Which by all means I feel is a &quot;good-enough&quot; straig=
ht forward properties substitute.<br>

<br></div><div>That said; along the same lines as properties being dis-like=
d for being confused with fields;=C2=A0 Using functions can also be confuse=
d with wider than memory adjustment functionality.=C2=A0 For some, it may b=
e a dilluted process to think that one function definition gets something w=
hile its overload does the exactly the opposite (inverse) and sets it.=C2=
=A0 This may be thought of as &quot;un-wildly&quot; different behavior.=C2=
=A0 I think for now though I&#39;m won over as a &quot;good-enough&quot; ap=
proach.=C2=A0 I should&#39;ve become more familiar with C++ before getting =
all upset about, &quot;Where&#39;s the darn properties&quot; :).. <br>

</div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote">On Sat, Jul 12, 2014 at 4:00 AM, Bo =
Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:bop@gmb.dk" target=3D"_blan=
k">bop@gmb.dk</a>&gt;</span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Tom Joe skrev 2014-07-12 09:11:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
&quot;If there is no good reason for a change, leave things as they are.&qu=
ot;<br>
<br>
Yes; agreed. =C2=A0But &quot;no good reason&quot; is a matter of view point=
..<br>
C++ typical access-or implementation has historically been with<br>
functions =C2=A0SetValue() GetValue().<br>
</blockquote>
<br></div>
Not really. How many getX and setX do you find in the standard library?<br>
<br>
I see it more common to have pairs of functions, like<br>
<br>
int value() const;<br>
void value(int);<br>
<br>
if you allow changing the value.<div><br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And once again it must be pointed out<br>
that Properties only simply the status quo.<br>
<br>
For Example a library object has:<br>
DoThis() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThis()<br>
DoThat() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThat()<br>
SetXPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0XPos#<br>
SetYPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 YPos#<br>
SetZPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0ZPos#<br>
GetXPos()<br>
GetYPos()<br>
GetZPos()<br>
<br>
There&#39;s always the overloading that is probably the easiest way to<br>
&quot;simulate&quot; properties<br>
int YPos(int Y){YPos =3D Y;}<br>
int YPos(){return Y;}<br>
<br>
but this really makes source code evaluation even the all the more confusin=
g<br>
if (Ypos()) { YPos(YPos() + 1);} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // Visually rather<br>
confusing<br>
vs if (YPos#) { YPos# =3D YPos# + 1;} =C2=A0 =C2=A0 =C2=A0 =C2=A0 // We kno=
w from syntax &#39;#&#39;<br>
YPos is an access-or and therefore may be a point of heavy processing<br>
</blockquote>
<br></div>
I would do this<br>
<br>
if (YPos())<br>
=C2=A0 =C2=A0MoveUp(1);<br>
<br>
which is even shorter and hides the internal representation better.<span><f=
ont color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div><div><br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013d115e5c61a904fe0294e8--

.

--047d7b6d7aa67f16c804fe0a8ff3
Content-Type: text/plain; charset=UTF-8

"I think this is a non-issue." - I'm sure it is as you've stated; just
wanted the implementation part to be under consideration by the experts :).

For some odd reason I still believe it would be a plus for C++ to adopt a
"standard" properties approach.
Just as a more clearly defined isolation definition between Public
Variable, Property, and Method callers. ( Using syntax difference between
field and property Object~Property = 3.0 and Object~>Property = 1.0 )

But with simple overloading doing the API shrinking into-half as keyword
elements instead of get/set prefixes; the only benefit left in
consideration is syntactics Object.Property(3.0) vs Object~Property = 3.0
Its extremely minor so; for me, If it acts like a property and has the API
of a property the setting(value) is just as good/functional as an '=' sign
once the concept sets in.

How much abstraction at what architectural level is best practice; I
suppose can vary from every particular situation and implementation level.


On Sat, Jul 12, 2014 at 11:42 AM, Michael Hamilton <mike@m2tm.net> wrote:

> MoveUp is a great method.  Most good method names increase the level of
> abstraction while allowing the user to express intent rather than focus on
> twiddling variables.
>
> Part of the reason I don't care too much about properties is that they are
> a pretty low-level concept that can be over-used to break encapsulation by
> tying an object's interface too closely to its internal representation.
>
> Obviously I don't think "because it can be misused it shouldn't be in the
> language".  But I do want to bring this up.
>
> "But one concern I had with this route was how IDE tools with
> intellisense would differentiate the "." from the "~" list.  If only
> properties are shown with a "~" is that going to hide important API
> discovery?" -Tom Joe
>
> I think this is a non-issue.  Vendors would have *more* flexibility in
> exposing properties and methods and variables as separate concepts than
> ever before.  It's a common tool behavior to automatically dereference a
> pointer variable when you type "." by replacing it with "->".  What makes
> you think a compiler vendor or tool vendor would be incapable of parsing
> object~ any more than object. or object->?
>
> Given the following class:
>
> class Class {
> public:
>     int Member~ {
>         get: {return Member}
>     }
>     void Method(){}
>     void Method(int param){}
>     int MemberPublic;
> private:
>     int Member;
> };
>
> If I were to type:
>
> Class object;
> object.M------
>
> The intellisense could easily check all members and offer such a list:
>
> (Method) void Method()
> (Method) void Method(int)
> (Property:Get) Member
> (Variable) int MemberPublic
> (Private)-----
> (Variable) int Member
>
> Then if you were to select the Member get it could easily substitute the .
> for ~
>
> I think you vastly underestimate tool vendors and compiler vendors.  They
> have access to all the information, it's just a matter of presentation.
>  While not free to implement (nothing is), it certainly wouldn't be
> impossible or ambiguous.
>
>
>
> On Sat, Jul 12, 2014 at 5:55 AM, Tom Joe <tgit28@gmail.com> wrote:
>
>> Not to bring out the point that MoveUp() is completely blind to it's
>> association of the YPos memory since it is not named the same (this was an
>> example context - so point made).  I'll be honest; when starting out
>> learning C++ I had instantly lock-thought "properties" and researching
>> produced a plethora of hacks that were dis-heartening.  Only till some time
>> later I saw a post say "overloading" at which point was a slap in the head
>> *duh*.  Which by all means I feel is a "good-enough" straight forward
>> properties substitute.
>>
>> That said; along the same lines as properties being dis-liked for being
>> confused with fields;  Using functions can also be confused with wider than
>> memory adjustment functionality.  For some, it may be a dilluted process to
>> think that one function definition gets something while its overload does
>> the exactly the opposite (inverse) and sets it.  This may be thought of as
>> "un-wildly" different behavior.  I think for now though I'm won over as a
>> "good-enough" approach.  I should've become more familiar with C++ before
>> getting all upset about, "Where's the darn properties" :)..
>>
>>
>> On Sat, Jul 12, 2014 at 4:00 AM, Bo Persson <bop@gmb.dk> wrote:
>>
>>> Tom Joe skrev 2014-07-12 09:11:
>>>
>>>  "If there is no good reason for a change, leave things as they are."
>>>>
>>>> Yes; agreed.  But "no good reason" is a matter of view point.
>>>> C++ typical access-or implementation has historically been with
>>>> functions  SetValue() GetValue().
>>>>
>>>
>>> Not really. How many getX and setX do you find in the standard library?
>>>
>>> I see it more common to have pairs of functions, like
>>>
>>> int value() const;
>>> void value(int);
>>>
>>> if you allow changing the value.
>>>
>>>
>>>
>>>  And once again it must be pointed out
>>>> that Properties only simply the status quo.
>>>>
>>>> For Example a library object has:
>>>> DoThis()                            DoThis()
>>>> DoThat()                            DoThat()
>>>> SetXPos()                          XPos#
>>>> SetYPos()                         YPos#
>>>> SetZPos()                          ZPos#
>>>> GetXPos()
>>>> GetYPos()
>>>> GetZPos()
>>>>
>>>> There's always the overloading that is probably the easiest way to
>>>> "simulate" properties
>>>> int YPos(int Y){YPos = Y;}
>>>> int YPos(){return Y;}
>>>>
>>>> but this really makes source code evaluation even the all the more
>>>> confusing
>>>> if (Ypos()) { YPos(YPos() + 1);}                 // Visually rather
>>>> confusing
>>>> vs if (YPos#) { YPos# = YPos# + 1;}         // We know from syntax '#'
>>>> YPos is an access-or and therefore may be a point of heavy processing
>>>>
>>>
>>> I would do this
>>>
>>> if (YPos())
>>>    MoveUp(1);
>>>
>>> which is even shorter and hides the internal representation better.
>>>
>>>
>>> Bo Persson
>>>
>>>
>>>
>>>
>>>
>>> --
>>>
>>> --- You received this message because you are subscribed to a topic in
>>> the Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit https://groups.google.com/a/
>>> isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposals+unsubscribe@isocpp.org.
>>> To post to this group, send email to std-proposals@isocpp.org.
>>> Visit this group at http://groups.google.com/a/isocpp.org/group/std-
>>> proposals/.
>>>
>>
>>  --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b6d7aa67f16c804fe0a8ff3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>&quot;I think this is a non-issue.&quot; - =
I&#39;m sure it is as you&#39;ve stated; just wanted the implementation par=
t to be under consideration by the experts :).<br><br></div>For some odd re=
ason I still believe it would be a plus for C++ to adopt a &quot;standard&q=
uot; properties approach.<br>
Just as a more clearly defined isolation definition between Public Variable=
, Property, and Method callers. ( Using syntax difference between field and=
 property Object~Property =3D 3.0 and Object~&gt;Property =3D 1.0 )<br><br>
But with simple overloading doing the API shrinking into-half as keyword el=
ements instead of get/set prefixes; the only benefit left in consideration =
is syntactics Object.Property(3.0) vs Object~Property =3D 3.0<br></div>Its =
extremely minor so; for me, If it acts like a property and has the API of a=
 property the setting(value) is just as good/functional as an &#39;=3D&#39;=
 sign once the concept sets in.<br>
<br></div>How much abstraction at what architectural level is best practice=
; I suppose can vary from every particular situation and implementation lev=
el.<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">
On Sat, Jul 12, 2014 at 11:42 AM, Michael Hamilton <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:mike@m2tm.net" target=3D"_blank">mike@m2tm.net</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr">MoveUp is a great method. =C2=A0Most good method names inc=
rease the level of abstraction while allowing the user to express intent ra=
ther than focus on twiddling variables.<div><br></div><div>Part of the reas=
on I don&#39;t care too much about properties is that they are a pretty low=
-level concept that can be over-used to break encapsulation by tying an obj=
ect&#39;s interface too closely to its internal representation.</div>

<div><br></div><div>Obviously I don&#39;t think &quot;because it can be mis=
used it shouldn&#39;t be in the language&quot;. =C2=A0But I do want to brin=
g this up.</div><div><br></div><div>&quot;<span style=3D"font-family:arial,=
sans-serif;font-size:13px">But one concern I had with this route was how ID=
E tools with intellisense would differentiate the &quot;.&quot; from the &q=
uot;~&quot; list.=C2=A0 If only properties are shown with a &quot;~&quot; i=
s that going to hide important API discovery?&quot; -Tom Joe</span></div>

<div><br></div><div>I think this is a non-issue. =C2=A0Vendors would have *=
more* flexibility in exposing properties and methods and variables as separ=
ate concepts than ever before. =C2=A0It&#39;s a common tool behavior to aut=
omatically dereference a pointer variable when you type &quot;.&quot; by re=
placing it with &quot;-&gt;&quot;. =C2=A0What makes you think a compiler ve=
ndor or tool vendor would be incapable of parsing object~ any more than obj=
ect. or object-&gt;?</div>

<div><br></div><div>Given the following class:</div><div><br></div><div>cla=
ss Class {</div><div>public:</div><div><div>=C2=A0 =C2=A0 int Member~ {</di=
v><div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 get: {return Member}</div><div>=C2=A0 =
=C2=A0 }</div></div><div>=C2=A0 =C2=A0 void Method(){}</div>

<div>=C2=A0 =C2=A0 void Method(int param){}</div><div>=C2=A0 =C2=A0 int Mem=
berPublic;</div><div>private:</div><div>=C2=A0 =C2=A0 int Member;<br></div>=
<div>};</div><div><br></div><div>If I were to type:</div><div><br></div><di=
v>Class object;</div><div>

object.M------</div><div><br></div><div>The intellisense could easily check=
 all members and offer such a list:</div><div><br></div><div>(Method) void =
Method()</div><div>(Method) void Method(int)</div><div>(Property:Get) Membe=
r</div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px">(Variable)=
 int MemberPublic</span></div><div>(Private)-----</div><div>(Variable) int =
Member</div><div><span style=3D"font-family:arial,sans-serif;font-size:13px=
"><br>

</span></div><div><font face=3D"arial, sans-serif">Then if you were to sele=
ct the Member get it could easily substitute the . for ~</font></div><div><=
font face=3D"arial, sans-serif"><br></font></div><div><font face=3D"arial, =
sans-serif">I think you vastly underestimate tool vendors and compiler vend=
ors. =C2=A0They have access to all the information, it&#39;s just a matter =
of presentation. =C2=A0While not free to implement (nothing is), it certain=
ly wouldn&#39;t be impossible or ambiguous.</font></div>

<div><span style=3D"font-family:arial,sans-serif;font-size:13px"><br></span=
></div></div><div class=3D"HOEnZb"><div class=3D"h5"><div class=3D"gmail_ex=
tra"><br><br><div class=3D"gmail_quote">On Sat, Jul 12, 2014 at 5:55 AM, To=
m Joe <span dir=3D"ltr">&lt;<a href=3D"mailto:tgit28@gmail.com" target=3D"_=
blank">tgit28@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Not to bring out the p=
oint that MoveUp() is completely blind to it&#39;s association of the YPos =
memory since it is not named the same (this was an example context - so poi=
nt made).=C2=A0 I&#39;ll be honest; when starting out learning C++ I had in=
stantly lock-thought &quot;properties&quot; and researching produced a plet=
hora of hacks that were dis-heartening.=C2=A0 Only till some time later I s=
aw a post say &quot;overloading&quot; at which point was a slap in the head=
 *duh*.=C2=A0 Which by all means I feel is a &quot;good-enough&quot; straig=
ht forward properties substitute.<br>


<br></div><div>That said; along the same lines as properties being dis-like=
d for being confused with fields;=C2=A0 Using functions can also be confuse=
d with wider than memory adjustment functionality.=C2=A0 For some, it may b=
e a dilluted process to think that one function definition gets something w=
hile its overload does the exactly the opposite (inverse) and sets it.=C2=
=A0 This may be thought of as &quot;un-wildly&quot; different behavior.=C2=
=A0 I think for now though I&#39;m won over as a &quot;good-enough&quot; ap=
proach.=C2=A0 I should&#39;ve become more familiar with C++ before getting =
all upset about, &quot;Where&#39;s the darn properties&quot; :).. <br>


</div></div><div><div><div class=3D"gmail_extra"><br><br><div class=3D"gmai=
l_quote">On Sat, Jul 12, 2014 at 4:00 AM, Bo Persson <span dir=3D"ltr">&lt;=
<a href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a>&gt;</span> w=
rote:<br>

<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Tom Joe skrev 2014-07-12 09:11:<div><br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
&quot;If there is no good reason for a change, leave things as they are.&qu=
ot;<br>
<br>
Yes; agreed. =C2=A0But &quot;no good reason&quot; is a matter of view point=
..<br>
C++ typical access-or implementation has historically been with<br>
functions =C2=A0SetValue() GetValue().<br>
</blockquote>
<br></div>
Not really. How many getX and setX do you find in the standard library?<br>
<br>
I see it more common to have pairs of functions, like<br>
<br>
int value() const;<br>
void value(int);<br>
<br>
if you allow changing the value.<div><br>
<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And once again it must be pointed out<br>
that Properties only simply the status quo.<br>
<br>
For Example a library object has:<br>
DoThis() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThis()<br>
DoThat() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DoThat()<br>
SetXPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0XPos#<br>
SetYPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 YPos#<br>
SetZPos() =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0ZPos#<br>
GetXPos()<br>
GetYPos()<br>
GetZPos()<br>
<br>
There&#39;s always the overloading that is probably the easiest way to<br>
&quot;simulate&quot; properties<br>
int YPos(int Y){YPos =3D Y;}<br>
int YPos(){return Y;}<br>
<br>
but this really makes source code evaluation even the all the more confusin=
g<br>
if (Ypos()) { YPos(YPos() + 1);} =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 // Visually rather<br>
confusing<br>
vs if (YPos#) { YPos# =3D YPos# + 1;} =C2=A0 =C2=A0 =C2=A0 =C2=A0 // We kno=
w from syntax &#39;#&#39;<br>
YPos is an access-or and therefore may be a point of heavy processing<br>
</blockquote>
<br></div>
I would do this<br>
<br>
if (YPos())<br>
=C2=A0 =C2=A0MoveUp(1);<br>
<br>
which is even shorter and hides the internal representation better.<span><f=
ont color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div><div><br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/<u></u>isocpp.org/d/topic/std-<u></u>proposa=
ls/n0QcD_K5dBY/<u></u>unsubscribe</a>.<br>



To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@<u></u>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.=
org/group/std-<u></u>proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>


To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b6d7aa67f16c804fe0a8ff3--

.

------=_Part_742_29936711.1405259886039
Content-Type: text/plain; charset=UTF-8

What about having public const access to members? I think it avoids most of
the problems and still improves things significantly.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_742_29936711.1405259886039
Content-Type: text/html; charset=UTF-8

<div dir="ltr">What about having public const access to members? I think it avoids most of the problems and still improves things significantly.</div>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_742_29936711.1405259886039--

.

------=_Part_2304_4410888.1405389404174
Content-Type: text/plain; charset=UTF-8

On the other hand I'm not sure that the abuse of a feature is a good
argument against that feature.

On Friday, June 6, 2014 1:03:19 AM UTC-4, Miro Knejp wrote:
>
>
> Am 06.06.2014 06:23, schrieb Andrew Tomazos:
> > (...) A little more boilerplate and maybe a little less efficient than
> > what the compiler could do for you (...)
> >
> To me this statement is an indication that maybe language support might
> be worth considering, as a portable "zero cost" library solution is not
> possible for something that could be done with no overhead by the
> compiler. That being said I'm myself not sure whether properties in
> general are a good idea as something that looks like an innocent member
> access could be hiding an expensive operation without the user being
> aware of its implication. The function call syntax at least makes the
> reader aware that "something's possibly happening". And that being said
> I can't remember how many times I wished I could give a member variable
> public read access without having to boilerplate a getter every time.
> I'm really not sure on which side of the fence I am here.
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On the other hand I'm not sure that the abuse of a feature=
 is a good argument against that feature.<div><br>On Friday, June 6, 2014 1=
:03:19 AM UTC-4, Miro Knejp wrote:<blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<br>Am 06.06.2014 06:23, schrieb Andrew Tomazos:
<br>&gt; (...) A little more boilerplate and maybe a little less efficient =
than=20
<br>&gt; what the compiler could do for you (...)
<br>&gt;
<br>To me this statement is an indication that maybe language support might=
=20
<br>be worth considering, as a portable "zero cost" library solution is not=
=20
<br>possible for something that could be done with no overhead by the=20
<br>compiler. That being said I'm myself not sure whether properties in=20
<br>general are a good idea as something that looks like an innocent member=
=20
<br>access could be hiding an expensive operation without the user being=20
<br>aware of its implication. The function call syntax at least makes the=
=20
<br>reader aware that "something's possibly happening". And that being said=
=20
<br>I can't remember how many times I wished I could give a member variable=
=20
<br>public read access without having to boilerplate a getter every time.=
=20
<br>I'm really not sure on which side of the fence I am here.
<br>
<br></blockquote></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2304_4410888.1405389404174--

.

--089e01182d0a95fff204fe35cd4e
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 15, 2014 at 3:56 AM, <openmysourcecode@gmail.com> wrote:

> On the other hand I'm not sure that the abuse of a feature is a good
> argument against that feature.
>

 I would say, in general, that the committee considers very carefully how a
proposed feature could be abused and what the consequences of that abuse
could be.  This analysis does strongly impact how they vote.  Most voting
members come from very large companies that team program very large
important codebases, where the cost of potentially dangerous, or even
potentially hard to read / follow code, is very high and to which they are
very sensitive.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01182d0a95fff204fe35cd4e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tue, Jul 15, 2014 at 3:56 AM,  <span dir=3D"ltr">&lt;<a=
 href=3D"mailto:openmysourcecode@gmail.com" target=3D"_blank">openmysourcec=
ode@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div clas=
s=3D"gmail_quote">
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr">On the other hand I&#39;m n=
ot sure that the abuse of a feature is a good argument against that feature=
..</div>
</blockquote><div><br></div><div>=C2=A0I would say, in general, that the co=
mmittee considers very carefully how a proposed feature could be abused and=
 what the consequences of that abuse could be.=C2=A0 This analysis does str=
ongly impact how they vote.=C2=A0 Most voting members come from very large =
companies that team program very large important codebases, where the cost =
of potentially dangerous, or even potentially hard to read / follow code, i=
s very high and to which they are very sensitive.<br>
</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01182d0a95fff204fe35cd4e--

.

Properties will improve fundamental abstraction in c++. Currently, we have =
the situation where a class can have member variables and functions. At the=
 very lowest level of abstraction, these variables and functions can often =
match directly to the abstraction's "properties " and "methods" and things =
appears fine.

As the level of abstraction increases, member functions can follow, impleme=
nting increasing levels of abstraction. However the member variables fall f=
lat on their faces and instead of being able to carry on directly modeling =
the "properties" of the object, they are inadequate and we have to start us=
ing functions to represent the properties instead (getters and setters). Th=
is ends up with a disparity between low-level abstractions and high-level a=
bstractions.=20

In summary, properties would allow class designers to provide clearer abstr=
actions  by removing the necessity to use member functions instead of varia=
bles to represent an abstraction's properties as the abstraction level incr=
eases. They are able to provide a clear high-level representation without f=
orcing designers down the road of turning their class interfaces into a gro=
up of functions, where some happen to represent abstracted properties of so=
me level, and its not clear which (some get/set functions might relate to a=
bstracted properties, other get/set functions might not).

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--047d7bdc915e063fd4050055225d
Content-Type: text/plain; charset=UTF-8

Dido what Tim Yorke states, "improve fundamental abstraction".

Properties may be considered 'ad-lib' to many and by all means it is.
However, Object-Oriented programming paradigms introduce 'Properties' in
general and by-far as an OOP fundamental component of abstraction.  That
reason alone (Yes; that is a reason) should make a good basis for adoption
of 'Properties' in C++ (An OOP language) just as it would not be expected
to be included in C because C is not an OOP language.  The C++ OOP-Model
doesn't feel "complete/mature" without property support.

With symbolic upper-level syntax differences between properties vs fields,
there doesn't seem to be a good reason not to have a basic standard for the
OOP-abstraction component 'Properties' is there?




On Sat, Aug 9, 2014 at 2:08 AM, Tim Yorke <timyorke34@gmail.com> wrote:

> Properties will improve fundamental abstraction in c++. Currently, we have
> the situation where a class can have member variables and functions. At the
> very lowest level of abstraction, these variables and functions can often
> match directly to the abstraction's "properties " and "methods" and things
> appears fine.
>
> As the level of abstraction increases, member functions can follow,
> implementing increasing levels of abstraction. However the member variables
> fall flat on their faces and instead of being able to carry on directly
> modeling the "properties" of the object, they are inadequate and we have to
> start using functions to represent the properties instead (getters and
> setters). This ends up with a disparity between low-level abstractions and
> high-level abstractions.
>
> In summary, properties would allow class designers to provide clearer
> abstractions  by removing the necessity to use member functions instead of
> variables to represent an abstraction's properties as the abstraction level
> increases. They are able to provide a clear high-level representation
> without forcing designers down the road of turning their class interfaces
> into a group of functions, where some happen to represent abstracted
> properties of some level, and its not clear which (some get/set functions
> might relate to abstracted properties, other get/set functions might not).
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdc915e063fd4050055225d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dido what Tim Yorke states, &quot;improve fundamental abst=
raction&quot;.=C2=A0 <br><br>Properties may be considered &#39;ad-lib&#39; =
to many and by all means it is.=C2=A0 However, Object-Oriented programming =
paradigms introduce &#39;Properties&#39; in general and by-far as an OOP fu=
ndamental component of abstraction.=C2=A0 That reason alone (Yes; that is a=
 reason) should make a good basis for adoption of &#39;Properties&#39; in C=
++ (An OOP language) just as it would not be expected to be included in C b=
ecause C is not an OOP language.=C2=A0 The C++ OOP-Model doesn&#39;t feel &=
quot;complete/mature&quot; without property support.<br>
<br>With symbolic upper-level syntax differences between properties vs fiel=
ds, there doesn&#39;t seem to be a good reason not to have a basic standard=
 for the OOP-abstraction component &#39;Properties&#39; is there?<br><br>
<br></div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On =
Sat, Aug 9, 2014 at 2:08 AM, Tim Yorke <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:timyorke34@gmail.com" target=3D"_blank">timyorke34@gmail.com</a>&gt;</s=
pan> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">Properties will improve fundamental abstract=
ion in c++. Currently, we have the situation where a class can have member =
variables and functions. At the very lowest level of abstraction, these var=
iables and functions can often match directly to the abstraction&#39;s &quo=
t;properties &quot; and &quot;methods&quot; and things appears fine.<br>

<br>
As the level of abstraction increases, member functions can follow, impleme=
nting increasing levels of abstraction. However the member variables fall f=
lat on their faces and instead of being able to carry on directly modeling =
the &quot;properties&quot; of the object, they are inadequate and we have t=
o start using functions to represent the properties instead (getters and se=
tters). This ends up with a disparity between low-level abstractions and hi=
gh-level abstractions.<br>

<br>
In summary, properties would allow class designers to provide clearer abstr=
actions =C2=A0by removing the necessity to use member functions instead of =
variables to represent an abstraction&#39;s properties as the abstraction l=
evel increases. They are able to provide a clear high-level representation =
without forcing designers down the road of turning their class interfaces i=
nto a group of functions, where some happen to represent abstracted propert=
ies of some level, and its not clear which (some get/set functions might re=
late to abstracted properties, other get/set functions might not).<br>

<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc915e063fd4050055225d--

.

On 2014-08-11, at 3:02 PM, Tom Joe <tgit28@gmail.com> wrote:

> Properties may be considered 'ad-lib' to many and by all means it is.  Ho=
wever, Object-Oriented programming paradigms introduce 'Properties' in gene=
ral and by-far as an OOP fundamental component of abstraction.  That reason=
 alone (Yes; that is a reason) should make a good basis for adoption of 'Pr=
operties' in C++ (An OOP language) just as it would not be expected to be i=
ncluded in C because C is not an OOP language.  The C++ OOP-Model doesn't f=
eel "complete/mature" without property support.

Manager: Marketing data shows that sales would increase 68% if the front wi=
ndow had multicolored tabs.
Engineer: But that would be inconsistent! What kind of users want colorful =
baubles; do we really want to sell to them at all?

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a1136d018b982dc0501171a3b
Content-Type: text/plain; charset=UTF-8

It would be interesting to know which implementation (properties vs
overloading) at the language core level would execute faster.  I've kind-of
gotta hunch that dis-ambiguating a property would execute quicker than
dis-ambiguating an overload thinking along the assumption that properties
would only have 2-paths available.


On Mon, Aug 11, 2014 at 6:32 PM, David Krauss <potswa@gmail.com> wrote:

>
> On 2014-08-11, at 3:02 PM, Tom Joe <tgit28@gmail.com> wrote:
>
> > Properties may be considered 'ad-lib' to many and by all means it is.
> However, Object-Oriented programming paradigms introduce 'Properties' in
> general and by-far as an OOP fundamental component of abstraction.  That
> reason alone (Yes; that is a reason) should make a good basis for adoption
> of 'Properties' in C++ (An OOP language) just as it would not be expected
> to be included in C because C is not an OOP language.  The C++ OOP-Model
> doesn't feel "complete/mature" without property support.
>
> Manager: Marketing data shows that sales would increase 68% if the front
> window had multicolored tabs.
> Engineer: But that would be inconsistent! What kind of users want colorful
> baubles; do we really want to sell to them at all?
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1136d018b982dc0501171a3b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">It would be interesting to know which implementation (prop=
erties vs overloading) at the language core level would execute faster.=C2=
=A0 I&#39;ve kind-of gotta hunch that dis-ambiguating a property would exec=
ute quicker than dis-ambiguating an overload thinking along the assumption =
that properties would only have 2-paths available.<br>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">On Mon,=
 Aug 11, 2014 at 6:32 PM, David Krauss <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>&gt;</span> wro=
te:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D""><br>
On 2014-08-11, at 3:02 PM, Tom Joe &lt;<a href=3D"mailto:tgit28@gmail.com">=
tgit28@gmail.com</a>&gt; wrote:<br>
<br>
&gt; Properties may be considered &#39;ad-lib&#39; to many and by all means=
 it is.=C2=A0 However, Object-Oriented programming paradigms introduce &#39=
;Properties&#39; in general and by-far as an OOP fundamental component of a=
bstraction.=C2=A0 That reason alone (Yes; that is a reason) should make a g=
ood basis for adoption of &#39;Properties&#39; in C++ (An OOP language) jus=
t as it would not be expected to be included in C because C is not an OOP l=
anguage.=C2=A0 The C++ OOP-Model doesn&#39;t feel &quot;complete/mature&quo=
t; without property support.<br>

<br>
</div>Manager: Marketing data shows that sales would increase 68% if the fr=
ont window had multicolored tabs.<br>
Engineer: But that would be inconsistent! What kind of users want colorful =
baubles; do we really want to sell to them at all?<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>

To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1136d018b982dc0501171a3b--

.

------=_Part_343_62688595.1412080148898
Content-Type: text/plain; charset=UTF-8

Here is a good article on the subject of properties in C++:

Saying No To Properties
<http://www.drdobbs.com/windows/saying-no-to-properties/240005920>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_343_62688595.1412080148898
Content-Type: text/html; charset=UTF-8

<div dir="ltr">Here is a good article on the subject of properties in C++:<br><br><a href="http://www.drdobbs.com/windows/saying-no-to-properties/240005920">Saying No To Properties</a><br><br></div>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

------=_Part_343_62688595.1412080148898--

.

--089e01228b1aef9ccc0504497d0b
Content-Type: text/plain; charset=UTF-8

I always have to laugh at these articles. While trying to prove properties
are terrible they always seem to me to UN-intentionally show better their
benefits.

Casting - How would you internally cast a field w/o re-implementing a new
API whereas if a property has a multi-type return the cast could be
encapsulated by it's class definition.
Expression dog.expressHappiness()? wouldn't that even be better expressed
as dog.IsHappy = True/False leaving the finer details of doing anything at
all up to the class definition.

Call it bad practice; but I've always found it very handy to allow event
triggers that are strictly related to a property/data change to happen
automatically.  Just as an example; who would really appreciate having to
set all the fonts, size, margins etc...  in menus and THEN having to
remember to call Doc.ApplySettings(Struct Settings).  When making a setting
it seems natural to just apply it automatically and when one wants to
retrieve what font is used just retrieve it.  Maybe it's just a thinking
method but I've always associated data structures to be part of class
design and consider it the benefit of having OOP over Functional
programming (No more packing around data everywhere; just keep it where
functions are written to use it and ability to create any # of
Storage/Functioning compartments (objects).   Print MyData.ToString()

New B BankAccount($0);
B.Widrawl($50);
B.Deposit($50);
B.AccountType = FreeChecking(Enum);

If B.AccountType = FreeChecking Then ....

On Tue, Sep 30, 2014 at 8:38 AM, Tom Joe <tgit28@gmail.com> wrote:

> I always have to laugh at these articles. While trying to prove properties
> are terrible they always seem to me to UN-intentionally show better their
> benefits.
>
> Casting - How would you internally cast a field w/o re-implementing a new
> API whereas if a property has a multi-type return the cast could be
> encapsulated by it's class definition.
> Expression dog.expressHappiness()? wouldn't that even be better expressed
> as dog.IsHappy = True/False leaving the finer details of doing anything at
> all up to the class definition.
>
> Call it bad practice; but I've always found it very handy to allow event
> triggers that are strictly related to a property/data change to happen
> automatically.  Just as an example; who would really appreciate having to
> set all the fonts, size, margins etc...  in menus and THEN having to
> remember to call Doc.ApplySettings(Struct Settings).  When making a setting
> it seems natural to just apply it automatically and when one wants to
> retrieve what font is used just retrieve it.  Maybe it's just a thinking
> method but I've always associated data structures to be part of class
> design and consider it the benefit of having OOP over Functional
> programming (No more packing around data everywhere; just keep it where
> functions are written to use it and ability to create any # of
> Storage/Functioning compartments (objects).   Print MyData.ToString()
>
> New B BankAccount($0);
> B.Widrawl($50);
> B.Deposit($50);
> B.AccountType = FreeChecking(Enum);
>
> If B.AccountType = FreeChecking Then ....
>
>
> On Tue, Sep 30, 2014 at 6:29 AM, Boris Rasin <rasin.boris@gmail.com>
> wrote:
>
>> Here is a good article on the subject of properties in C++:
>>
>> Saying No To Properties
>> <http://www.drdobbs.com/windows/saying-no-to-properties/240005920>
>>
>>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01228b1aef9ccc0504497d0b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div>I always have to laugh at th=
ese articles.=20
While trying to prove properties are terrible they always seem to me to=20
UN-intentionally show better their benefits.<br><br></div>Casting - How=20
would you internally cast a field w/o re-implementing a new API whereas=20
if a property has a multi-type return the cast could be encapsulated by=20
it&#39;s class definition.<br>Expression <code>dog.expressHappiness()? </co=
de>wouldn&#39;t
 that even be better expressed as dog.IsHappy =3D True/False leaving the=20
finer details of doing anything at all up to the class definition.<br><br><=
/div>Call
 it bad practice; but I&#39;ve always found it very handy to allow event=20
triggers that are strictly related to a property/data change to happen=20
automatically.=C2=A0 Just as an example; who would really appreciate having=
=20
to set all the fonts, size, margins etc...=C2=A0 in menus and THEN having t=
o=20
remember to call Doc.ApplySettings(Struct Settings).=C2=A0 When making a=20
setting it seems natural to just apply it automatically and when one=20
wants to retrieve what font is used just retrieve it.=C2=A0 Maybe it&#39;s =
just a
 thinking method but I&#39;ve always associated data structures to be part=
=20
of class design and consider it the benefit of having OOP over=20
Functional programming (No more packing around data everywhere; just=20
keep it where functions are written to use it and ability to create any #
 of Storage/Functioning compartments (objects).=C2=A0=C2=A0 Print=20
MyData.ToString()<br><br></div>New B BankAccount($0);<br></div>B.Widrawl($5=
0);<br>B.Deposit($50);<br></div>B.AccountType =3D FreeChecking(Enum);<br><b=
r></div>If B.AccountType =3D FreeChecking Then ....</div><div class=3D"gmai=
l_extra"><br><div class=3D"gmail_quote">On Tue, Sep 30, 2014 at 8:38 AM, To=
m Joe <span dir=3D"ltr">&lt;<a href=3D"mailto:tgit28@gmail.com" target=3D"_=
blank">tgit28@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail=
_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div dir=3D"ltr"><div><div><div><div><div><div>I always have to laugh =
at these articles. While trying to prove properties are terrible they alway=
s seem to me to UN-intentionally show better their benefits.<br><br></div>C=
asting - How would you internally cast a field w/o re-implementing a new AP=
I whereas if a property has a multi-type return the cast could be encapsula=
ted by it&#39;s class definition.<br>Expression <code>dog.expressHappiness(=
)? </code>wouldn&#39;t that even be better expressed as dog.IsHappy =3D Tru=
e/False leaving the finer details of doing anything at all up to the class =
definition.<br><br></div>Call it bad practice; but I&#39;ve always found it=
 very handy to allow event triggers that are strictly related to a property=
/data change to happen automatically.=C2=A0 Just as an example; who would r=
eally appreciate having to set all the fonts, size, margins etc...=C2=A0 in=
 menus and THEN having to remember to call Doc.ApplySettings(Struct Setting=
s).=C2=A0 When making a setting it seems natural to just apply it automatic=
ally and when one wants to retrieve what font is used just retrieve it.=C2=
=A0 Maybe it&#39;s just a thinking method but I&#39;ve always associated da=
ta structures to be part of class design and consider it the benefit of hav=
ing OOP over Functional programming (No more packing around data everywhere=
; just keep it where functions are written to use it and ability to create =
any # of Storage/Functioning compartments (objects).=C2=A0=C2=A0 Print MyDa=
ta.ToString()<br><br></div>New B BankAccount($0);<br></div>B.Widrawl($50);<=
br>B.Deposit($50);<br></div>B.AccountType =3D FreeChecking(Enum);<br><br></=
div>If B.AccountType =3D FreeChecking Then ....<br><div><div><div><div><div=
><br></div></div></div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tue, S=
ep 30, 2014 at 6:29 AM, Boris Rasin <span dir=3D"ltr">&lt;<a href=3D"mailto=
:rasin.boris@gmail.com" target=3D"_blank">rasin.boris@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Here is a goo=
d article on the subject of properties in C++:<br><br><a href=3D"http://www=
..drdobbs.com/windows/saying-no-to-properties/240005920" target=3D"_blank">S=
aying No To Properties</a><br><br></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01228b1aef9ccc0504497d0b--

.

How's that a good article?
I don't think it's good at all. It's basically saying: don't use
properties as public data members.

On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin <rasin.boris@gmail.com> wrote:
> Here is a good article on the subject of properties in C++:
>
> Saying No To Properties
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.



--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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


On Tuesday, 30 September 2014 15:49:36 UTC+1, Tom Joe wrote:
>
> =20
> Call it bad practice; but I've always found it very handy to allow event=
=20
> triggers that are strictly related to a property/data change to happen=20
> automatically.  Just as an example; who would really appreciate having to=
=20
> set all the fonts, size, margins etc...  in menus and THEN having to=20
> remember to call Doc.ApplySettings(Struct Settings).  When making a setti=
ng=20
> it seems natural to just apply it automatically and when one wants to=20
> retrieve what font is used just retrieve it.  Maybe it's just a thinking=
=20
> method but I've always associated data structures to be part of class=20
> design and consider it the benefit of having OOP over Functional=20
> programming (No more packing around data everywhere; just keep it where=
=20
> functions are written to use it and ability to create any # of=20
> Storage/Functioning compartments (objects).   Print MyData.ToString()
>
What?  Surely if properties were to be allowed, using some sort of trigger=
=20
mechanism seems inefficient to me.  As far as I=E2=80=99m concerned, the on=
ly=20
realistic way would be to implement property handlers, i.e. to map it to a=
=20
setter/getter.=20

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr"><br>On Tuesday, 30 September 2014 15:49:36 UTC+1, Tom Joe =
 wrote:<blockquote style=3D"margin: 0px 0px 0px 0.8ex; padding-left: 1ex; b=
order-left-color: rgb(204, 204, 204); border-left-width: 1px; border-left-s=
tyle: solid;" class=3D"gmail_quote"><div dir=3D"ltr"><div><div><div><div><d=
iv>&nbsp;</div>Call
 it bad practice; but I've always found it very handy to allow event=20
triggers that are strictly related to a property/data change to happen=20
automatically.&nbsp; Just as an example; who would really appreciate having=
=20
to set all the fonts, size, margins etc...&nbsp; in menus and THEN having t=
o=20
remember to call Doc.ApplySettings(Struct Settings).&nbsp; When making a=20
setting it seems natural to just apply it automatically and when one=20
wants to retrieve what font is used just retrieve it.&nbsp; Maybe it's just=
 a
 thinking method but I've always associated data structures to be part=20
of class design and consider it the benefit of having OOP over=20
Functional programming (No more packing around data everywhere; just=20
keep it where functions are written to use it and ability to create any #
 of Storage/Functioning compartments (objects).&nbsp;&nbsp; Print=20
MyData.ToString()<br></div></div></div></div></div></blockquote><div>What?&=
nbsp;&nbsp;Surely if properties were to be allowed, using some sort of trig=
ger mechanism seems inefficient to me.&nbsp;&nbsp;As far as I=E2=80=99m con=
cerned, the only realistic way would be to implement property handlers, i.e=
.. to map it to a setter/getter.&nbsp;</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5319_1498760943.1412152841752--

.

------=_Part_5363_317993742.1412153396226
Content-Type: text/plain; charset=UTF-8

It says don't use public data members, properties or not. And that, I
think, is a pretty good practice.

On Tuesday, September 30, 2014 7:16:11 PM UTC+3, Olaf van der Spek wrote:
>
> How's that a good article?
> I don't think it's good at all. It's basically saying: don't use
> properties as public data members.
>
> On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin <rasin...@gmail.com
> <javascript:>> wrote:
> > Here is a good article on the subject of properties in C++:
> >
> > Saying No To Properties
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to a topic in the
> > Google Groups "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this topic, visit
> >
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe.
>
> > To unsubscribe from this group and all its topics, send an email to
> > std-proposal...@isocpp.org <javascript:>.
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
>
> --
> Olaf
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">It says don't use public data members, properties or not. =
And that, I think, is a pretty good practice.<br><br>On Tuesday, September =
30, 2014 7:16:11 PM UTC+3, Olaf van der Spek wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid=
;padding-left: 1ex;">How's that a good article?
<br>I don't think it's good at all. It's basically saying: don't use
<br>properties as public data members.
<br>
<br>On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"vZ0kxpbkE7wJ" onmousedown=3D"t=
his.href=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:'=
;return true;">rasin...@gmail.com</a>&gt; wrote:
<br>&gt; Here is a good article on the subject of properties in C++:
<br>&gt;
<br>&gt; Saying No To Properties
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to a topic in=
 the
<br>&gt; Google Groups "ISO C++ Standard - Future Proposals" group.
<br>&gt; To unsubscribe from this topic, visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/n0QcD_K5dBY/unsubscribe" target=3D"_blank" onmousedown=3D"this.href=
=3D'https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dB=
Y/unsubscribe';return true;" onclick=3D"this.href=3D'https://groups.google.=
com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe';return true=
;">https://groups.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/n=
0QcD_K5dBY/<wbr>unsubscribe</a>.
<br>&gt; To unsubscribe from this group and all its topics, send an email t=
o
<br>&gt; <a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"vZ0kxpbkE7wJ" onmousedown=3D"this.href=3D'javascript:';return true;" oncli=
ck=3D"this.href=3D'javascript:';return true;">std-proposal...@<wbr>isocpp.o=
rg</a>.
<br>&gt; To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"vZ0kxpbkE7wJ" onmousedown=3D"this.hre=
f=3D'javascript:';return true;" onclick=3D"this.href=3D'javascript:';return=
 true;">std-pr...@isocpp.org</a>.
<br>&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank" onmousedown=3D"this.href=3D'http://groups.google.com=
/a/isocpp.org/group/std-proposals/';return true;" onclick=3D"this.href=3D'h=
ttp://groups.google.com/a/isocpp.org/group/std-proposals/';return true;">ht=
tp://groups.google.com/a/<wbr>isocpp.org/group/std-<wbr>proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Olaf
<br></blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5363_317993742.1412153396226--

.

--047d7bd9037ed3047f0504e32ef3
Content-Type: text/plain; charset=UTF-8

Actually I personally am quite curious as to this claim "don't use public
data members" - I've heard it time and time again from many different
sources but have often wondered where it originates from or what exactly is
it's intention.  While I can relate to the versatility of separating user
data from functional code (say XML file as input) - if everything is XML
then what exactly was the point of the OOP paradigm (Allowing data and
function to be encapsulated together) to begin with?  Just stuff all the
XML attributes into a function and stick with functional programming with
namespaces.

I'm sure I'm missing something here - but I have yet to have someone offer
up a good explanation.

On Wed, Oct 1, 2014 at 2:49 AM, Boris Rasin <rasin.boris@gmail.com> wrote:

> It says don't use public data members, properties or not. And that, I
> think, is a pretty good practice.
>
> On Tuesday, September 30, 2014 7:16:11 PM UTC+3, Olaf van der Spek wrote:
>>
>> How's that a good article?
>> I don't think it's good at all. It's basically saying: don't use
>> properties as public data members.
>>
>> On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin <rasin...@gmail.com> wrote:
>> > Here is a good article on the subject of properties in C++:
>> >
>> > Saying No To Properties
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to a topic in the
>> > Google Groups "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this topic, visit
>> > https://groups.google.com/a/isocpp.org/d/topic/std-
>> proposals/n0QcD_K5dBY/unsubscribe.
>> > To unsubscribe from this group and all its topics, send an email to
>> > std-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>>
>>
>> --
>> Olaf
>>
>  --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd9037ed3047f0504e32ef3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Actually I personally am quite curious as to this cla=
im &quot;don&#39;t use public data members&quot; - I&#39;ve heard it time a=
nd time again from many different sources but have often wondered where it =
originates from or what exactly is it&#39;s intention.=C2=A0 While I can re=
late to the versatility of separating user data from functional code (say X=
ML file as input) - if everything is XML then what exactly was the point of=
 the OOP paradigm (Allowing data and function to be encapsulated together) =
to begin with?=C2=A0 Just stuff all the XML attributes into a function and =
stick with functional programming with namespaces.<br><br></div>I&#39;m sur=
e I&#39;m missing something here - but I have yet to have someone offer up =
a good explanation.<br></div><div class=3D"gmail_extra"><br><div class=3D"g=
mail_quote">On Wed, Oct 1, 2014 at 2:49 AM, Boris Rasin <span dir=3D"ltr">&=
lt;<a href=3D"mailto:rasin.boris@gmail.com" target=3D"_blank">rasin.boris@g=
mail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=
=3D"ltr">It says don&#39;t use public data members, properties or not. And =
that, I think, is a pretty good practice.<span class=3D""><br><br>On Tuesda=
y, September 30, 2014 7:16:11 PM UTC+3, Olaf van der Spek wrote:</span><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><span class=3D"">How&#39;s that a good =
article?
<br>I don&#39;t think it&#39;s good at all. It&#39;s basically saying: don&=
#39;t use
<br>properties as public data members.
<br>
<br></span><span class=3D"">On Tue, Sep 30, 2014 at 2:29 PM, Boris Rasin &l=
t;<a>rasin...@gmail.com</a>&gt; wrote:
<br>&gt; Here is a good article on the subject of properties in C++:
<br>&gt;
<br>&gt; Saying No To Properties
<br>&gt;
<br>&gt; --
<br>&gt;
<br>&gt; ---
<br>&gt; You received this message because you are subscribed to a topic in=
 the
<br>&gt; Google Groups &quot;ISO C++ Standard - Future Proposals&quot; grou=
p.
<br>&gt; To unsubscribe from this topic, visit
<br>&gt; <a href=3D"https://groups.google.com/a/isocpp.org/d/topic/std-prop=
osals/n0QcD_K5dBY/unsubscribe" target=3D"_blank">https://groups.google.com/=
a/<u></u>isocpp.org/d/topic/std-<u></u>proposals/n0QcD_K5dBY/<u></u>unsubsc=
ribe</a>.
<br>&gt; To unsubscribe from this group and all its topics, send an email t=
o
<br></span>&gt; <a>std-proposal...@<u></u>isocpp.org</a>.
<br>&gt; To post to this group, send email to <a>std-pr...@isocpp.org</a>.
<br><span class=3D"">&gt; Visit this group at
<br>&gt; <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank">http://groups.google.com/a/<u></u>isocpp.org/group/s=
td-<u></u>proposals/</a>.
<br>
<br>
<br>
<br>--=20
<br>Olaf
<br></span></blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd9037ed3047f0504e32ef3--

.

------=_Part_785_540105009.1412763802200
Content-Type: text/plain; charset=UTF-8



On Wednesday, October 8, 2014 7:11:14 PM UTC+13, Tom Joe wrote:
>
> Actually I personally am quite curious as to this claim "don't use public
> data members" - I've heard it time and time again from many different
> sources but have often wondered where it originates from or what exactly is
> it's intention.  While I can relate to the versatility of separating user
> data from functional code (say XML file as input) - if everything is XML
> then what exactly was the point of the OOP paradigm (Allowing data and
> function to be encapsulated together) to begin with?  Just stuff all the
> XML attributes into a function and stick with functional programming with
> namespaces.
>
> I'm sure I'm missing something here - but I have yet to have someone offer
> up a good explanation.
>
>
>
Isn't there a few reasons why you don't want to use public data members,
one being that you might later want to encapsulate the data for some
reason, perhaps you might later decide to calculate the result or change
it's internal representation or something for example.

I personally think the "rule" is over stated though. I've used public data
members reasonably often and rarely regretted that and wanted to refactor
it to functions. But it does happen.

I am more often bitten by fad use (initially my own) of lots of getter and
setter functions that never evolved to do anything more than get or set an
internal variable and I found I've more often wanted to just get delete
those to avoid clutter and the regret was mostly over the waste of time
typing them. Maybe other people have had different experiences.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, October 8, 2014 7:11:14 PM UTC+13, T=
om Joe wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><div>Actually I =
personally am quite curious as to this claim "don't use public data members=
" - I've heard it time and time again from many different sources but have =
often wondered where it originates from or what exactly is it's intention.&=
nbsp; While I can relate to the versatility of separating user data from fu=
nctional code (say XML file as input) - if everything is XML then what exac=
tly was the point of the OOP paradigm (Allowing data and function to be enc=
apsulated together) to begin with?&nbsp; Just stuff all the XML attributes =
into a function and stick with functional programming with namespaces.<br><=
br></div>I'm sure I'm missing something here - but I have yet to have someo=
ne offer up a good explanation.<br></div><div><br><br></div></blockquote><d=
iv><br></div><div>Isn't there a few reasons&nbsp;why you don't want to use =
public data members, one being&nbsp;that you might&nbsp;later want to encap=
sulate the data for some reason, perhaps&nbsp;you might later&nbsp;decide t=
o&nbsp;calculate the result or change it's internal representation or somet=
hing for example.</div><div>&nbsp;</div><div>I personally think the "rule" =
is over stated though. I've&nbsp;used public data members reasonably often =
and rarely regretted that and wanted to refactor it to functions. But it do=
es happen.</div><div><br></div><div>I am more often&nbsp;bitten by&nbsp;fad=
&nbsp;use (initially my own) of&nbsp;lots of getter and setter functions th=
at never evolved to do anything more than get or set&nbsp;an internal varia=
ble and I found I've more often&nbsp;wanted to just get&nbsp;delete those t=
o avoid clutter and the regret was mostly over the waste of time typing the=
m. Maybe other people have had different experiences.</div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_785_540105009.1412763802200--

.

--001a11349bb2a9040c0504e7200b
Content-Type: text/plain; charset=UTF-8

This is why built-in properties would help. They'd prevent all this
get,set,get,set,get,set,get,set mess cluttering up interfaces.
At the same time they provide encapsulation of any implementation you might
have or want to add later.

In C#, the convention is to capitalise the initial letter of properties
which visibly differentiates properties from member variables.

On 8 October 2014 11:23, <gmisocpp@gmail.com> wrote:

>
>
> On Wednesday, October 8, 2014 7:11:14 PM UTC+13, Tom Joe wrote:
>>
>> Actually I personally am quite curious as to this claim "don't use public
>> data members" - I've heard it time and time again from many different
>> sources but have often wondered where it originates from or what exactly is
>> it's intention.  While I can relate to the versatility of separating user
>> data from functional code (say XML file as input) - if everything is XML
>> then what exactly was the point of the OOP paradigm (Allowing data and
>> function to be encapsulated together) to begin with?  Just stuff all the
>> XML attributes into a function and stick with functional programming with
>> namespaces.
>>
>> I'm sure I'm missing something here - but I have yet to have someone
>> offer up a good explanation.
>>
>>
>>
> Isn't there a few reasons why you don't want to use public data members,
> one being that you might later want to encapsulate the data for some
> reason, perhaps you might later decide to calculate the result or change
> it's internal representation or something for example.
>
> I personally think the "rule" is over stated though. I've used public data
> members reasonably often and rarely regretted that and wanted to refactor
> it to functions. But it does happen.
>
> I am more often bitten by fad use (initially my own) of lots of getter and
> setter functions that never evolved to do anything more than get or set an
> internal variable and I found I've more often wanted to just get delete
> those to avoid clutter and the regret was mostly over the waste of time
> typing them. Maybe other people have had different experiences.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11349bb2a9040c0504e7200b
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">This is why built-in properties would help. They&#39;d pre=
vent all this get,set,get,set,get,set,get,set mess cluttering up interfaces=
..=C2=A0<div><div>At the same time they provide encapsulation of any impleme=
ntation you might have or want to add later.=C2=A0</div></div><div><br></di=
v><div>In C#, the convention is to capitalise the initial letter of propert=
ies which visibly differentiates properties from member variables.=C2=A0</d=
iv></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 8 Oct=
ober 2014 11:23,  <span dir=3D"ltr">&lt;<a href=3D"mailto:gmisocpp@gmail.co=
m" target=3D"_blank">gmisocpp@gmail.com</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex"><div dir=3D"ltr"><span class=3D""><br><br>On Wednesday=
, October 8, 2014 7:11:14 PM UTC+13, Tom Joe wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-co=
lor:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div di=
r=3D"ltr"><div>Actually I personally am quite curious as to this claim &quo=
t;don&#39;t use public data members&quot; - I&#39;ve heard it time and time=
 again from many different sources but have often wondered where it origina=
tes from or what exactly is it&#39;s intention.=C2=A0 While I can relate to=
 the versatility of separating user data from functional code (say XML file=
 as input) - if everything is XML then what exactly was the point of the OO=
P paradigm (Allowing data and function to be encapsulated together) to begi=
n with?=C2=A0 Just stuff all the XML attributes into a function and stick w=
ith functional programming with namespaces.<br><br></div>I&#39;m sure I&#39=
;m missing something here - but I have yet to have someone offer up a good =
explanation.<br></div><div><br><br></div></blockquote><div><br></div></span=
><div>Isn&#39;t there a few reasons=C2=A0why you don&#39;t want to use publ=
ic data members, one being=C2=A0that you might=C2=A0later want to encapsula=
te the data for some reason, perhaps=C2=A0you might later=C2=A0decide to=C2=
=A0calculate the result or change it&#39;s internal representation or somet=
hing for example.</div><div>=C2=A0</div><div>I personally think the &quot;r=
ule&quot; is over stated though. I&#39;ve=C2=A0used public data members rea=
sonably often and rarely regretted that and wanted to refactor it to functi=
ons. But it does happen.</div><div><br></div><div>I am more often=C2=A0bitt=
en by=C2=A0fad=C2=A0use (initially my own) of=C2=A0lots of getter and sette=
r functions that never evolved to do anything more than get or set=C2=A0an =
internal variable and I found I&#39;ve more often=C2=A0wanted to just get=
=C2=A0delete those to avoid clutter and the regret was mostly over the wast=
e of time typing them. Maybe other people have had different experiences.</=
div></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11349bb2a9040c0504e7200b--

.

> In C#, the convention is to capitalise the initial letter of properties
> which visibly differentiates properties from member variables.

This convention works fine with C#, aber it works IMO badly with the
style of the Standard Library. If you argue based on such conventions,
such aspects need to be considered too, because new language features
are typically used by the library as well.

- Daniel

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11349bb244c8d30504ed54ed
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

You're right, perhaps a more "stylistically appropriate" convention for the
standard library could be a prefix "prop_", or a symbol of some sort.
Unfortunately this board won't allow me to edit my previous post.

However...whatever is decided in the end would be voluntary and just a
detail at this stage so I don't want it to sidetrack discussion. People
would be free to use whatever conventions they like, and the same goes for
the standard library.

Perhaps its time for me to create a proxy "property" class to demonstrate
the limitations of no built-in support.

On 8 October 2014 12:08, Daniel Kr=C3=BCgler <daniel.kruegler@gmail.com> wr=
ote:

> > In C#, the convention is to capitalise the initial letter of properties
> > which visibly differentiates properties from member variables.
>
> This convention works fine with C#, aber it works IMO badly with the
> style of the Standard Library. If you argue based on such conventions,
> such aspects need to be considered too, because new language features
> are typically used by the library as well.
>
> - Daniel
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11349bb244c8d30504ed54ed
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">You&#39;re right, perhaps a more &quot;stylistically appro=
priate&quot; convention for the standard library could be a prefix &quot;pr=
op_&quot;, or a symbol of some sort. Unfortunately this board won&#39;t all=
ow me to edit my previous post.=C2=A0<div><br><div>However...whatever is de=
cided in the end would be voluntary and just a detail at this stage so I do=
n&#39;t want it to sidetrack discussion. People would be free to use whatev=
er conventions they like, and the same goes for the standard library.</div>=
</div><div><br></div><div>Perhaps its time for me to create a proxy &quot;p=
roperty&quot; class to demonstrate the limitations of no built-in support.<=
/div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 8 O=
ctober 2014 12:08, Daniel Kr=C3=BCgler <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:daniel.kruegler@gmail.com" target=3D"_blank">daniel.kruegler@gmail.com<=
/a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&g=
t; In C#, the convention is to capitalise the initial letter of properties<=
br>
&gt; which visibly differentiates properties from member variables.<br>
<br>
</span>This convention works fine with C#, aber it works IMO badly with the=
<br>
style of the Standard Library. If you argue based on such conventions,<br>
such aspects need to be considered too, because new language features<br>
are typically used by the library as well.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
- Daniel<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11349bb244c8d30504ed54ed--

.

------=_Part_3737_1305790408.1440523983421
Content-Type: multipart/alternative;
 boundary="----=_Part_3738_148805840.1440523983422"

------=_Part_3738_148805840.1440523983422
Content-Type: text/plain; charset=UTF-8

I would like to raise this topic again. Some while ago I made some working
but dirty solution for properties using preprocessor and some pointer
arithmetics here:
http://www.nanoant.com/c++/cpp-field-accessors-cure-for-public-field-fobia

My blog entry above explains why current C++11/14 standards do not allow
easy implementation of properties without some magic tricks that are not
portable, eg. not requiring extra storage space for each property just
because C++ standard prohibits zero size structs, even they have no member
fields.

The reason I bump this topic is that I am vitally interested in having
properties in C++ standard. I work everyday with various C++ APIs and
everyday I feel that all these set, get are just obscuring the code.

I have read this whole thread, and here is my feedback to some voices
against properties in C++.

*1. Currect C++ standard allows implementing properties via cast and `()`
operators and some `property` struct/class.*

   This is not entirely true. You cannot just easily access embedding class
members from embedding property struct/class. Also using lambdas require
storing pointer which effectively make your embedding class grow. (see my
blog entry)

*2. Looking at the code we will no longer know if `foo.boo` actually just
accesses member field or calls a method which may be less effective.*

   This is false for many APIs using simple inline accessors setting some
private member variables, while on other hand `foo.boo = x` may trigger
some constructors or assign operators.

   Moreover it is pretty easy for modern IDEs to highlight regular member
field vs property access differently. This is also argument to these who
want some extra suffix such as `#` to see if we are accessing property or
something else.

*3. We prefer using `set`/`get`.*

   Even if there will be properties in the standard nobody forces you to
use them, similarly some ppl use STL others not, so it is up to you.

I opt for either simplest possible extension using new C++11 [[attribute]]
syntax, eg.:

struct vec2 {
  float x, y;
  [[property(length)]]
  float getLength() { return x*x + y*y; }
  [[property(length)]]
  void setLength(float l) { float ratio = l / getLength(); x *= ratio; y *=
ratio; }
};

Or when property has the same name as the method:

struct vec2 {
  float x, y;
  [[property]] float length() { return x*x + y*y; }
  [[property]] void length(float l) { float ratio = l / length(); x *= ratio
; y *= ratio; }
};

That will make it somehow backwards compatible, since compilers will just
generated warnings about non existing property attribute and let ppl that
prefer using accessors (setters/getters) use them. But this really light
implementation does not allow for example specifying how you perform for
example `foo.boo += 2`.

Alternative (heavier) solution (that would not be backwards compatible) is
introducing "property operators" eg:

struct vec2 {
  float x, y;
  float operator.length() { return x*x + y*y; }
  void operator.length=(float l) { float ratio = l / this->length; x *=
ratio; y *= ratio; }
  void operator.length+=(float l) { this->length = this->length + l; }
};

Effectively this would let you use `operator.<name><op>` for all existing
`<op>` operators, giving you fine grained control what you can do with the
property. This again does not introduce any new keywords to the language.

Also solution above addresses problems stated in Saying No To Properties,
eg. you may have several `operator.property=` methods accepting different
types.

Whatever solution is accepted will make writing in C++ easier and clean,
therefore I humbly ask to review propositions above.

Regards,
--
Adam Strzelecki

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div>I would like to raise this topic again. Some while ag=
o I made some working but dirty solution for properties using preprocessor =
and some pointer arithmetics here:</div><div><a href=3D"http://www.nanoant.=
com/c++/cpp-field-accessors-cure-for-public-field-fobia">http://www.nanoant=
..com/c++/cpp-field-accessors-cure-for-public-field-fobia</a></div><div><br>=
</div><div>My blog entry above explains why current C++11/14 standards do n=
ot allow easy implementation of properties without some magic tricks that a=
re not portable, eg. not requiring extra storage space for each property ju=
st because C++ standard prohibits zero size structs, even they have no memb=
er fields.</div><div><br></div><div>The reason I bump this topic is that I =
am vitally interested in having properties in C++ standard. I work everyday=
 with various C++ APIs and everyday I feel that all these set, get are just=
 obscuring the code.</div><div><br></div><div>I have read this whole thread=
, and here is my feedback to some voices against properties in C++.</div><d=
iv><br></div><div><i>1. Currect C++ standard allows implementing properties=
 via cast and `()` operators and some `property` struct/class.</i></div><di=
v><br></div><div>=C2=A0 =C2=A0This is not entirely true. You cannot just ea=
sily access embedding class members from embedding property struct/class. A=
lso using lambdas require storing pointer which effectively make your embed=
ding class grow. (see my blog entry)</div><div><br></div><div><i>2. Looking=
 at the code we will no longer know if `foo.boo` actually just accesses mem=
ber field or calls a method which may be less effective.</i></div><div><br>=
</div><div>=C2=A0 =C2=A0This is false for many APIs using simple inline acc=
essors setting some private member variables, while on other hand `foo.boo =
=3D x` may trigger some constructors or assign operators.</div><div><br></d=
iv><div>=C2=A0 =C2=A0Moreover it is pretty easy for modern IDEs to highligh=
t regular member field vs property access differently. This is also argumen=
t to these who want some extra suffix such as `#` to see if we are accessin=
g property or something else.</div><div><br></div><div><i>3. We prefer usin=
g `set`/`get`.</i></div><div><br></div><div>=C2=A0 =C2=A0Even if there will=
 be properties in the standard nobody forces you to use them, similarly som=
e ppl use STL others not, so it is up to you.</div><div><br></div><div>I op=
t for either simplest possible extension using new C++11 [[attribute]] synt=
ax, eg.:</div><div><br></div><div class=3D"prettyprint" style=3D"background=
-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap=
: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> vec2 </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> y</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">[[</span><span style=3D"color: #000;" class=3D"styled-by-prettify">proper=
ty</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">length</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)]]</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> getLength</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">()</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> x</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">x </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">*</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">y</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[[<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">property</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">length</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">)]]</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">void</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> setLength</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> l</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> ratio </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> l </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">/</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> getLength</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">*=3D</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> ratio</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> y </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">*=3D</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> ratio</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span></div></code></div><div><br></div><div>Or when p=
roperty has the same name as the method:</div><div><br></div><div class=3D"=
prettyprint" style=3D"background-color: rgb(250, 250, 250); border: 1px sol=
id rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint">=
<div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-=
by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> vec2 </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">flo=
at</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">property</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> length</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">x </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">y</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">[[</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify">property</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">]]</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">vo=
id</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> length<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> l</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">float</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> ratio </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l </sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">/</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> length</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">*=3D</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> ratio</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> y </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">*=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> ratio</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span></div></code></div><div><=
br></div><div>That will make it somehow backwards compatible, since compile=
rs will just generated warnings about non existing property attribute and l=
et ppl that prefer using accessors (setters/getters) use them. But this rea=
lly light implementation does not allow for example specifying how you perf=
orm for example `foo.boo +=3D 2`.<br></div><div><br></div><div>Alternative =
(heavier) solution (that would not be backwards compatible) is introducing =
&quot;property operators&quot; eg:</div><div><br></div><div class=3D"pretty=
print" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div c=
lass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> vec2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0=
 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> y</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">operator</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">length</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">*</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">x </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">y</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">operator</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">l=
ength</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D(<=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> l</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">float</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> ratio </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 l </span><span style=3D"color: #660;" class=3D"styled-by-prettify">/</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">this</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">-&gt;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">length</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">*=3D</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> ratio</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 y </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*=3D</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> ratio</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">operator</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify">length</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">+=3D(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">flo=
at</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> l</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">this</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">-&gt;</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify">length </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify">length </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> l</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">};</span></div></code></div><div><br></div><div>Effectively this woul=
d let you use `operator.&lt;name&gt;&lt;op&gt;` for all existing `&lt;op&gt=
;` operators, giving you fine grained control what you can do with the prop=
erty. This again does not introduce any new keywords to the language.<br></=
div><div><br></div><div>Also solution above addresses problems stated in=C2=
=A0Saying No To Properties, eg. you may have several `operator.property=3D`=
 methods accepting different types.</div><div><br></div><div>Whatever solut=
ion is accepted will make writing in C++ easier and clean, therefore I humb=
ly ask to review propositions above.</div><div><br></div><div>Regards,</div=
><div>--=C2=A0</div><div>Adam Strzelecki</div><div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3738_148805840.1440523983422--
------=_Part_3737_1305790408.1440523983421--

.

------=_Part_773_539209416.1440526089892
Content-Type: multipart/alternative;
 boundary="----=_Part_774_301662315.1440526089892"

------=_Part_774_301662315.1440526089892
Content-Type: text/plain; charset=UTF-8



On Tuesday, August 25, 2015 at 1:33:03 PM UTC-4, adam.st...@java.pl wrote:
>
> I would like to raise this topic again. Some while ago I made some working
> but dirty solution for properties using preprocessor and some pointer
> arithmetics here:
> http://www.nanoant.com/c++/cpp-field-accessors-cure-for-public-field-fobia
> <http://www.google.com/url?q=http%3A%2F%2Fwww.nanoant.com%2Fc%2B%2B%2Fcpp-field-accessors-cure-for-public-field-fobia&sa=D&sntz=1&usg=AFQjCNEY9bUeVz8RH5mAwOpqtcPo82ylrQ>
>
> My blog entry above explains why current C++11/14 standards do not allow
> easy implementation of properties without some magic tricks that are not
> portable, eg. not requiring extra storage space for each property just
> because C++ standard prohibits zero size structs, even they have no member
> fields.
>
> The reason I bump this topic is that I am vitally interested in having
> properties in C++ standard. I work everyday with various C++ APIs and
> everyday I feel that all these set, get are just obscuring the code.
>
> I have read this whole thread, and here is my feedback to some voices
> against properties in C++.
>
> *1. Currect C++ standard allows implementing properties via cast and `()`
> operators and some `property` struct/class.*
>
>    This is not entirely true. You cannot just easily access embedding
> class members from embedding property struct/class. Also using lambdas
> require storing pointer which effectively make your embedding class grow.
> (see my blog entry)
>
> *2. Looking at the code we will no longer know if `foo.boo` actually just
> accesses member field or calls a method which may be less effective.*
>
>    This is false for many APIs using simple inline accessors setting some
> private member variables, while on other hand `foo.boo = x` may trigger
> some constructors or assign operators.
>

That is very true.

But `foo.boo` will always be accessing a member of `foo`. What you do with
such access may be more complex, but `foo.boo` itself will not provoke a
function call.


>
>    Moreover it is pretty easy for modern IDEs to highlight regular member
> field vs property access differently. This is also argument to these who
> want some extra suffix such as `#` to see if we are accessing property or
> something else.
>

.... so what? Not everyone uses "modern IDEs". If someone wants to use
Notepad to code in C++, I see no reason why we should make their lives more
difficult.


>
> *3. We prefer using `set`/`get`.*
>
>    Even if there will be properties in the standard nobody forces you to
> use them, similarly some ppl use STL others not, so it is up to you.
>

Except that this is not true. If someone defines properties in their types,
then you *have* to use them to use those types. Just as when someone
defines a function to take a `const std::string &`, you have to use
std::string to call that function.

So no, it's not up to you. It's up to you and the code you use.


> I opt for either simplest possible extension using new C++11 [[attribute]]
> syntax, eg.:
>

False start!

Attributes are *never* to be used for actual syntax. They should *never* be
allowed to change the actual meaning of code. They should *never* be used
in lieu of an actual keyword, for the sole purpose of making the "simplest
possible extension."

If your feature needs a keyword, and there aren't enough people who believe
that the feature merits the pain of adding a new keyword, *tough luck*. You
don't get to pervert an attribute into a keyword for your personal pet
features.


> Alternative (heavier) solution (that would not be backwards compatible) is
> introducing "property operators" eg:
>
> struct vec2 {
>   float x, y;
>   float operator.length() { return x*x + y*y; }
>   void operator.length=(float l) { float ratio = l / this->length; x *=
> ratio; y *= ratio; }
>   void operator.length+=(float l) { this->length = this->length + l; }
> };
>
> Effectively this would let you use `operator.<name><op>` for all existing
> `<op>` operators, giving you fine grained control what you can do with the
> property. This again does not introduce any new keywords to the language.
>

But it does co-opt the possibility of allowing an overload for operator.
And while I despise the idea of `operator.` overloading, I'd rather that
debate be unencumbered by questions of whether the syntax could be reserved
for properties.

Syntax is a rare and precious thing.


> Also solution above addresses problems stated in Saying No To Properties,
> eg. you may have several `operator.property=` methods accepting different
> types.
>
> Whatever solution is accepted will make writing in C++ easier and clean,
> therefore I humbly ask to review propositions above.
>

Well, here's the big problem that I personally have with properties:

I do not believe that they are that important.

If C++98 had properties from day 1, I'd be fine with them. But it doesn't.
And adding a non-trivial language feature like this takes time and effort.
Time and effort that would not be spent other features of far more pressing
importance like concepts, modules, ranges, coroutines, etc.

At the end of the day, C++ has a lot more important deficiencies that need
to be addressed than properties.

If C++ never gets properties, I won't feel like I'm missing something
critical. If C++ never gets *modules*, then we will definitely be missing
something critical (ie: compile-time performance, solving the static
initialization ordering problem, etc). Having concepts dramatically lowers
the bar in template metaprogramming, opening some of that up to the average
programmer (as well as improving error messages for everyone involved).
Ranges and lazy evaluation changes the way you code. Coroutines
fundamentally change the way you deal with threading (and even
not-so-threaded code). And so forth.

Properties just isn't in the same league as far as its importance is
concerned. Properties are very nice bits of syntactic sugar. But at the end
of the day, it's just sugar. And it's not even that particularly sweet
sugar like lambdas. They won't make your code that much more readable. They
won't make your code that much more maintainable.

They're useful. But not critical. And certainly not critical enough to take
up the committee's time when they're dealing with so many real issues.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Tuesday, August 25, 2015 at 1:33:03 PM UTC-4, adam.st...@java.pl=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>I=
 would like to raise this topic again. Some while ago I made some working b=
ut dirty solution for properties using preprocessor and some pointer arithm=
etics here:</div><div><a href=3D"http://www.google.com/url?q=3Dhttp%3A%2F%2=
Fwww.nanoant.com%2Fc%2B%2B%2Fcpp-field-accessors-cure-for-public-field-fobi=
a&amp;sa=3DD&amp;sntz=3D1&amp;usg=3DAFQjCNEY9bUeVz8RH5mAwOpqtcPo82ylrQ" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;http://www.=
google.com/url?q\75http%3A%2F%2Fwww.nanoant.com%2Fc%2B%2B%2Fcpp-field-acces=
sors-cure-for-public-field-fobia\46sa\75D\46sntz\0751\46usg\75AFQjCNEY9bUeV=
z8RH5mAwOpqtcPo82ylrQ&#39;;return true;" onclick=3D"this.href=3D&#39;http:/=
/www.google.com/url?q\75http%3A%2F%2Fwww.nanoant.com%2Fc%2B%2B%2Fcpp-field-=
accessors-cure-for-public-field-fobia\46sa\75D\46sntz\0751\46usg\75AFQjCNEY=
9bUeVz8RH5mAwOpqtcPo82ylrQ&#39;;return true;">http://www.nanoant.com/c++/<w=
br>cpp-field-accessors-cure-for-<wbr>public-field-fobia</a></div><div><br><=
/div><div>My blog entry above explains why current C++11/14 standards do no=
t allow easy implementation of properties without some magic tricks that ar=
e not portable, eg. not requiring extra storage space for each property jus=
t because C++ standard prohibits zero size structs, even they have no membe=
r fields.</div><div><br></div><div>The reason I bump this topic is that I a=
m vitally interested in having properties in C++ standard. I work everyday =
with various C++ APIs and everyday I feel that all these set, get are just =
obscuring the code.</div><div><br></div><div>I have read this whole thread,=
 and here is my feedback to some voices against properties in C++.</div><di=
v><br></div><div><i>1. Currect C++ standard allows implementing properties =
via cast and `()` operators and some `property` struct/class.</i></div><div=
><br></div><div>=C2=A0 =C2=A0This is not entirely true. You cannot just eas=
ily access embedding class members from embedding property struct/class. Al=
so using lambdas require storing pointer which effectively make your embedd=
ing class grow. (see my blog entry)</div><div><br></div><div><i>2. Looking =
at the code we will no longer know if `foo.boo` actually just accesses memb=
er field or calls a method which may be less effective.</i></div><div><br><=
/div><div>=C2=A0 =C2=A0This is false for many APIs using simple inline acce=
ssors setting some private member variables, while on other hand `foo.boo =
=3D x` may trigger some constructors or assign operators.</div></div></bloc=
kquote><div><br>That is very true.<br><br>But `foo.boo` will always be acce=
ssing a member of `foo`. What you do with such access may be more complex, =
but `foo.boo` itself will not provoke a function call.<br>=C2=A0<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><br></div=
><div>=C2=A0 =C2=A0Moreover it is pretty easy for modern IDEs to highlight =
regular member field vs property access differently. This is also argument =
to these who want some extra suffix such as `#` to see if we are accessing =
property or something else.</div></div></blockquote><div><br>... so what? N=
ot everyone uses &quot;modern IDEs&quot;. If someone wants to use Notepad t=
o code in C++, I see no reason why we should make their lives more difficul=
t.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br></div><div><i>3. We prefer using `set`/`get`.</i></div><div><=
br></div><div>=C2=A0 =C2=A0Even if there will be properties in the standard=
 nobody forces you to use them, similarly some ppl use STL others not, so i=
t is up to you.</div></div></blockquote><div><br>Except that this is not tr=
ue. If someone defines properties in their types, then you <i>have</i> to u=
se them to use those types. Just as when someone defines a function to take=
 a `const std::string &amp;`, you have to use std::string to call that func=
tion.<br><br>So no, it&#39;s not up to you. It&#39;s up to you and the code=
 you use.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div =
dir=3D"ltr"><div></div><div>I opt for either simplest possible extension us=
ing new C++11 [[attribute]] syntax, eg.:</div></div></blockquote><div><br>F=
alse start!<br><br>Attributes are <i>never</i> to be used for actual syntax=
.. They should <i>never</i> be allowed to change the actual meaning of code.=
 They should <i>never</i> be used in lieu of an actual keyword, for the sol=
e purpose of making the &quot;simplest possible extension.&quot;<br><br>If =
your feature needs a keyword, and there aren&#39;t enough people who believ=
e that the feature merits the pain of adding a new keyword, <i>tough luck</=
i>. You don&#39;t get to pervert an attribute into a keyword for your perso=
nal pet features.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div></div><div>Alternative (heavier) solution (that wo=
uld not be backwards compatible) is introducing &quot;property operators&qu=
ot; eg:</div><div><br></div><div style=3D"background-color:rgb(250,250,250)=
;border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span s=
tyle=3D"color:#008">struct</span><span style=3D"color:#000"> vec2 </span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </sp=
an><span style=3D"color:#008">float</span><span style=3D"color:#000"> x</sp=
an><span style=3D"color:#660">,</span><span style=3D"color:#000"> y</span><=
span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </s=
pan><span style=3D"color:#008">float</span><span style=3D"color:#000"> </sp=
an><span style=3D"color:#008">operator</span><span style=3D"color:#660">.</=
span><span style=3D"color:#000">length</span><span style=3D"color:#660">()<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">return</span=
><span style=3D"color:#000"> x</span><span style=3D"color:#660">*</span><sp=
an style=3D"color:#000">x </span><span style=3D"color:#660">+</span><span s=
tyle=3D"color:#000"> y</span><span style=3D"color:#660">*</span><span style=
=3D"color:#000">y</span><span style=3D"color:#660">;</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#660">}</span><span style=3D"color:=
#000"><br>=C2=A0 </span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span sty=
le=3D"color:#660">.</span><span style=3D"color:#000">length</span><span sty=
le=3D"color:#660">=3D(</span><span style=3D"color:#008">float</span><span s=
tyle=3D"color:#000"> l</span><span style=3D"color:#660">)</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">float</span><span style=3D"co=
lor:#000"> ratio </span><span style=3D"color:#660">=3D</span><span style=3D=
"color:#000"> l </span><span style=3D"color:#660">/</span><span style=3D"co=
lor:#000"> </span><span style=3D"color:#008">this</span><span style=3D"colo=
r:#660">-&gt;</span><span style=3D"color:#000">length</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> x </span><span style=3D"col=
or:#660">*=3D</span><span style=3D"color:#000"> ratio</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> y </span><span style=3D"col=
or:#660">*=3D</span><span style=3D"color:#000"> ratio</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"=
color:#008">void</span><span style=3D"color:#000"> </span><span style=3D"co=
lor:#008">operator</span><span style=3D"color:#660">.</span><span style=3D"=
color:#000">length</span><span style=3D"color:#660">+=3D(</span><span style=
=3D"color:#008">float</span><span style=3D"color:#000"> l</span><span style=
=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">{</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">this</span><span style=3D"color:#660">-&gt;</span><span style=3D"colo=
r:#000">length </span><span style=3D"color:#660">=3D</span><span style=3D"c=
olor:#000"> </span><span style=3D"color:#008">this</span><span style=3D"col=
or:#660">-&gt;</span><span style=3D"color:#000">length </span><span style=
=3D"color:#660">+</span><span style=3D"color:#000"> l</span><span style=3D"=
color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"color=
:#660">}</span><span style=3D"color:#000"><br></span><span style=3D"color:#=
660">};</span></div></code></div><div><br></div><div>Effectively this would=
 let you use `operator.&lt;name&gt;&lt;op&gt;` for all existing `&lt;op&gt;=
` operators, giving you fine grained control what you can do with the prope=
rty. This again does not introduce any new keywords to the language.<br></d=
iv></div></blockquote><div><br>But it does co-opt the possibility of allowi=
ng an overload for operator. And while I despise the idea of `operator.` ov=
erloading, I&#39;d rather that debate be unencumbered by questions of wheth=
er the syntax could be reserved for properties.<br><br>Syntax is a rare and=
 precious thing.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><div dir=3D"ltr"><div></div><div></div><div>Also solution above addresses=
 problems stated in=C2=A0Saying No To Properties, eg. you may have several =
`operator.property=3D` methods accepting different types.</div><div><br></d=
iv><div>Whatever solution is accepted will make writing in C++ easier and c=
lean, therefore I humbly ask to review propositions above.</div></div></blo=
ckquote><div><br>Well, here&#39;s the big problem that I personally have wi=
th properties:<br><br>I do not believe that they are that important.<br><br=
>If C++98 had properties from day 1, I&#39;d be fine with them. But it does=
n&#39;t. And adding a non-trivial language feature like this takes time and=
 effort. Time and effort that would not be spent other features of far more=
 pressing importance like concepts, modules, ranges, coroutines, etc.<br><b=
r>At the end of the day, C++ has a lot more important deficiencies that nee=
d to be addressed than properties.<br><br>If C++ never gets properties, I w=
on&#39;t feel like I&#39;m missing something critical. If C++ never gets <i=
>modules</i>, then we will definitely be missing something critical (ie: co=
mpile-time performance, solving the static initialization ordering problem,=
 etc). Having concepts dramatically lowers the bar in template metaprogramm=
ing, opening some of that up to the average programmer (as well as improvin=
g error messages for everyone involved). Ranges and lazy evaluation changes=
 the way you code. Coroutines fundamentally change the way you deal with th=
reading (and even not-so-threaded code). And so forth.<br><br>Properties ju=
st isn&#39;t in the same league as far as its importance is concerned. Prop=
erties are very nice bits of syntactic sugar. But at the end of the day, it=
&#39;s just sugar. And it&#39;s not even that particularly sweet sugar like=
 lambdas. They won&#39;t make your code that much more readable. They won&#=
39;t make your code that much more maintainable.<br><br>They&#39;re useful.=
 But not critical. And certainly not critical enough to take up the committ=
ee&#39;s time when they&#39;re dealing with so many real issues.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_774_301662315.1440526089892--
------=_Part_773_539209416.1440526089892--

.

------=_Part_3893_1683929243.1440526412900
Content-Type: multipart/alternative;
 boundary="----=_Part_3894_1973176383.1440526412900"

------=_Part_3894_1973176383.1440526412900
Content-Type: text/plain; charset=UTF-8


>
> *2. Looking at the code we will no longer know if `foo.boo` actually just
> accesses member field or calls a method which may be less effective.*
>
>    This is false for many APIs using simple inline accessors setting some
> private member variables, while on other hand `foo.boo = x` may trigger
> some constructors or assign operators.
>

I forgot to mention an issue with this. Namely, it's not clear what
`foo.boo` means if `boo` is a property. Or more to the point, if you see
`foo.boo = x`, you might naturally assume that `auto &y = foo.boo; y = x`
is a reasonable thing to do.

Under your property rules, that's no longer true.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"l=
tr"><div><i>2. Looking at the code we will no longer know if `foo.boo` actu=
ally just accesses member field or calls a method which may be less effecti=
ve.</i></div><div><br></div><div>=C2=A0 =C2=A0This is false for many APIs u=
sing simple inline accessors setting some private member variables, while o=
n other hand `foo.boo =3D x` may trigger some constructors or assign operat=
ors.</div></div></blockquote><div><br>I forgot to mention an issue with thi=
s. Namely, it&#39;s not clear what `foo.boo` means if `boo` is a property. =
Or more to the point, if you see `foo.boo =3D x`, you might naturally assum=
e that `auto &amp;y =3D foo.boo; y =3D x` is a reasonable thing to do.<br><=
br>Under your property rules, that&#39;s no longer true.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3894_1973176383.1440526412900--
------=_Part_3893_1683929243.1440526412900--

.

--047d7b3a91e69e6330051e27c783
Content-Type: text/plain; charset=UTF-8

See Krauss' N4147 "inline variables" which provides for a getter-only
(mostly) form of property. Doesn't solve all the use cases of C#-like
properties but it would be useful to keep the paper in mind for discussions
on the topic, I think.

(Anyone know the status of that proposal, btw? Completely rejected or still
being pursued?)
On Aug 25, 2015 10:33 AM, <adam.strzelecki@java.pl> wrote:

> I would like to raise this topic again. Some while ago I made some working
> but dirty solution for properties using preprocessor and some pointer
> arithmetics here:
> http://www.nanoant.com/c++/cpp-field-accessors-cure-for-public-field-fobia
>
> My blog entry above explains why current C++11/14 standards do not allow
> easy implementation of properties without some magic tricks that are not
> portable, eg. not requiring extra storage space for each property just
> because C++ standard prohibits zero size structs, even they have no member
> fields.
>
> The reason I bump this topic is that I am vitally interested in having
> properties in C++ standard. I work everyday with various C++ APIs and
> everyday I feel that all these set, get are just obscuring the code.
>
> I have read this whole thread, and here is my feedback to some voices
> against properties in C++.
>
> *1. Currect C++ standard allows implementing properties via cast and `()`
> operators and some `property` struct/class.*
>
>    This is not entirely true. You cannot just easily access embedding
> class members from embedding property struct/class. Also using lambdas
> require storing pointer which effectively make your embedding class grow.
> (see my blog entry)
>
> *2. Looking at the code we will no longer know if `foo.boo` actually just
> accesses member field or calls a method which may be less effective.*
>
>    This is false for many APIs using simple inline accessors setting some
> private member variables, while on other hand `foo.boo = x` may trigger
> some constructors or assign operators.
>
>    Moreover it is pretty easy for modern IDEs to highlight regular member
> field vs property access differently. This is also argument to these who
> want some extra suffix such as `#` to see if we are accessing property or
> something else.
>
> *3. We prefer using `set`/`get`.*
>
>    Even if there will be properties in the standard nobody forces you to
> use them, similarly some ppl use STL others not, so it is up to you.
>
> I opt for either simplest possible extension using new C++11 [[attribute]]
> syntax, eg.:
>
> struct vec2 {
>   float x, y;
>   [[property(length)]]
>   float getLength() { return x*x + y*y; }
>   [[property(length)]]
>   void setLength(float l) { float ratio = l / getLength(); x *= ratio; y
> *= ratio; }
> };
>
> Or when property has the same name as the method:
>
> struct vec2 {
>   float x, y;
>   [[property]] float length() { return x*x + y*y; }
>   [[property]] void length(float l) { float ratio = l / length(); x *=
> ratio; y *= ratio; }
> };
>
> That will make it somehow backwards compatible, since compilers will just
> generated warnings about non existing property attribute and let ppl that
> prefer using accessors (setters/getters) use them. But this really light
> implementation does not allow for example specifying how you perform for
> example `foo.boo += 2`.
>
> Alternative (heavier) solution (that would not be backwards compatible) is
> introducing "property operators" eg:
>
> struct vec2 {
>   float x, y;
>   float operator.length() { return x*x + y*y; }
>   void operator.length=(float l) { float ratio = l / this->length; x *=
> ratio; y *= ratio; }
>   void operator.length+=(float l) { this->length = this->length + l; }
> };
>
> Effectively this would let you use `operator.<name><op>` for all existing
> `<op>` operators, giving you fine grained control what you can do with the
> property. This again does not introduce any new keywords to the language.
>
> Also solution above addresses problems stated in Saying No To Properties,
> eg. you may have several `operator.property=` methods accepting different
> types.
>
> Whatever solution is accepted will make writing in C++ easier and clean,
> therefore I humbly ask to review propositions above.
>
> Regards,
> --
> Adam Strzelecki
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b3a91e69e6330051e27c783
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">See Krauss&#39; N4147 &quot;inline variables&quot; which pro=
vides for a getter-only (mostly) form of property. Doesn&#39;t solve all th=
e use cases of C#-like properties but it would be useful to keep the paper =
in mind for discussions on the topic, I think.</p>
<p dir=3D"ltr">(Anyone know the status of that proposal, btw? Completely re=
jected or still being pursued?)</p>
<div class=3D"gmail_quote">On Aug 25, 2015 10:33 AM,  &lt;<a href=3D"mailto=
:adam.strzelecki@java.pl">adam.strzelecki@java.pl</a>&gt; wrote:<br type=3D=
"attribution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I would =
like to raise this topic again. Some while ago I made some working but dirt=
y solution for properties using preprocessor and some pointer arithmetics h=
ere:</div><div><a href=3D"http://www.nanoant.com/c++/cpp-field-accessors-cu=
re-for-public-field-fobia" target=3D"_blank">http://www.nanoant.com/c++/cpp=
-field-accessors-cure-for-public-field-fobia</a></div><div><br></div><div>M=
y blog entry above explains why current C++11/14 standards do not allow eas=
y implementation of properties without some magic tricks that are not porta=
ble, eg. not requiring extra storage space for each property just because C=
++ standard prohibits zero size structs, even they have no member fields.</=
div><div><br></div><div>The reason I bump this topic is that I am vitally i=
nterested in having properties in C++ standard. I work everyday with variou=
s C++ APIs and everyday I feel that all these set, get are just obscuring t=
he code.</div><div><br></div><div>I have read this whole thread, and here i=
s my feedback to some voices against properties in C++.</div><div><br></div=
><div><i>1. Currect C++ standard allows implementing properties via cast an=
d `()` operators and some `property` struct/class.</i></div><div><br></div>=
<div>=C2=A0 =C2=A0This is not entirely true. You cannot just easily access =
embedding class members from embedding property struct/class. Also using la=
mbdas require storing pointer which effectively make your embedding class g=
row. (see my blog entry)</div><div><br></div><div><i>2. Looking at the code=
 we will no longer know if `foo.boo` actually just accesses member field or=
 calls a method which may be less effective.</i></div><div><br></div><div>=
=C2=A0 =C2=A0This is false for many APIs using simple inline accessors sett=
ing some private member variables, while on other hand `foo.boo =3D x` may =
trigger some constructors or assign operators.</div><div><br></div><div>=C2=
=A0 =C2=A0Moreover it is pretty easy for modern IDEs to highlight regular m=
ember field vs property access differently. This is also argument to these =
who want some extra suffix such as `#` to see if we are accessing property =
or something else.</div><div><br></div><div><i>3. We prefer using `set`/`ge=
t`.</i></div><div><br></div><div>=C2=A0 =C2=A0Even if there will be propert=
ies in the standard nobody forces you to use them, similarly some ppl use S=
TL others not, so it is up to you.</div><div><br></div><div>I opt for eithe=
r simplest possible extension using new C++11 [[attribute]] syntax, eg.:</d=
iv><div><br></div><div style=3D"background-color:rgb(250,250,250);border:1p=
x solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"co=
lor:#008">struct</span><span style=3D"color:#000"> vec2 </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=A0 </span><span =
style=3D"color:#008">float</span><span style=3D"color:#000"> x</span><span =
style=3D"color:#660">,</span><span style=3D"color:#000"> y</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br>=C2=A0 </span><span=
 style=3D"color:#660">[[</span><span style=3D"color:#000">property</span><s=
pan style=3D"color:#660">(</span><span style=3D"color:#000">length</span><s=
pan style=3D"color:#660">)]]</span><span style=3D"color:#000"><br>=C2=A0 </=
span><span style=3D"color:#008">float</span><span style=3D"color:#000"> get=
Length</span><span style=3D"color:#660">()</span><span style=3D"color:#000"=
> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </s=
pan><span style=3D"color:#008">return</span><span style=3D"color:#000"> x</=
span><span style=3D"color:#660">*</span><span style=3D"color:#000">x </span=
><span style=3D"color:#660">+</span><span style=3D"color:#000"> y</span><sp=
an style=3D"color:#660">*</span><span style=3D"color:#000">y</span><span st=
yle=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><span =
style=3D"color:#660">[[</span><span style=3D"color:#000">property</span><sp=
an style=3D"color:#660">(</span><span style=3D"color:#000">length</span><sp=
an style=3D"color:#660">)]]</span><span style=3D"color:#000"><br>=C2=A0 </s=
pan><span style=3D"color:#008">void</span><span style=3D"color:#000"> setLe=
ngth</span><span style=3D"color:#660">(</span><span style=3D"color:#008">fl=
oat</span><span style=3D"color:#000"> l</span><span style=3D"color:#660">)<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">{</span=
><span style=3D"color:#000"> </span><span style=3D"color:#008">float</span>=
<span style=3D"color:#000"> ratio </span><span style=3D"color:#660">=3D</sp=
an><span style=3D"color:#000"> l </span><span style=3D"color:#660">/</span>=
<span style=3D"color:#000"> getLength</span><span style=3D"color:#660">();<=
/span><span style=3D"color:#000"> x </span><span style=3D"color:#660">*=3D<=
/span><span style=3D"color:#000"> ratio</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> y </span><span style=3D"color:#660">*=3D<=
/span><span style=3D"color:#000"> ratio</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"> </span><span style=3D"color:#660">}</span=
><span style=3D"color:#000"><br></span><span style=3D"color:#660">};</span>=
</div></code></div><div><br></div><div>Or when property has the same name a=
s the method:</div><div><br></div><div style=3D"background-color:rgb(250,25=
0,250);border:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><=
span style=3D"color:#008">struct</span><span style=3D"color:#000"> vec2 </s=
pan><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>=C2=
=A0 </span><span style=3D"color:#008">float</span><span style=3D"color:#000=
"> x</span><span style=3D"color:#660">,</span><span style=3D"color:#000"> y=
</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>=
=C2=A0 </span><span style=3D"color:#660">[[</span><span style=3D"color:#000=
">property</span><span style=3D"color:#660">]]</span><span style=3D"color:#=
000"> </span><span style=3D"color:#008">float</span><span style=3D"color:#0=
00"> length</span><span style=3D"color:#660">()</span><span style=3D"color:=
#000"> </span><span style=3D"color:#660">{</span><span style=3D"color:#000"=
> </span><span style=3D"color:#008">return</span><span style=3D"color:#000"=
> x</span><span style=3D"color:#660">*</span><span style=3D"color:#000">x <=
/span><span style=3D"color:#660">+</span><span style=3D"color:#000"> y</spa=
n><span style=3D"color:#660">*</span><span style=3D"color:#000">y</span><sp=
an style=3D"color:#660">;</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><sp=
an style=3D"color:#660">[[</span><span style=3D"color:#000">property</span>=
<span style=3D"color:#660">]]</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">void</span><span style=3D"color:#000"> length</span>=
<span style=3D"color:#660">(</span><span style=3D"color:#008">float</span><=
span style=3D"color:#000"> l</span><span style=3D"color:#660">)</span><span=
 style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#008">float</span><span style=
=3D"color:#000"> ratio </span><span style=3D"color:#660">=3D</span><span st=
yle=3D"color:#000"> l </span><span style=3D"color:#660">/</span><span style=
=3D"color:#000"> length</span><span style=3D"color:#660">();</span><span st=
yle=3D"color:#000"> x </span><span style=3D"color:#660">*=3D</span><span st=
yle=3D"color:#000"> ratio</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> y </span><span style=3D"color:#660">*=3D</span><span st=
yle=3D"color:#000"> ratio</span><span style=3D"color:#660">;</span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">}</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#660">};</span></div></code=
></div><div><br></div><div>That will make it somehow backwards compatible, =
since compilers will just generated warnings about non existing property at=
tribute and let ppl that prefer using accessors (setters/getters) use them.=
 But this really light implementation does not allow for example specifying=
 how you perform for example `foo.boo +=3D 2`.<br></div><div><br></div><div=
>Alternative (heavier) solution (that would not be backwards compatible) is=
 introducing &quot;property operators&quot; eg:</div><div><br></div><div st=
yle=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);=
word-wrap:break-word"><code><div><span style=3D"color:#008">struct</span><s=
pan style=3D"color:#000"> vec2 </span><span style=3D"color:#660">{</span><s=
pan style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">float=
</span><span style=3D"color:#000"> x</span><span style=3D"color:#660">,</sp=
an><span style=3D"color:#000"> y</span><span style=3D"color:#660">;</span><=
span style=3D"color:#000"><br>=C2=A0 </span><span style=3D"color:#008">floa=
t</span><span style=3D"color:#000"> </span><span style=3D"color:#008">opera=
tor</span><span style=3D"color:#660">.</span><span style=3D"color:#000">len=
gth</span><span style=3D"color:#660">()</span><span style=3D"color:#000"> <=
/span><span style=3D"color:#660">{</span><span style=3D"color:#000"> </span=
><span style=3D"color:#008">return</span><span style=3D"color:#000"> x</spa=
n><span style=3D"color:#660">*</span><span style=3D"color:#000">x </span><s=
pan style=3D"color:#660">+</span><span style=3D"color:#000"> y</span><span =
style=3D"color:#660">*</span><span style=3D"color:#000">y</span><span style=
=3D"color:#660">;</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">}</span><span style=3D"color:#000"><br>=C2=A0 </span><span style=
=3D"color:#008">void</span><span style=3D"color:#000"> </span><span style=
=3D"color:#008">operator</span><span style=3D"color:#660">.</span><span sty=
le=3D"color:#000">length</span><span style=3D"color:#660">=3D(</span><span =
style=3D"color:#008">float</span><span style=3D"color:#000"> l</span><span =
style=3D"color:#660">)</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">float</span><span style=3D"color:#000"> ratio </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> l </span><span style=
=3D"color:#660">/</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#008">this</span><span style=3D"color:#660">-&gt;</span><span style=3D=
"color:#000">length</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> x </span><span style=3D"color:#660">*=3D</span><span style=3D=
"color:#000"> ratio</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> y </span><span style=3D"color:#660">*=3D</span><span style=3D=
"color:#000"> ratio</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br>=C2=A0 </span><span style=3D"color:#008">void</span><span style=
=3D"color:#000"> </span><span style=3D"color:#008">operator</span><span sty=
le=3D"color:#660">.</span><span style=3D"color:#000">length</span><span sty=
le=3D"color:#660">+=3D(</span><span style=3D"color:#008">float</span><span =
style=3D"color:#000"> l</span><span style=3D"color:#660">)</span><span styl=
e=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"=
color:#000"> </span><span style=3D"color:#008">this</span><span style=3D"co=
lor:#660">-&gt;</span><span style=3D"color:#000">length </span><span style=
=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=3D=
"color:#008">this</span><span style=3D"color:#660">-&gt;</span><span style=
=3D"color:#000">length </span><span style=3D"color:#660">+</span><span styl=
e=3D"color:#000"> l</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"> </span><span style=3D"color:#660">}</span><span style=3D"colo=
r:#000"><br></span><span style=3D"color:#660">};</span></div></code></div><=
div><br></div><div>Effectively this would let you use `operator.&lt;name&gt=
;&lt;op&gt;` for all existing `&lt;op&gt;` operators, giving you fine grain=
ed control what you can do with the property. This again does not introduce=
 any new keywords to the language.<br></div><div><br></div><div>Also soluti=
on above addresses problems stated in=C2=A0Saying No To Properties, eg. you=
 may have several `operator.property=3D` methods accepting different types.=
</div><div><br></div><div>Whatever solution is accepted will make writing i=
n C++ easier and clean, therefore I humbly ask to review propositions above=
..</div><div><br></div><div>Regards,</div><div>--=C2=A0</div><div>Adam Strze=
lecki</div><div><br></div></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b3a91e69e6330051e27c783--

.

On 25 August 2015 at 22:31, Sean Middleditch <sean@middleditch.us> wrote:
> See Krauss' N4147 "inline variables" which provides for a getter-only
> (mostly) form of property. Doesn't solve all the use cases of C#-like
> properties but it would be useful to keep the paper in mind for discussions
> on the topic, I think.
>
> (Anyone know the status of that proposal, btw? Completely rejected or still
> being pursued?)


There's a newer inline variable paper
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf
which EWG seemed to like, but that one will likely be discussed further.
I don't think this newer paper has much anything to do with properties, though.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1140f4e6435c7a051e28029e
Content-Type: text/plain; charset=UTF-8

On Aug 25, 2015 12:33 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:
>
> On 25 August 2015 at 22:31, Sean Middleditch <sean@middleditch.us> wrote:
> > See Krauss' N4147 "inline variables" which provides for a getter-only
> > (mostly) form of property. Doesn't solve all the use cases of C#-like
> > properties but it would be useful to keep the paper in mind for
discussions
> > on the topic, I think.
> >
> > (Anyone know the status of that proposal, btw? Completely rejected or
still
> > being pursued?)
>
>
> There's a newer inline variable paper
> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf
> which EWG seemed to like, but that one will likely be discussed further.
> I don't think this newer paper has much anything to do with properties,
though.

Huh, yeah, at a very cursory glance on my phone that basically seems like a
totally different feature. Was the "encapsulated expression" of N4147
rejected entirely then?

>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
..
> To unsubscribe from this group and all its topics, send an email to
std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
http://groups.google.com/a/isocpp.org/group/std-proposals/.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1140f4e6435c7a051e28029e
Content-Type: text/html; charset=UTF-8

<p dir="ltr">On Aug 25, 2015 12:33 PM, &quot;Ville Voutilainen&quot; &lt;<a href="mailto:ville.voutilainen@gmail.com">ville.voutilainen@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On 25 August 2015 at 22:31, Sean Middleditch &lt;<a href="mailto:sean@middleditch.us">sean@middleditch.us</a>&gt; wrote:<br>
&gt; &gt; See Krauss&#39; N4147 &quot;inline variables&quot; which provides for a getter-only<br>
&gt; &gt; (mostly) form of property. Doesn&#39;t solve all the use cases of C#-like<br>
&gt; &gt; properties but it would be useful to keep the paper in mind for discussions<br>
&gt; &gt; on the topic, I think.<br>
&gt; &gt;<br>
&gt; &gt; (Anyone know the status of that proposal, btw? Completely rejected or still<br>
&gt; &gt; being pursued?)<br>
&gt;<br>
&gt;<br>
&gt; There&#39;s a newer inline variable paper<br>
&gt; <a href="http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf">http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf</a><br>
&gt; which EWG seemed to like, but that one will likely be discussed further.<br>
&gt; I don&#39;t think this newer paper has much anything to do with properties, though.</p>
<p dir="ltr">Huh, yeah, at a very cursory glance on my phone that basically seems like a totally different feature. Was the &quot;encapsulated expression&quot; of N4147 rejected entirely then?</p>
<p dir="ltr">&gt;<br>
&gt; --<br>
&gt;<br>
&gt; ---<br>
&gt; You received this message because you are subscribed to a topic in the Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
&gt; To unsubscribe from this topic, visit <a href="https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe</a>.<br>
&gt; To unsubscribe from this group and all its topics, send an email to <a href="mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br>
&gt; To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br>
&gt; Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</p>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--001a1140f4e6435c7a051e28029e--

.

On 25 August 2015 at 22:47, Sean Middleditch <sean@middleditch.us> wrote:
>> There's a newer inline variable paper
>> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf
> Huh, yeah, at a very cursory glance on my phone that basically seems like a
> totally different feature. Was the "encapsulated expression" of N4147
> rejected entirely then?


Not entirely, but the guidance was that inline variables and expression aliases
should be separate.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1140eaaa82103e051e28ffa8
Content-Type: text/plain; charset=UTF-8

My concern though in this is that as an oo programmer, i feel that getters
and setters are an antipattern.
On Aug 25, 2015 4:04 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:

> On 25 August 2015 at 22:47, Sean Middleditch <sean@middleditch.us> wrote:
> >> There's a newer inline variable paper
> >> http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4424.pdf
> > Huh, yeah, at a very cursory glance on my phone that basically seems
> like a
> > totally different feature. Was the "encapsulated expression" of N4147
> > rejected entirely then?
>
>
> Not entirely, but the guidance was that inline variables and expression
> aliases
> should be separate.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1140eaaa82103e051e28ffa8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">My concern though in this is that as an oo programmer, i fee=
l that getters and setters are an antipattern. </p>
<div class=3D"gmail_quote">On Aug 25, 2015 4:04 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">On 25 August 2015 at 22:47, Sean Middleditch &lt;<a href=3D"mailto:se=
an@middleditch.us">sean@middleditch.us</a>&gt; wrote:<br>
&gt;&gt; There&#39;s a newer inline variable paper<br>
&gt;&gt; <a href=3D"http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n44=
24.pdf" rel=3D"noreferrer" target=3D"_blank">http://open-std.org/JTC1/SC22/=
WG21/docs/papers/2015/n4424.pdf</a><br>
&gt; Huh, yeah, at a very cursory glance on my phone that basically seems l=
ike a<br>
&gt; totally different feature. Was the &quot;encapsulated expression&quot;=
 of N4147<br>
&gt; rejected entirely then?<br>
<br>
<br>
Not entirely, but the guidance was that inline variables and expression ali=
ases<br>
should be separate.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1140eaaa82103e051e28ffa8--

.

On 25 August 2015 at 23:58, Gino Vincenzini <openmysourcecode@gmail.com> wrote:
> My concern though in this is that as an oo programmer, i feel that getters
> and setters are an antipattern.


If so, how are properties not an antipattern? They are merely a
shortcut syntax for getters
and setters.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1147d2d0aeefb2051e295a4c
Content-Type: text/plain; charset=UTF-8

That's my point.
On Aug 25, 2015 5:19 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:

> On 25 August 2015 at 23:58, Gino Vincenzini <openmysourcecode@gmail.com>
> wrote:
> > My concern though in this is that as an oo programmer, i feel that
> getters
> > and setters are an antipattern.
>
>
> If so, how are properties not an antipattern? They are merely a
> shortcut syntax for getters
> and setters.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1147d2d0aeefb2051e295a4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">That&#39;s my point. </p>
<div class=3D"gmail_quote">On Aug 25, 2015 5:19 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">On 25 August 2015 at 23:58, Gino Vincenzini &lt;<a href=3D"mailto:ope=
nmysourcecode@gmail.com">openmysourcecode@gmail.com</a>&gt; wrote:<br>
&gt; My concern though in this is that as an oo programmer, i feel that get=
ters<br>
&gt; and setters are an antipattern.<br>
<br>
<br>
If so, how are properties not an antipattern? They are merely a<br>
shortcut syntax for getters<br>
and setters.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1147d2d0aeefb2051e295a4c--

.

On 26 August 2015 at 00:24, Gino Vincenzini <openmysourcecode@gmail.com> wrote:
> That's my point.


Ok. Well, I have a vague feeling that the point of many
getters/setters being less than desirable
has been mentioned before in various property discussions, and it's
just one of the many things
that the property suggestions/proposals have thus far failed to answer
in a satisfactory manner
for the committee to accept anything like it.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1140eaaa0e0f1f051e298ee9
Content-Type: text/plain; charset=UTF-8

I wouldnt just say less than desirable, i mean your code shouldnt contain
them.
On Aug 25, 2015 5:27 PM, "Ville Voutilainen" <ville.voutilainen@gmail.com>
wrote:

> On 26 August 2015 at 00:24, Gino Vincenzini <openmysourcecode@gmail.com>
> wrote:
> > That's my point.
>
>
> Ok. Well, I have a vague feeling that the point of many
> getters/setters being less than desirable
> has been mentioned before in various property discussions, and it's
> just one of the many things
> that the property suggestions/proposals have thus far failed to answer
> in a satisfactory manner
> for the committee to accept anything like it.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1140eaaa0e0f1f051e298ee9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I wouldnt just say less than desirable, i mean your code sho=
uldnt contain them. </p>
<div class=3D"gmail_quote">On Aug 25, 2015 5:27 PM, &quot;Ville Voutilainen=
&quot; &lt;<a href=3D"mailto:ville.voutilainen@gmail.com">ville.voutilainen=
@gmail.com</a>&gt; wrote:<br type=3D"attribution"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex">On 26 August 2015 at 00:24, Gino Vincenzini &lt;<a href=3D"mailto:ope=
nmysourcecode@gmail.com">openmysourcecode@gmail.com</a>&gt; wrote:<br>
&gt; That&#39;s my point.<br>
<br>
<br>
Ok. Well, I have a vague feeling that the point of many<br>
getters/setters being less than desirable<br>
has been mentioned before in various property discussions, and it&#39;s<br>
just one of the many things<br>
that the property suggestions/proposals have thus far failed to answer<br>
in a satisfactory manner<br>
for the committee to accept anything like it.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1140eaaa0e0f1f051e298ee9--

.

--001a113e2406668029051e298e7c
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 25, 2015 at 2:19 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 25 August 2015 at 23:58, Gino Vincenzini <openmysourcecode@gmail.com>
> wrote:
> > My concern though in this is that as an oo programmer, i feel that
> getters
> > and setters are an antipattern.
>
>
> If so, how are properties not an antipattern? They are merely a
> shortcut syntax for getters
> and setters.


I can't speak for others, but I consider properties an antipattern in this
respect as well. Personally, I never quite understood why people want
properties. I don't see any tangible advantage of invoking something as
".size" rather than ".size()". It just seems to unnecessarily complicate
the language without actual gain.

As well, accessing data by way of member access tends to often go away
anyway as code becomes mature anyway, whether member function or
"properties", especially with respect to generic code. Take for example
..begin() and .end(). One might suggest that these would somehow be "nicer"
by being invoked as though they were properties such as ".begin" and ".end"
(I personally don't see why that's any better), but even if you did that,
you miss out on the fact that in modern C++, non-member access is usually
preferred anyway. In generic code you use std::begin(c) and std::end(c)
(and as of C++17, std::size(c)). Properties don't really fit into the mix.

IMHO, properties are not worthwhile to pursue as a C++ language feature.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113e2406668029051e298e7c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 25, 2015 at 2:19 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 25 August 2015 at 23:58, Gino Vincenzini &lt;<a href=3D"mailto=
:openmysourcecode@gmail.com">openmysourcecode@gmail.com</a>&gt; wrote:<br>
&gt; My concern though in this is that as an oo programmer, i feel that get=
ters<br>
&gt; and setters are an antipattern.<br>
<br>
<br>
</span>If so, how are properties not an antipattern? They are merely a<br>
shortcut syntax for getters<br>
and setters.</blockquote><div><br></div><div>I can&#39;t speak for others, =
but I consider properties an antipattern in this respect as well. Personall=
y, I never quite understood why people want properties. I don&#39;t see any=
 tangible advantage of invoking something as &quot;.size&quot; rather than =
&quot;.size()&quot;. It just seems to unnecessarily complicate the language=
 without actual gain.</div><div><br></div><div>As well, accessing data by w=
ay of member access tends to often go away anyway as code becomes mature an=
yway, whether member function or &quot;properties&quot;, especially with re=
spect to generic code. Take for example .begin() and .end(). One might sugg=
est that these would somehow be &quot;nicer&quot; by being invoked as thoug=
h they were properties such as &quot;.begin&quot; and &quot;.end&quot; (I p=
ersonally don&#39;t see why that&#39;s any better), but even if you did tha=
t, you miss out on the fact that in modern C++, non-member access is usuall=
y preferred anyway. In generic code you use std::begin(c) and std::end(c) (=
and as of C++17, std::size(c)). Properties don&#39;t really fit into the mi=
x.</div><div><br></div><div>IMHO, properties are not worthwhile to pursue a=
s a C++ language feature.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113e2406668029051e298e7c--

.

2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com>:
> I wouldnt just say less than desirable, i mean your code shouldnt contain
> them.

Got a reference for that?
I mean, should class person not contain a name function/property?
Should containers not have a size function/property?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

> But `foo.boo` will always be accessing a member of `foo`. What you do wit=
h such access may be more complex, but `foo.boo` itself will not provoke a =
function call.

Neither `foo.getBoo()` will provoke function call in actual machine code if=
 it is inline function just accessing some private member. So () are actual=
ly meaningless if you don't see its implementation.

> ... so what? Not everyone uses "modern IDEs". If someone wants to use Not=
epad to code in C++, I see no reason why we should make their lives more di=
fficult.

See above. Again you cannot just assume that method call is expensive, if i=
t may be inlined and trivial. Having () just gives you false comfort of kno=
wing what's going on.

> Except that this is not true. If someone defines properties in their type=
s, then you have to use them to use those types. Just as when someone defin=
es a function to take a `const std::string &`, you have to use std::string =
to call that function.
> So no, it's not up to you. It's up to you and the code you use.

You can give this argument to anything that you don't like, not only proper=
ties but actually any language feature that is getting proposed and you don=
't want to be there.

> Attributes are never to be used for actual syntax. They should never be a=
llowed to change the actual meaning of code. They should never be used in l=
ieu of an actual keyword, for the sole purpose of making the "simplest poss=
ible extension."

I see your point. Putting this into attribute may not be best idea then, re=
gardless how Microsoft did that in MSVC with __declspec(property)

> If your feature needs a keyword, and there aren't enough people who belie=
ve that the feature merits the pain of adding a new keyword, tough luck. Yo=
u don't get to pervert an attribute into a keyword for your personal pet fe=
atures.

I humbly ask you to stop being sarcastic. I am not the original author of t=
his thread and you can see there are others that would like to have propert=
ies as a part of C++ standard, so calling this my personal pet feature is j=
ust not right. You should call it rather some C++ developers zoo.

> But it does co-opt the possibility of allowing an overload for operator. =
And while I despise the idea of `operator.` overloading, I'd rather that de=
bate be unencumbered by questions of whether the syntax could be reserved f=
or properties.
> Syntax is a rare and precious thing.

OK. This was just an idea. Actually I don't really care how they will be de=
clared, as long as then can be used in place of member access and the decla=
ration syntax won't be convoluted too much (as it often happens with C++).

> Well, here's the big problem that I personally have with properties:
>=20
> I do not believe that they are that important.

This is really matter of taste, but there is a reason why other languages s=
uch as D or Nim are getting some attraction and you cannot just deny that. =
These languages fill the gap of missing C++ features and just to be honest =
C++ obscure syntax.

> If C++98 had properties from day 1, I'd be fine with them. But it doesn't=
.. And adding a non-trivial language feature like this takes time and effort=
.. Time and effort that would not be spent other features of far more pressi=
ng importance like concepts, modules, ranges, coroutines, etc.

At that time in 1998 probably there was no need, because programmers were j=
ust exploring and learning what was possible with C++, there were also no o=
ther languages on horizon that could inspire C++ committee to bring propert=
ies. But if you follow the history of this whole subject, you can see that =
there were some ideas of bringing properties to C++ around 2003 already, th=
at 12 years ago! And what happened during these 12 years?

> At the end of the day, C++ has a lot more important deficiencies that nee=
d to be addressed than properties.
>=20
> If C++ never gets properties, I won't feel like I'm missing something cri=
tical. If C++ never gets modules, then we will definitely be missing someth=
ing critical (ie: compile-time performance, solving the static initializati=
on ordering problem, etc).

D has all of that already. Why won't you switch to D then? I am already exp=
loring migration either to D or Nim with some of my projects. The only prob=
lem is C++ library dependencies. Since there is no C++ ABI standard (which =
is a read problem) you usually don't see C++ ffi.

> Having concepts dramatically lowers the bar in template metaprogramming, =
opening some of that up to the average programmer (as well as improving err=
or messages for everyone involved). Ranges and lazy evaluation changes the =
way you code. Coroutines fundamentally change the way you deal with threadi=
ng (and even not-so-threaded code). And so forth.

Do any of these features let you develop something that is not possible tod=
ay? Or it is just about improving language expressiveness and reducing code=
 bloat?

> Properties just isn't in the same league as far as its importance is conc=
erned. Properties are very nice bits of syntactic sugar. But at the end of =
the day, it's just sugar. And it's not even that particularly sweet sugar l=
ike lambdas. They won't make your code that much more readable. They won't =
make your code that much more maintainable.

Yes they do. Simple example is turning some API implementation member varia=
ble into property and back do not require fixing code depending on this API=
.. I have seen so many times that developers were doing trivial accessors in=
stead of making member fields public just because they feared at some point=
 they will have to extend these accessors. Also currently C++ does not allo=
w you to have publicly readonly member, that is not privately readonly (con=
st).

> They're useful. But not critical. And certainly not critical enough to ta=
ke up the committee's time when they're dealing with so many real issues.

Properties are not a real issue to you, okay I do acknowledge that, but fin=
ally you and the committee should acknowledge that they are many (other) C+=
+ developers that would like to see and USE this feature. And honestly ther=
e are so many C++ features most of C++ developers don't know they exist, bu=
t somehow they made its way into C++ standard (eg. method ref qualifiers).

-- Adam

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2015-08-25 17:51, Adam Strzelecki wrote:
>> But `foo.boo` will always be accessing a member of `foo`. What you
>> do with such access may be more complex, but `foo.boo` itself will
>> not provoke a function call.
>
> Neither `foo.getBoo()` will provoke function call in actual machine
> code if it is inline function just accessing some private member. So
> () are actually meaningless if you don't see its implementation.

There's a pretty big difference between something that looks cheap but
might actually be expensive, and something that looks [potentially]
expensive but might actually be cheap.

> I have seen so many times that developers were doing trivial
> accessors instead of making member fields public just because they
> feared at some point they will have to extend these accessors.

You miss a big difference here; if the accessors are not inline,
changing between trivial and not-trivial is not just a SC change, but
also a BC change. Likewise with member vs. property would at best be SC,
but would be BIC.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

> There's a pretty big difference between something that looks cheap but
> might actually be expensive, and something that looks [potentially]
> expensive but might actually be cheap.

From my experience I can see many APIs that have accessors() only, so you d=
on't see any . there, since all member fields are private, therefore there =
is absolutely no hint what's cheap and what's not in the code using API as =
there are only get/set everywhere.

(Also currently C++ has many other places that look cheap but are expensive=
, eg. cast operators, copy operators.)

API designers prefer in many cases consistency making everything available =
through accessors than making selectively some field available directly, wh=
ich will lead you to constantly peek into docs "was this accessible via get=
.... or via dot.". Some call it public field phobia, but I don't think this =
is entirely true.

I'd just love these APIs to use properties everywhere in place of these acc=
essors and use player.health +=3D 10 instead player.setHealth(player.getHea=
lth() + 10).

>> I have seen so many times that developers were doing trivial=20
>> accessors instead of making member fields public just because they
>> feared at some point they will have to extend these accessors.
>=20
> You miss a big difference here; if the accessors are not inline,
> changing between trivial and not-trivial is not just a SC change, but
> also a BC change. Likewise with member vs. property would at best be SC,
> but would be BIC.

I don't think binary compatibility is a specific to properties and having p=
roperties in C++ can make it better or worse.

All I am just saying properties lets you refine implementation while keepin=
g source compatibility intact as long you don't abuse properties, keeping i=
t verb =3D method, noun =3D property or direct field access.

--=20
Adam

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--089e015370f6742c2d051e2a8533
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 25, 2015 at 10:33 AM, <adam.strzelecki@java.pl> wrote:

> I would like to raise this topic again.
>

Can you provide some standard examples of the problems that properties
solve that make them a worthwhile addition to the language. For instance,
can you take standard C++ types (I.E. containers, etc.) and explain where
you might use properties instead and what benefits you would gain from them
being properties? If not with containers, some type that people in the
community are already familiar with.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e015370f6742c2d051e2a8533
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Aug 25, 2015 at 10:33 AM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:adam=
..strzelecki@java.pl" target=3D"_blank">adam.strzelecki@java.pl</a>&gt;</spa=
n> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>I would l=
ike to raise this topic again.</div></div></blockquote><div><br></div><div>=
Can you provide some standard examples of the problems that properties solv=
e that make them a worthwhile addition to the language. For instance, can y=
ou take standard C++ types (I.E. containers, etc.) and explain where you mi=
ght use properties instead and what benefits you would gain from them being=
 properties? If not with containers, some type that people in the community=
 are already familiar with.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e015370f6742c2d051e2a8533--

.

On 2015-08-25 23:51, Olaf van der Spek wrote:
> 2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com>:
>> I wouldnt just say less than desirable, i mean your code shouldnt contain
>> them.
>
> Got a reference for that?
> I mean, should class person not contain a name function/property?

It might have a function returning the name, but it should not have a
public set_name, and certainly not set_age, or set_height.

> Should containers not have a size function/property?

Likewise, vec.set_size(vec.get_size + 1) isn't a very good interface.


A bit up the thread Adam writes:

"I'd just love these APIs to use properties everywhere in place of these
accessors and use player.health += 10 instead
player.setHealth(player.getHealth() + 10)."

Which is also an odd interface. I would expect to use
player.visit_doctor() or player.eat_your_medicine() to improve health.
Not player.health++.


Bo Persson




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_1118_755611674.1440543592247
Content-Type: text/plain; charset=UTF-8

I have previously had a proposal idea similar to this which would allow property implementations.
I agree with the need to be able to simplify APIs through the use of dynamic members (I.e. simple functions for validation / concatenation of other members).
The only argument I ever really got was that it had been discussed and rejected many times before and thus was pointless to pursue.
At that time I had not fully read through all the standard and also was rather new to this group. However I do still have my original draft proposal somewhere.
If so many people are asking for this then we should try to figure out the simplest way to implement it. Maybe initially with some basic limitations like what was done with auto deduced function return value deduction.
I would also suggest that any getter should be equivalent to:
    type getter-function-name() get(private-member-name) const...
Also any setters should be equal to:
    void setter-function-name(private-member-type) set(private-member-name)...

These would then allow:
auto a = x.private-member-name to map to the public getter
x.private-member-name = a to map to the validating setter value

In the case of concatenating members we could comma separate the declared get member list. However for the set declaration only a single private-member-name can be declared as it is not easy to reason about what conversions may apply.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

------=_Part_1118_755611674.1440543592247--

.

------=_Part_4229_1658715872.1440544510647
Content-Type: multipart/alternative;
 boundary="----=_Part_4230_606429813.1440544510648"

------=_Part_4230_606429813.1440544510648
Content-Type: text/plain; charset=UTF-8



On Tuesday, August 25, 2015 at 5:51:10 PM UTC-4, Adam Strzelecki wrote:
>
> > Except that this is not true. If someone defines properties in their
> types, then you have to use them to use those types. Just as when someone
> defines a function to take a `const std::string &`, you have to use
> std::string to call that function.
> > So no, it's not up to you. It's up to you and the code you use.
>
> You can give this argument to anything that you don't like, not only
> properties but actually any language feature that is getting proposed and
> you don't want to be there.
>

.... yes. That's why what you said is not a argument against that view. Some
people do not like the look of properties in syntax. You don't have an
argument against that viewpoint, because if properties are adopted, those
people will have to look at it.

The correct response to such an argument is "so what?"


> > If your feature needs a keyword, and there aren't enough people who
> believe that the feature merits the pain of adding a new keyword, tough
> luck. You don't get to pervert an attribute into a keyword for your
> personal pet features.
>
> I humbly ask you to stop being sarcastic. I am not the original author of
> this thread and you can see there are others that would like to have
> properties as a part of C++ standard, so calling this my personal pet
> feature is just not right. You should call it rather some C++ developers
> zoo.
>

Consider it the "royal you" then. "You" as in "those wanting properties in
C++."

Also, you were the one who wanted to use attributes for keywords. So either
form of "you" applies, since I was specifically aiming that criticism at
your idea specifically.


> > Well, here's the big problem that I personally have with properties:
> >
> > I do not believe that they are that important.
>
> This is really matter of taste, but there is a reason why other languages
> such as D or Nim are getting some attraction and you cannot just deny that.
> These languages fill the gap of missing C++ features and just to be honest
> C++ obscure syntax.
>

Yes... and?

Can you provide evidence that properties are a *significant* reason for the
attraction for those languages? Otherwise, we should focus on the features
of those languages that *are* attractive: concepts/static if, modules, etc.


> > If C++98 had properties from day 1, I'd be fine with them. But it
> doesn't. And adding a non-trivial language feature like this takes time and
> effort. Time and effort that would not be spent other features of far more
> pressing importance like concepts, modules, ranges, coroutines, etc.
>
> At that time in 1998 probably there was no need, because programmers were
> just exploring and learning what was possible with C++, there were also no
> other languages on horizon that could inspire C++ committee to bring
> properties. But if you follow the history of this whole subject, you can
> see that there were some ideas of bringing properties to C++ around 2003
> already, that 12 years ago! And what happened during these 12 years?
>

There were also some ideas for modules and concepts. And even rudimentary
ranges. There were also really bad ideas proposed. Lots of people have had
ideas for what C++ should do.

That doesn't make your idea a priori correct.

> At the end of the day, C++ has a lot more important deficiencies that
> need to be addressed than properties.
> >
> > If C++ never gets properties, I won't feel like I'm missing something
> critical. If C++ never gets modules, then we will definitely be missing
> something critical (ie: compile-time performance, solving the static
> initialization ordering problem, etc).
>
> D has all of that already. Why won't you switch to D then? I am already
> exploring migration either to D or Nim with some of my projects.


Then I ask again: are properties a *significant* part of why people want
those other languages? Do you have actual evidence that they are?


> The only problem is C++ library dependencies. Since there is no C++ ABI
> standard (which is a read problem) you usually don't see C++ ffi.
>
> > Having concepts dramatically lowers the bar in template metaprogramming,
> opening some of that up to the average programmer (as well as improving
> error messages for everyone involved). Ranges and lazy evaluation changes
> the way you code. Coroutines fundamentally change the way you deal with
> threading (and even not-so-threaded code). And so forth.
>
> Do any of these features let you develop something that is not possible
> today? Or it is just about improving language expressiveness and reducing
> code bloat?
>

Not "possible"? For the most part, no. But just because something is
possible doesn't mean that we should not bother to make it reasonable
rather than a hack. Or to improve upon it so that you can do more with it.
Or to make the language compile faster.

> Properties just isn't in the same league as far as its importance is
> concerned. Properties are very nice bits of syntactic sugar. But at the end
> of the day, it's just sugar. And it's not even that particularly sweet
> sugar like lambdas. They won't make your code that much more readable. They
> won't make your code that much more maintainable.
>
> Yes they do. Simple example is turning some API implementation member
> variable into property and back do not require fixing code depending on
> this API. I have seen so many times that developers were doing trivial
> accessors instead of making member fields public just because they feared
> at some point they will have to extend these accessors. Also currently C++
> does not allow you to have publicly readonly member, that is not privately
> readonly (const).


You can't actually do that. Or at least, you can't switch from a member
variable to a property if you're changing the nature of a variable.
Consider this struct:

struct A
{
  std::string name;
};

Now, you want to convert this into a property, who's internal
representation has changed. Maybe the actual name comes from a database
query or something. So you do this:

struct A
{
  property[name] std::string getName() const;
  property[name] void setName(const std::string &name);
};

Well, you just broke this code:

A a;
auto &ref = a.name;
ref = "foo";

That code *used* to set the value within `a`. But in the new version, it
sets the temporary returned by `getName`, which has no effect on the string
stored in `a`.

So no, you can't do that transparently, even with properties.

You may have forgotten that C++ isn't D or C# ;)


> > They're useful. But not critical. And certainly not critical enough to
> take up the committee's time when they're dealing with so many real issues.
>
> Properties are not a real issue to you, okay I do acknowledge that, but
> finally you and the committee should acknowledge that they are many (other)
> C++ developers that would like to see and USE this feature. And honestly
> there are so many C++ features most of C++ developers don't know they
> exist, but somehow they made its way into C++ standard (eg. method ref
> qualifiers).


That some developers don't know about a feature doesn't mean that it's not
important. Reference qualifiers for `this` is quite important for move
correctness in various cases. It plugs an important hole in move semantics.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Tuesday, August 25, 2015 at 5:51:10 PM UTC-4, A=
dam Strzelecki wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; Except that this is not true. If someone defines properties in their t=
ypes, then you have to use them to use those types. Just as when someone de=
fines a function to take a `const std::string &amp;`, you have to use std::=
string to call that function.
<br>&gt; So no, it&#39;s not up to you. It&#39;s up to you and the code you=
 use.
<br>
<br>You can give this argument to anything that you don&#39;t like, not onl=
y properties but actually any language feature that is getting proposed and=
 you don&#39;t want to be there.<br></blockquote><div><br>... yes. That&#39=
;s why what you said is not a argument against that view. Some people do no=
t like the look of properties in syntax. You don&#39;t have an argument aga=
inst that viewpoint, because if properties are adopted, those people will h=
ave to look at it.<br><br>The correct response to such an argument is &quot=
;so what?&quot;<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
>&gt; If your feature needs a keyword, and there aren&#39;t enough people w=
ho believe that the feature merits the pain of adding a new keyword, tough =
luck. You don&#39;t get to pervert an attribute into a keyword for your per=
sonal pet features.
<br>
<br>I humbly ask you to stop being sarcastic. I am not the original author =
of this thread and you can see there are others that would like to have pro=
perties as a part of C++ standard, so calling this my personal pet feature =
is just not right. You should call it rather some C++ developers zoo.
<br></blockquote><div><br>Consider it the &quot;royal you&quot; then. &quot=
;You&quot; as in &quot;those wanting properties in C++.&quot;<br><br>Also, =
you were the one who wanted to use attributes for keywords. So either form =
of &quot;you&quot; applies, since I was specifically aiming that criticism =
at your idea specifically.<br>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">
&gt; Well, here&#39;s the big problem that I personally have with propertie=
s:
<br>&gt;=20
<br>&gt; I do not believe that they are that important.
<br>
<br>This is really matter of taste, but there is a reason why other languag=
es such as D or Nim are getting some attraction and you cannot just deny th=
at. These languages fill the gap of missing C++ features and just to be hon=
est C++ obscure syntax.
<br></blockquote><div><br>Yes... and?<br><br>Can you provide evidence that =
properties are a <i>significant</i> reason for the attraction for those lan=
guages? Otherwise, we should focus on the features of those languages that =
<i>are</i> attractive: concepts/static if, modules, etc.<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">
&gt; If C++98 had properties from day 1, I&#39;d be fine with them. But it =
doesn&#39;t. And adding a non-trivial language feature like this takes time=
 and effort. Time and effort that would not be spent other features of far =
more pressing importance like concepts, modules, ranges, coroutines, etc.
<br>
<br>At that time in 1998 probably there was no need, because programmers we=
re just exploring and learning what was possible with C++, there were also =
no other languages on horizon that could inspire C++ committee to bring pro=
perties. But if you follow the history of this whole subject, you can see t=
hat there were some ideas of bringing properties to C++ around 2003 already=
, that 12 years ago! And what happened during these 12 years?<br></blockquo=
te><div><br>There were also some ideas for modules and concepts. And even r=
udimentary ranges. There were also really bad ideas proposed. Lots of peopl=
e have had ideas for what C++ should do.<br><br>That doesn&#39;t make your =
idea a priori correct.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
&gt; At the end of the day, C++ has a lot more important deficiencies that =
need to be addressed than properties.
<br>&gt;=20
<br>&gt; If C++ never gets properties, I won&#39;t feel like I&#39;m missin=
g something critical. If C++ never gets modules, then we will definitely be=
 missing something critical (ie: compile-time performance, solving the stat=
ic initialization ordering problem, etc).
<br>
<br>D has all of that already. Why won&#39;t you switch to D then? I am alr=
eady exploring migration either to D or Nim with some of my projects.</bloc=
kquote><div><br>Then I ask again: are properties a <i>significant</i> part =
of why people want those other languages? Do you have actual evidence that =
they are?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">The o=
nly problem is C++ library dependencies. Since there is no C++ ABI standard=
 (which is a read problem) you usually don&#39;t see C++ ffi.
<br>
<br>&gt; Having concepts dramatically lowers the bar in template metaprogra=
mming, opening some of that up to the average programmer (as well as improv=
ing error messages for everyone involved). Ranges and lazy evaluation chang=
es the way you code. Coroutines fundamentally change the way you deal with =
threading (and even not-so-threaded code). And so forth.
<br>
<br>Do any of these features let you develop something that is not possible=
 today? Or it is just about improving language expressiveness and reducing =
code bloat?<br></blockquote><div><br>Not &quot;possible&quot;? For the most=
 part, no. But just because something is possible doesn&#39;t mean that we =
should not bother to make it reasonable rather than a hack. Or to improve u=
pon it so that you can do more with it. Or to make the language compile fas=
ter.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; Properties just isn&#39;t in the same league as far as its importance =
is concerned. Properties are very nice bits of syntactic sugar. But at the =
end of the day, it&#39;s just sugar. And it&#39;s not even that particularl=
y sweet sugar like lambdas. They won&#39;t make your code that much more re=
adable. They won&#39;t make your code that much more maintainable.
<br>
<br>Yes they do. Simple example is turning some API implementation member v=
ariable into property and back do not require fixing code depending on this=
 API. I have seen so many times that developers were doing trivial accessor=
s=20
instead of making member fields public just because they feared at some=20
point they will have to extend these accessors. Also currently C++ does=20
not allow you to have publicly readonly member, that is not privately=20
readonly (const).
</blockquote><div><br>You can&#39;t actually do that. Or at least, you can&=
#39;t switch from a member variable to a property if you&#39;re changing th=
e nature of a variable. Consider this struct:<br><br><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> A<br></span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 std</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> name</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</=
span></div></code></div><br>Now, you want to convert this into a property, =
who&#39;s internal representation has changed. Maybe the actual name comes =
from a database query or something. So you do this:<br><br><div class=3D"pr=
ettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb=
(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> A<br></span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 property</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify">name</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> std</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">::</span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>string</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> ge=
tName</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 property</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify">name</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">]</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> setName</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">co=
nst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">string</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">name</span><span style=3D"color: #660;"=
 class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br></span></div></code></div><br>Well, you just broke this code:=
<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250,=
 250); border-color: rgb(187, 187, 187); border-style: solid; border-width:=
 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"sub=
prettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">A a<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">ref</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">name</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">ref</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #080;" class=3D"style=
d-by-prettify">&quot;foo&quot;</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">;</span></div></code></div><br>That code <i>used</i> to=
 set the value within `a`. But in the new version, it sets the temporary re=
turned by `getName`, which has no effect on the string stored in `a`.<br><b=
r>So no, you can&#39;t do that transparently, even with properties.<br><br>=
You may have forgotten that C++ isn&#39;t D or C# ;)<br>=C2=A0</div><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">&gt; They&#39;re useful. But not crit=
ical. And certainly not critical enough to take up the committee&#39;s time=
 when they&#39;re dealing with so many real issues.
<br>
<br>Properties are not a real issue to you, okay I do acknowledge that, but=
 finally you and the committee should acknowledge that they are many (other=
) C++ developers that would like to see and USE this feature. And honestly =
there are so many C++ features most of C++ developers don&#39;t know they e=
xist, but somehow they made its way into C++ standard (eg. method ref quali=
fiers).</blockquote><div><br>That some developers don&#39;t know about a fe=
ature doesn&#39;t mean that it&#39;s not important. Reference qualifiers fo=
r `this` is quite important for move correctness in various cases. It plugs=
 an important hole in move semantics.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4230_606429813.1440544510648--
------=_Part_4229_1658715872.1440544510647--

.

2015-08-26 0:53 GMT+02:00 Bo Persson <bop@gmb.dk>:
> On 2015-08-25 23:51, Olaf van der Spek wrote:
>>
>> 2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com>:
>>>
>>> I wouldnt just say less than desirable, i mean your code shouldnt contain
>>> them.
>>
>>
>> Got a reference for that?
>> I mean, should class person not contain a name function/property?
>
>
> It might have a function returning the name, but it should not have a public
> set_name, and certainly not set_age, or set_height.
>
>> Should containers not have a size function/property?
>
>
> Likewise, vec.set_size(vec.get_size + 1) isn't a very good interface.

True, IMO properties are more important for read-access then for write-access.
Wasn't there a proposal for function calls not requiring parenthesis?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-08-26 1:15 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> Yes... and?
>
> Can you provide evidence that properties are a significant reason for the
> attraction for those languages? Otherwise, we should focus on the features
> of those languages that are attractive: concepts/static if, modules, etc.

Since we're talking about evidence etc, can you provide evidence that
concepts/static if, modules, etc. are (more) attractive? ;)

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Tuesday 25 August 2015 16:15:10 Nicol Bolas wrote:
> > This is really matter of taste, but there is a reason why other languages
> > such as D or Nim are getting some attraction and you cannot just deny
> > that.  These languages fill the gap of missing C++ features and just to
> > be honest C++ obscure syntax.
>
> Yes... and?
>
> Can you provide evidence that properties are a *significant* reason for the
> attraction for those languages? Otherwise, we should focus on the features
> of those languages that *are* attractive: concepts/static if, modules, etc.

Another point to consider is that D's market share is a couple of orders of
magnitude smaller than C++'s. For as long as D has existed, people have been
predicting that it's a nicer language than C++ and would eventually take over.
It hasn't happened (I don't think it ever will), so comparisons with D usually
backfire. We can easily claim that any difference from C++ is a reason why it
*isn't* successful. (By definition, we can say that the sum of its differences
is the reason)

As for Nim, I've never even heard of it. That's how much attraction it has...

Like Nicol says, I'd investigate what new features attract people to a given
language. Rust seems to be in vogue these days.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113fdcc8552182051e311552
Content-Type: text/plain; charset=UTF-8

I really hope that nothing comes of that (proposal for function calls not
requiring parenthesis) - syntax is precious, as Nicol says, and method
access without function call operator should be reserved for partially
bound functions (what C# calls delegates).

On the other hand, removal of parentheses could be opt-in, but then we're
back at expression aliases.

Adam - would your users be satisfied with player.health() += 10? Because
that's feasible already, perhaps with some library support.
On 26 Aug 2015 08:09, "Olaf van der Spek" <olafvdspek@gmail.com> wrote:

> 2015-08-26 0:53 GMT+02:00 Bo Persson <bop@gmb.dk>:
> > On 2015-08-25 23:51, Olaf van der Spek wrote:
> >>
> >> 2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com
> >:
> >>>
> >>> I wouldnt just say less than desirable, i mean your code shouldnt
> contain
> >>> them.
> >>
> >>
> >> Got a reference for that?
> >> I mean, should class person not contain a name function/property?
> >
> >
> > It might have a function returning the name, but it should not have a
> public
> > set_name, and certainly not set_age, or set_height.
> >
> >> Should containers not have a size function/property?
> >
> >
> > Likewise, vec.set_size(vec.get_size + 1) isn't a very good interface.
>
> True, IMO properties are more important for read-access then for
> write-access.
> Wasn't there a proposal for function calls not requiring parenthesis?
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113fdcc8552182051e311552
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">I really hope that nothing comes of that (proposal for funct=
ion calls not requiring parenthesis) - syntax is precious, as Nicol says, a=
nd method access without function call operator should be reserved for part=
ially bound functions (what C# calls delegates). </p>
<p dir=3D"ltr">On the other hand, removal of parentheses could be opt-in, b=
ut then we&#39;re back at expression aliases. </p>
<p dir=3D"ltr">Adam - would your users be satisfied with player.health() +=
=3D 10? Because that&#39;s feasible already, perhaps with some library supp=
ort. </p>
<div class=3D"gmail_quote">On 26 Aug 2015 08:09, &quot;Olaf van der Spek&qu=
ot; &lt;<a href=3D"mailto:olafvdspek@gmail.com">olafvdspek@gmail.com</a>&gt=
; wrote:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D=
"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2015-08-26 =
0:53 GMT+02:00 Bo Persson &lt;<a href=3D"mailto:bop@gmb.dk">bop@gmb.dk</a>&=
gt;:<br>
&gt; On 2015-08-25 23:51, Olaf van der Spek wrote:<br>
&gt;&gt;<br>
&gt;&gt; 2015-08-25 23:38 GMT+02:00 Gino Vincenzini &lt;<a href=3D"mailto:o=
penmysourcecode@gmail.com">openmysourcecode@gmail.com</a>&gt;:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I wouldnt just say less than desirable, i mean your code shoul=
dnt contain<br>
&gt;&gt;&gt; them.<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Got a reference for that?<br>
&gt;&gt; I mean, should class person not contain a name function/property?<=
br>
&gt;<br>
&gt;<br>
&gt; It might have a function returning the name, but it should not have a =
public<br>
&gt; set_name, and certainly not set_age, or set_height.<br>
&gt;<br>
&gt;&gt; Should containers not have a size function/property?<br>
&gt;<br>
&gt;<br>
&gt; Likewise, vec.set_size(vec.get_size + 1) isn&#39;t a very good interfa=
ce.<br>
<br>
True, IMO properties are more important for read-access then for write-acce=
ss.<br>
Wasn&#39;t there a proposal for function calls not requiring parenthesis?<b=
r>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-proposals+unsubscrib=
e@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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113fdcc8552182051e311552--

.

--Apple-Mail=_3C2EE038-4A3C-4678-AB65-B80723B057B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8

> Adam - would your users be satisfied with player.health() +=3D 10? Becaus=
e that's feasible already, perhaps with some library support.
>=20
Yeah I know, returning temporary proxy object carrying pointer to the `play=
er` and having `operator=3D` calling accessor on `player`. This is super ug=
ly solution that would make debugging really ugly too (seeing the whole pro=
xy thing in the stack trace).

My concern is having uniform API for properties, either they are dynamic or=
 direct member access. I don't really want to bother with implementation de=
tails when writing client code, I don't really want to wonder whether I nee=
d to add () or not because it is dynamic property or normal member.

I can see the biggest gripe on properties is the removal of () which is an =
indication whether something gets called or is just pure memory access. But=
 many APIs don't have public members at all in their classes, so you have t=
o use () everywhere anyway, so everything looks "expensive".

As I said nothing forces you to use properties once they are in the languag=
e, similarly C++ is not enforcing any particular naming conventions. Saying=
 that allowing properties into the language will force to use them when usi=
ng someone's else API is no argument to me. C++ anyway lets you make an ugl=
y API today regardless of properties being a part of the language.

Moreover properties give you power to express that something is in fact che=
ap, as opposite to () indicating something may be expensive. For example be=
gin() end() iterators in many cases are O(1), so they can be easily perceiv=
ed as properties. Similar is std::string::length(), since it knows its leng=
th, then length can be property as it is just a memory access to some priva=
te variable, so str.length (w/o ()) looks cheap because it is cheap.

-- Adam

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--Apple-Mail=_3C2EE038-4A3C-4678-AB65-B80723B057B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=UTF-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dus-ascii"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-mode=
: space; -webkit-line-break: after-white-space;" class=3D""><div><blockquot=
e type=3D"cite" class=3D""><div class=3D""><p dir=3D"ltr" class=3D"">Adam -=
 would your users be satisfied with player.health() +=3D 10? Because that's=
 feasible already, perhaps with some library support. </p></div></blockquot=
e><div>Yeah I know, returning temporary proxy object carrying pointer to th=
e `player` and having `operator=3D` calling accessor on `player`. This is s=
uper ugly solution that would make debugging really ugly too (seeing the wh=
ole proxy thing in the stack trace).</div><div><br class=3D""></div><div>My=
 concern is having uniform API for properties, either they are dynamic or d=
irect member access. I don't really want to bother with implementation deta=
ils when writing client code, I don't really want to wonder whether I need =
to add () or not because it is dynamic property or normal member.</div><div=
><br class=3D""></div><div>I can see the biggest gripe on properties is the=
 removal of () which is an indication whether something gets called or is j=
ust pure memory access. But many APIs don't have public members at all in t=
heir classes, so you have to use () everywhere anyway, so everything looks =
"expensive".</div><div><br class=3D""></div><div>As I said nothing forces y=
ou to use properties once they are in the language, similarly C++ is not en=
forcing any particular naming conventions. Saying that allowing properties =
into the language will force to use them when using someone's else API is n=
o argument to me. C++ anyway lets you make an ugly API today regardless of =
properties being a part of the language.</div><div><br class=3D""></div><di=
v>Moreover properties give you power to express that something is in fact c=
heap, as opposite to () indicating something may be expensive. For example =
begin() end() iterators in many cases are O(1), so they can be easily perce=
ived as properties. Similar is std::string::length(), since it knows its le=
ngth, then length can be property as it is just a memory access to some pri=
vate variable, so str.length (w/o ()) looks cheap because it is cheap.</div=
><div><br class=3D""></div><div>-- Adam</div></div></body></html>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--Apple-Mail=_3C2EE038-4A3C-4678-AB65-B80723B057B8--

.

------=_Part_216_1218689863.1440583601750
Content-Type: multipart/alternative;
 boundary="----=_Part_217_1160295701.1440583601751"

------=_Part_217_1160295701.1440583601751
Content-Type: text/plain; charset=UTF-8

And instead of:
player.health() += 10 or player.health += 10,



one can already do better with C++ existing syntax:

player.addHealth(10);

<=== what's the problem with this?

I've actually finished my first big game (bit of self promotion, be ready
to turn volume off) :
http://bad-cast-games.itch.io/insane-insects-the-inception
and during the makings of that game I've used language which actually
preferred (but not enforced) this notation:

player.health += 10

My opinion based on my very recent experience? Couldn't hate it more. Yes,
hate it. Why? Because there is simply no checking if players' health will
get more than player_max_health_. So why did I do used this notation you've
asked, why didn't I use the safer notation instead?
Mostly I did use the safer syntax, but being human and with everything what
goes with it, plus time constraints and pressures, sometimes I've used that
*unsafe* syntax for one reason only, it is simply faster to write it. And I
regret this fact, because I could never be sure if somewhere this code
*because of this syntax which breaks encapsulation* is broken.

So, no, I'm against properties.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">And instead of:<br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=
=3D"styled-by-prettify">player</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify">health</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">or</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> player</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">health </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">+=3D</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">10<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span></div></code=
></div><br><br><br>one can already do better with C++ existing syntax:<br><=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">player</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify">addHealth</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">10</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">);</span></div></code></div><br> &lt;=3D=
=3D=3D what&#39;s the problem with this?<br><br>I&#39;ve actually finished =
my first big game (bit of self promotion, be ready to turn volume off) : ht=
tp://bad-cast-games.itch.io/insane-insects-the-inception <br>and during the=
 makings of that game I&#39;ve used language which actually preferred (but =
not enforced) this notation:<br><br>player.health +=3D 10<br><br>My opinion=
 based on my very recent experience? Couldn&#39;t hate it more. Yes, hate i=
t. Why? Because there is simply no checking if players&#39; health will get=
 more than player_max_health_. So why did I do used this notation you&#39;v=
e asked, why didn&#39;t I use the safer notation instead? <br>Mostly I did =
use the safer syntax, but being human and with everything what goes with it=
, plus time constraints and pressures, sometimes I&#39;ve used that *unsafe=
* syntax for one reason only, it is simply faster to write it. And I regret=
 this fact, because I could never be sure if somewhere this code *because o=
f this syntax which breaks encapsulation* is broken.<br><br>So, no, I&#39;m=
 against properties.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_217_1160295701.1440583601751--
------=_Part_216_1218689863.1440583601750--

.

------=_Part_23_524007008.1440592863667
Content-Type: multipart/alternative;
 boundary="----=_Part_24_1315888830.1440592863667"

------=_Part_24_1315888830.1440592863667
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 26, 2015 at 2:15:17 AM UTC-4, Olaf van der Spek wrote:
>
> 2015-08-26 1:15 GMT+02:00 Nicol Bolas <jmck...@gmail.com <javascript:>>:
> > Yes... and?
> >
> > Can you provide evidence that properties are a significant reason for
> the
> > attraction for those languages? Otherwise, we should focus on the
> features
> > of those languages that are attractive: concepts/static if, modules,
> etc.
>
> Since we're talking about evidence etc, can you provide evidence that
> concepts/static if, modules, etc. are (more) attractive? ;)
>

I don't need to. He's arguing that a reason to add properties to C++ is
that it will attract D/etc programmers or otherwise stop C++ programmers
from switching. He's making the claim, so he needs to provide the evidence
;)

My argument for why C++ should get concepts/static if, modules, etc, is not
because other languages have them, but because of their inherent utility.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, August 26, 2015 at 2:15:17 AM UTC-4,=
 Olaf van der Spek wrote:<blockquote class=3D"gmail_quote" style=3D"margin:=
 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">2015-=
08-26 1:15 GMT+02:00 Nicol Bolas &lt;<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"j1dOhAM-BgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt;:
<br>&gt; Yes... and?
<br>&gt;
<br>&gt; Can you provide evidence that properties are a significant reason =
for the
<br>&gt; attraction for those languages? Otherwise, we should focus on the =
features
<br>&gt; of those languages that are attractive: concepts/static if, module=
s, etc.
<br>
<br>Since we&#39;re talking about evidence etc, can you provide evidence th=
at
<br>concepts/static if, modules, etc. are (more) attractive? ;)
<br></blockquote><div><br>I don&#39;t need to. He&#39;s arguing that a reas=
on to add properties to C++ is that it will attract D/etc programmers or ot=
herwise stop C++ programmers from switching. He&#39;s making the claim, so =
he needs to provide the evidence ;)<br><br>My argument for why C++ should g=
et concepts/static if, modules, etc, is not because other languages have th=
em, but because of their inherent utility.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_24_1315888830.1440592863667--
------=_Part_23_524007008.1440592863667--

.

------=_Part_4819_185127961.1440594864743
Content-Type: multipart/alternative;
 boundary="----=_Part_4820_362338816.1440594864743"

------=_Part_4820_362338816.1440594864743
Content-Type: text/plain; charset=UTF-8

On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:
>
> Adam - would your users be satisfied with player.health() += 10? Because
> that's feasible already, perhaps with some library support.
>
> Yeah I know, returning temporary proxy object carrying pointer to the
> `player` and having `operator=` calling accessor on `player`. This is super
> ugly solution that would make debugging really ugly too (seeing the whole
> proxy thing in the stack trace).
>
> My concern is having uniform API for properties, either they are dynamic
> or direct member access. I don't really want to bother with implementation
> details when writing client code, I don't really want to wonder whether I
> need to add () or not because it is dynamic property or normal member.
>
> I can see the biggest gripe on properties is the removal of () which is an
> indication whether something gets called or is just pure memory access.
>

No, that's *a* gripe. It's simply the one being focused on in this
discussion. There are other reasons not to have properties.

Let's take your health example. I would never use even `player.health() +=
10`, let alone the property syntax. Why?

Because you can't search for it.

Changing the health of an entity is rather special, not something you ought
to be doing with any entity pointer/reference you happen to have. It's
really important, if there's a bug causing an entity's health to be
increased incorrectly, that I be able to search for every place where
health is being increased.

Your way makes that impossible. Or at least, not without a boatload of
false positives to sift through. And I certainly don't want to stick a
breakpoint in the `health()` function, or in the proxy object returned by
it or whatever, or a memory breakpoint in the entity's actual health.

Whereas if you simply had `player.addHealth(10)`, that's something you can
search for.

A lot of the pro-properties side tends to operate under the assumption that
all, or even *most* accessors were of the form "get variable, set variable."

Generally speaking, that's not how it usually works. Or at least, not in my
experience.

Oh, it sometimes is. But encapsulation usually requires more control over
how the internal property changes. A name could be decomposed into a first
name and last name. Or a first/last/middle. Or whatever. And while you
might at first want a simple "set_name" function, odds are good that what
you really want are "set_surname", "set_givenname", and "set_middlename".
If you want to set the whole name, you need some information about the
ordering of the names from the user. Since that requires two input
parameters, it couldn't be a property.

The property style interface works OK only in the *simplest* of cases. Do
we really need syntax for simple stuff? It seems to me that we need the
most syntax for complex things, not trivial accessors.

But many APIs don't have public members at all in their classes, so you
> have to use () everywhere anyway, so everything looks "expensive".
>

If you're relying on using `()` to differentiate between "cheap" and
"expensive", then you've been wrong for years now. We should not encourage
such thinking. Indeed, we've been trying to convince people that function
calls are not a priori slow for years, and we're finally making some
headway.

Why turn back the clock on that progress?


> Moreover properties give you power to express that something is in fact
> cheap, as opposite to () indicating something may be expensive. For example
> begin() end() iterators in many cases are O(1), so they can be easily
> perceived as properties. Similar is std::string::length(), since it knows
> its length, then length can be property as it is just a memory access to
> some private variable, so str.length (w/o ()) looks cheap because it is
> cheap.
>

Even if, for some unfathomable reason, want to differentiate between fast
function calls and slow ones, the speed of a function call is unrelated to
the number of arguments it takes (generally speaking). Yet, your property
syntax *requires* that getters take no parameters, and that setters take
only one.

If I have a cheap function that needs a parameter and returns a value, I
can't use property syntax to express that it's cheap. So properties are
incapable of reasonably expressing the difference you want them to.

Not to mention, one of your arguments for properties before was that you
could easily shift between direct member access and accessor functions that
do actual work. Well, "actual work" doesn't have to be fast, and in many
cases it's not. Boundary checking may be O(1), but that doesn't mean it's
as fast as not having boundary checking. So in doing so, you've shifted
from "cheap" to "not-as-cheap".

By your own reasoning, you *should* make that an explicit function call
now, since it's not as cheap as it used to be.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:break-wo=
rd"><div><blockquote type=3D"cite"><div><p dir=3D"ltr">Adam - would your us=
ers be satisfied with player.health() +=3D 10? Because that&#39;s feasible =
already, perhaps with some library support. </p></div></blockquote><div>Yea=
h I know, returning temporary proxy object carrying pointer to the `player`=
 and having `operator=3D` calling accessor on `player`. This is super ugly =
solution that would make debugging really ugly too (seeing the whole proxy =
thing in the stack trace).</div><div><br></div><div>My concern is having un=
iform API for properties, either they are dynamic or direct member access. =
I don&#39;t really want to bother with implementation details when writing =
client code, I don&#39;t really want to wonder whether I need to add () or =
not because it is dynamic property or normal member.</div><div><br></div><d=
iv>I can see the biggest gripe on properties is the removal of () which is =
an indication whether something gets called or is just pure memory access.<=
/div></div></div></blockquote><div><br>No, that&#39;s <i>a</i> gripe. It&#3=
9;s simply the one being focused on in this discussion. There are other rea=
sons not to have properties.<br><br>Let&#39;s take your health example. I w=
ould never use even `player.health() +=3D 10`, let alone the property synta=
x. Why?<br><br>Because you can&#39;t search for it.<br><br>Changing the hea=
lth of an entity is rather special, not something you ought to be doing wit=
h any entity pointer/reference you happen to have. It&#39;s really importan=
t, if there&#39;s a bug causing an entity&#39;s health to be increased inco=
rrectly, that I be able to search for every place where health is being inc=
reased.<br><br>Your way makes that impossible. Or at least, not without a b=
oatload of false positives to sift through. And I certainly don&#39;t want =
to stick a breakpoint in the `health()` function, or in the proxy object re=
turned by it or whatever, or a memory breakpoint in the entity&#39;s actual=
 health.<br><br>Whereas if you simply had `player.addHealth(10)`, that&#39;=
s something you can search for.<br><br>A lot of the pro-properties side ten=
ds to operate under the assumption that all, or even <i>most</i> accessors =
were of the form &quot;get variable, set variable.&quot;<br><br>Generally s=
peaking, that&#39;s not how it usually works. Or at least, not in my experi=
ence.<br><br>Oh, it sometimes is. But encapsulation usually requires more c=
ontrol over how the internal property changes. A name could be decomposed i=
nto a first name and last name. Or a first/last/middle. Or whatever. And wh=
ile you might at first want a simple &quot;set_name&quot; function, odds ar=
e good that what you really want are &quot;set_surname&quot;, &quot;set_giv=
enname&quot;, and &quot;set_middlename&quot;. If you want to set the whole =
name, you need some information about the ordering of the names from the us=
er. Since that requires two input parameters, it couldn&#39;t be a property=
..<br><br>The property style interface works OK only in the <i>simplest</i> =
of cases. Do we really need syntax for simple stuff? It seems to me that we=
 need the most syntax for complex things, not trivial accessors.<br><br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wrap:bre=
ak-word"><div><div>But many APIs don&#39;t have public members at all in th=
eir classes, so you have to use () everywhere anyway, so everything looks &=
quot;expensive&quot;.</div></div></div></blockquote><div><br>If you&#39;re =
relying on using `()` to differentiate between &quot;cheap&quot; and &quot;=
expensive&quot;, then you&#39;ve been wrong for years now. We should not en=
courage such thinking. Indeed, we&#39;ve been trying to convince people tha=
t function calls are not a priori slow for years, and we&#39;re finally mak=
ing some headway.<br><br>Why turn back the clock on that progress?<br>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div style=3D"word-wr=
ap:break-word"><div><div></div><div>Moreover properties give you power to e=
xpress that something is in fact cheap, as opposite to () indicating someth=
ing may be expensive. For example begin() end() iterators in many cases are=
 O(1), so they can be easily perceived as properties. Similar is std::strin=
g::length(), since it knows its length, then length can be property as it i=
s just a memory access to some private variable, so str.length (w/o ()) loo=
ks cheap because it is cheap.</div></div></div></blockquote><div></div><br>=
Even if, for some unfathomable reason, want to differentiate between fast f=
unction calls and slow ones, the speed of a function call is unrelated to t=
he number of arguments it takes (generally speaking). Yet, your property sy=
ntax <i>requires</i> that getters take no parameters, and that setters take=
 only one.<br><br>If I have a cheap function that needs a parameter and ret=
urns a value, I can&#39;t use property syntax to express that it&#39;s chea=
p. So properties are incapable of reasonably expressing the difference you =
want them to.<br><br>Not to mention, one of your arguments for properties b=
efore was that you could easily shift between direct member access and acce=
ssor functions that do actual work. Well, &quot;actual work&quot; doesn&#39=
;t have to be fast, and in many cases it&#39;s not. Boundary checking may b=
e O(1), but that doesn&#39;t mean it&#39;s as fast as not having boundary c=
hecking. So in doing so, you&#39;ve shifted from &quot;cheap&quot; to &quot=
;not-as-cheap&quot;.<br><br>By your own reasoning, you <i>should</i> make t=
hat an explicit function call now, since it&#39;s not as cheap as it used t=
o be.<br>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_4820_362338816.1440594864743--
------=_Part_4819_185127961.1440594864743--

.

--089e0141ab449ed4ff051e371405
Content-Type: text/plain; charset=UTF-8

I'd like to add some thoughts getting back onto the subject.  I think Nicol
really hit the nail on the head with;

 "A lot of the pro-properties side tends to operate under the assumption
that all, or even *most* accessors were of the form "get variable, set
variable."
Generally speaking, that's not how it usually works. Or at least, not in my
experience.


I think the idea behind a property would be the restriction of
multi-arguments to a single-argument passing.  Properties seem to play a
vital role in determining a setting from a method while also providing
other unique features like code separation that would allow limits inside
the property code.

Whereas you can use overloading for "player.health()" to get and
"player.health(10)" to set it nullifies the use of full-on optional
arguments that could be used.
Properties distinguish a ONE-ARG setting from a typical method.

With properties
"player.health" is ALWAYS a get - their cannot be an option argument for
setting it (for example; by accident "optional arg=0" thus resetting the
setting when called.)
"player.health = 1" is always a set.

they're limited to a single value setting and as such are distinct from
methods.

Thoughts?



On Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:
>>
>> Adam - would your users be satisfied with player.health() += 10? Because
>> that's feasible already, perhaps with some library support.
>>
>> Yeah I know, returning temporary proxy object carrying pointer to the
>> `player` and having `operator=` calling accessor on `player`. This is super
>> ugly solution that would make debugging really ugly too (seeing the whole
>> proxy thing in the stack trace).
>>
>> My concern is having uniform API for properties, either they are dynamic
>> or direct member access. I don't really want to bother with implementation
>> details when writing client code, I don't really want to wonder whether I
>> need to add () or not because it is dynamic property or normal member.
>>
>> I can see the biggest gripe on properties is the removal of () which is
>> an indication whether something gets called or is just pure memory access.
>>
>
> No, that's *a* gripe. It's simply the one being focused on in this
> discussion. There are other reasons not to have properties.
>
> Let's take your health example. I would never use even `player.health() +=
> 10`, let alone the property syntax. Why?
>
> Because you can't search for it.
>
> Changing the health of an entity is rather special, not something you
> ought to be doing with any entity pointer/reference you happen to have.
> It's really important, if there's a bug causing an entity's health to be
> increased incorrectly, that I be able to search for every place where
> health is being increased.
>
> Your way makes that impossible. Or at least, not without a boatload of
> false positives to sift through. And I certainly don't want to stick a
> breakpoint in the `health()` function, or in the proxy object returned by
> it or whatever, or a memory breakpoint in the entity's actual health.
>
> Whereas if you simply had `player.addHealth(10)`, that's something you can
> search for.
>
> A lot of the pro-properties side tends to operate under the assumption
> that all, or even *most* accessors were of the form "get variable, set
> variable."
>
> Generally speaking, that's not how it usually works. Or at least, not in
> my experience.
>
> Oh, it sometimes is. But encapsulation usually requires more control over
> how the internal property changes. A name could be decomposed into a first
> name and last name. Or a first/last/middle. Or whatever. And while you
> might at first want a simple "set_name" function, odds are good that what
> you really want are "set_surname", "set_givenname", and "set_middlename".
> If you want to set the whole name, you need some information about the
> ordering of the names from the user. Since that requires two input
> parameters, it couldn't be a property.
>
> The property style interface works OK only in the *simplest* of cases. Do
> we really need syntax for simple stuff? It seems to me that we need the
> most syntax for complex things, not trivial accessors.
>
> But many APIs don't have public members at all in their classes, so you
>> have to use () everywhere anyway, so everything looks "expensive".
>>
>
> If you're relying on using `()` to differentiate between "cheap" and
> "expensive", then you've been wrong for years now. We should not encourage
> such thinking. Indeed, we've been trying to convince people that function
> calls are not a priori slow for years, and we're finally making some
> headway.
>
> Why turn back the clock on that progress?
>
>
>> Moreover properties give you power to express that something is in fact
>> cheap, as opposite to () indicating something may be expensive. For example
>> begin() end() iterators in many cases are O(1), so they can be easily
>> perceived as properties. Similar is std::string::length(), since it knows
>> its length, then length can be property as it is just a memory access to
>> some private variable, so str.length (w/o ()) looks cheap because it is
>> cheap.
>>
>
> Even if, for some unfathomable reason, want to differentiate between fast
> function calls and slow ones, the speed of a function call is unrelated to
> the number of arguments it takes (generally speaking). Yet, your property
> syntax *requires* that getters take no parameters, and that setters take
> only one.
>
> If I have a cheap function that needs a parameter and returns a value, I
> can't use property syntax to express that it's cheap. So properties are
> incapable of reasonably expressing the difference you want them to.
>
> Not to mention, one of your arguments for properties before was that you
> could easily shift between direct member access and accessor functions that
> do actual work. Well, "actual work" doesn't have to be fast, and in many
> cases it's not. Boundary checking may be O(1), but that doesn't mean it's
> as fast as not having boundary checking. So in doing so, you've shifted
> from "cheap" to "not-as-cheap".
>
> By your own reasoning, you *should* make that an explicit function call
> now, since it's not as cheap as it used to be.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0141ab449ed4ff051e371405
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div>I&#39;d like to add som=
e thoughts getting back onto the subject.=C2=A0 I think Nicol really hit th=
e nail on the head with;<br><br>=C2=A0&quot;A lot of the pro-properties sid=
e tends to operate under the assumption that all, or even <i>most</i> acces=
sors were of the form &quot;get variable, set variable.&quot;<br>Generally =
speaking, that&#39;s not how it usually works. Or at least, not in my exper=
ience.<br><br><br></div>I think the idea behind a property would be the res=
triction of multi-arguments to a single-argument passing.=C2=A0 Properties =
seem to play a vital role in determining a setting from a method while also=
 providing other unique features like code separation that would allow limi=
ts inside the property code.<br><br></div>Whereas you can use overloading f=
or &quot;player.health()&quot; to get and &quot;player.health(10)&quot; to =
set it nullifies the use of full-on optional arguments that could be used.<=
br></div>Properties distinguish a ONE-ARG setting from a typical method.<br=
><br></div><div>With properties<br></div>&quot;player.health&quot; is ALWAY=
S a get - their cannot be an option argument for setting it (for example; b=
y accident &quot;optional arg=3D0&quot; thus resetting the setting when cal=
led.)<br></div>&quot;player.health =3D 1&quot; is always a set.<br><br></di=
v>they&#39;re limited to a single value setting and as such are distinct fr=
om methods.<br><br></div>Thoughts?<br><div><div><br><div><div><div><div><br=
></div></div></div></div></div></div></div><div class=3D"gmail_extra"><br><=
div class=3D"gmail_quote">On Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <spa=
n dir=3D"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">=
jmckesson@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><span class=3D"">On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam S=
trzelecki wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-=
left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-=
wrap:break-word"><div><blockquote type=3D"cite"><div><p dir=3D"ltr">Adam - =
would your users be satisfied with player.health() +=3D 10? Because that&#3=
9;s feasible already, perhaps with some library support. </p></div></blockq=
uote><div>Yeah I know, returning temporary proxy object carrying pointer to=
 the `player` and having `operator=3D` calling accessor on `player`. This i=
s super ugly solution that would make debugging really ugly too (seeing the=
 whole proxy thing in the stack trace).</div><div><br></div><div>My concern=
 is having uniform API for properties, either they are dynamic or direct me=
mber access. I don&#39;t really want to bother with implementation details =
when writing client code, I don&#39;t really want to wonder whether I need =
to add () or not because it is dynamic property or normal member.</div><div=
><br></div><div>I can see the biggest gripe on properties is the removal of=
 () which is an indication whether something gets called or is just pure me=
mory access.</div></div></div></blockquote></span><div><br>No, that&#39;s <=
i>a</i> gripe. It&#39;s simply the one being focused on in this discussion.=
 There are other reasons not to have properties.<br><br>Let&#39;s take your=
 health example. I would never use even `player.health() +=3D 10`, let alon=
e the property syntax. Why?<br><br>Because you can&#39;t search for it.<br>=
<br>Changing the health of an entity is rather special, not something you o=
ught to be doing with any entity pointer/reference you happen to have. It&#=
39;s really important, if there&#39;s a bug causing an entity&#39;s health =
to be increased incorrectly, that I be able to search for every place where=
 health is being increased.<br><br>Your way makes that impossible. Or at le=
ast, not without a boatload of false positives to sift through. And I certa=
inly don&#39;t want to stick a breakpoint in the `health()` function, or in=
 the proxy object returned by it or whatever, or a memory breakpoint in the=
 entity&#39;s actual health.<br><br>Whereas if you simply had `player.addHe=
alth(10)`, that&#39;s something you can search for.<br><br>A lot of the pro=
-properties side tends to operate under the assumption that all, or even <i=
>most</i> accessors were of the form &quot;get variable, set variable.&quot=
;<br><br>Generally speaking, that&#39;s not how it usually works. Or at lea=
st, not in my experience.<br><br>Oh, it sometimes is. But encapsulation usu=
ally requires more control over how the internal property changes. A name c=
ould be decomposed into a first name and last name. Or a first/last/middle.=
 Or whatever. And while you might at first want a simple &quot;set_name&quo=
t; function, odds are good that what you really want are &quot;set_surname&=
quot;, &quot;set_givenname&quot;, and &quot;set_middlename&quot;. If you wa=
nt to set the whole name, you need some information about the ordering of t=
he names from the user. Since that requires two input parameters, it couldn=
&#39;t be a property.<br><br>The property style interface works OK only in =
the <i>simplest</i> of cases. Do we really need syntax for simple stuff? It=
 seems to me that we need the most syntax for complex things, not trivial a=
ccessors.<br><br></div><span class=3D""><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:=
1ex"><div style=3D"word-wrap:break-word"><div><div>But many APIs don&#39;t =
have public members at all in their classes, so you have to use () everywhe=
re anyway, so everything looks &quot;expensive&quot;.</div></div></div></bl=
ockquote></span><div><br>If you&#39;re relying on using `()` to differentia=
te between &quot;cheap&quot; and &quot;expensive&quot;, then you&#39;ve bee=
n wrong for years now. We should not encourage such thinking. Indeed, we&#3=
9;ve been trying to convince people that function calls are not a priori sl=
ow for years, and we&#39;re finally making some headway.<br><br>Why turn ba=
ck the clock on that progress?<br>=C2=A0</div><span class=3D""><blockquote =
class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #=
ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><div><=
/div><div>Moreover properties give you power to express that something is i=
n fact cheap, as opposite to () indicating something may be expensive. For =
example begin() end() iterators in many cases are O(1), so they can be easi=
ly perceived as properties. Similar is std::string::length(), since it know=
s its length, then length can be property as it is just a memory access to =
some private variable, so str.length (w/o ()) looks cheap because it is che=
ap.</div></div></div></blockquote><div></div><br></span>Even if, for some u=
nfathomable reason, want to differentiate between fast function calls and s=
low ones, the speed of a function call is unrelated to the number of argume=
nts it takes (generally speaking). Yet, your property syntax <i>requires</i=
> that getters take no parameters, and that setters take only one.<br><br>I=
f I have a cheap function that needs a parameter and returns a value, I can=
&#39;t use property syntax to express that it&#39;s cheap. So properties ar=
e incapable of reasonably expressing the difference you want them to.<br><b=
r>Not to mention, one of your arguments for properties before was that you =
could easily shift between direct member access and accessor functions that=
 do actual work. Well, &quot;actual work&quot; doesn&#39;t have to be fast,=
 and in many cases it&#39;s not. Boundary checking may be O(1), but that do=
esn&#39;t mean it&#39;s as fast as not having boundary checking. So in doin=
g so, you&#39;ve shifted from &quot;cheap&quot; to &quot;not-as-cheap&quot;=
..<br><br>By your own reasoning, you <i>should</i> make that an explicit fun=
ction call now, since it&#39;s not as cheap as it used to be.<div class=3D"=
HOEnZb"><div class=3D"h5"><br>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0141ab449ed4ff051e371405--

.

> player.health +=3D 10
>=20
> My opinion based on my very recent experience? Couldn't hate it more. Yes=
, hate it. Why? Because there is simply no checking if players' health will=
 get more than player_max_health_. So why did I do used this notation you'v=
e asked, why didn't I use the safer notation instead?=20
> Mostly I did use the safer syntax, but being human and with everything wh=
at goes with it, plus time constraints and pressures, sometimes I've used t=
hat *unsafe* syntax for one reason only, it is simply faster to write it. A=
nd I regret this fact, because I could never be sure if somewhere this code=
 *because of this syntax which breaks encapsulation* is broken.

You see. You've chosen something because it is easier to type and easier to=
 read. And this is the main argument for having properties given in this di=
scussion - to have clean readable code.

If you had them you would just add player_max_health_ check to the property=
 setter and everything would work.

> Your way makes that impossible. Or at least, not without a boatload of fa=
lse positives to sift through. And I certainly don't want to stick a breakp=
oint in the `health()` function, or in the proxy object returned by it or w=
hatever, or a memory breakpoint in the entity's actual health.

Wait what? I didn't propose that. See my original post about [[property]] o=
r operator.property. The "proxy thing" was my response to Edward saying tha=
t yes we can achieve sthing with today's C++, but something that's ugly.

> Whereas if you simply had `player.addHealth(10)`, that's something you ca=
n search for.

Honestly I don't see any benefit of not adding the check to setter there an=
d having separate addHealth.

> A lot of the pro-properties side tends to operate under the assumption th=
at all, or even mostaccessors were of the form "get variable, set variable.=
"

Did you see the proposition of having fine grained control on properties us=
ing operator.<prop><op>? If you want to have complete control on what you a=
re adding to property you can have operator.health+=3D in your Player class=
..

 class Player {
   ...
   void operator.health+=3D(int v) { ... }


> If you're relying on using `()` to differentiate between "cheap" and "exp=
ensive", then you've been wrong for years now. We should not encourage such=
 thinking. Indeed, we've been trying to convince people that function calls=
 are not a priori slow for years, and we're finally making some headway.

Hey it is not me who is relying on `()`. Please scroll back.

> Not to mention, one of your arguments for properties before was that you =
could easily shift between direct member access and accessor functions that=
 do actual work. Well, "actual work" doesn't have to be fast, and in many c=
ases it's not. Boundary checking may be O(1), but that doesn't mean it's as=
 fast as not having boundary checking. So in doing so, you've shifted from =
"cheap" to "not-as-cheap".

So? You said above relying on `()` has no use (I agree with that), but now =
you criticize ability to shift between direct member access and accessor fu=
nctions without breaking API. It looks like you are trying to reflect any a=
rgument given.

Like I said properties gives you some possibilities, but at the end you are=
 to choose whether you break an API but prefer `()` there or not.

> By your own reasoning, you should make that an explicit function call now=
, since it's not as cheap as it used to be.

Having properties does not remove ability to do so.

--=20
Adam

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

--001a11c3f3104b6167051e37882f
Content-Type: text/plain; charset=UTF-8

Also like to add;  What could possibly be more important than clarity in
programming?

Being that C++ is Object-Oriented it should have some means of passing
objects that are distinct (ie: clear) from a method.

Could you imagine;
GetDog().GetLeg().GetFoot().Run(10-Miles); vs
Dog.Leg.Foot.Run(10);

If we use overloading what does this mean?
Dog().Leg(30).Foot().Run(10);

Properties add code architecture clarity.
Dog.Leg.Size = 30; <- Size is an "Adjective" describing a noun (ie: object)
Dog.Leg.Foot.Run(10); <-Run we know is a Method "Adverb" describing an
Action

The () symbol makes it clear the intended architecture is a method - verb.

On Wed, Aug 26, 2015 at 7:46 AM, Tom Joe <tgit28@gmail.com> wrote:

> I'd like to add some thoughts getting back onto the subject.  I think
> Nicol really hit the nail on the head with;
>
>  "A lot of the pro-properties side tends to operate under the assumption
> that all, or even *most* accessors were of the form "get variable, set
> variable."
> Generally speaking, that's not how it usually works. Or at least, not in
> my experience.
>
>
> I think the idea behind a property would be the restriction of
> multi-arguments to a single-argument passing.  Properties seem to play a
> vital role in determining a setting from a method while also providing
> other unique features like code separation that would allow limits inside
> the property code.
>
> Whereas you can use overloading for "player.health()" to get and
> "player.health(10)" to set it nullifies the use of full-on optional
> arguments that could be used.
> Properties distinguish a ONE-ARG setting from a typical method.
>
> With properties
> "player.health" is ALWAYS a get - their cannot be an option argument for
> setting it (for example; by accident "optional arg=0" thus resetting the
> setting when called.)
> "player.health = 1" is always a set.
>
> they're limited to a single value setting and as such are distinct from
> methods.
>
> Thoughts?
>
>
>
> On Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>> On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:
>>>
>>> Adam - would your users be satisfied with player.health() += 10? Because
>>> that's feasible already, perhaps with some library support.
>>>
>>> Yeah I know, returning temporary proxy object carrying pointer to the
>>> `player` and having `operator=` calling accessor on `player`. This is super
>>> ugly solution that would make debugging really ugly too (seeing the whole
>>> proxy thing in the stack trace).
>>>
>>> My concern is having uniform API for properties, either they are dynamic
>>> or direct member access. I don't really want to bother with implementation
>>> details when writing client code, I don't really want to wonder whether I
>>> need to add () or not because it is dynamic property or normal member.
>>>
>>> I can see the biggest gripe on properties is the removal of () which is
>>> an indication whether something gets called or is just pure memory access.
>>>
>>
>> No, that's *a* gripe. It's simply the one being focused on in this
>> discussion. There are other reasons not to have properties.
>>
>> Let's take your health example. I would never use even `player.health()
>> += 10`, let alone the property syntax. Why?
>>
>> Because you can't search for it.
>>
>> Changing the health of an entity is rather special, not something you
>> ought to be doing with any entity pointer/reference you happen to have.
>> It's really important, if there's a bug causing an entity's health to be
>> increased incorrectly, that I be able to search for every place where
>> health is being increased.
>>
>> Your way makes that impossible. Or at least, not without a boatload of
>> false positives to sift through. And I certainly don't want to stick a
>> breakpoint in the `health()` function, or in the proxy object returned by
>> it or whatever, or a memory breakpoint in the entity's actual health.
>>
>> Whereas if you simply had `player.addHealth(10)`, that's something you
>> can search for.
>>
>> A lot of the pro-properties side tends to operate under the assumption
>> that all, or even *most* accessors were of the form "get variable, set
>> variable."
>>
>> Generally speaking, that's not how it usually works. Or at least, not in
>> my experience.
>>
>> Oh, it sometimes is. But encapsulation usually requires more control over
>> how the internal property changes. A name could be decomposed into a first
>> name and last name. Or a first/last/middle. Or whatever. And while you
>> might at first want a simple "set_name" function, odds are good that what
>> you really want are "set_surname", "set_givenname", and "set_middlename".
>> If you want to set the whole name, you need some information about the
>> ordering of the names from the user. Since that requires two input
>> parameters, it couldn't be a property.
>>
>> The property style interface works OK only in the *simplest* of cases.
>> Do we really need syntax for simple stuff? It seems to me that we need the
>> most syntax for complex things, not trivial accessors.
>>
>> But many APIs don't have public members at all in their classes, so you
>>> have to use () everywhere anyway, so everything looks "expensive".
>>>
>>
>> If you're relying on using `()` to differentiate between "cheap" and
>> "expensive", then you've been wrong for years now. We should not encourage
>> such thinking. Indeed, we've been trying to convince people that function
>> calls are not a priori slow for years, and we're finally making some
>> headway.
>>
>> Why turn back the clock on that progress?
>>
>>
>>> Moreover properties give you power to express that something is in fact
>>> cheap, as opposite to () indicating something may be expensive. For example
>>> begin() end() iterators in many cases are O(1), so they can be easily
>>> perceived as properties. Similar is std::string::length(), since it knows
>>> its length, then length can be property as it is just a memory access to
>>> some private variable, so str.length (w/o ()) looks cheap because it is
>>> cheap.
>>>
>>
>> Even if, for some unfathomable reason, want to differentiate between fast
>> function calls and slow ones, the speed of a function call is unrelated to
>> the number of arguments it takes (generally speaking). Yet, your property
>> syntax *requires* that getters take no parameters, and that setters take
>> only one.
>>
>> If I have a cheap function that needs a parameter and returns a value, I
>> can't use property syntax to express that it's cheap. So properties are
>> incapable of reasonably expressing the difference you want them to.
>>
>> Not to mention, one of your arguments for properties before was that you
>> could easily shift between direct member access and accessor functions that
>> do actual work. Well, "actual work" doesn't have to be fast, and in many
>> cases it's not. Boundary checking may be O(1), but that doesn't mean it's
>> as fast as not having boundary checking. So in doing so, you've shifted
>> from "cheap" to "not-as-cheap".
>>
>> By your own reasoning, you *should* make that an explicit function call
>> now, since it's not as cheap as it used to be.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c3f3104b6167051e37882f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div><div><div><div><div><div>Also lik=
e to add;=C2=A0 What could possibly be more important than clarity in progr=
amming?<br><br></div>Being that C++ is Object-Oriented it should have some =
means of passing objects that are distinct (ie: clear) from a method.<br></=
div><br>Could you imagine;<br></div>GetDog().GetLeg().GetFoot().Run(10-Mile=
s); vs<br></div>Dog.Leg.Foot.Run(10);<br><br></div>If we use overloading wh=
at does this mean?<br></div>Dog().Leg(30).Foot().Run(10);<br><br></div>Prop=
erties add code architecture clarity.<br></div>Dog.Leg.Size =3D 30; &lt;- S=
ize is an &quot;Adjective&quot; describing a noun (ie: object)<br></div>Dog=
..Leg.Foot.Run(10); &lt;-Run we know is a Method &quot;Adverb&quot; describi=
ng an Action<br><br></div>The () symbol makes it clear the intended archite=
cture is a method - verb.<br></div><div class=3D"gmail_extra"><br><div clas=
s=3D"gmail_quote">On Wed, Aug 26, 2015 at 7:46 AM, Tom Joe <span dir=3D"ltr=
">&lt;<a href=3D"mailto:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.co=
m</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div><div><div><div><div><div>I&#39;d like to add some thoughts gettin=
g back onto the subject.=C2=A0 I think Nicol really hit the nail on the hea=
d with;<span class=3D""><br><br>=C2=A0&quot;A lot of the pro-properties sid=
e tends to operate under the assumption that all, or even <i>most</i> acces=
sors were of the form &quot;get variable, set variable.&quot;<br>Generally =
speaking, that&#39;s not how it usually works. Or at least, not in my exper=
ience.<br><br><br></span></div>I think the idea behind a property would be =
the restriction of multi-arguments to a single-argument passing.=C2=A0 Prop=
erties seem to play a vital role in determining a setting from a method whi=
le also providing other unique features like code separation that would all=
ow limits inside the property code.<br><br></div>Whereas you can use overlo=
ading for &quot;player.health()&quot; to get and &quot;player.health(10)&qu=
ot; to set it nullifies the use of full-on optional arguments that could be=
 used.<br></div>Properties distinguish a ONE-ARG setting from a typical met=
hod.<br><br></div><div>With properties<br></div>&quot;player.health&quot; i=
s ALWAYS a get - their cannot be an option argument for setting it (for exa=
mple; by accident &quot;optional arg=3D0&quot; thus resetting the setting w=
hen called.)<br></div>&quot;player.health =3D 1&quot; is always a set.<br><=
br></div>they&#39;re limited to a single value setting and as such are dist=
inct from methods.<br><br></div>Thoughts?<br><div><div><br><div><div><div><=
div><br></div></div></div></div></div></div></div><div class=3D"HOEnZb"><di=
v class=3D"h5"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On=
 Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D=
"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;<=
/span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><span>On Wednesday, August =
26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:<blockquote class=3D"gm=
ail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;p=
adding-left:1ex"><div style=3D"word-wrap:break-word"><div><blockquote type=
=3D"cite"><div><p dir=3D"ltr">Adam - would your users be satisfied with pla=
yer.health() +=3D 10? Because that&#39;s feasible already, perhaps with som=
e library support. </p></div></blockquote><div>Yeah I know, returning tempo=
rary proxy object carrying pointer to the `player` and having `operator=3D`=
 calling accessor on `player`. This is super ugly solution that would make =
debugging really ugly too (seeing the whole proxy thing in the stack trace)=
..</div><div><br></div><div>My concern is having uniform API for properties,=
 either they are dynamic or direct member access. I don&#39;t really want t=
o bother with implementation details when writing client code, I don&#39;t =
really want to wonder whether I need to add () or not because it is dynamic=
 property or normal member.</div><div><br></div><div>I can see the biggest =
gripe on properties is the removal of () which is an indication whether som=
ething gets called or is just pure memory access.</div></div></div></blockq=
uote></span><div><br>No, that&#39;s <i>a</i> gripe. It&#39;s simply the one=
 being focused on in this discussion. There are other reasons not to have p=
roperties.<br><br>Let&#39;s take your health example. I would never use eve=
n `player.health() +=3D 10`, let alone the property syntax. Why?<br><br>Bec=
ause you can&#39;t search for it.<br><br>Changing the health of an entity i=
s rather special, not something you ought to be doing with any entity point=
er/reference you happen to have. It&#39;s really important, if there&#39;s =
a bug causing an entity&#39;s health to be increased incorrectly, that I be=
 able to search for every place where health is being increased.<br><br>You=
r way makes that impossible. Or at least, not without a boatload of false p=
ositives to sift through. And I certainly don&#39;t want to stick a breakpo=
int in the `health()` function, or in the proxy object returned by it or wh=
atever, or a memory breakpoint in the entity&#39;s actual health.<br><br>Wh=
ereas if you simply had `player.addHealth(10)`, that&#39;s something you ca=
n search for.<br><br>A lot of the pro-properties side tends to operate unde=
r the assumption that all, or even <i>most</i> accessors were of the form &=
quot;get variable, set variable.&quot;<br><br>Generally speaking, that&#39;=
s not how it usually works. Or at least, not in my experience.<br><br>Oh, i=
t sometimes is. But encapsulation usually requires more control over how th=
e internal property changes. A name could be decomposed into a first name a=
nd last name. Or a first/last/middle. Or whatever. And while you might at f=
irst want a simple &quot;set_name&quot; function, odds are good that what y=
ou really want are &quot;set_surname&quot;, &quot;set_givenname&quot;, and =
&quot;set_middlename&quot;. If you want to set the whole name, you need som=
e information about the ordering of the names from the user. Since that req=
uires two input parameters, it couldn&#39;t be a property.<br><br>The prope=
rty style interface works OK only in the <i>simplest</i> of cases. Do we re=
ally need syntax for simple stuff? It seems to me that we need the most syn=
tax for complex things, not trivial accessors.<br><br></div><span><blockquo=
te class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><div><di=
v>But many APIs don&#39;t have public members at all in their classes, so y=
ou have to use () everywhere anyway, so everything looks &quot;expensive&qu=
ot;.</div></div></div></blockquote></span><div><br>If you&#39;re relying on=
 using `()` to differentiate between &quot;cheap&quot; and &quot;expensive&=
quot;, then you&#39;ve been wrong for years now. We should not encourage su=
ch thinking. Indeed, we&#39;ve been trying to convince people that function=
 calls are not a priori slow for years, and we&#39;re finally making some h=
eadway.<br><br>Why turn back the clock on that progress?<br>=C2=A0</div><sp=
an><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-wo=
rd"><div><div></div><div>Moreover properties give you power to express that=
 something is in fact cheap, as opposite to () indicating something may be =
expensive. For example begin() end() iterators in many cases are O(1), so t=
hey can be easily perceived as properties. Similar is std::string::length()=
, since it knows its length, then length can be property as it is just a me=
mory access to some private variable, so str.length (w/o ()) looks cheap be=
cause it is cheap.</div></div></div></blockquote><div></div><br></span>Even=
 if, for some unfathomable reason, want to differentiate between fast funct=
ion calls and slow ones, the speed of a function call is unrelated to the n=
umber of arguments it takes (generally speaking). Yet, your property syntax=
 <i>requires</i> that getters take no parameters, and that setters take onl=
y one.<br><br>If I have a cheap function that needs a parameter and returns=
 a value, I can&#39;t use property syntax to express that it&#39;s cheap. S=
o properties are incapable of reasonably expressing the difference you want=
 them to.<br><br>Not to mention, one of your arguments for properties befor=
e was that you could easily shift between direct member access and accessor=
 functions that do actual work. Well, &quot;actual work&quot; doesn&#39;t h=
ave to be fast, and in many cases it&#39;s not. Boundary checking may be O(=
1), but that doesn&#39;t mean it&#39;s as fast as not having boundary check=
ing. So in doing so, you&#39;ve shifted from &quot;cheap&quot; to &quot;not=
-as-cheap&quot;.<br><br>By your own reasoning, you <i>should</i> make that =
an explicit function call now, since it&#39;s not as cheap as it used to be=
..<div><div><br>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3f3104b6167051e37882f--

.

------=_Part_172_772754658.1440599680970
Content-Type: multipart/alternative;
 boundary="----=_Part_173_1561415434.1440599680971"

------=_Part_173_1561415434.1440599680971
Content-Type: text/plain; charset=UTF-8

Not easier to type & read. Only to type.
And it doesn't allow for more than one argument which in my opinion (and
experience) is simply too restrictive to be accepted.
And let me tell you something, languages like C# and other have that
simplification for one reason only - they are simple languages for *Joe
Average* users. They cannot be more complicated as they are now because
those dudes would not be able to use them. That's why those languages are
simple. They have target audience which is Joe Average and that all they
are *the average language*.
I love C++ not because I can program in it/use it, but because it allows me
to be as expressive and flexible as I want it to be. That cannot be said
about C# and other *languages for Joe Average*. They are simple and there
is a reason for it. Let's not dumbify C++.

On Wednesday, 26 August 2015 14:52:42 UTC+1, Adam Strzelecki wrote:
>
> > player.health += 10
> >
> > My opinion based on my very recent experience? Couldn't hate it more.
> Yes, hate it. Why? Because there is simply no checking if players' health
> will get more than player_max_health_. So why did I do used this notation
> you've asked, why didn't I use the safer notation instead?
> > Mostly I did use the safer syntax, but being human and with everything
> what goes with it, plus time constraints and pressures, sometimes I've used
> that *unsafe* syntax for one reason only, it is simply faster to write it.
> And I regret this fact, because I could never be sure if somewhere this
> code *because of this syntax which breaks encapsulation* is broken.
>
> You see. You've chosen something because it is easier to type and easier
> to read. And this is the main argument for having properties given in this
> discussion - to have clean readable code.
>
> If you had them you would just add player_max_health_ check to the
> property setter and everything would work.
>
> > Your way makes that impossible. Or at least, not without a boatload of
> false positives to sift through. And I certainly don't want to stick a
> breakpoint in the `health()` function, or in the proxy object returned by
> it or whatever, or a memory breakpoint in the entity's actual health.
>
> Wait what? I didn't propose that. See my original post about [[property]]
> or operator.property. The "proxy thing" was my response to Edward saying
> that yes we can achieve sthing with today's C++, but something that's ugly.
>
> > Whereas if you simply had `player.addHealth(10)`, that's something you
> can search for.
>
> Honestly I don't see any benefit of not adding the check to setter there
> and having separate addHealth.
>
> > A lot of the pro-properties side tends to operate under the assumption
> that all, or even mostaccessors were of the form "get variable, set
> variable."
>
> Did you see the proposition of having fine grained control on properties
> using operator.<prop><op>? If you want to have complete control on what you
> are adding to property you can have operator.health+= in your Player class.
>
>         class Player {
>           ...
>           void operator.health+=(int v) { ... }
>
>
> > If you're relying on using `()` to differentiate between "cheap" and
> "expensive", then you've been wrong for years now. We should not encourage
> such thinking. Indeed, we've been trying to convince people that function
> calls are not a priori slow for years, and we're finally making some
> headway.
>
> Hey it is not me who is relying on `()`. Please scroll back.
>
> > Not to mention, one of your arguments for properties before was that you
> could easily shift between direct member access and accessor functions that
> do actual work. Well, "actual work" doesn't have to be fast, and in many
> cases it's not. Boundary checking may be O(1), but that doesn't mean it's
> as fast as not having boundary checking. So in doing so, you've shifted
> from "cheap" to "not-as-cheap".
>
> So? You said above relying on `()` has no use (I agree with that), but now
> you criticize ability to shift between direct member access and accessor
> functions without breaking API. It looks like you are trying to reflect any
> argument given.
>
> Like I said properties gives you some possibilities, but at the end you
> are to choose whether you break an API but prefer `()` there or not.
>
> > By your own reasoning, you should make that an explicit function call
> now, since it's not as cheap as it used to be.
>
> Having properties does not remove ability to do so.
>
> --
> Adam

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Not easier to type &amp; read. Only to type.<br>And it doe=
sn&#39;t allow for more than one argument which in my opinion (and experien=
ce) is simply too restrictive to be accepted.<br>And let me tell you someth=
ing, languages like C# and other have that simplification for one reason on=
ly - they are simple languages for *Joe Average* users. They cannot be more=
 complicated as they are now because those dudes would not be able to use t=
hem. That&#39;s why those languages are simple. They have target audience w=
hich is Joe Average and that all they are *the average language*. <br>I lov=
e C++ not because I can program in it/use it, but because it allows me to b=
e as expressive and flexible as I want it to be. That cannot be said about =
C# and other *languages for Joe Average*. They are simple and there is a re=
ason for it. Let&#39;s not dumbify C++. <br><br>On Wednesday, 26 August 201=
5 14:52:42 UTC+1, Adam Strzelecki  wrote:<blockquote class=3D"gmail_quote" =
style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-l=
eft: 1ex;">&gt; player.health +=3D 10
<br>&gt;=20
<br>&gt; My opinion based on my very recent experience? Couldn&#39;t hate i=
t more. Yes, hate it. Why? Because there is simply no checking if players&#=
39; health will get more than player_max_health_. So why did I do used this=
 notation you&#39;ve asked, why didn&#39;t I use the safer notation instead=
?=20
<br>&gt; Mostly I did use the safer syntax, but being human and with everyt=
hing what goes with it, plus time constraints and pressures, sometimes I&#3=
9;ve used that *unsafe* syntax for one reason only, it is simply faster to =
write it. And I regret this fact, because I could never be sure if somewher=
e this code *because of this syntax which breaks encapsulation* is broken.
<br>
<br>You see. You&#39;ve chosen something because it is easier to type and e=
asier to read. And this is the main argument for having properties given in=
 this discussion - to have clean readable code.
<br>
<br>If you had them you would just add player_max_health_ check to the prop=
erty setter and everything would work.
<br>
<br>&gt; Your way makes that impossible. Or at least, not without a boatloa=
d of false positives to sift through. And I certainly don&#39;t want to sti=
ck a breakpoint in the `health()` function, or in the proxy object returned=
 by it or whatever, or a memory breakpoint in the entity&#39;s actual healt=
h.
<br>
<br>Wait what? I didn&#39;t propose that. See my original post about [[prop=
erty]] or operator.property. The &quot;proxy thing&quot; was my response to=
 Edward saying that yes we can achieve sthing with today&#39;s C++, but som=
ething that&#39;s ugly.
<br>
<br>&gt; Whereas if you simply had `player.addHealth(10)`, that&#39;s somet=
hing you can search for.
<br>
<br>Honestly I don&#39;t see any benefit of not adding the check to setter =
there and having separate addHealth.
<br>
<br>&gt; A lot of the pro-properties side tends to operate under the assump=
tion that all, or even mostaccessors were of the form &quot;get variable, s=
et variable.&quot;
<br>
<br>Did you see the proposition of having fine grained control on propertie=
s using operator.&lt;prop&gt;&lt;op&gt;? If you want to have complete contr=
ol on what you are adding to property you can have operator.health+=3D in y=
our Player class.
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0class Player {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0...
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0void operator.he=
alth+=3D(int v) { ... }
<br>
<br>
<br>&gt; If you&#39;re relying on using `()` to differentiate between &quot=
;cheap&quot; and &quot;expensive&quot;, then you&#39;ve been wrong for year=
s now. We should not encourage such thinking. Indeed, we&#39;ve been trying=
 to convince people that function calls are not a priori slow for years, an=
d we&#39;re finally making some headway.
<br>
<br>Hey it is not me who is relying on `()`. Please scroll back.
<br>
<br>&gt; Not to mention, one of your arguments for properties before was th=
at you could easily shift between direct member access and accessor functio=
ns that do actual work. Well, &quot;actual work&quot; doesn&#39;t have to b=
e fast, and in many cases it&#39;s not. Boundary checking may be O(1), but =
that doesn&#39;t mean it&#39;s as fast as not having boundary checking. So =
in doing so, you&#39;ve shifted from &quot;cheap&quot; to &quot;not-as-chea=
p&quot;.
<br>
<br>So? You said above relying on `()` has no use (I agree with that), but =
now you criticize ability to shift between direct member access and accesso=
r functions without breaking API. It looks like you are trying to reflect a=
ny argument given.
<br>
<br>Like I said properties gives you some possibilities, but at the end you=
 are to choose whether you break an API but prefer `()` there or not.
<br>
<br>&gt; By your own reasoning, you should make that an explicit function c=
all now, since it&#39;s not as cheap as it used to be.
<br>
<br>Having properties does not remove ability to do so.
<br>
<br>--=20
<br>Adam</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_173_1561415434.1440599680971--
------=_Part_172_772754658.1440599680970--

.

------=_Part_3668_1930111002.1440599850802
Content-Type: multipart/alternative;
 boundary="----=_Part_3669_141547109.1440599850803"

------=_Part_3669_141547109.1440599850803
Content-Type: text/plain; charset=UTF-8

And you are either simplifying it so it does not reflect production code or
you simply have very poor style of coding.
Normally that dog example would/should be:
GetDog().run(10_miles); <<== What is wrong with that?

I don't want to hear about some dumb properties because some dumb languages
for simpletons like C# and c.o. have it. Let them have it but don't bring
that trash to C++.

On Wednesday, 26 August 2015 15:19:04 UTC+1, Tom Joe wrote:
>
> Also like to add;  What could possibly be more important than clarity in
> programming?
>
> Being that C++ is Object-Oriented it should have some means of passing
> objects that are distinct (ie: clear) from a method.
>
> Could you imagine;
> GetDog().GetLeg().GetFoot().Run(10-Miles); vs
> Dog.Leg.Foot.Run(10);
>
> If we use overloading what does this mean?
> Dog().Leg(30).Foot().Run(10);
>
> Properties add code architecture clarity.
> Dog.Leg.Size = 30; <- Size is an "Adjective" describing a noun (ie: object)
> Dog.Leg.Foot.Run(10); <-Run we know is a Method "Adverb" describing an
> Action
>
> The () symbol makes it clear the intended architecture is a method - verb.
>
> On Wed, Aug 26, 2015 at 7:46 AM, Tom Joe <tgi...@gmail.com <javascript:>>
> wrote:
>
>> I'd like to add some thoughts getting back onto the subject.  I think
>> Nicol really hit the nail on the head with;
>>
>>  "A lot of the pro-properties side tends to operate under the assumption
>> that all, or even *most* accessors were of the form "get variable, set
>> variable."
>> Generally speaking, that's not how it usually works. Or at least, not in
>> my experience.
>>
>>
>> I think the idea behind a property would be the restriction of
>> multi-arguments to a single-argument passing.  Properties seem to play a
>> vital role in determining a setting from a method while also providing
>> other unique features like code separation that would allow limits inside
>> the property code.
>>
>> Whereas you can use overloading for "player.health()" to get and
>> "player.health(10)" to set it nullifies the use of full-on optional
>> arguments that could be used.
>> Properties distinguish a ONE-ARG setting from a typical method.
>>
>> With properties
>> "player.health" is ALWAYS a get - their cannot be an option argument for
>> setting it (for example; by accident "optional arg=0" thus resetting the
>> setting when called.)
>> "player.health = 1" is always a set.
>>
>> they're limited to a single value setting and as such are distinct from
>> methods.
>>
>> Thoughts?
>>
>>
>>
>> On Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <jmck...@gmail.com
>> <javascript:>> wrote:
>>
>>> On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Adam Strzelecki wrote:
>>>>
>>>> Adam - would your users be satisfied with player.health() += 10?
>>>> Because that's feasible already, perhaps with some library support.
>>>>
>>>> Yeah I know, returning temporary proxy object carrying pointer to the
>>>> `player` and having `operator=` calling accessor on `player`. This is super
>>>> ugly solution that would make debugging really ugly too (seeing the whole
>>>> proxy thing in the stack trace).
>>>>
>>>> My concern is having uniform API for properties, either they are
>>>> dynamic or direct member access. I don't really want to bother with
>>>> implementation details when writing client code, I don't really want to
>>>> wonder whether I need to add () or not because it is dynamic property or
>>>> normal member.
>>>>
>>>> I can see the biggest gripe on properties is the removal of () which is
>>>> an indication whether something gets called or is just pure memory access.
>>>>
>>>
>>> No, that's *a* gripe. It's simply the one being focused on in this
>>> discussion. There are other reasons not to have properties.
>>>
>>> Let's take your health example. I would never use even `player.health()
>>> += 10`, let alone the property syntax. Why?
>>>
>>> Because you can't search for it.
>>>
>>> Changing the health of an entity is rather special, not something you
>>> ought to be doing with any entity pointer/reference you happen to have.
>>> It's really important, if there's a bug causing an entity's health to be
>>> increased incorrectly, that I be able to search for every place where
>>> health is being increased.
>>>
>>> Your way makes that impossible. Or at least, not without a boatload of
>>> false positives to sift through. And I certainly don't want to stick a
>>> breakpoint in the `health()` function, or in the proxy object returned by
>>> it or whatever, or a memory breakpoint in the entity's actual health.
>>>
>>> Whereas if you simply had `player.addHealth(10)`, that's something you
>>> can search for.
>>>
>>> A lot of the pro-properties side tends to operate under the assumption
>>> that all, or even *most* accessors were of the form "get variable, set
>>> variable."
>>>
>>> Generally speaking, that's not how it usually works. Or at least, not in
>>> my experience.
>>>
>>> Oh, it sometimes is. But encapsulation usually requires more control
>>> over how the internal property changes. A name could be decomposed into a
>>> first name and last name. Or a first/last/middle. Or whatever. And while
>>> you might at first want a simple "set_name" function, odds are good that
>>> what you really want are "set_surname", "set_givenname", and
>>> "set_middlename". If you want to set the whole name, you need some
>>> information about the ordering of the names from the user. Since that
>>> requires two input parameters, it couldn't be a property.
>>>
>>> The property style interface works OK only in the *simplest* of cases.
>>> Do we really need syntax for simple stuff? It seems to me that we need the
>>> most syntax for complex things, not trivial accessors.
>>>
>>> But many APIs don't have public members at all in their classes, so you
>>>> have to use () everywhere anyway, so everything looks "expensive".
>>>>
>>>
>>> If you're relying on using `()` to differentiate between "cheap" and
>>> "expensive", then you've been wrong for years now. We should not encourage
>>> such thinking. Indeed, we've been trying to convince people that function
>>> calls are not a priori slow for years, and we're finally making some
>>> headway.
>>>
>>> Why turn back the clock on that progress?
>>>
>>>
>>>> Moreover properties give you power to express that something is in fact
>>>> cheap, as opposite to () indicating something may be expensive. For example
>>>> begin() end() iterators in many cases are O(1), so they can be easily
>>>> perceived as properties. Similar is std::string::length(), since it knows
>>>> its length, then length can be property as it is just a memory access to
>>>> some private variable, so str.length (w/o ()) looks cheap because it is
>>>> cheap.
>>>>
>>>
>>> Even if, for some unfathomable reason, want to differentiate between
>>> fast function calls and slow ones, the speed of a function call is
>>> unrelated to the number of arguments it takes (generally speaking). Yet,
>>> your property syntax *requires* that getters take no parameters, and
>>> that setters take only one.
>>>
>>> If I have a cheap function that needs a parameter and returns a value, I
>>> can't use property syntax to express that it's cheap. So properties are
>>> incapable of reasonably expressing the difference you want them to.
>>>
>>> Not to mention, one of your arguments for properties before was that you
>>> could easily shift between direct member access and accessor functions that
>>> do actual work. Well, "actual work" doesn't have to be fast, and in many
>>> cases it's not. Boundary checking may be O(1), but that doesn't mean it's
>>> as fast as not having boundary checking. So in doing so, you've shifted
>>> from "cheap" to "not-as-cheap".
>>>
>>> By your own reasoning, you *should* make that an explicit function call
>>> now, since it's not as cheap as it used to be.
>>>
>>> --
>>>
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "ISO C++ Standard - Future Proposals" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>>> .
>>> To unsubscribe from this group and all its topics, send an email to
>>> std-proposal...@isocpp.org <javascript:>.
>>> To post to this group, send email to std-pr...@isocpp.org <javascript:>.
>>> Visit this group at
>>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>>
>>
>>
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">And you are either simplifying it so it does not reflect p=
roduction code or you simply have very poor style of coding.<br>Normally th=
at dog example would/should be:<br>GetDog().run(10_miles); &lt;&lt;=3D=3D W=
hat is wrong with that?<br><br>I don&#39;t want to hear about some dumb pro=
perties because some dumb languages for simpletons like C# and c.o. have it=
.. Let them have it but don&#39;t bring that trash to C++.<br><br>On Wednesd=
ay, 26 August 2015 15:19:04 UTC+1, Tom Joe  wrote:<blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div><div><div><div><div><div><div><di=
v><div><div>Also like to add;=C2=A0 What could possibly be more important t=
han clarity in programming?<br><br></div>Being that C++ is Object-Oriented =
it should have some means of passing objects that are distinct (ie: clear) =
from a method.<br></div><br>Could you imagine;<br></div>GetDog().GetLeg().G=
etFoot().<wbr>Run(10-Miles); vs<br></div>Dog.Leg.Foot.Run(10);<br><br></div=
>If we use overloading what does this mean?<br></div>Dog().Leg(30).Foot().R=
un(10);<br><br></div>Properties add code architecture clarity.<br></div>Dog=
..Leg.Size =3D 30; &lt;- Size is an &quot;Adjective&quot; describing a noun =
(ie: object)<br></div>Dog.Leg.Foot.Run(10); &lt;-Run we know is a Method &q=
uot;Adverb&quot; describing an Action<br><br></div>The () symbol makes it c=
lear the intended architecture is a method - verb.<br></div><div><br><div c=
lass=3D"gmail_quote">On Wed, Aug 26, 2015 at 7:46 AM, Tom Joe <span dir=3D"=
ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D=
"604x52lYBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:=
&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;">tgi...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><div dir=3D"ltr"><div><div><div><div><div><div><div>I&#39;d like to add s=
ome thoughts getting back onto the subject.=C2=A0 I think Nicol really hit =
the nail on the head with;<span><br><br>=C2=A0&quot;A lot of the pro-proper=
ties side tends to operate under the assumption that all, or even <i>most</=
i> accessors were of the form &quot;get variable, set variable.&quot;<br>Ge=
nerally speaking, that&#39;s not how it usually works. Or at least, not in =
my experience.<br><br><br></span></div>I think the idea behind a property w=
ould be the restriction of multi-arguments to a single-argument passing.=C2=
=A0 Properties seem to play a vital role in determining a setting from a me=
thod while also providing other unique features like code separation that w=
ould allow limits inside the property code.<br><br></div>Whereas you can us=
e overloading for &quot;player.health()&quot; to get and &quot;player.healt=
h(10)&quot; to set it nullifies the use of full-on optional arguments that =
could be used.<br></div>Properties distinguish a ONE-ARG setting from a typ=
ical method.<br><br></div><div>With properties<br></div>&quot;player.health=
&quot; is ALWAYS a get - their cannot be an option argument for setting it =
(for example; by accident &quot;optional arg=3D0&quot; thus resetting the s=
etting when called.)<br></div>&quot;player.health =3D 1&quot; is always a s=
et.<br><br></div>they&#39;re limited to a single value setting and as such =
are distinct from methods.<br><br></div>Thoughts?<br><div><div><br><div><di=
v><div><div><br></div></div></div></div></div></div></div><div><div><div><b=
r><div class=3D"gmail_quote">On Wed, Aug 26, 2015 at 7:14 AM, Nicol Bolas <=
span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscat=
ed-mailto=3D"604x52lYBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39=
;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39=
;;return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><span>On Wednesday, August 26, 2015 at 3:52:45 AM UTC-4, Ada=
m Strzelecki wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;marg=
in-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word"><div><blockquote type=3D"cite"><div><p dir=3D"ltr">Adam=
 - would your users be satisfied with player.health() +=3D 10? Because that=
&#39;s feasible already, perhaps with some library support. </p></div></blo=
ckquote><div>Yeah I know, returning temporary proxy object carrying pointer=
 to the `player` and having `operator=3D` calling accessor on `player`. Thi=
s is super ugly solution that would make debugging really ugly too (seeing =
the whole proxy thing in the stack trace).</div><div><br></div><div>My conc=
ern is having uniform API for properties, either they are dynamic or direct=
 member access. I don&#39;t really want to bother with implementation detai=
ls when writing client code, I don&#39;t really want to wonder whether I ne=
ed to add () or not because it is dynamic property or normal member.</div><=
div><br></div><div>I can see the biggest gripe on properties is the removal=
 of () which is an indication whether something gets called or is just pure=
 memory access.</div></div></div></blockquote></span><div><br>No, that&#39;=
s <i>a</i> gripe. It&#39;s simply the one being focused on in this discussi=
on. There are other reasons not to have properties.<br><br>Let&#39;s take y=
our health example. I would never use even `player.health() +=3D 10`, let a=
lone the property syntax. Why?<br><br>Because you can&#39;t search for it.<=
br><br>Changing the health of an entity is rather special, not something yo=
u ought to be doing with any entity pointer/reference you happen to have. I=
t&#39;s really important, if there&#39;s a bug causing an entity&#39;s heal=
th to be increased incorrectly, that I be able to search for every place wh=
ere health is being increased.<br><br>Your way makes that impossible. Or at=
 least, not without a boatload of false positives to sift through. And I ce=
rtainly don&#39;t want to stick a breakpoint in the `health()` function, or=
 in the proxy object returned by it or whatever, or a memory breakpoint in =
the entity&#39;s actual health.<br><br>Whereas if you simply had `player.ad=
dHealth(10)`, that&#39;s something you can search for.<br><br>A lot of the =
pro-properties side tends to operate under the assumption that all, or even=
 <i>most</i> accessors were of the form &quot;get variable, set variable.&q=
uot;<br><br>Generally speaking, that&#39;s not how it usually works. Or at =
least, not in my experience.<br><br>Oh, it sometimes is. But encapsulation =
usually requires more control over how the internal property changes. A nam=
e could be decomposed into a first name and last name. Or a first/last/midd=
le. Or whatever. And while you might at first want a simple &quot;set_name&=
quot; function, odds are good that what you really want are &quot;set_surna=
me&quot;, &quot;set_givenname&quot;, and &quot;set_middlename&quot;. If you=
 want to set the whole name, you need some information about the ordering o=
f the names from the user. Since that requires two input parameters, it cou=
ldn&#39;t be a property.<br><br>The property style interface works OK only =
in the <i>simplest</i> of cases. Do we really need syntax for simple stuff?=
 It seems to me that we need the most syntax for complex things, not trivia=
l accessors.<br><br></div><span><blockquote class=3D"gmail_quote" style=3D"=
margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v style=3D"word-wrap:break-word"><div><div>But many APIs don&#39;t have pub=
lic members at all in their classes, so you have to use () everywhere anywa=
y, so everything looks &quot;expensive&quot;.</div></div></div></blockquote=
></span><div><br>If you&#39;re relying on using `()` to differentiate betwe=
en &quot;cheap&quot; and &quot;expensive&quot;, then you&#39;ve been wrong =
for years now. We should not encourage such thinking. Indeed, we&#39;ve bee=
n trying to convince people that function calls are not a priori slow for y=
ears, and we&#39;re finally making some headway.<br><br>Why turn back the c=
lock on that progress?<br>=C2=A0</div><span><blockquote class=3D"gmail_quot=
e" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-l=
eft:1ex"><div style=3D"word-wrap:break-word"><div><div></div><div>Moreover =
properties give you power to express that something is in fact cheap, as op=
posite to () indicating something may be expensive. For example begin() end=
() iterators in many cases are O(1), so they can be easily perceived as pro=
perties. Similar is std::string::length(), since it knows its length, then =
length can be property as it is just a memory access to some private variab=
le, so str.length (w/o ()) looks cheap because it is cheap.</div></div></di=
v></blockquote><div></div><br></span>Even if, for some unfathomable reason,=
 want to differentiate between fast function calls and slow ones, the speed=
 of a function call is unrelated to the number of arguments it takes (gener=
ally speaking). Yet, your property syntax <i>requires</i> that getters take=
 no parameters, and that setters take only one.<br><br>If I have a cheap fu=
nction that needs a parameter and returns a value, I can&#39;t use property=
 syntax to express that it&#39;s cheap. So properties are incapable of reas=
onably expressing the difference you want them to.<br><br>Not to mention, o=
ne of your arguments for properties before was that you could easily shift =
between direct member access and accessor functions that do actual work. We=
ll, &quot;actual work&quot; doesn&#39;t have to be fast, and in many cases =
it&#39;s not. Boundary checking may be O(1), but that doesn&#39;t mean it&#=
39;s as fast as not having boundary checking. So in doing so, you&#39;ve sh=
ifted from &quot;cheap&quot; to &quot;not-as-cheap&quot;.<br><br>By your ow=
n reasoning, you <i>should</i> make that an explicit function call now, sin=
ce it&#39;s not as cheap as it used to be.<div><div><br>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://groups.google.c=
om/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe&#39;;return t=
rue;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/isocpp.org/d/=
topic/std-proposals/n0QcD_K5dBY/unsubscribe&#39;;return true;">https://grou=
ps.google.com/a/<wbr>isocpp.org/d/topic/std-<wbr>proposals/n0QcD_K5dBY/<wbr=
>unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"604x52lYBgAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">std-proposal=
....@<wbr>isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"604x52lYBgAJ" rel=3D"nofollow" onmousedown=3D"=
this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39=
;javascript:&#39;;return true;">std-pr...@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;http://groups.google.com/a/isocpp.org/group/std-proposals/&#39;;ret=
urn true;" onclick=3D"this.href=3D&#39;http://groups.google.com/a/isocpp.or=
g/group/std-proposals/&#39;;return true;">http://groups.google.com/a/<wbr>i=
socpp.org/group/std-<wbr>proposals/</a>.<br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3669_141547109.1440599850803--
------=_Part_3668_1930111002.1440599850802--

.

--001a11c340142dc45a051e38099d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

=E2=80=8BI'm not convinced by most examples so far. In my experience, the o=
nly
general case properties becomes interesting is when
you need an interface which match the way a domain-specific notation works
but still want the liberty to change and optimize the implementation.
Typically, in basic geometry, if we have something like this:

struct Point
{
   float x =3D 0.f;
   float y =3D 0.f;
};

We can write:

    auto z =3D (a.x * (b.y - c.y)) + (b.x * (c.y - a.y)) + (c.x * (a.y -
b.y)); // A

But as soon as we want to keep the interface of Point while making it a
Structure Of Array for
some usage-specifc performance reasons, we need to protect the user from
these "details"
by using functions instead of direct member usage (which imply isolating
the user from memory layout):

    auto z =3D (a.x() * (b.y() - c.y()) + (b.x() * (c.y() - a.y())) + (c.x(=
)
* (a.y() - b.y()))); // B

Basically we end up with syntactic noise.
This is supportable but still increase the chances of bugs being hidden in
the forest of parenthesis.
One way to make this possible without the functions calls would be to
replace the float type by something
more complex, which might lead to code bloat (compared to just making an
accessor function) and potentially make Point bigger than necessary.

So basically, to me it's more about noise in domain specific expressions.

I'm not sure if that example of "problem" to solve is useful to identify if
properties would be interesting or not.

In my opinion, having a way to ignore if accessing an object imply a
function call or not is necessary if we want a language that 100% isolate
user
from memory layout when the library designer decides that it is necessary
for the library.
All arguments about clarity of difference between direct access and
function call looks a lot like arguments against virtual calls.
Though it can be easily overused and abused, it's still very useful.

I can work without properties, but I do sometime wonder if some parts of my
types would be easier to deal with with such interface simplifications.

My 2cents.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c340142dc45a051e38099d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br>=E2=80=8BI&#39;m not convinced by most examples so far=
.. In my experience, the only general case properties becomes interesting is=
 when=C2=A0<div>you need an interface which match the way a domain-specific=
 notation works but still want the liberty to change and optimize the imple=
mentation.</div><div>Typically, in basic geometry, if we have something lik=
e this:</div><div><br></div><div>struct Point</div><div>{</div><div>=C2=A0 =
=C2=A0float x =3D 0.f;</div><div>=C2=A0 =C2=A0float y =3D 0.f;</div><div>};=
</div><div><br></div><div>We can write:</div><div><br></div><div>=C2=A0 =C2=
=A0 auto z =3D (a.x * (b.y - c.y)) + (b.x * (c.y - a.y)) + (c.x * (a.y - b.=
y)); // A<br></div><div><br></div><div>But as soon as we want to keep the i=
nterface of Point while making it a Structure Of Array for=C2=A0</div><div>=
some usage-specifc performance reasons, we need to protect the user from th=
ese &quot;details&quot;</div><div>by using functions instead of direct memb=
er usage (which imply isolating the user from memory layout):</div><div><br=
></div><div><div>=C2=A0 =C2=A0 auto z =3D (a.x() * (b.y() - c.y()) + (b.x()=
 * (c.y() - a.y())) + (c.x() * (a.y() - b.y()))); // B<br></div></div><div>=
<br></div><div>Basically we end up with syntactic noise.</div><div>This is =
supportable but still increase the chances of bugs being hidden in the fore=
st of parenthesis.</div><div>One way to make this possible without the func=
tions calls would be to replace the float type by something</div><div>more =
complex, which might lead to code bloat (compared to just making an accesso=
r function) and potentially make Point bigger than necessary.</div><div><br=
></div><div>So basically, to me it&#39;s more about noise in domain specifi=
c expressions.</div><div><br></div><div>I&#39;m not sure if that example of=
 &quot;problem&quot; to solve is useful to identify if properties would be =
interesting or not.</div><div><br></div><div>In my opinion, having a way to=
 ignore if accessing an object imply a function call or not is necessary if=
 we want a language that 100% isolate user</div><div>from memory layout whe=
n the library designer decides that it is necessary for the library.</div><=
div>All arguments about clarity of difference between direct access and fun=
ction call looks a lot like arguments against virtual calls.</div><div>Thou=
gh it can be easily overused and abused, it&#39;s still very useful.</div><=
div><br></div><div>I can work without properties, but I do sometime wonder =
if some parts of my types would be easier to deal with with such interface =
simplifications.</div><div><br></div><div>My 2cents.</div><div><br></div><d=
iv><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c340142dc45a051e38099d--

.

--001a11c3f386e97b6b051e380db1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 26 August 2015 at 16:55, Klaim - Jo=C3=ABl Lamotte <mjklaim@gmail.com> w=
rote:

>
> I can work without properties, but I do sometime wonder if some parts of
> my types would be easier to deal with with such interface simplifications=
..
>
> My 2cents.
>

Oh I just forgot to add: did you spot the issue in B? :)

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a11c3f386e97b6b051e380db1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 26 August 2015 at 16:55, Klaim - Jo=C3=ABl Lamotte <span dir=3D"ltr">&lt=
;<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim@gmail.com</=
a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0=
 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>=
I can work without properties, but I do sometime wonder if some parts of my=
 types would be easier to deal with with such interface simplifications.</d=
iv><div><br></div><div>My 2cents.</div></blockquote></div><br>Oh I just for=
got to add: did you spot the issue in B? :)</div><div class=3D"gmail_extra"=
><br></div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c3f386e97b6b051e380db1--

.

------=_Part_607_714772373.1440601690613
Content-Type: multipart/alternative;
 boundary="----=_Part_608_1011457790.1440601690614"

------=_Part_608_1011457790.1440601690614
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 26, 2015 at 9:52:42 AM UTC-4, Adam Strzelecki wrote:
>
> > Whereas if you simply had `player.addHealth(10)`, that's something you
> can search for.
>
> Honestly I don't see any benefit of not adding the check to setter there
> and having separate addHealth.
>

You mean besides the fact that you're making it clear that `addHealth` can
only *add* health, rather than remove it or set it? Because that sounds
like a pretty good benefit if you don't want people to be able to remove or
set health. Or if you want people to do that, then they have to use a
different function for it.

Your way puts adding, removing, and setting all in the same property.

If you cannot see the benefits of either being able to search for where
health is being added, or of being able to separate the operations that
change health, then we can't effectively have a debate. You may not see
these benefits as being significant, but that they exist should not be a
question.


>
> > A lot of the pro-properties side tends to operate under the assumption
> that all, or even mostaccessors were of the form "get variable, set
> variable."
>
> Did you see the proposition of having fine grained control on properties
> using operator.<prop><op>? If you want to have complete control on what you
> are adding to property you can have operator.health+= in your Player class.
>
>         class Player {
>           ...
>           void operator.health+=(int v) { ... }
>
>
.... how is that any more searchable than `player.health()`? That's my
point; *any* form of this is unqueryable.


>
> > If you're relying on using `()` to differentiate between "cheap" and
> "expensive", then you've been wrong for years now. We should not encourage
> such thinking. Indeed, we've been trying to convince people that function
> calls are not a priori slow for years, and we're finally making some
> headway.
>
> Hey it is not me who is relying on `()`. Please scroll back.
>

But you were arguing in favor of it.


>
> > Not to mention, one of your arguments for properties before was that you
> could easily shift between direct member access and accessor functions that
> do actual work. Well, "actual work" doesn't have to be fast, and in many
> cases it's not. Boundary checking may be O(1), but that doesn't mean it's
> as fast as not having boundary checking. So in doing so, you've shifted
> from "cheap" to "not-as-cheap".
>
> So? You said above relying on `()` has no use (I agree with that), but now
> you criticize ability to shift between direct member access and accessor
> functions without breaking API. It looks like you are trying to reflect any
> argument given.
>

No, my point here was to say that, if your goal is to use `()` to
differentiate between "slow" and "fast" operations, properties fails to
achieve that. This is because the whole point of properties is to turn a
member access into a function call. A function call that will at best be no
faster than a member access, and may well be slower depending on how it's
implemented.

So you don't achieve the stated goal.

I already proved that shifting "between direct member access and accessor
functions without breaking API" *is not possible*. You didn't respond to
it, so I assumed you accepted it.


>
> Like I said properties gives you some possibilities, but at the end you
> are to choose whether you break an API but prefer `()` there or not.
>
> > By your own reasoning, you should make that an explicit function call
> now, since it's not as cheap as it used to be.
>
> Having properties does not remove ability to do so.


No, it just makes it easier to do the wrong thing, thereby making your API
lie to the user about what's fast and slow.

Again, this is under the presumption that we even want `()` to mean
"slow"`, while pure member access means "fast". I don't agree with that,
but that is something you keep talking about wanting properties to help
differentiate between.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, August 26, 2015 at 9:52:42 AM UTC-4,=
 Adam Strzelecki wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; Wh=
ereas if you simply had `player.addHealth(10)`, that&#39;s something you ca=
n search for.
<br>
<br>Honestly I don&#39;t see any benefit of not adding the check to setter =
there and having separate addHealth.<br></blockquote><div><br>You mean besi=
des the fact that you&#39;re making it clear that `addHealth` can only <i>a=
dd</i> health, rather than remove it or set it? Because that sounds like a =
pretty good benefit if you don&#39;t want people to be able to remove or se=
t health. Or if you want people to do that, then they have to use a differe=
nt function for it.<br><br>Your way puts adding, removing, and setting all =
in the same property.<br><br>If you cannot see the benefits of either being=
 able to search for where health is being added, or of being able to separa=
te the operations that change health, then we can&#39;t effectively have a =
debate. You may not see these benefits as being significant, but that they =
exist should not be a question.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>&gt; A lot of the pro-properties side tends to operate under the assump=
tion that all, or even mostaccessors were of the form &quot;get variable, s=
et variable.&quot;
<br>
<br>Did you see the proposition of having fine grained control on propertie=
s using operator.&lt;prop&gt;&lt;op&gt;? If you want to have complete contr=
ol on what you are adding to property you can have operator.health+=3D in y=
our Player class.
<br>
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0class Player {
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0...
<br>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0void operator.he=
alth+=3D(int v) { ... }
<br>
<br></blockquote><div><br>... how is that any more searchable than `player.=
health()`? That&#39;s my point; <i>any</i> form of this is unqueryable.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; If you&#39;re relying on using `()` to differentiate between &quot=
;cheap&quot; and &quot;expensive&quot;, then you&#39;ve been wrong for year=
s now. We should not encourage such thinking. Indeed, we&#39;ve been trying=
 to convince people that function calls are not a priori slow for years, an=
d we&#39;re finally making some headway.
<br>
<br>Hey it is not me who is relying on `()`. Please scroll back.
<br></blockquote><div><br>But you were arguing in favor of it.<br>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Not to mention, one of your arguments for properties before was th=
at you could easily shift between direct member access and accessor functio=
ns that do actual work. Well, &quot;actual work&quot; doesn&#39;t have to b=
e fast, and in many cases it&#39;s not. Boundary checking may be O(1), but =
that doesn&#39;t mean it&#39;s as fast as not having boundary checking. So =
in doing so, you&#39;ve shifted from &quot;cheap&quot; to &quot;not-as-chea=
p&quot;.
<br>
<br>So? You said above relying on `()` has no use (I agree with that), but =
now you criticize ability to shift between direct member access and accesso=
r functions without breaking API. It looks like you are trying to reflect a=
ny argument given.
<br></blockquote><div><br>No, my point here was to say that, if your goal i=
s to use `()` to differentiate between &quot;slow&quot; and &quot;fast&quot=
; operations, properties fails to achieve that. This is because the whole p=
oint of properties is to turn a member access into a function call. A funct=
ion call that will at best be no faster than a member access, and may well =
be slower depending on how it&#39;s implemented.<br><br>So you don&#39;t ac=
hieve the stated goal.<br><br>I already proved that shifting &quot;between =
direct member access and accessor functions without breaking API&quot; <i><=
b>is not possible</b></i>. You didn&#39;t respond to it, so I assumed you a=
ccepted it.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>Like I said properties gives you some possibilities, but at the end you=
 are to choose whether you break an API but prefer `()` there or not.
<br>
<br>&gt; By your own reasoning, you should make that an explicit function c=
all now, since it&#39;s not as cheap as it used to be.
<br>
<br>Having properties does not remove ability to do so.</blockquote><div><b=
r>No, it just makes it easier to do the wrong thing, thereby making your AP=
I lie to the user about what&#39;s fast and slow.<br><br>Again, this is und=
er the presumption that we even want `()` to mean &quot;slow&quot;`, while =
pure member access means &quot;fast&quot;. I don&#39;t agree with that, but=
 that is something you keep talking about wanting properties to help differ=
entiate between. <br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_608_1011457790.1440601690614--
------=_Part_607_714772373.1440601690613--

.

------=_Part_5182_102858832.1440602190167
Content-Type: multipart/alternative;
 boundary="----=_Part_5183_811204512.1440602190167"

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

On Wednesday, August 26, 2015 at 10:55:06 AM UTC-4, Klaim - Jo=C3=ABl Lamot=
te=20
wrote:
>
>
> =E2=80=8BI'm not convinced by most examples so far. In my experience, the=
 only=20
> general case properties becomes interesting is when=20
> you need an interface which match the way a domain-specific notation work=
s=20
> but still want the liberty to change and optimize the implementation.
>

My concern with this is that it's very special case.

Your example only works because, in the structure-of-array version, there=
=20
remains a 1:1 correspondence between the data. That is, every Point still=
=20
has one float for x and one float for y. They may be stored elsewhere, and=
=20
in a different way, but they still exist and use the same underlying data=
=20
type. And therefore, the accessor/property can return an actual reference=
=20
to an actual object of the previous type.

However, any example where the underlying nature of the data changes will=
=20
not work correctly. If you wanted to, for example, pack the two float=20
values into a single 32-bit integer, this wouldn't work. Your getter=20
accessor/property would not be able to return a `float&`, and any code that=
=20
previously expected to be able to get a modifiable reference to the actual=
=20
data will be non-functional.

Therefore, you cannot *transparently* switch from one to the other if your=
=20
implementation optimization changes the data types in question. This limits=
=20
your options to just putting the same data values in a different place.

Is this case truly so common that we need to add language syntax to C++ to=
=20
support it? I'd like to see evidence of that.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Wednesday, August 26, 2015 at 10:55:06 AM UTC-4, Klaim =
- Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margin=
: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div=
 dir=3D"ltr"><br>=E2=80=8BI&#39;m not convinced by most examples so far. In=
 my experience, the only general case properties becomes interesting is whe=
n=C2=A0<div>you need an interface which match the way a domain-specific not=
ation works but still want the liberty to change and optimize the implement=
ation.</div></div></blockquote><div><br>My concern with this is that it&#39=
;s very special case.<br><br>Your example only works because, in the struct=
ure-of-array version, there remains a 1:1 correspondence between the data. =
That is, every Point still has one float for x and one float for y. They ma=
y be stored elsewhere, and in a different way, but they still exist and use=
 the same underlying data type. And therefore, the accessor/property can re=
turn an actual reference to an actual object of the previous type.<br><br>H=
owever, any example where the underlying nature of the data changes will no=
t work correctly. If you wanted to, for example, pack the two float values =
into a single 32-bit integer, this wouldn&#39;t work. Your getter accessor/=
property would not be able to return a `float&amp;`, and any code that prev=
iously expected to be able to get a modifiable reference to the actual data=
 will be non-functional.<br><br>Therefore, you cannot <i>transparently</i> =
switch from one to the other if your implementation optimization changes th=
e data types in question. This limits your options to just putting the same=
 data values in a different place.<br><br>Is this case truly so common that=
 we need to add language syntax to C++ to support it? I&#39;d like to see e=
vidence of that.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5183_811204512.1440602190167--
------=_Part_5182_102858832.1440602190167--

.

On 2015-08-26 09:52, Adam Strzelecki wrote:

> Moreover properties give you power to express that something is in fact
> cheap, as opposite to () indicating something may be expensive. For
> example begin() end() iterators in many cases are O(1), so they can be
> easily perceived as properties. Similar is std::string::length(), since
> it knows its length, then length can be property as it is just a memory
> access to some private variable, so str.length (w/o ()) looks cheap
> because it is cheap.
>

What?!

How is str.length cheaper than str.lenght()? We all know that small
inline functions are dirt cheap. I really don't need a new syntax to
tell me that.

Perhaps we should use str.size() instead. That's shorter, so it must be
cheaper too?


Bo Persson



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 15:46, Tom Joe wrote:
> I'd like to add some thoughts getting back onto the subject.  I think
> Nicol really hit the nail on the head with;
>
>   "A lot of the pro-properties side tends to operate under the
> assumption that all, or even /most/ accessors were of the form "get
> variable, set variable."
> Generally speaking, that's not how it usually works. Or at least, not in
> my experience.
>
>
> I think the idea behind a property would be the restriction of
> multi-arguments to a single-argument passing.  Properties seem to play a
> vital role in determining a setting from a method while also providing
> other unique features like code separation that would allow limits
> inside the property code.
>
> Whereas you can use overloading for "player.health()" to get and
> "player.health(10)" to set it nullifies the use of full-on optional
> arguments that could be used.
> Properties distinguish a ONE-ARG setting from a typical method.
>
> With properties
> "player.health" is ALWAYS a get - their cannot be an option argument for
> setting it (for example; by accident "optional arg=0" thus resetting the
> setting when called.)
> "player.health = 1" is always a set.
>
> they're limited to a single value setting and as such are distinct from
> methods.
>

Are they. So we don't allow members to be structs or tuples or
std::initializer_list?

player.name = {"John", "M", "Doe"};


Bo Persson



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 8/26/2015 5:06 AM, Arthur Tchaikovsky wrote:
> ...I've used language which actually preferred (but not enforced) this notation:
>
> player.health += 10
>
> My opinion based on my very recent experience? Couldn't hate it more.
> Yes, hate it. Why? Because there is simply no checking if players'
> health will get more than player_max_health_.

That's not true at all. One of the main points of properties is that you
*can* define a setter that can perform some operation more complex than
assignment, e.g. clamping a value to a particular maximum.

While I don't have a strong opinion about properties either way, I don't
think it's constructive to argue against strawmen. That won't convince
anyone.

- Jim

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 8/26/2015 9:34 AM, Arthur Tchaikovsky wrote:
> I love C++ not because I can program in it/use it, but because it allows
> me to be as expressive and flexible as I want it to be. That cannot be
> said about C# and other *languages for Joe Average*. They are simple and
> there is a reason for it. Let's not dumbify C++.

Can you elaborate on why adding a feature to allow new ways of
expressing a particular operation *decreases* expressivity or
flexibility? It seems that it would only add to it. That's not to say
that every feature in the world needs to go into C++, but this argument
doesn't seem to hold water.

In fact, if your argument about "Joe Average" programmers holds water (I
don't think it does), then that would actually be an argument *for*
importing C#'s language features into C++: while everyone reading this
list may be a genius-level intellect (at least about C++), I'm sure
we've all worked with C++ programmers who are less-talented. Helping
them out means less work for the geniuses. More to the point, even if
you *are* a genius, you probably want your language to provide helpful
features to reduce your cognitive load so you can focus on interesting
problems.

I'm not convinced that properties are sufficiently-helpful to warrant
standardization, but they wouldn't "dumbify" the language. (Granted, I'm
not 100% sure what you mean by that.)

- Jim

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e011769591cdf5e051e38f830
Content-Type: text/plain; charset=UTF-8

On 26 August 2015 at 17:16, Nicol Bolas <jmckesson@gmail.com> wrote:

>
> Is this case truly so common that we need to add language syntax to C++ to
> support it? I'd like to see evidence of that.


I don't know if it's common in other domains but the issue I point (and I
agree that it's mostly about having access code in-between access to a data)
is pretty common in game/simulation code which is geometry-heavy (also in
easing/tweening code and AI spatial modelisations) where in the end you
often work with raw structs
because the language does not allow the simple access to members to be
potentially changed in SoA which is a common example these days.

So far the few other times I felt that such a feature were similar in that
I just felt that the () noise was not worth in situations where I just have
a function which is basically an accessor to data that I do not want any
user to know how I build, store and retrieve.

Again I'm not for or against the feature, but I can't avoid thinking that
there are reasons why people seem to propose it again and again
but paradoxally it also seems very hard to point exactly what problem it
solves. I can only think of what I just described but I might have forgot
some other cases.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e011769591cdf5e051e38f830
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On 26 August 2015 at 17:16, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"ma=
ilto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</sp=
an> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex"><br>Is this case truly so comm=
on that we need to add language syntax to C++ to support it? I&#39;d like t=
o see evidence of that.</blockquote></div><br>I don&#39;t know if it&#39;s =
common in other domains but the issue I point (and I agree that it&#39;s mo=
stly about having access code in-between access to a data)</div><div class=
=3D"gmail_extra">is pretty common in game/simulation code which is geometry=
-heavy (also in easing/tweening code and AI spatial modelisations) where in=
 the end you often work with raw structs</div><div class=3D"gmail_extra">be=
cause the language does not allow the simple access to members to be potent=
ially changed in SoA which is a common example these days.</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">So far the few other =
times I felt that such a feature were similar in that I just felt that the =
() noise was not worth in situations where I just have<br></div><div class=
=3D"gmail_extra">a function which is basically an accessor to data that I d=
o not want any user to know how I build, store and retrieve.</div><div clas=
s=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Again I&#39;m not fo=
r or against the feature, but I can&#39;t avoid thinking that there are rea=
sons why people seem to propose it again and again</div><div class=3D"gmail=
_extra">but paradoxally it also seems very hard to point exactly what probl=
em it solves. I can only think of what I just described but I might have fo=
rgot some other cases.</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e011769591cdf5e051e38f830--

.

------=_Part_659_944439058.1440605715970
Content-Type: multipart/alternative;
 boundary="----=_Part_660_1452770724.1440605715970"

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

On Wednesday, August 26, 2015 at 12:01:55 PM UTC-4, Klaim - Jo=C3=ABl Lamot=
te=20
wrote:
>
>
> On 26 August 2015 at 17:16, Nicol Bolas <jmck...@gmail.com <javascript:>>=
=20
> wrote:
>
>>
>> Is this case truly so common that we need to add language syntax to C++=
=20
>> to support it? I'd like to see evidence of that.
>
>
> I don't know if it's common in other domains but the issue I point (and I=
=20
> agree that it's mostly about having access code in-between access to a da=
ta)
> is pretty common in game/simulation code which is geometry-heavy (also in=
=20
> easing/tweening code and AI spatial modelisations) where in the end you=
=20
> often work with raw structs
> because the language does not allow the simple access to members to be=20
> potentially changed in SoA which is a common example these days.
>
> So far the few other times I felt that such a feature were similar in tha=
t=20
> I just felt that the () noise was not worth in situations where I just ha=
ve
> a function which is basically an accessor to data that I do not want any=
=20
> user to know how I build, store and retrieve.
>
> Again I'm not for or against the feature, but I can't avoid thinking that=
=20
> there are reasons why people seem to propose it again and again
>

Nobody's arguing that there aren't reasons for the feature. It's a question=
=20
of whether their reasons are genuinely compelling. I can't say that I find=
=20
"D and C# have them" to be particularly compelling. And while the reason=20
you cite is a real reason, I just don't think it's enough of one to add a=
=20
bunch of syntax to the language.

It should also be noted that what you're asking for might be taken care of=
=20
by being able to overload operator., via the Smart Objects proposal=20
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4495.html>. I=20
think that could cover your use case, without having to expose full get/set=
=20
property syntax. I'm not certain, as that proposal relies on a lot of=20
template stuff I don't quite understand, but it seems possible on the face=
=20
of it.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

On Wednesday, August 26, 2015 at 12:01:55 PM UTC-4, Klaim - Jo=C3=ABl Lamot=
te wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: =
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div=
><br><div class=3D"gmail_quote">On 26 August 2015 at 17:16, Nicol Bolas <sp=
an dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated=
-mailto=3D"Kq29ngZeBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;j=
avascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;=
return true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br>Is this case truly so common that we need to add language=
 syntax to C++ to support it? I&#39;d like to see evidence of that.</blockq=
uote></div><br>I don&#39;t know if it&#39;s common in other domains but the=
 issue I point (and I agree that it&#39;s mostly about having access code i=
n-between access to a data)</div><div>is pretty common in game/simulation c=
ode which is geometry-heavy (also in easing/tweening code and AI spatial mo=
delisations) where in the end you often work with raw structs</div><div>bec=
ause the language does not allow the simple access to members to be potenti=
ally changed in SoA which is a common example these days.</div><div><br></d=
iv><div>So far the few other times I felt that such a feature were similar =
in that I just felt that the () noise was not worth in situations where I j=
ust have<br></div><div>a function which is basically an accessor to data th=
at I do not want any user to know how I build, store and retrieve.</div><di=
v><br></div><div>Again I&#39;m not for or against the feature, but I can&#3=
9;t avoid thinking that there are reasons why people seem to propose it aga=
in and again</div></div></blockquote><div><br>Nobody&#39;s arguing that the=
re aren&#39;t reasons for the feature. It&#39;s a question of whether their=
 reasons are genuinely compelling. I can&#39;t say that I find &quot;D and =
C# have them&quot; to be particularly compelling. And while the reason you =
cite is a real reason, I just don&#39;t think it&#39;s enough of one to add=
 a bunch of syntax to the language.<br><br>It should also be noted that wha=
t you&#39;re asking for might be taken care of by being able to overload op=
erator., via the <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/pap=
ers/2015/n4495.html">Smart Objects proposal</a>. I think that could cover y=
our use case, without having to expose full get/set property syntax. I&#39;=
m not certain, as that proposal relies on a lot of template stuff I don&#39=
;t quite understand, but it seems possible on the face of it.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_660_1452770724.1440605715970--
------=_Part_659_944439058.1440605715970--

.

--047d7b4142f003d46d051e39843d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Smart Objects would work, but it's a lot of boilerplate:

class Player {
    union Properties {
        struct Health {
            Player* self;
            operator int() const { ... }
            Health& operator=3D(int) { ... }
        } health;
        // ...
    };
public:
    template<class F> auto operator.(F&& f)
    -> decltype(f(Properties{{this}}) { return f(Properties{{this}}); }
}

This is already pretty gnarly as it's using the common initial sequence
trick; the alternative is one nested proxy plus operator. overload per
property name.
On 26 Aug 2015 6:15 pm, "Nicol Bolas" <jmckesson@gmail.com> wrote:

> On Wednesday, August 26, 2015 at 12:01:55 PM UTC-4, Klaim - Jo=C3=ABl Lam=
otte
> wrote:
>>
>>
>> On 26 August 2015 at 17:16, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>>
>>> Is this case truly so common that we need to add language syntax to C++
>>> to support it? I'd like to see evidence of that.
>>
>>
>> I don't know if it's common in other domains but the issue I point (and =
I
>> agree that it's mostly about having access code in-between access to a d=
ata)
>> is pretty common in game/simulation code which is geometry-heavy (also i=
n
>> easing/tweening code and AI spatial modelisations) where in the end you
>> often work with raw structs
>> because the language does not allow the simple access to members to be
>> potentially changed in SoA which is a common example these days.
>>
>> So far the few other times I felt that such a feature were similar in
>> that I just felt that the () noise was not worth in situations where I j=
ust
>> have
>> a function which is basically an accessor to data that I do not want any
>> user to know how I build, store and retrieve.
>>
>> Again I'm not for or against the feature, but I can't avoid thinking tha=
t
>> there are reasons why people seem to propose it again and again
>>
>
> Nobody's arguing that there aren't reasons for the feature. It's a
> question of whether their reasons are genuinely compelling. I can't say
> that I find "D and C# have them" to be particularly compelling. And while
> the reason you cite is a real reason, I just don't think it's enough of o=
ne
> to add a bunch of syntax to the language.
>
> It should also be noted that what you're asking for might be taken care o=
f
> by being able to overload operator., via the Smart Objects proposal
> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4495.html>. I
> think that could cover your use case, without having to expose full get/s=
et
> property syntax. I'm not certain, as that proposal relies on a lot of
> template stuff I don't quite understand, but it seems possible on the fac=
e
> of it.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/=
unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--047d7b4142f003d46d051e39843d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Smart Objects would work, but it&#39;s a lot of boilerplate:=
</p>
<p dir=3D"ltr">class Player {<br>
=C2=A0=C2=A0=C2=A0 union Properties {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct Health {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Player* =
self;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operator=
 int() const { ... }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Health&a=
mp; operator=3D(int) { ... }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } health;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...<br>
=C2=A0=C2=A0=C2=A0 };<br>
public:<br>
=C2=A0=C2=A0=C2=A0 template&lt;class F&gt; auto operator.(F&amp;&amp; f)<br=
>
=C2=A0=C2=A0=C2=A0 -&gt; decltype(f(Properties{{this}}) { return f(Properti=
es{{this}}); }<br>
}</p>
<p dir=3D"ltr">This is already pretty gnarly as it&#39;s using the common i=
nitial sequence trick; the alternative is one nested proxy plus operator. o=
verload per property name. </p>
<div class=3D"gmail_quote">On 26 Aug 2015 6:15 pm, &quot;Nicol Bolas&quot; =
&lt;<a href=3D"mailto:jmckesson@gmail.com">jmckesson@gmail.com</a>&gt; wrot=
e:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wednesday, Aug=
ust 26, 2015 at 12:01:55 PM UTC-4, Klaim - Jo=C3=ABl Lamotte wrote:<blockqu=
ote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1=
px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br><div class=3D"gma=
il_quote">On 26 August 2015 at 17:16, Nicol Bolas <span dir=3D"ltr">&lt;<a =
rel=3D"nofollow">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><br>Is this case truly so common that we need to add langua=
ge syntax to C++ to support it? I&#39;d like to see evidence of that.</bloc=
kquote></div><br>I don&#39;t know if it&#39;s common in other domains but t=
he issue I point (and I agree that it&#39;s mostly about having access code=
 in-between access to a data)</div><div>is pretty common in game/simulation=
 code which is geometry-heavy (also in easing/tweening code and AI spatial =
modelisations) where in the end you often work with raw structs</div><div>b=
ecause the language does not allow the simple access to members to be poten=
tially changed in SoA which is a common example these days.</div><div><br><=
/div><div>So far the few other times I felt that such a feature were simila=
r in that I just felt that the () noise was not worth in situations where I=
 just have<br></div><div>a function which is basically an accessor to data =
that I do not want any user to know how I build, store and retrieve.</div><=
div><br></div><div>Again I&#39;m not for or against the feature, but I can&=
#39;t avoid thinking that there are reasons why people seem to propose it a=
gain and again</div></div></blockquote><div><br>Nobody&#39;s arguing that t=
here aren&#39;t reasons for the feature. It&#39;s a question of whether the=
ir reasons are genuinely compelling. I can&#39;t say that I find &quot;D an=
d C# have them&quot; to be particularly compelling. And while the reason yo=
u cite is a real reason, I just don&#39;t think it&#39;s enough of one to a=
dd a bunch of syntax to the language.<br><br>It should also be noted that w=
hat you&#39;re asking for might be taken care of by being able to overload =
operator., via the <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/p=
apers/2015/n4495.html" target=3D"_blank">Smart Objects proposal</a>. I thin=
k that could cover your use case, without having to expose full get/set pro=
perty syntax. I&#39;m not certain, as that proposal relies on a lot of temp=
late stuff I don&#39;t quite understand, but it seems possible on the face =
of it.<br></div>

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b4142f003d46d051e39843d--

.

--001a113ece66268a58051e39dd3e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hey folks,

My 2c about the properties discussion. Every project I have ever worked on
in 20 years as a professional developer using C++ has ended up implementing
something like properties as described here. In the old days it was with
macros (paraphrasing):

#define PROPERTY(PTYPE, PNAME)                                  \
public:                                                         \
    const PTYPE & get##PNAME() const { return m_##PNAME ; }     \
    void set##PNAME(const PTYPE & value) { m_##PNAME =3D value; } \
protected:                                                      \
    PTYPE m_##PNAME ;                                           \
public:

Nowadays most of the build systems I work in have a reflection pass,
similar to what Qt does, so these things are able to be added automatically
via some sort of reflection.

On one hand, I think the argument can be made that since each of these
property instantiations often has slightly different, application-specific
variations, it makes sense to have them continue to be implemented by
developers.

On the other hand, any time I see something that is just tediously done
over and over and over, with very little meaningful variation, this seems
to me to be qualification for "part of the vernacular".  And though I don't
think C++ has to try to be like other languages, I do think it is relevant
that many of the recently created languages (Swift, etc...) feature
properties as an intrinsic grammatical feature.  I think this speaks to the
appeal of this idiom.

Please pardon my anecdotal approach to this discussion, I realize I'm not
explicitly providing examples of why this is a crucial utility.

Chris

On Wed, Aug 26, 2015 at 9:41 AM, 'Edward Catmur' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> Smart Objects would work, but it's a lot of boilerplate:
>
> class Player {
>     union Properties {
>         struct Health {
>             Player* self;
>             operator int() const { ... }
>             Health& operator=3D(int) { ... }
>         } health;
>         // ...
>     };
> public:
>     template<class F> auto operator.(F&& f)
>     -> decltype(f(Properties{{this}}) { return f(Properties{{this}}); }
> }
>
> This is already pretty gnarly as it's using the common initial sequence
> trick; the alternative is one nested proxy plus operator. overload per
> property name.
> On 26 Aug 2015 6:15 pm, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
>> On Wednesday, August 26, 2015 at 12:01:55 PM UTC-4, Klaim - Jo=C3=ABl La=
motte
>> wrote:
>>>
>>>
>>> On 26 August 2015 at 17:16, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>>
>>>> Is this case truly so common that we need to add language syntax to C+=
+
>>>> to support it? I'd like to see evidence of that.
>>>
>>>
>>> I don't know if it's common in other domains but the issue I point (and
>>> I agree that it's mostly about having access code in-between access to =
a
>>> data)
>>> is pretty common in game/simulation code which is geometry-heavy (also
>>> in easing/tweening code and AI spatial modelisations) where in the end =
you
>>> often work with raw structs
>>> because the language does not allow the simple access to members to be
>>> potentially changed in SoA which is a common example these days.
>>>
>>> So far the few other times I felt that such a feature were similar in
>>> that I just felt that the () noise was not worth in situations where I =
just
>>> have
>>> a function which is basically an accessor to data that I do not want an=
y
>>> user to know how I build, store and retrieve.
>>>
>>> Again I'm not for or against the feature, but I can't avoid thinking
>>> that there are reasons why people seem to propose it again and again
>>>
>>
>> Nobody's arguing that there aren't reasons for the feature. It's a
>> question of whether their reasons are genuinely compelling. I can't say
>> that I find "D and C# have them" to be particularly compelling. And whil=
e
>> the reason you cite is a real reason, I just don't think it's enough of =
one
>> to add a bunch of syntax to the language.
>>
>> It should also be noted that what you're asking for might be taken care
>> of by being able to overload operator., via the Smart Objects proposal
>> <http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4495.html>. I
>> think that could cover your use case, without having to expose full get/=
set
>> property syntax. I'm not certain, as that proposal relies on a lot of
>> template stuff I don't quite understand, but it seems possible on the fa=
ce
>> of it.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to a topic in the
>> Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

--001a113ece66268a58051e39dd3e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey folks,</div><div><br></div><div>My 2c about the p=
roperties discussion. Every project I have ever worked on in 20 years as a =
professional developer using C++ has ended up implementing something like p=
roperties as described here. In the old days it was with macros (paraphrasi=
ng):</div><div><br></div><div><font face=3D"monospace, monospace" size=3D"1=
">#define PROPERTY(PTYPE, PNAME) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0\</font></div><div><font face=3D"monospace, monospace" size=3D"1">public=
: =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \</font></div><div><font f=
ace=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 const PTYPE &amp; get=
##PNAME() const { return m_##PNAME ; } =C2=A0 =C2=A0 \</font></div><div><fo=
nt face=3D"monospace, monospace" size=3D"1">=C2=A0 =C2=A0 void set##PNAME(c=
onst PTYPE &amp; value) { m_##PNAME =3D value; } \</font></div><div><font f=
ace=3D"monospace, monospace" size=3D"1">protected: =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0\</font></div><div><font face=3D"monospace, monospace" siz=
e=3D"1">=C2=A0 =C2=A0 PTYPE m_##PNAME ; =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 \</font></div><div><font face=3D"mon=
ospace, monospace" size=3D"1">public:=C2=A0</font></div><div><br></div><div=
>Nowadays most of the build systems I work in have a reflection pass, simil=
ar to what Qt does, so these things are able to be added automatically via =
some sort of reflection. =C2=A0</div><div><br></div><div>On one hand, I thi=
nk the argument can be made that since each of these property instantiation=
s often has slightly different, application-specific variations, it makes s=
ense to have them continue to be implemented by developers.</div><div><br><=
/div><div>On the other hand, any time I see something that is just tediousl=
y done over and over and over, with very little meaningful variation, this =
seems to me to be qualification for &quot;part of the vernacular&quot;.=C2=
=A0 And though I don&#39;t think C++ has to try to be like other languages,=
 I do think it is relevant that many of the recently created languages (Swi=
ft, etc...) feature properties as an intrinsic grammatical feature.=C2=A0 I=
 think this speaks to the appeal of this idiom.</div><div><br></div><div>Pl=
ease pardon my anecdotal approach to this discussion, I realize I&#39;m not=
 explicitly providing examples of why this is a crucial utility.</div><div>=
<br></div><div>Chris</div></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Aug 26, 2015 at 9:41 AM, &#39;Edward Catmur&#39; v=
ia ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.org</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Smart =
Objects would work, but it&#39;s a lot of boilerplate:</p>
<p dir=3D"ltr">class Player {<br>
=C2=A0=C2=A0=C2=A0 union Properties {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 struct Health {<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Player* =
self;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 operator=
 int() const { ... }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Health&a=
mp; operator=3D(int) { ... }<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 } health;<br>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 // ...<br>
=C2=A0=C2=A0=C2=A0 };<br>
public:<br>
=C2=A0=C2=A0=C2=A0 template&lt;class F&gt; auto operator.(F&amp;&amp; f)<br=
>
=C2=A0=C2=A0=C2=A0 -&gt; decltype(f(Properties{{this}}) { return f(Properti=
es{{this}}); }<br>
}</p>
<p dir=3D"ltr">This is already pretty gnarly as it&#39;s using the common i=
nitial sequence trick; the alternative is one nested proxy plus operator. o=
verload per property name. </p>
<div class=3D"gmail_quote"><span class=3D"">On 26 Aug 2015 6:15 pm, &quot;N=
icol Bolas&quot; &lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blan=
k">jmckesson@gmail.com</a>&gt; wrote:<br type=3D"attribution"></span><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><span class=3D"">On Wednesday, August 26, 2015 at =
12:01:55 PM UTC-4, Klaim - Jo=C3=ABl Lamotte wrote:<blockquote class=3D"gma=
il_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr"><div><br><div class=3D"gmail_quote">On 26 =
August 2015 at 17:16, Nicol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow"=
>jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">=
<br>Is this case truly so common that we need to add language syntax to C++=
 to support it? I&#39;d like to see evidence of that.</blockquote></div><br=
>I don&#39;t know if it&#39;s common in other domains but the issue I point=
 (and I agree that it&#39;s mostly about having access code in-between acce=
ss to a data)</div><div>is pretty common in game/simulation code which is g=
eometry-heavy (also in easing/tweening code and AI spatial modelisations) w=
here in the end you often work with raw structs</div><div>because the langu=
age does not allow the simple access to members to be potentially changed i=
n SoA which is a common example these days.</div><div><br></div><div>So far=
 the few other times I felt that such a feature were similar in that I just=
 felt that the () noise was not worth in situations where I just have<br></=
div><div>a function which is basically an accessor to data that I do not wa=
nt any user to know how I build, store and retrieve.</div><div><br></div><d=
iv>Again I&#39;m not for or against the feature, but I can&#39;t avoid thin=
king that there are reasons why people seem to propose it again and again</=
div></div></blockquote><div><br>Nobody&#39;s arguing that there aren&#39;t =
reasons for the feature. It&#39;s a question of whether their reasons are g=
enuinely compelling. I can&#39;t say that I find &quot;D and C# have them&q=
uot; to be particularly compelling. And while the reason you cite is a real=
 reason, I just don&#39;t think it&#39;s enough of one to add a bunch of sy=
ntax to the language.<br><br>It should also be noted that what you&#39;re a=
sking for might be taken care of by being able to overload operator., via t=
he <a href=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4495=
..html" target=3D"_blank">Smart Objects proposal</a>. I think that could cov=
er your use case, without having to expose full get/set property syntax. I&=
#39;m not certain, as that proposal relies on a lot of template stuff I don=
&#39;t quite understand, but it seems possible on the face of it.<br></div>

<p></p>

-- <br>
<br>
--- <br></span>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<span class=3D""><br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</span></blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ece66268a58051e39dd3e--

.

2015-08-26 15:14 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> Let's take your health example. I would never use even `player.health() +=
> 10`, let alone the property syntax. Why?
>
> Because you can't search for it.
>
> Changing the health of an entity is rather special, not something you ought
> to be doing with any entity pointer/reference you happen to have. It's
> really important, if there's a bug causing an entity's health to be
> increased incorrectly, that I be able to search for every place where health
> is being increased.

You can't grep for it but can't tools using the AST point you to all
write-accesses?

> Your way makes that impossible. Or at least, not without a boatload of false
> positives to sift through. And I certainly don't want to stick a breakpoint
> in the `health()` function, or in the proxy object returned by it or
> whatever, or a memory breakpoint in the entity's actual health.
>
> Whereas if you simply had `player.addHealth(10)`, that's something you can
> search for.
>
> A lot of the pro-properties side tends to operate under the assumption that
> all, or even most accessors were of the form "get variable, set variable."
>
> Generally speaking, that's not how it usually works. Or at least, not in my
> experience.

If you don't want the default setter then don't use the default setter..

> Oh, it sometimes is. But encapsulation usually requires more control over
> how the internal property changes. A name could be decomposed into a first
> name and last name. Or a first/last/middle. Or whatever. And while you might
> at first want a simple "set_name" function, odds are good that what you
> really want are "set_surname", "set_givenname", and "set_middlename". If you
> want to set the whole name, you need some information about the ordering of
> the names from the user. Since that requires two input parameters, it
> couldn't be a property.

If you store the name as parts wouldn't you simply have multiple
properties, one for each part?
And then an extra getter for the entire name?

> The property style interface works OK only in the simplest of cases. Do we
> really need syntax for simple stuff? It seems to me that we need the most
> syntax for complex things, not trivial accessors.

Simple things should be as simple as possible.. so yes, IMO.
Of course making complex things simpler is good too.

--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

Let me preface this by saying I'm not convinced that we need properties.



That said, based on the recent discussions, it seems to me that *IF* we
added properties, they should look something like:

  class Player
  {
  public:
    inline class {
      operator int() const;

      auto& operator=(int) -> decltype(Player::health)
      { ...; return this.health; }

      void add(int);
    } health;
  };

Note that, rather than calling it a "property", I have called it an
"inline class" (thus, not introducing new keywords). An inline class is
a special case of a nested class-type which itself has no storage, and
for which "this" refers to the parent class which must contain the
inline class as a member. This inline class can contain member
definitions as usual. Read access is via conversion operator, which
additionally permits different operations depending on the desired
conversion (i.e. the property itself can define its conversions to
various types). Setting the property is via assignment operator; other
operators (e.g. '+=') can be trivially defined. One can also add named
members, so one can write e.g. 'player.health.add(5)'.

I chose also to use the existing operator syntax to avoid introducing
context keywords "get" and "set", and for consistency with existing
constructs. I'm not wedded to that, or to "inline class" vs. e.g.
"property", though I feel that the consistency and no-new-keywords
arguments are compelling.



An auto reference to the property would have the inline class type as
the type, so that code like:

  auto& h = player.health;
  h += 5;

....will still work (i.e. will still change 'player.health'), newly using
the "property" operator+=. Trying to assign to a POD reference won't
compile because the conversion operator cannot be invoked to assign a
reference (this is the case in current C++), so code will not silently
break.

Similarly, assignment operators return a reference to the property so
that chaining works as usual. (I'm not entirely sure what's the best way
to write a return type of an inline class reference; the syntax given
above is not ideal, although 'auto&' with inferred type might be okay.)



The above syntax implies that the get/set operators can be defined
out-of-line. Also, conceivably, the inline class type could be named,
and the containing class could contain several properties of the same
type. (Binding these to the appropriate corresponding internal data
members might be fun, but a template inline class and some offsetof
magic should make that achievable.)



Anyway, the main points that I think any properties implementation
should address are storage efficiency (i.e. does not require more
storage than the underlying value member; bonus points if it also works
with PIMPL) and ease of defining / overloading operators. These are the
main two points where attempts to implement properties as a purely
library solution struggle.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

> Note that, rather than calling it a "property", I have called it an
> "inline class" (thus, not introducing new keywords). An inline class is
> a special case of a nested class-type which itself has no storage, and
> for which "this" refers to the parent class which must contain the
> inline class as a member.

This is excellent idea, it would be cool is I could have "inline struct" too (members public by default) vs "inline class" (members private by default).

This would solve biggest problem with current standard not letting you access enclosing class easily from embedded class/struct.

This would be also much more powerful than properties.

-- Adam

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 13:44, Olaf van der Spek wrote:
> If you store the name as parts wouldn't you simply have multiple
> properties, one for each part?
> And then an extra getter for the entire name?

See the other message in this thread I just wrote. Inline classes (which
use the parent instance's storage) would allow you to have
*"properties"* that can overlap in terms of what actual storage they use.

Example:

  class Person {
    array<string, 3> m_name_parts;
  public:
    template <size_t Part> inline class NamePart {
    public:
      operator string() const;
      auto& operator=(string const&);
    };

    inline class {
    public:
      operator string() const { return join(this.m_name_parts, " "); }
      auto& operator=(array<string, 3> const&);
    } full_name;

    NamePart<0> given_name;
    NamePart<1> middle_name;
    NamePart<2> surname;
  };

So, yes, you have a "property" for each part of the name, *and* a
"property" for the full name. And 'full_name' can also have a conversion
operator to 'array<string, 3>', multiple assignment operators, and so
forth :-).

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5390_829276896.1440612517050
Content-Type: multipart/alternative;
 boundary="----=_Part_5391_37841995.1440612517051"

------=_Part_5391_37841995.1440612517051
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4, Matthew Woehlke wrote:
>
> Let me preface this by saying I'm not convinced that we need properties.
>
>
>
> That said, based on the recent discussions, it seems to me that *IF* we
> added properties, they should look something like:
>

Ugh. I hate properties, but I hate hacks more. If properties are important
enough to have, then they should be exactly what they are: syntactic sugar
around syntax. `var.prop` as part of a non-assignment expression calls a
getter function. `var.prop` as part of an assignment expression calls a
setter function. One of the modifying assignment operators should
automatically work as a getter followed by the modification followed by the
setter.

A "property" should not be some type that implements methods. It should not
have storage. It should not consist of anything more than 2 function
declarations/definitions.

Anything more is just hacky syntax to try to make properties work without
adding real property syntax.

To put it another way, we should not add a couple of special-case syntaxes
to make library property hacks work. If properties are important enough to
add (and I do not believe they are), then they should be added *correctly*,
as a first-class feature. If they're not important enough to be a
first-class feature, then they're not important enough to add some hack
solutions for.

Unless there is some other use for these inline classes, I'm against using
them as a way to put properties into the language.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><br><br>On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4,=
 Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Let me =
preface this by saying I&#39;m not convinced that we need properties.
<br>
<br>
<br>
<br>That said, based on the recent discussions, it seems to me that *IF* we
<br>added properties, they should look something like:<br></blockquote><div=
><br>Ugh. I hate properties, but I hate hacks more. If properties are impor=
tant enough to have, then they should be exactly what they are: syntactic s=
ugar around syntax. `var.prop` as part of a non-assignment expression calls=
 a getter function. `var.prop` as part of an assignment expression calls a =
setter function. One of the modifying assignment operators should automatic=
ally work as a getter followed by the modification followed by the setter.<=
br><br>A &quot;property&quot; should not be some type that implements metho=
ds. It should not have storage. It should not consist of anything more than=
 2 function declarations/definitions.<br><br>Anything more is just hacky sy=
ntax to try to make properties work without adding real property syntax.</d=
iv><br>To put it another way, we should not add a couple of special-case sy=
ntaxes to make library property hacks work. If properties are important eno=
ugh to add (and I do not believe they are), then they should be added <i>co=
rrectly</i>, as a first-class feature. If they&#39;re not important enough =
to be a first-class feature, then they&#39;re not important enough to add s=
ome hack solutions for.<br><br>Unless there is some other use for these inl=
ine classes, I&#39;m against using them as a way to put properties into the=
 language.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5391_37841995.1440612517051--
------=_Part_5390_829276896.1440612517050--

.

On 2015-08-26 14:01, Adam Strzelecki wrote:
>> Note that, rather than calling it a "property", I have called it an
>> "inline class" (thus, not introducing new keywords). An inline class is
>> a special case of a nested class-type which itself has no storage, and
>> for which "this" refers to the parent class which must contain the
>> inline class as a member.
>
> This is excellent idea, it would be cool is I could have "inline
> struct" too (members public by default) vs "inline class" (members
> private by default).

Sure, I don't see why not. In fact, that would likely be the more common
case. (I realized after I sent the previous message that I forgot a
'public:' in the inline class :-).)

> This would solve biggest problem with current standard not letting
> you access enclosing class easily from embedded class/struct.

Right; that's the main idea.

The only complication is that an inline class can't have its own members
(think about it for a bit; it has no way of knowing the location of its
own members relative to the parent instance. It can know one or the
other, but not both without additional storage or generating different
code per member of the class type. The latter is essentially my template
offsetof suggestion.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a11c32ce2f5bc8f051e3b148e
Content-Type: text/plain; charset=UTF-8

I think these two comments wrap it up.

Christopher Hovath, "Every project I have ever worked on in 20 years as a
professional developer using C++ has ended up implementing something like
properties"

Nicol, "I hate properties, but I hate hacks more. If properties are
important enough to have, then they should be exactly what they are"
If they're not important enough to be a first-class feature, then they're
not important enough to add some hack solutions for.

Sounds to me like everyone is "hacking" property features into C++;  Why
not give them all a break and implement it as a standard?

-------

Somethings to consider though was our previous discussion about hidden
work-load.  A few discussion back we were discussion a Object~>Property
syntax to separate it from a Public field (direct access).

Couldn't help but wonder if the compiler doesn't or couldn't chop out any
over-head caused by a blank property (just a get/set) wrapper to prevent
any extra run-time.  Along those lines is there anyway a public field could
be modified to a property down the road and still maintain API
compatibility?

For Example;
Original library just made "public int value" but down the road we wanted
set limits enforced on value - is there anyway possible to add a Set/Get
Property that wouldn't break the original API?


On Wed, Aug 26, 2015 at 12:08 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

>
>
> On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4, Matthew Woehlke wrote:
>>
>> Let me preface this by saying I'm not convinced that we need properties.
>>
>>
>>
>> That said, based on the recent discussions, it seems to me that *IF* we
>> added properties, they should look something like:
>>
>
> Ugh. I hate properties, but I hate hacks more. If properties are important
> enough to have, then they should be exactly what they are: syntactic sugar
> around syntax. `var.prop` as part of a non-assignment expression calls a
> getter function. `var.prop` as part of an assignment expression calls a
> setter function. One of the modifying assignment operators should
> automatically work as a getter followed by the modification followed by the
> setter.
>
> A "property" should not be some type that implements methods. It should
> not have storage. It should not consist of anything more than 2 function
> declarations/definitions.
>
> Anything more is just hacky syntax to try to make properties work without
> adding real property syntax.
>
> To put it another way, we should not add a couple of special-case syntaxes
> to make library property hacks work. If properties are important enough to
> add (and I do not believe they are), then they should be added *correctly*,
> as a first-class feature. If they're not important enough to be a
> first-class feature, then they're not important enough to add some hack
> solutions for.
>
> Unless there is some other use for these inline classes, I'm against using
> them as a way to put properties into the language.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a11c32ce2f5bc8f051e3b148e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div><div><div>I think these two comments wrap i=
t up.<br><br>Christopher Hovath, &quot;Every project I have ever worked on =
in 20 years as a professional developer using C++ has ended up implementing=
 something like properties&quot;<br><br>Nicol, &quot;I hate properties, but=
 I hate hacks more. If properties are important enough to have, then they s=
hould be exactly what they are&quot;<br>If they&#39;re not important enough=
 to be a first-class feature, then they&#39;re not important enough to add =
some hack solutions for.<br><br></div>Sounds to me like everyone is &quot;h=
acking&quot; property features into C++;=C2=A0 Why not give them all a brea=
k and implement it as a standard?<br><br>-------<br><br></div>Somethings to=
 consider though was our previous discussion about hidden work-load.=C2=A0 =
A few discussion back we were discussion a Object~&gt;Property syntax to se=
parate it from a Public field (direct access).<br></div><br>Couldn&#39;t he=
lp but wonder if the compiler doesn&#39;t or couldn&#39;t chop out any over=
-head caused by a blank property (just a get/set) wrapper to prevent any ex=
tra run-time.=C2=A0 Along those lines is there anyway a public field could =
be modified to a property down the road and still maintain API compatibilit=
y?<br><br></div>For Example;<br></div>Original library just made &quot;publ=
ic int value&quot; but down the road we wanted set limits enforced on value=
 - is there anyway possible to add a Set/Get Property that wouldn&#39;t bre=
ak the original API?<br><br></div><div class=3D"gmail_extra"><br><div class=
=3D"gmail_quote">On Wed, Aug 26, 2015 at 12:08 PM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesso=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><span class=3D""><br><br>On Wednesday, August 26, 2015 at 1:54:48=
 PM UTC-4, Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D=
"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Le=
t me preface this by saying I&#39;m not convinced that we need properties.
<br>
<br>
<br>
<br>That said, based on the recent discussions, it seems to me that *IF* we
<br>added properties, they should look something like:<br></blockquote></sp=
an><div><br>Ugh. I hate properties, but I hate hacks more. If properties ar=
e important enough to have, then they should be exactly what they are: synt=
actic sugar around syntax. `var.prop` as part of a non-assignment expressio=
n calls a getter function. `var.prop` as part of an assignment expression c=
alls a setter function. One of the modifying assignment operators should au=
tomatically work as a getter followed by the modification followed by the s=
etter.<br><br>A &quot;property&quot; should not be some type that implement=
s methods. It should not have storage. It should not consist of anything mo=
re than 2 function declarations/definitions.<br><br>Anything more is just h=
acky syntax to try to make properties work without adding real property syn=
tax.</div><br>To put it another way, we should not add a couple of special-=
case syntaxes to make library property hacks work. If properties are import=
ant enough to add (and I do not believe they are), then they should be adde=
d <i>correctly</i>, as a first-class feature. If they&#39;re not important =
enough to be a first-class feature, then they&#39;re not important enough t=
o add some hack solutions for.<br><br>Unless there is some other use for th=
ese inline classes, I&#39;m against using them as a way to put properties i=
nto the language.<br></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a11c32ce2f5bc8f051e3b148e--

.

On 2015-08-26 14:08, Nicol Bolas wrote:
> On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4, Matthew Woehlke wrote:
>> based on the recent discussions, it seems to me that *IF* we
>> added properties, they should look something like:
>
> Ugh. I hate properties, but I hate hacks more. If properties are important
> enough to have, then they should be exactly what they are: syntactic sugar
> around syntax. `var.prop` as part of a non-assignment expression calls a
> getter function. `var.prop` as part of an assignment expression calls a
> setter function.

That's exactly how an inline class *works*. You *MUST* define the
get/set methods somewhere. At "best", by your logic, you would have:

  class Foo {
    int property bar get() const;
    property bar set(int);
  };

I've suggested exactly the same thing, but with the property name as a
scope, and reusing existing keywords and constructs rather than
introducing new ones. Only my suggestion opens up a lot of *additional*
possibilities.

> One of the modifying assignment operators should automatically work
> as a getter followed by the modification followed by the setter.

This requires a substantial change to language semantics, and I'm not
entirely convinced it is always TRTTD.

With inline classes, you could achieve this easily with a mixin.

> A "property" should not be some type that implements methods.

Ignoring the second half of that, if it's not a type, how do you solve
the problem of someone taking a reference to the property and
subsequently modifying it?

> It should not have storage.

There has to be storage *somewhere*. Both properties and inline classes
use the parent for that storage.

> It should not consist of anything more than 2 function
> declarations/definitions.

Most inline class "properties" won't.

> To put it another way, we should not add a couple of special-case syntaxes
> to make library property hacks work.

That's not at all what I suggested. (I'll also point out that what I
suggested was exactly *one* syntax, not "a couple". Nor did I at any
point call on a library to provide boilerplate code.)

I admit that trivial support for modifying operators may require some
library help, but I think that's more than worth it, considering the
advantages:

 - No new keywords.

 - Ability to reuse get/set logic for multiple properties, even in
   multiple parent types.

 - Additional potential use outside of "properties".

 - Minimal changes to the language.

The only language change for inline classes, really, is the new "inline
class/struct" syntax, and the concept that the storage of such an object
is the same as the parent. For "proper properties", besides the syntax
(and I'm not sure how you'll avoid new keywords), you've added, at
minimum, the magic that 'foo.bar += 4' must convert to 'foo.bar =
(foo.bar + 4)'. Don't forget you've also introduces some new magical
"property reference type" so that you can write 'auto& prop = foo.bar;
prop += 4;'. Inline classes just leverage existing language features for
all of this.

> Unless there is some other use for these inline classes, I'm against using
> them as a way to put properties into the language.

Sort of related, but how about this?

  auto c = get_color();
  c.hsl.hue = 15;
  cout << c.hcy.hue;

The outer inline class is used to manipulate the object "as an X", i.e.
such that various possibly X's have methods/"properties" of the same
name, but different semantics. Something like a downcast, except you can
"downcast" to multiple types at the same hierarchy level.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 26 August 2015 at 21:33, Tom Joe <tgit28@gmail.com> wrote:
> I think these two comments wrap it up.
>
> Christopher Hovath, "Every project I have ever worked on in 20 years as a
> professional developer using C++ has ended up implementing something like
> properties"
>
> Nicol, "I hate properties, but I hate hacks more. If properties are
> important enough to have, then they should be exactly what they are"
> If they're not important enough to be a first-class feature, then they're
> not important enough to add some hack solutions for.
>
> Sounds to me like everyone is "hacking" property features into C++;  Why not
> give them all a break and implement it as a standard?


Because for any set of "everyone" that hacks properties into C++, it's easy to
find equally large or larger sets of "everyone" that don't and
haven't, and won't use these
properties even if we add them to C++?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-08-26 20:57 GMT+02:00 Ville Voutilainen <ville.voutilainen@gmail.com>:
> On 26 August 2015 at 21:33, Tom Joe <tgit28@gmail.com> wrote:
>> I think these two comments wrap it up.
>>
>> Christopher Hovath, "Every project I have ever worked on in 20 years as a
>> professional developer using C++ has ended up implementing something like
>> properties"
>>
>> Nicol, "I hate properties, but I hate hacks more. If properties are
>> important enough to have, then they should be exactly what they are"
>> If they're not important enough to be a first-class feature, then they're
>> not important enough to add some hack solutions for.
>>
>> Sounds to me like everyone is "hacking" property features into C++;  Why not
>> give them all a break and implement it as a standard?
>
>
> Because for any set of "everyone" that hacks properties into C++, it's easy to
> find equally large or larger sets of "everyone" that don't and
> haven't, and won't use these
> properties even if we add them to C++?

And that's a problem how?

Does every feature have to appeal to every user?


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 14:57, Ville Voutilainen wrote:
> Because for any set of "everyone" that hacks properties into C++, it's easy to
> find equally large or larger sets of "everyone" that don't and
> haven't, and won't use these properties even if we add them to C++?

By that logic, why do we have iostreams or containers in STL? Why do we
have virtual inheritance? (Heck, why do we have STL *at all*?)

Just because a feature is not *universally* used doesn't mean it isn't
valuable. (And yes, the above are rhetorical questions.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 14:33, Tom Joe wrote:
> Couldn't help but wonder if the compiler doesn't or couldn't chop out any
> over-head caused by a blank property (just a get/set) wrapper to prevent
> any extra run-time.

For either "real properties" or inline classes, I'd darned well file a
compiler missed-optimization bug for any property get/set that is
inlinable and isn't inlined :-). I can't imagine why either case should
make the usual inlining mechanism suddenly not work.

> Along those lines is there anyway a public field could be modified to
> a property down the road and still maintain API compatibility?

SC, yes (both approaches). BC... well, if the get/set is trivial, i.e.
the effects don't change, then you won't actually be calling the get/set
(until you recompile), but there won't be an observable difference anyway.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 26 August 2015 at 22:12, Olaf van der Spek <olafvdspek@gmail.com> wrote:
>> Because for any set of "everyone" that hacks properties into C++, it's easy to
>> find equally large or larger sets of "everyone" that don't and
>> haven't, and won't use these
>> properties even if we add them to C++?
> And that's a problem how?

It's a problem if the benefit of adding properties as a feature is not
worth its cost.

> Does every feature have to appeal to every user?

No. In contrast, not every feature that appeals to some users has to
be standardized.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 26 August 2015 at 23:22, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2015-08-26 14:57, Ville Voutilainen wrote:
>> Because for any set of "everyone" that hacks properties into C++, it's easy to
>> find equally large or larger sets of "everyone" that don't and
>> haven't, and won't use these properties even if we add them to C++?
> By that logic, why do we have iostreams or containers in STL? Why do we
> have virtual inheritance? (Heck, why do we have STL *at all*?)
> Just because a feature is not *universally* used doesn't mean it isn't
> valuable. (And yes, the above are rhetorical questions.)

Properties have been suggested multiple times. They have failed every time.
Perhaps all the features you enumerated were considered more valuable
than properties.

I find it amusing that responding to "some people really like
properties, so let's
standardize them" with "many people don't" gets people up in arms. Anyone who
wants to attempt standardizing properties again needs to have better rationale
than that, and the onus is not on the opposing side to present rationale that
the proponents of properties accept.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1147d2d0607c97051e3ccbae
Content-Type: text/plain; charset=UTF-8

Just simply the fact that classes weren't meant to be data aggregators but
living things that do things. You dont get the age, the class does things
with the age for you. What sorts of things would you do with an age? Maybe
determine if he's older or younger than someone? Say the age as a string or
number? It may look like "get" in that instance but it's not. You're not
ripping the class's head open and jabbing probes into it's brain and
getting a number you could have just asked him for.
On Aug 25, 2015 6:53 PM, "Bo Persson" <bop@gmb.dk> wrote:

> On 2015-08-25 23:51, Olaf van der Spek wrote:
>
>> 2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com>:
>>
>>> I wouldnt just say less than desirable, i mean your code shouldnt contain
>>> them.
>>>
>>
>> Got a reference for that?
>> I mean, should class person not contain a name function/property?
>>
>
> It might have a function returning the name, but it should not have a
> public set_name, and certainly not set_age, or set_height.
>
> Should containers not have a size function/property?
>>
>
> Likewise, vec.set_size(vec.get_size + 1) isn't a very good interface.
>
>
> A bit up the thread Adam writes:
>
> "I'd just love these APIs to use properties everywhere in place of these
> accessors and use player.health += 10 instead
> player.setHealth(player.getHealth() + 10)."
>
> Which is also an odd interface. I would expect to use
> player.visit_doctor() or player.eat_your_medicine() to improve health. Not
> player.health++.
>
>
> Bo Persson
>
>
>
>
> --
>
> --- You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1147d2d0607c97051e3ccbae
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Just simply the fact that classes weren&#39;t meant to be da=
ta aggregators but living things that do things. You dont get the age, the =
class does things with the age for you. What sorts of things would you do w=
ith an age? Maybe determine if he&#39;s older or younger than someone? Say =
the age as a string or number? It may look like &quot;get&quot; in that ins=
tance but it&#39;s not. You&#39;re not ripping the class&#39;s head open an=
d jabbing probes into it&#39;s brain and getting a number you could have ju=
st asked him for.</p>
<div class=3D"gmail_quote">On Aug 25, 2015 6:53 PM, &quot;Bo Persson&quot; =
&lt;<a href=3D"mailto:bop@gmb.dk">bop@gmb.dk</a>&gt; wrote:<br type=3D"attr=
ibution"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde=
r-left:1px #ccc solid;padding-left:1ex">On 2015-08-25 23:51, Olaf van der S=
pek wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2015-08-25 23:38 GMT+02:00 Gino Vincenzini &lt;<a href=3D"mailto:openmysour=
cecode@gmail.com" target=3D"_blank">openmysourcecode@gmail.com</a>&gt;:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I wouldnt just say less than desirable, i mean your code shouldnt contain<b=
r>
them.<br>
</blockquote>
<br>
Got a reference for that?<br>
I mean, should class person not contain a name function/property?<br>
</blockquote>
<br>
It might have a function returning the name, but it should not have a publi=
c set_name, and certainly not set_age, or set_height.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Should containers not have a size function/property?<br>
</blockquote>
<br>
Likewise, vec.set_size(vec.get_size + 1) isn&#39;t a very good interface.<b=
r>
<br>
<br>
A bit up the thread Adam writes:<br>
<br>
&quot;I&#39;d just love these APIs to use properties everywhere in place of=
 these accessors and use player.health +=3D 10 instead player.setHealth(pla=
yer.getHealth() + 10).&quot;<br>
<br>
Which is also an odd interface. I would expect to use player.visit_doctor()=
 or player.eat_your_medicine() to improve health. Not player.health++.<br>
<br>
<br>
Bo Persson<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1147d2d0607c97051e3ccbae--

.

--089e01176905b40a27051e3d24fc
Content-Type: text/plain; charset=UTF-8

>""I'd just love these APIs to use properties everywhere in place of these
accessors and use player.health += 10 instead
player.setHealth(player.getHealth() + 10)."
>
>Which is also an odd interface. I would expect to use
player.visit_doctor() or player.eat_your_medicine() to improve health. Not
player.health++.

Unless someone is using static external settings file and/or data stream
parsing; I fail to see how one could make all classes completely "verb"
based.  I'd like to think of objects as dynamic machines that can
contain/handle various.  So your class implementations doesn't have to have
a "White Car", "Blue Car" and "Purple Car" implementations.  TheCar.Color =
"White".

All machines in the physical world "settings" (ie: switches and
configuration) so why can't OO class programs??  So the
"player.visit_doctor()" but how many health points does that associate?
Will that answer be statically programmed or dynamic for clients?

On Wed, Aug 26, 2015 at 2:35 PM, Gino Vincenzini <openmysourcecode@gmail.com
> wrote:

> Just simply the fact that classes weren't meant to be data aggregators but
> living things that do things. You dont get the age, the class does things
> with the age for you. What sorts of things would you do with an age? Maybe
> determine if he's older or younger than someone? Say the age as a string or
> number? It may look like "get" in that instance but it's not. You're not
> ripping the class's head open and jabbing probes into it's brain and
> getting a number you could have just asked him for.
> On Aug 25, 2015 6:53 PM, "Bo Persson" <bop@gmb.dk> wrote:
>
>> On 2015-08-25 23:51, Olaf van der Spek wrote:
>>
>>> 2015-08-25 23:38 GMT+02:00 Gino Vincenzini <openmysourcecode@gmail.com>:
>>>
>>>> I wouldnt just say less than desirable, i mean your code shouldnt
>>>> contain
>>>> them.
>>>>
>>>
>>> Got a reference for that?
>>> I mean, should class person not contain a name function/property?
>>>
>>
>> It might have a function returning the name, but it should not have a
>> public set_name, and certainly not set_age, or set_height.
>>
>> Should containers not have a size function/property?
>>>
>>
>> Likewise, vec.set_size(vec.get_size + 1) isn't a very good interface.
>>
>>
>> A bit up the thread Adam writes:
>>
>> "I'd just love these APIs to use properties everywhere in place of these
>> accessors and use player.health += 10 instead
>> player.setHealth(player.getHealth() + 10)."
>>
>> Which is also an odd interface. I would expect to use
>> player.visit_doctor() or player.eat_your_medicine() to improve health. Not
>> player.health++.
>>
>>
>> Bo Persson
>>
>>
>>
>>
>> --
>>
>> --- You received this message because you are subscribed to a topic in
>> the Google Groups "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, send an email to
>> std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01176905b40a27051e3d24fc
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt;&quot;&quot;I&#39;d just love these APIs to use p=
roperties everywhere in place of these
 accessors and use player.health +=3D 10 instead player.setHealth(player.ge=
tHealth() + 10).&quot;<br>
&gt;<br>&gt;Which is also an odd interface. I would expect to use=20
player.visit_doctor() or player.eat_your_medicine() to improve health.=20
Not player.health++.<br><br>Unless someone is using static external setting=
s file and/or data stream parsing; I fail to see how one could make all cla=
sses completely &quot;verb&quot; based.=C2=A0 I&#39;d like to think of obje=
cts as dynamic machines that can contain/handle various.=C2=A0 So your clas=
s implementations doesn&#39;t have to have a &quot;White Car&quot;, &quot;B=
lue Car&quot; and &quot;Purple Car&quot; implementations.=C2=A0 TheCar.Colo=
r =3D &quot;White&quot;.<br><br></div>All machines in the physical world &q=
uot;settings&quot; (ie: switches and configuration) so why can&#39;t OO cla=
ss programs??=C2=A0 So the &quot;player.visit_doctor()&quot; but how many h=
ealth points does that associate?=C2=A0 Will that answer be statically prog=
rammed or dynamic for clients?<br></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Wed, Aug 26, 2015 at 2:35 PM, Gino Vincenzini <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:openmysourcecode@gmail.com" target=3D"=
_blank">openmysourcecode@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><p dir=3D"ltr">Just simply the fact that classes weren&#39;=
t meant to be data aggregators but living things that do things. You dont g=
et the age, the class does things with the age for you. What sorts of thing=
s would you do with an age? Maybe determine if he&#39;s older or younger th=
an someone? Say the age as a string or number? It may look like &quot;get&q=
uot; in that instance but it&#39;s not. You&#39;re not ripping the class&#3=
9;s head open and jabbing probes into it&#39;s brain and getting a number y=
ou could have just asked him for.</p>
<div class=3D"gmail_quote"><span class=3D"">On Aug 25, 2015 6:53 PM, &quot;=
Bo Persson&quot; &lt;<a href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gm=
b.dk</a>&gt; wrote:<br type=3D"attribution"></span><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"">On 2015-08-25 23:51, Olaf van der Spek wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
2015-08-25 23:38 GMT+02:00 Gino Vincenzini &lt;<a href=3D"mailto:openmysour=
cecode@gmail.com" target=3D"_blank">openmysourcecode@gmail.com</a>&gt;:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
I wouldnt just say less than desirable, i mean your code shouldnt contain<b=
r>
them.<br>
</blockquote>
<br>
Got a reference for that?<br>
I mean, should class person not contain a name function/property?<br>
</blockquote>
<br>
It might have a function returning the name, but it should not have a publi=
c set_name, and certainly not set_age, or set_height.<br>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Should containers not have a size function/property?<br>
</blockquote>
<br>
Likewise, vec.set_size(vec.get_size + 1) isn&#39;t a very good interface.<b=
r>
<br>
<br></span>
A bit up the thread Adam writes:<br>
<br>
&quot;I&#39;d just love these APIs to use properties everywhere in place of=
 these accessors and use player.health +=3D 10 instead player.setHealth(pla=
yer.getHealth() + 10).&quot;<br>
<br>
Which is also an odd interface. I would expect to use player.visit_doctor()=
 or player.eat_your_medicine() to improve health. Not player.health++.<br>
<br>
<br>
Bo Persson<span class=3D""><br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</span></blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01176905b40a27051e3d24fc--

.

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

I fail to see the points against "properties" when people just say that the=
y hate them. If that is the case then you don't have to use them. However o=
ther libraries have implemented the idea of properties and there are many u=
sers of that idea. Surely then that means it would be handy to have as part=
 of the standard?

Also if they are to become part of the standard they should have simple and=
 understandable syntax and not just cobble together existing keywords. That=
 will just end up limiting what is possible.

Having said all that I do like the idea of an inline class/struct. That wou=
ld potentially simplify the idea of properties as well as many other things=
.. One of which I can think of off the top of my head is the pimpl ideom. An=
 inline class would allow simple implementation of that ideom in my opinion=
..

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5274_702581737.1440623029998--

.

On 2015-08-26 17:03, Izzy Coding wrote:
> Also if they are to become part of the standard they should have
> simple and understandable syntax and not just cobble together
> existing keywords. That will just end up limiting what is possible.

Introducing new keywords is extremely difficult. I gave a complete
syntax, which I don't think I've seen from someone that wants "real
properties".

IMHO, I think inline struct/class is pretty straight forward. The only
new concept to grasp is that 'this' of an inline class/struct refers to
nearest enclosing class/struct that is not inline. In every other way,
they simply use existing features.

> Having said all that I do like the idea of an inline class/struct.
> That would potentially simplify the idea of properties as well as many
> other things. One of which I can think of off the top of my head is the
> pimpl ideom. An inline class would allow simple implementation of that
> ideom in my opinion.

Um... how? The whole point of PIMPL is indirection of the class's
storage (so that the size/layout can change without affecting ABI).
That's sort-of the exact opposite as inline class/struct...

Well... as far as data. Come to think of it, if there was a way to add
an inline class definition and member to a class that has already been
defined (and the only trouble doing so is syntactic, since an inline
class definition and/or member cannot alter a class's layout), this
could allow private extension of classes. OTOH, that breaks
encapsulation, so it's probably not a good thing to allow... (Not that
you can't do that anyway by redefining a class's private class, but
still...)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--047d7bd7648e083622051e3d7f68
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 26, 2015 at 2:03 PM, Izzy Coding <matthew.i.greenwood@gmail.com>
wrote:

> I fail to see the points against "properties" when people just say that
> they hate them.


I personally "hate" them because nobody has presented code where properties
solve *anything* at all in a way that is simpler than what can already be
done in the language, short of maybe removing "()". All I see are
effectively syntactic transformations that provide no additional power. The
only rationale I hear is that certain people like the way they look.
Similarly, the same people point to other languages that have them, as if
that alone is a reason why they are a worthwhile feature. C++ pulls in
features from other languages not because the language wants to fit in with
trendy syntax, but because often there are features that a language
provides that provide tangible worth (I.E. lambdas). Unless there are
problems that properties actually solve and that solution is simpler than
existing alternatives, then they serve no practical purpose and only
complicate the language. Please provide an example of:

* A problem that properties solve that you can't already do with a similar
amount of constructs in the language already.
* Ideally, places in existing code, such as the standard library, that
would be objectively better with properties.

Until and unless there are some convincing examples of properties as
anything other than a function call with different syntax, I don't see
properties as adding anything of value to the language. "I like them" isn't
a good rationale.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bd7648e083622051e3d7f68
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 26, 2015 at 2:03 PM, Izzy Coding <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:matthew.i.greenwood@gmail.com" target=3D"_blank">matthew.i.greenwood@=
gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I fail t=
o see the points against &quot;properties&quot; when people just say that t=
hey hate them.</blockquote><div><br></div><div>I personally &quot;hate&quot=
; them because nobody has presented code where properties solve *anything* =
at all in a way that is simpler than what can already be done in the langua=
ge, short of maybe removing &quot;()&quot;. All I see are effectively synta=
ctic transformations that provide no additional power. The only rationale I=
 hear is that certain people like the way they look. Similarly, the same pe=
ople point to other languages that have them, as if that alone is a reason =
why they are a worthwhile feature. C++ pulls in features from other languag=
es not because the language wants to fit in with trendy syntax, but because=
 often there are features that a language provides that provide tangible wo=
rth (I.E. lambdas). Unless there are problems that properties actually solv=
e and that solution is simpler than existing alternatives, then they serve =
no practical purpose and only complicate the language. Please provide an ex=
ample of:</div><div><br></div><div>* A problem that properties solve that y=
ou can&#39;t already do with a similar amount of constructs in the language=
 already.</div><div>* Ideally, places in existing code, such as the standar=
d library, that would be objectively better with properties.</div><div><br>=
</div><div>Until and unless there are some convincing examples of propertie=
s as anything other than a function call with different syntax, I don&#39;t=
 see properties as adding anything of value to the language. &quot;I like t=
hem&quot; isn&#39;t a good rationale.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bd7648e083622051e3d7f68--

.

On 2015-08-26 23:00, Tom Joe wrote:
>  >""I'd just love these APIs to use properties everywhere in place of
> these accessors and use player.health += 10 instead
> player.setHealth(player.getHealth() + 10)."
>  >
>  >Which is also an odd interface. I would expect to use
> player.visit_doctor() or player.eat_your_medicine() to improve health.
> Not player.health++.
>
> Unless someone is using static external settings file and/or data stream
> parsing; I fail to see how one could make all classes completely "verb"
> based.  I'd like to think of objects as dynamic machines that can
> contain/handle various.  So your class implementations doesn't have to
> have a "White Car", "Blue Car" and "Purple Car" implementations.
> TheCar.Color = "White".

Again, I would prefer Paint(TheCar) to change the color.

>
> All machines in the physical world "settings" (ie: switches and
> configuration) so why can't OO class programs??

But in the real world you don't do room.lights = on, you turn_switch().
You don't do door.locked = false, you do unlock_door_with(key).

Those of us who "hate" properties also dislike the kind of interfaces we
run into, because the abstractions seem wrong. I sometimes have to work
hard to find the proper verb, but are very pleased when it works out
well. There is some kind of beauty in that.


Bo Persson




--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e01176905c001ef051e3db68f
Content-Type: text/plain; charset=UTF-8

>* A problem that properties solve that you can't already do with a similar
amount of constructs in the language already.

Clarity;  Unless everyone uses SetValue and GetValue methods there is no
clear difference between a method (verb) and a setting (adjective).
Does ThisCar.Color() return a value or preform the coloring?  One could
look-up the documentation every-time but perhaps a language syntax that
differentiates the two by its syntax would be simpler.

>* Ideally, places in existing code, such as the standard library, that
would be objectively better with properties.

From what I understand is STL uses overloading to implement the same effect
as properties (Is that because C++ doesn't support them??)  -  why use
method overloading to do two entirely different functions (set/get) one
might ask?  Well frankly I think it's so the API is only 1/2 as polluted as
having separate get/set Value methods.



On Wed, Aug 26, 2015 at 3:25 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, Aug 26, 2015 at 2:03 PM, Izzy Coding <
> matthew.i.greenwood@gmail.com> wrote:
>
>> I fail to see the points against "properties" when people just say that
>> they hate them.
>
>
> I personally "hate" them because nobody has presented code where
> properties solve *anything* at all in a way that is simpler than what can
> already be done in the language, short of maybe removing "()". All I see
> are effectively syntactic transformations that provide no additional power.
> The only rationale I hear is that certain people like the way they look.
> Similarly, the same people point to other languages that have them, as if
> that alone is a reason why they are a worthwhile feature. C++ pulls in
> features from other languages not because the language wants to fit in with
> trendy syntax, but because often there are features that a language
> provides that provide tangible worth (I.E. lambdas). Unless there are
> problems that properties actually solve and that solution is simpler than
> existing alternatives, then they serve no practical purpose and only
> complicate the language. Please provide an example of:
>
> * A problem that properties solve that you can't already do with a similar
> amount of constructs in the language already.
> * Ideally, places in existing code, such as the standard library, that
> would be objectively better with properties.
>
> Until and unless there are some convincing examples of properties as
> anything other than a function call with different syntax, I don't see
> properties as adding anything of value to the language. "I like them" isn't
> a good rationale.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e01176905c001ef051e3db68f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>&gt;* A problem that properties solve that =
you can&#39;t already do with a similar amount of constructs in the languag=
e already.<br><br></div>Clarity;=C2=A0 Unless everyone uses SetValue and Ge=
tValue methods there is no clear difference between a method (verb) and a s=
etting (adjective).<br></div>Does ThisCar.Color() return a value or preform=
 the coloring?=C2=A0 One could look-up the documentation every-time but per=
haps a language syntax that differentiates the two by its syntax would be s=
impler.<br><br>&gt;* Ideally, places in existing code, such as the standard=
 library, that would be objectively better with properties.<br><br></div>Fr=
om what I understand is STL uses overloading to implement the same effect a=
s properties (Is that because C++ doesn&#39;t support them??)=C2=A0 -=C2=A0=
 why use method overloading to do two entirely different functions (set/get=
) one might ask?=C2=A0 Well frankly I think it&#39;s so the API is only 1/2=
 as polluted as having separate get/set Value methods.<br><div><div><div><d=
iv><br><br></div></div></div></div></div><div class=3D"gmail_extra"><br><di=
v class=3D"gmail_quote">On Wed, Aug 26, 2015 at 3:25 PM, &#39;Matt Calabres=
e&#39; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocp=
p.org</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">=
On Wed, Aug 26, 2015 at 2:03 PM, Izzy Coding <span dir=3D"ltr">&lt;<a href=
=3D"mailto:matthew.i.greenwood@gmail.com" target=3D"_blank">matthew.i.green=
wood@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" s=
tyle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I fa=
il to see the points against &quot;properties&quot; when people just say th=
at they hate them.</blockquote><div><br></div></span><div>I personally &quo=
t;hate&quot; them because nobody has presented code where properties solve =
*anything* at all in a way that is simpler than what can already be done in=
 the language, short of maybe removing &quot;()&quot;. All I see are effect=
ively syntactic transformations that provide no additional power. The only =
rationale I hear is that certain people like the way they look. Similarly, =
the same people point to other languages that have them, as if that alone i=
s a reason why they are a worthwhile feature. C++ pulls in features from ot=
her languages not because the language wants to fit in with trendy syntax, =
but because often there are features that a language provides that provide =
tangible worth (I.E. lambdas). Unless there are problems that properties ac=
tually solve and that solution is simpler than existing alternatives, then =
they serve no practical purpose and only complicate the language. Please pr=
ovide an example of:</div><div><br></div><div>* A problem that properties s=
olve that you can&#39;t already do with a similar amount of constructs in t=
he language already.</div><div>* Ideally, places in existing code, such as =
the standard library, that would be objectively better with properties.</di=
v><div><br></div><div>Until and unless there are some convincing examples o=
f properties as anything other than a function call with different syntax, =
I don&#39;t see properties as adding anything of value to the language. &qu=
ot;I like them&quot; isn&#39;t a good rationale.</div></div></div></div><di=
v class=3D"HOEnZb"><div class=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e01176905c001ef051e3db68f--

.

--089e0117690582d87e051e3dc09d
Content-Type: text/plain; charset=UTF-8

> But in the real world you don't do room.lights = on, you turn_switch().
You don't do door.locked = false, you do unlock_door_with(key).

You walk into a room - are the lights on or off already?

On Wed, Aug 26, 2015 at 3:40 PM, Bo Persson <bop@gmb.dk> wrote:

> On 2015-08-26 23:00, Tom Joe wrote:
>
>>  >""I'd just love these APIs to use properties everywhere in place of
>> these accessors and use player.health += 10 instead
>> player.setHealth(player.getHealth() + 10)."
>>  >
>>  >Which is also an odd interface. I would expect to use
>> player.visit_doctor() or player.eat_your_medicine() to improve health.
>> Not player.health++.
>>
>> Unless someone is using static external settings file and/or data stream
>> parsing; I fail to see how one could make all classes completely "verb"
>> based.  I'd like to think of objects as dynamic machines that can
>> contain/handle various.  So your class implementations doesn't have to
>> have a "White Car", "Blue Car" and "Purple Car" implementations.
>> TheCar.Color = "White".
>>
>
> Again, I would prefer Paint(TheCar) to change the color.
>
>
>> All machines in the physical world "settings" (ie: switches and
>> configuration) so why can't OO class programs??
>>
>
> But in the real world you don't do room.lights = on, you turn_switch().
> You don't do door.locked = false, you do unlock_door_with(key).
>
> Those of us who "hate" properties also dislike the kind of interfaces we
> run into, because the abstractions seem wrong. I sometimes have to work
> hard to find the proper verb, but are very pleased when it works out well.
> There is some kind of beauty in that.
>
>
>
> Bo Persson
>
>
>
>
> --
>
> --- You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0117690582d87e051e3dc09d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">&gt; But in the real world you don&#39;t do room.lights =
=3D on, you turn_switch().=20
You don&#39;t do door.locked =3D false, you do unlock_door_with(key).<br><b=
r>You walk into a room - are the lights on or off already?<br></div><div cl=
ass=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 26, 2015 at =
3:40 PM, Bo Persson <span dir=3D"ltr">&lt;<a href=3D"mailto:bop@gmb.dk" tar=
get=3D"_blank">bop@gmb.dk</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex"><span class=3D"">On 2015-08-26 23:00, Tom Joe wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0&gt;&quot;&quot;I&#39;d just love these APIs to use properties everyw=
here in place of<br>
these accessors and use player.health +=3D 10 instead<br>
player.setHealth(player.getHealth() + 10).&quot;<br>
=C2=A0&gt;<br>
=C2=A0&gt;Which is also an odd interface. I would expect to use<br>
player.visit_doctor() or player.eat_your_medicine() to improve health.<br>
Not player.health++.<br>
<br>
Unless someone is using static external settings file and/or data stream<br=
>
parsing; I fail to see how one could make all classes completely &quot;verb=
&quot;<br>
based.=C2=A0 I&#39;d like to think of objects as dynamic machines that can<=
br>
contain/handle various.=C2=A0 So your class implementations doesn&#39;t hav=
e to<br>
have a &quot;White Car&quot;, &quot;Blue Car&quot; and &quot;Purple Car&quo=
t; implementations.<br>
TheCar.Color =3D &quot;White&quot;.<br>
</blockquote>
<br></span>
Again, I would prefer Paint(TheCar) to change the color.<span class=3D""><b=
r>
<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
All machines in the physical world &quot;settings&quot; (ie: switches and<b=
r>
configuration) so why can&#39;t OO class programs??<br>
</blockquote>
<br></span>
But in the real world you don&#39;t do room.lights =3D on, you turn_switch(=
). You don&#39;t do door.locked =3D false, you do unlock_door_with(key).<br=
>
<br>
Those of us who &quot;hate&quot; properties also dislike the kind of interf=
aces we run into, because the abstractions seem wrong. I sometimes have to =
work hard to find the proper verb, but are very pleased when it works out w=
ell. There is some kind of beauty in that.<div class=3D"HOEnZb"><div class=
=3D"h5"><br>
<br>
<br>
Bo Persson<br>
<br>
<br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0117690582d87e051e3dc09d--

.

On 2015-08-26 23:03, Izzy Coding wrote:
> I fail to see the points against "properties" when people just say that they hate them.  If that is the case then you don't have to use them.

So you don't expect the next proposal to be: "Now that we have these
nifty properties in the language, why aren't they used by the standard
library?"

And then they will not be optional anymore.



Bo Persson



--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 23:41, Tom Joe wrote:
>  >* A problem that properties solve that you can't already do with a
> similar amount of constructs in the language already.
>
> Clarity;  Unless everyone uses SetValue and GetValue methods there is no
> clear difference between a method (verb) and a setting (adjective).
> Does ThisCar.Color() return a value or preform the coloring?  One could
> look-up the documentation every-time but perhaps a language syntax that
> differentiates the two by its syntax would be simpler.
>
>  >* Ideally, places in existing code, such as the standard library, that
> would be objectively better with properties.
>
>  From what I understand is STL uses overloading to implement the same
> effect as properties (Is that because C++ doesn't support them??)  -
> why use method overloading to do two entirely different functions
> (set/get) one might ask?  Well frankly I think it's so the API is only
> 1/2 as polluted as having separate get/set Value methods.

I see tons of verbs in the STL - resize, reserve, erase, append, assign,
replace, push, insert, emplace, swap.

We also have find, count, sort, search, copy, move, transform, etc in
<algorithm>.


Bo Persson


--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113471067983ee051e3e2aa6
Content-Type: text/plain; charset=UTF-8

>I see tons of verbs in the STL

For sure; Its not feasible to eliminate "verb" (functions) and I'd even
encouraged them over properties.

"room.lights = on" is entirely a bad programming practice as it implies an
action being taken.

However, In the exact same sense;  trying to support a
setting/configuration/count using a method would be bad practice as there
is no functional action associated with it.

Granite; I'm sure we've all seen these bad practices (Using properties to
activate an action) but I'd like to think it's not any worse than implying
an action when no action is taken.

On Wed, Aug 26, 2015 at 4:02 PM, Bo Persson <bop@gmb.dk> wrote:

> On 2015-08-26 23:41, Tom Joe wrote:
>
>>  >* A problem that properties solve that you can't already do with a
>> similar amount of constructs in the language already.
>>
>> Clarity;  Unless everyone uses SetValue and GetValue methods there is no
>> clear difference between a method (verb) and a setting (adjective).
>> Does ThisCar.Color() return a value or preform the coloring?  One could
>> look-up the documentation every-time but perhaps a language syntax that
>> differentiates the two by its syntax would be simpler.
>>
>>  >* Ideally, places in existing code, such as the standard library, that
>> would be objectively better with properties.
>>
>>  From what I understand is STL uses overloading to implement the same
>> effect as properties (Is that because C++ doesn't support them??)  -
>> why use method overloading to do two entirely different functions
>> (set/get) one might ask?  Well frankly I think it's so the API is only
>> 1/2 as polluted as having separate get/set Value methods.
>>
>
> I see tons of verbs in the STL - resize, reserve, erase, append, assign,
> replace, push, insert, emplace, swap.
>
> We also have find, count, sort, search, copy, move, transform, etc in
> <algorithm>.
>
>
> Bo Persson
>
>
>
> --
>
> --- You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113471067983ee051e3e2aa6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>&gt;I see tons of verbs in the STL<br><br></div>=
For sure; Its not feasible to eliminate &quot;verb&quot; (functions) and I&=
#39;d even encouraged them over properties.<br><br>&quot;room.lights =3D on=
&quot; is entirely a bad programming practice as it implies an action being=
 taken.<br><br>However, In the exact same sense;=C2=A0 trying to support a =
setting/configuration/count using a method would be bad practice as there i=
s no functional action associated with it.<br><br></div>Granite; I&#39;m su=
re we&#39;ve all seen these bad practices (Using properties to activate an =
action) but I&#39;d like to think it&#39;s not any worse than implying an a=
ction when no action is taken.<br></div><div class=3D"gmail_extra"><br><div=
 class=3D"gmail_quote">On Wed, Aug 26, 2015 at 4:02 PM, Bo Persson <span di=
r=3D"ltr">&lt;<a href=3D"mailto:bop@gmb.dk" target=3D"_blank">bop@gmb.dk</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">On 2=
015-08-26 23:41, Tom Joe wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
=C2=A0&gt;* A problem that properties solve that you can&#39;t already do w=
ith a<br>
similar amount of constructs in the language already.<br>
<br>
Clarity;=C2=A0 Unless everyone uses SetValue and GetValue methods there is =
no<br>
clear difference between a method (verb) and a setting (adjective).<br>
Does ThisCar.Color() return a value or preform the coloring?=C2=A0 One coul=
d<br>
look-up the documentation every-time but perhaps a language syntax that<br>
differentiates the two by its syntax would be simpler.<br>
<br>
=C2=A0&gt;* Ideally, places in existing code, such as the standard library,=
 that<br>
would be objectively better with properties.<br>
<br>
=C2=A0From what I understand is STL uses overloading to implement the same<=
br>
effect as properties (Is that because C++ doesn&#39;t support them??)=C2=A0=
 -<br>
why use method overloading to do two entirely different functions<br>
(set/get) one might ask?=C2=A0 Well frankly I think it&#39;s so the API is =
only<br>
1/2 as polluted as having separate get/set Value methods.<br>
</blockquote>
<br></span>
I see tons of verbs in the STL - resize, reserve, erase, append, assign, re=
place, push, insert, emplace, swap.<br>
<br>
We also have find, count, sort, search, copy, move, transform, etc in &lt;a=
lgorithm&gt;.<span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
<br>
Bo Persson</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to a topic in the =
Google Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" rel=3D"noreferr=
er" target=3D"_blank">https://groups.google.com/a/isocpp.org/d/topic/std-pr=
oposals/n0QcD_K5dBY/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org" target=3D"_blank">std-pr=
oposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113471067983ee051e3e2aa6--

.

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

>The whole point of PIMPL is indirection of the class's
storage (so that the size/layout can change without affecting ABI).
>That's sort-of the exact opposite as inline class/struct...

I was under the impression that the pimpl ideom was more a way to hide impl=
ementation details. As such the inline class could provide that ability whi=
le not using extra storage. I could of course be wrong.

>So you don't expect the next proposal to be: "Now that we have these nifty=
 properties in the language, why aren't they used by the standard library?"
>And then they will not be optional anymore.

I generally don't use a lot of standard library facilities. However I would=
 not be surprised if they were used under the hood of the facilities I do u=
se. As long as the ABI does not change then what effect does that have?

I agree to implement the usage of properties throughout the standard librar=
y would be a big breaking ABI change. That I do not agree with. However, pr=
oviding a much simpler and cleaner way for a developer to implement the ide=
a of properties if they so wish would be good to help reduce common pitfall=
s. After all is that not why most if not all of c++ exists today? To make C=
 easier and safer to use? Again I could be very wrong here, but that is my =
current belief.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_5345_753728471.1440628190131--

.

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

>The whole point of PIMPL is indirection of the class's
storage (so that the size/layout can change without affecting ABI).
>That's sort-of the exact opposite as inline class/struct...

I was under the impression that the pimpl ideom was more a way to hide impl=
ementation details. As such the inline class could provide that ability whi=
le not using extra storage. I could of course be wrong.

>So you don't expect the next proposal to be: "Now that we have these nifty=
 properties in the language, why aren't they used by the standard library?"
>And then they will not be optional anymore.

I generally don't use a lot of standard library facilities. However I would=
 not be surprised if they were used under the hood of the facilities I do u=
se. As long as the ABI does not change then what effect does that have?

I agree to implement the usage of properties throughout the standard librar=
y would be a big breaking ABI change. That I do not agree with. However, pr=
oviding a much simpler and cleaner way for a developer to implement the ide=
a of properties if they so wish would be good to help reduce common pitfall=
s. After all is that not why most if not all of c++ exists today? To make C=
 easier and safer to use? Again I could be very wrong here, but that is my =
current belief.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_4_1308038291.1440628236989--

.

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

>The whole point of PIMPL is indirection of the class's
storage (so that the size/layout can change without affecting ABI).
>That's sort-of the exact opposite as inline class/struct...

I was under the impression that the pimpl ideom was more a way to hide impl=
ementation details. As such the inline class could provide that ability whi=
le not using extra storage. I could of course be wrong.

>So you don't expect the next proposal to be: "Now that we have these nifty=
 properties in the language, why aren't they used by the standard library?"
>And then they will not be optional anymore.

I generally don't use a lot of standard library facilities. However I would=
 not be surprised if they were used under the hood of the facilities I do u=
se. As long as the ABI does not change then what effect does that have?

I agree to implement the usage of properties throughout the standard librar=
y would be a big breaking ABI change. That I do not agree with. However, pr=
oviding a much simpler and cleaner way for a developer to implement the ide=
a of properties if they so wish would be good to help reduce common pitfall=
s. After all is that not why most if not all of c++ exists today? To make C=
 easier and safer to use? Again I could be very wrong here, but that is my =
current belief.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_97_1703552888.1440628237756--

.

--089e015370f67036ae051e3eb33a
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 26, 2015 at 2:44 PM, Tom Joe <tgit28@gmail.com> wrote:

> > But in the real world you don't do room.lights = on, you turn_switch().
> You don't do door.locked = false, you do unlock_door_with(key).
>
> You walk into a room - are the lights on or off already?
>

is_lit(room)

-or-

room.is_lit()

I don't see how a property is in any way better than that. It's just
different and needless.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e015370f67036ae051e3eb33a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 26, 2015 at 2:44 PM, Tom Joe <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span class=3D"">&gt; =
But in the real world you don&#39;t do room.lights =3D on, you turn_switch(=
).=20
You don&#39;t do door.locked =3D false, you do unlock_door_with(key).<br><b=
r></span>You walk into a room - are the lights on or off already?</div></bl=
ockquote><div><br></div><div>is_lit(room)</div><div><br></div><div>-or-</di=
v><div><br></div><div>room.is_lit()</div><div><br></div><div>I don&#39;t se=
e how a property is in any way better than that. It&#39;s just different an=
d needless.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e015370f67036ae051e3eb33a--

.

--001a113e240633b5ef051e3eccc0
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 26, 2015 at 3:13 PM, Tom Joe <tgit28@gmail.com> wrote:\
>
> "room.lights = on" is entirely a bad programming practice as it implies an
> action being taken.
>
> However, In the exact same sense;  trying to support a
> setting/configuration/count using a method would be bad practice as there
> is no functional action associated with it.
>

What do you even mean by this? What is a "functional action"? Calling a
named function is executing a function, and calling operator = is also
executing a function. The distinction you are trying to make is entirely
artificial.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113e240633b5ef051e3eccc0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Aug 26, 2015 at 3:13 PM, Tom Joe <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.com</a>&gt;</span> wrote=
:\<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:=
1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>&quot;room.lights =
=3D on&quot; is entirely a bad programming practice as it implies an action=
 being taken.<br><br>However, In the exact same sense;=C2=A0 trying to supp=
ort a setting/configuration/count using a method would be bad practice as t=
here is no functional action associated with it.</div></div></blockquote><d=
iv><br></div><div>What do you even mean by this? What is a &quot;functional=
 action&quot;? Calling a named function is executing a function, and callin=
g operator =3D is also executing a function. The distinction you are trying=
 to make is entirely artificial.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113e240633b5ef051e3eccc0--

.

--001a1141cf7802e02f051e3f2581
Content-Type: text/plain; charset=UTF-8

Hey Matt...

The only reason I have ever wanted properties, or something like them, is
to able to reduce the need to type this:

class Something {
    Thing m_thing;
public:
    const Thing& getThing() const { return m_thing; }
    void setThing(const Thing& thing) { m_thing = thing; }
};

and instead be able to just say any variation of this:

class Something {
public:
    property Thing thing;
};

I want this solely from a notational brevity perspective. There are others
in this thread who want other features - that's fine by me, but they're not
the reason I'd support some solution.  I'm also quite happy if there's some
clever way to do this using existing language features.

class Something {
public:
    std::property<Thing> thing;
};

I don't mind, notationally, any of these on the calling side:

my_something.thing() = blah;
my_something.thing().set(blah);
my_something.thing->set(blah);

etc.

So... I may be diverging from the other folks in this thread on this
point.  I think the key idea would be that in the future, should I need to
explicitly call out the implementation of one of these methods, like this:

// in the future...
class FutureSomething {
     NewThingInRadiansInsteadOfDegrees m_new_thing;
public:
    float get_thing() const { return radians_to_degrees(m_new_thing); }
    void set_thing(float thing_in_degrees) { m_new_thing =
degrees_to_radians(thing_in_degrees); }
};

The above is a contrived example - a more practical one that I ran into
recently is where a rigid transform had previously been expressed as a 4x4
matrix, and was now expressed as a unit quaternion (stored as only two
values) and a translation - but the "setTransform" functions still needed
to support the 4x4 matrix case for backwards compatibility.

Please pardon my programming metaphor mixing here.

Chris


On Wed, Aug 26, 2015 at 3:52 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, Aug 26, 2015 at 2:44 PM, Tom Joe <tgit28@gmail.com> wrote:
>
>> > But in the real world you don't do room.lights = on, you turn_switch().
>> You don't do door.locked = false, you do unlock_door_with(key).
>>
>> You walk into a room - are the lights on or off already?
>>
>
> is_lit(room)
>
> -or-
>
> room.is_lit()
>
> I don't see how a property is in any way better than that. It's just
> different and needless.
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1141cf7802e02f051e3f2581
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hey Matt...<div><br></div><div>The only reason I have ever=
 wanted properties, or something like them, is to able to reduce the need t=
o type this:</div><div><br></div><div>class Something {</div><div>=C2=A0 =
=C2=A0 Thing m_thing;</div><div>public:</div><div>=C2=A0 =C2=A0 const Thing=
&amp; getThing() const { return m_thing; }=C2=A0</div><div>=C2=A0 =C2=A0 vo=
id setThing(const Thing&amp; thing) { m_thing =3D thing; }</div><div>};</di=
v><div><br></div><div>and instead be able to just say any variation of this=
:</div><div><br></div><div>class Something {</div><div>public:</div><div>=
=C2=A0 =C2=A0 property Thing thing;</div><div>};</div><div><br></div><div>I=
 want this solely from a notational brevity perspective. There are others i=
n this thread who want other features - that&#39;s fine by me, but they&#39=
;re not the reason I&#39;d support some solution.=C2=A0 I&#39;m also quite =
happy if there&#39;s some clever way to do this using existing language fea=
tures.</div><div><br></div><div>class Something {</div><div>public:</div><d=
iv>=C2=A0 =C2=A0 std::property&lt;Thing&gt; thing;</div><div>};</div><div><=
br></div><div>I don&#39;t mind, notationally, any of these on the calling s=
ide:</div><div><br></div><div>my_something.thing() =3D blah;</div><div>my_s=
omething.thing().set(blah);</div><div>my_something.thing-&gt;set(blah);</di=
v><div><br></div><div>etc.</div><div><br></div><div>So... I may be divergin=
g from the other folks in this thread on this point.=C2=A0 I think the key =
idea would be that in the future, should I need to explicitly call out the =
implementation of one of these methods, like this:</div><div><br></div><div=
>// in the future...</div><div>class FutureSomething {</div><div>=C2=A0 =C2=
=A0 =C2=A0NewThingInRadiansInsteadOfDegrees m_new_thing;</div><div>public:<=
/div><div>=C2=A0 =C2=A0 float get_thing() const { return radians_to_degrees=
(m_new_thing); }</div><div>=C2=A0 =C2=A0 void set_thing(float thing_in_degr=
ees) { m_new_thing =3D degrees_to_radians(thing_in_degrees); }</div><div>};=
</div><div><br></div><div>The above is a contrived example - a more practic=
al one that I ran into recently is where a rigid transform had previously b=
een expressed as a 4x4 matrix, and was now expressed as a unit quaternion (=
stored as only two values) and a translation - but the &quot;setTransform&q=
uot; functions still needed to support the 4x4 matrix case for backwards co=
mpatibility.</div><div><br></div><div>Please pardon my programming metaphor=
 mixing here.</div><div><br></div><div>Chris=C2=A0</div><div><br></div></di=
v><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug 26,=
 2015 at 3:52 PM, &#39;Matt Calabrese&#39; via ISO C++ Standard - Future Pr=
oposals <span dir=3D"ltr">&lt;<a href=3D"mailto:std-proposals@isocpp.org" t=
arget=3D"_blank">std-proposals@isocpp.org</a>&gt;</span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div cla=
ss=3D"gmail_quote"><span class=3D"">On Wed, Aug 26, 2015 at 2:44 PM, Tom Jo=
e <span dir=3D"ltr">&lt;<a href=3D"mailto:tgit28@gmail.com" target=3D"_blan=
k">tgit28@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><div dir=3D"ltr"><span>&gt; But in the real world you don&#39;t do room.li=
ghts =3D on, you turn_switch().=20
You don&#39;t do door.locked =3D false, you do unlock_door_with(key).<br><b=
r></span>You walk into a room - are the lights on or off already?</div></bl=
ockquote><div><br></div></span><div>is_lit(room)</div><div><br></div><div>-=
or-</div><div><br></div><div>room.is_lit()</div><div><br></div><div>I don&#=
39;t see how a property is in any way better than that. It&#39;s just diffe=
rent and needless.</div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
<br>
--- <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" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1141cf7802e02f051e3f2581--

.

On 8/26/2015 6:23 PM, Christopher Horvath wrote:
> ...and instead be able to just say any variation of this:
>
> class Something {
> public:
>      property Thing thing;
> };

What does the "property" keyword here provide? Couldn't you just have a
public member variable? It seems to me that the benefit of properties is
being able to write a getter/setter, which would probably look a lot
like writing traditional getX/setX member functions.

- Jim

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113ece66680b45051e3f50bd
Content-Type: text/plain; charset=UTF-8

On Wed, Aug 26, 2015 at 4:28 PM, Jim Porter <jvp4846@g.rit.edu> wrote:

> On 8/26/2015 6:23 PM, Christopher Horvath wrote:
>
>> ...and instead be able to just say any variation of this:
>>
>> class Something {
>> public:
>>      property Thing thing;
>> };
>>
>
> What does the "property" keyword here provide? Couldn't you just have a
> public member variable? It seems to me that the benefit of properties is
> being able to write a getter/setter, which would probably look a lot like
> writing traditional getX/setX member functions.


Hey Jim,

I was doing notation handwaving, which I realize is contrary to the purpose
of this list and this thread.  All I'm trying to get at is,

"some way to indicate that I want a standard getter/setter wrapper around a
struct member named 'thing', that only requires me to type the thing and
its type once".

with the added feature,

"and I'm able to make a more complex wrapper in the future, should I need
to".

This comes up in geometry code all the time - a property (like length) goes
from being a struct member to a derived quantity, or vice versa.  That's
why we don't just say:

struct Something {
    Thing thing;
};

Because we can never undo that, at an API level.  The functional thing() we
can undo, but it is tedious to always write the getter/setter/value (or
more, with const stuff) thing.



>
>
> - Jim
>
>
> --
>
> --- 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113ece66680b45051e3f50bd
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Wed, Aug 26, 2015 at 4:28 PM, Jim Porter <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:jvp4846@g.rit.edu" target=3D"_blank">jvp4846@g.rit.edu</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex">On 8/26/2015 6:23 PM, Chri=
stopher Horvath wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
....and instead be able to just say any variation of this:<span class=3D""><=
br>
<br>
class Something {<br>
public:<br>
=C2=A0 =C2=A0 =C2=A0property Thing thing;<br>
};<br>
</span></blockquote>
<br>
What does the &quot;property&quot; keyword here provide? Couldn&#39;t you j=
ust have a public member variable? It seems to me that the benefit of prope=
rties is being able to write a getter/setter, which would probably look a l=
ot like writing traditional getX/setX member functions.</blockquote><div><b=
r></div><div>Hey Jim,</div><div><br></div><div>I was doing notation handwav=
ing, which I realize is contrary to the purpose of this list and this threa=
d.=C2=A0 All I&#39;m trying to get at is,</div><div><br></div><div>&quot;so=
me way to indicate that I want a standard getter/setter wrapper around a st=
ruct member named &#39;thing&#39;, that only requires me to type the thing =
and its type once&quot;.</div><div><br></div><div>with the added feature,</=
div><div><br></div><div>&quot;and I&#39;m able to make a more complex wrapp=
er in the future, should I need to&quot;.</div><div><br></div><div>This com=
es up in geometry code all the time - a property (like length) goes from be=
ing a struct member to a derived quantity, or vice versa.=C2=A0 That&#39;s =
why we don&#39;t just say:</div><div><br></div><div>struct Something {</div=
><div>=C2=A0 =C2=A0 Thing thing;</div><div>};</div><div><br></div><div>Beca=
use we can never undo that, at an API level.=C2=A0 The functional thing() w=
e can undo, but it is tedious to always write the getter/setter/value (or m=
ore, with const stuff) thing.</div><div><br></div><div>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex"><span class=3D"HOEnZb"><font color=3D"#888888"><br>
<br>
- Jim</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ece66680b45051e3f50bd--

.

On 8/26/2015 6:36 PM, Christopher Horvath wrote:
> "some way to indicate that I want a standard getter/setter wrapper
> around a struct member named 'thing', that only requires me to type the
> thing and its type once". ... "and I'm able to make a more complex
 > wrapper in the future, should I need to".

Ok, that makes sense. I suppose I'd probably implement that as a member
variable first, and upgrade to a property later.

I will say I rather like properties in other languages for the
maintenance reasons you point out, and that they signal a different
intent to me; others in this thread have had the concern that a property
makes slow things (complex function calls) look fast (like member
accesses), but I tend to use properties for things that are fast, and
functions for things that are slow. In other words, it's a way of
annotating the "weight" of a call.

I'm not entirely convinced that the complexity of properties is worth
it, though. One major concern I have is how C++ would handle `foo.bar +=
2;` when bar is a property. In other languages, this usually expands to
`foo.bar = foo.bar + 2;`, but I'm not sure that makes sense for C++,
where you'd normally have to overload += to do that. Perhaps the "inline
class" suggestion would resolve this.

-  Jim

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113366be84b4bb051e45023c
Content-Type: text/plain; charset=UTF-8

>room.is_lit()

The prefix "Is" is a commonly used "boolean" syntax clarifier in every
language.  We can all look at that and say it'll return T/F.

That is exactly the same idea as property notation.

-----  If it acts like a variable member it should look like a variable
member and not a function.  -----

While one could say assigning values to any variable is still at its most
basic level a function; the intent is not the same.  A functional action
would be the "processing" or action the object takes to execute a written
algorithm that produces some intended effect for the user.  A function
"uses" properties to know exactly how to process said information.  In a
sense it is an entirely an artificial artifact that bring clarity to the
program architecture and its member purpose/usage just like an "Is" prefix.

However, you can't use "Is" for my previous example of 'TheCar.Color()' <-
Is that intended to color the car or return the "already" color of the
car??  Properties provide a syntax that instantly tells the user if the
member is a "verb or noun".  And how would our "room.turn_light_on()" know
if it is being used in a 120V or 12V system?

>wrapper in the future

As Jim mentioned - an empty wrapper provides one purpose and that is the
expansion of it without breaking interfaces.  Otherwise it could just be a
public variable.

---- Properties fill the gap between a public variable and function ----

Expand-ability of course plays a huge role in programming.  This is were
"properties" shine.  C++ has no first-class value wrapping capabilities; so
as such that "value wrapping" get done by hacking/overloading function
calls.  Even on a pure 1:1 function-to-value we end up with 2x the
Interface of a public variable by adding Get/Set functions.


On Wed, Aug 26, 2015 at 4:52 PM, 'Matt Calabrese' via ISO C++ Standard -
Future Proposals <std-proposals@isocpp.org> wrote:

> On Wed, Aug 26, 2015 at 2:44 PM, Tom Joe <tgit28@gmail.com> wrote:
>
>> > But in the real world you don't do room.lights = on, you turn_switch().
>> You don't do door.locked = false, you do unlock_door_with(key).
>>
>> You walk into a room - are the lights on or off already?
>>
>
> is_lit(room)
>
> -or-
>
> room.is_lit()
>
> I don't see how a property is in any way better than that. It's just
> different and needless.
>
> --
>
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe
> .
> To unsubscribe from this group and all its topics, send an email to
> std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113366be84b4bb051e45023c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div><div>&gt;room.is_lit()<br><br></div>The prefix &=
quot;Is&quot; is a commonly used &quot;boolean&quot; syntax clarifier in ev=
ery language.=C2=A0 We can all look at that and say it&#39;ll return T/F.<b=
r><br></div>That is exactly the same idea as property notation.<br><br>----=
-=C2=A0 If it acts like a variable member it should look like a variable me=
mber and not a function.=C2=A0 -----<br><br>While one could say assigning v=
alues to any variable is still at its most basic level a function; the inte=
nt is not the same.=C2=A0 A functional action would be the &quot;processing=
&quot; or action the object takes to execute a written algorithm that produ=
ces some intended effect for the user.=C2=A0 A function &quot;uses&quot; pr=
operties to know exactly how to process said information.=C2=A0 In a sense =
it is an entirely an artificial artifact that bring clarity to the program =
architecture and its member purpose/usage just like an &quot;Is&quot; prefi=
x.<br><br></div>However, you can&#39;t use &quot;Is&quot; for my previous e=
xample of &#39;TheCar.Color()&#39; &lt;- Is that intended to color the car =
or return the &quot;already&quot; color of the car??=C2=A0 Properties provi=
de a syntax that instantly tells the user if the member is a &quot;verb or =
noun&quot;.=C2=A0 And how would our &quot;room.turn_light_on()&quot; know i=
f it is being used in a 120V or 12V system?<br><div><br></div><div>&gt;wrap=
per in the future<br><br></div><div>As Jim mentioned - an empty wrapper pro=
vides one purpose and that is the expansion of it without breaking interfac=
es.=C2=A0 Otherwise it could just be a public variable.=C2=A0 <br><br>---- =
Properties fill the gap between a public variable and function ----<br><br>=
</div><div>Expand-ability of course plays a huge role in programming.=C2=A0=
 This is were &quot;properties&quot; shine.=C2=A0 C++ has no first-class va=
lue wrapping capabilities; so as such that &quot;value wrapping&quot; get d=
one by hacking/overloading function calls.=C2=A0 Even on a pure 1:1 functio=
n-to-value we end up with 2x the Interface of a public variable by adding G=
et/Set functions.<br><br></div></div><div class=3D"gmail_extra"><br><div cl=
ass=3D"gmail_quote">On Wed, Aug 26, 2015 at 4:52 PM, &#39;Matt Calabrese&#3=
9; via ISO C++ Standard - Future Proposals <span dir=3D"ltr">&lt;<a href=3D=
"mailto:std-proposals@isocpp.org" target=3D"_blank">std-proposals@isocpp.or=
g</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><span class=3D"">On W=
ed, Aug 26, 2015 at 2:44 PM, Tom Joe <span dir=3D"ltr">&lt;<a href=3D"mailt=
o:tgit28@gmail.com" target=3D"_blank">tgit28@gmail.com</a>&gt;</span> wrote=
:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-le=
ft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><span>&gt; But in the =
real world you don&#39;t do room.lights =3D on, you turn_switch().=20
You don&#39;t do door.locked =3D false, you do unlock_door_with(key).<br><b=
r></span>You walk into a room - are the lights on or off already?</div></bl=
ockquote><div><br></div></span><div>is_lit(room)</div><div><br></div><div>-=
or-</div><div><br></div><div>room.is_lit()</div><div><br></div><div>I don&#=
39;t see how a property is in any way better than that. It&#39;s just diffe=
rent and needless.</div></div></div></div><div class=3D"HOEnZb"><div class=
=3D"h5">

<p></p>

-- <br>
<br>
--- <br>
You received this message because you are subscribed to a topic in the Goog=
le Groups &quot;ISO C++ Standard - Future Proposals&quot; group.<br>
To unsubscribe from this topic, visit <a href=3D"https://groups.google.com/=
a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY/unsubscribe" target=3D"_blan=
k">https://groups.google.com/a/isocpp.org/d/topic/std-proposals/n0QcD_K5dBY=
/unsubscribe</a>.<br>
To unsubscribe from this group and all its topics, send an email to <a href=
=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_blank">std-prop=
osals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113366be84b4bb051e45023c--

.

2015-08-27 0:29 GMT+02:00 Izzy Coding <matthew.i.greenwood@gmail.com>:
> I agree to implement the usage of properties throughout the standard library would be a big breaking ABI change. That I do not agree with.

Why not?
MSVC breaks ABI on every major compiler release.
GCC breaks ABI sometimes as well..


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wed, Aug 26, 2015 at 11:08:36AM -0700, Nicol Bolas wrote:
>
> Ugh. I hate properties, but I hate hacks more. If properties are important
> enough to have, then they should be exactly what they are: syntactic sugar
> around syntax. `var.prop` as part of a non-assignment expression calls a
> getter function. `var.prop` as part of an assignment expression calls a
> setter function. One of the modifying assignment operators should
> automatically work as a getter followed by the modification followed by the
> setter.

How would this interact with threads?

/MF

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

I am just wondering if the real problem here is the definition of what a "p=
roperty" actually is?

To me it is essentially public const access to a value for assignment from =
or comparison, and a function call to assign to a variable. In essence some=
thing like this:

class Something {
public:
    property<type> namedThing (type&& value) {
        // set function declaration
    };
};

Is equivalent to:
class Something {
public:
    type namedThing() const { return m_namedThing; }
    void namedThing(type&& value) { // defined set function body }
private:
    type m_namedThing;
};
Where "mySomething.namedThing =3D value;" is translated to "mySomething.nam=
edThing(value);" and "a =3D mySomething.namedThing;" is translated to "a =
=3D mySomething.namedThing();"

Surely this is just a way to simplify implementation of this feature that i=
s implemented in various different ways already. Those who use this feature=
 would be aware of its requirements and limitation. Those who are against i=
t can simply not use it like so many others do now with current things in t=
he standard.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

------=_Part_299_898148279.1440675791998--

.

On 27 August 2015 at 14:43, Izzy Coding <matthew.i.greenwood@gmail.com> wro=
te:
> I am just wondering if the real problem here is the definition of what a =
"property" actually is?
>
> To me it is essentially public const access to a value for assignment fro=
m or comparison, and a function call to assign to a variable. In essence so=
mething like this:
>
> class Something {
> public:
>     property<type> namedThing (type&& value) {
>         // set function declaration
>     };
> };
>
> Is equivalent to:
> class Something {
> public:
>     type namedThing() const { return m_namedThing; }
>     void namedThing(type&& value) { // defined set function body }
> private:
>     type m_namedThing;
> };
> Where "mySomething.namedThing =3D value;" is translated to "mySomething.n=
amedThing(value);" and "a =3D mySomething.namedThing;" is translated to "a =
=3D mySomething.namedThing();"

I wonder whether you intended to write that pseudocode so that it
doesn't work with a move-only
member, like unique_ptr.

>
> Surely this is just a way to simplify implementation of this feature that=
 is implemented in various different ways already. Those who use this featu=
re would be aware of its requirements and limitation. Those who are against=
 it can simply not use it like so many others do now with current things in=
 the standard.


My observation is that some people don't buy the design rationale of
properties in general,
as opposed to using member functions from the get-go. Other reason for
opposition
seems to be that people don't see the rationale as something worth
spending specification
time on.

My personal view is that properties are still sold as a convenient way
to turn data members
into something more complicated without changing the syntax clients
use for accessing
them. I don't see that as a very convincing rationale. Thus far I have
seen very little that
really requires a language extension as opposed to a library utility
type std::property<T>.

It has also been said previously that a new proposal in this area
should look at why
previous attempts at getting properties failed and explain why this
hypothetical new
proposal is better.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On Thursday 27 August 2015 08:41:50 Olaf van der Spek wrote:
> 2015-08-27 0:29 GMT+02:00 Izzy Coding <matthew.i.greenwood@gmail.com>:
> > I agree to implement the usage of properties throughout the standard
> > library would be a big breaking ABI change. That I do not agree with.
> Why not?
> MSVC breaks ABI on every major compiler release.
> GCC breaks ABI sometimes as well..

There has been one break in 12 years for GCC and it's limited at std::string.
If you don't use std::string, your binaries built with GCC 3.4 still work
today.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

2015-08-27 17:02 GMT+02:00 Thiago Macieira <thiago@macieira.org>:
> On Thursday 27 August 2015 08:41:50 Olaf van der Spek wrote:
>> 2015-08-27 0:29 GMT+02:00 Izzy Coding <matthew.i.greenwood@gmail.com>:
>> > I agree to implement the usage of properties throughout the standard
>> > library would be a big breaking ABI change. That I do not agree with.
>> Why not?
>> MSVC breaks ABI on every major compiler release.
>> GCC breaks ABI sometimes as well..
>
> There has been one break in 12 years for GCC and it's limited at std::string.
> If you don't use std::string, your binaries built with GCC 3.4 still work
> today.

You didn't answer the question. ;)

Also, didn't they break std::list for C++11 conformance (when using C++11 ABI)?


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

>>> I agree to implement the usage of properties throughout the standard
>>> library would be a big breaking ABI change. That I do not agree with.
>> Why not?
>> MSVC breaks ABI on every major compiler release.
>> GCC breaks ABI sometimes as well..
> There has been one break in 12 years for GCC and it's limited at std::string.
> If you don't use std::string, your binaries built with GCC 3.4 still work
> today.

Ok, so now we know that properties break ABI already, even we don't know how they exactly will be implemented and what will be the syntax. How this is possible? Clairvoyance, superpowers?

Anyways, if we assume properties are just syntactic sugar around normal member calls, how this could break ABI? (This is something different from inline class/struct, which is completely different solution)

-- Adam

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 18:29, Izzy Coding wrote:
>> The whole point of PIMPL is indirection of the class's
> storage (so that the size/layout can change without affecting ABI).
>> That's sort-of the exact opposite as inline class/struct...
>
> I was under the impression that the pimpl ideom was more a way to
> hide implementation details. As such the inline class could provide that
> ability while not using extra storage. I could of course be wrong.

Hmm... okay, this somewhat contradicts what I said previously, but on
further thought, I suppose there is no particular reason one couldn't
forward declare an inline class and define it later. A class can even
contain a member of that type, because by definition an inline class has
zero size. So I guess you *could* do something like:

  // foo.h
  class Foo
  {
    inline class Private p;
    friend inline class Private;
    ...
  };

  // foo.cpp
  inline class Foo::Private
  {
    // ...private methods...
  };


Note however that you can't hide private *data* members like this, so
it's of limited use. On further thought, I also think it's okay for
encapsulation... while some other TU could redefine Foo::Private, only
Foo has access to the instance thereof (member 'p'), so you don't really
gain anything.

However, I honestly don't see the point. You can't have virtual members
this way (in fact, I think inline classes necessarily cannot have
virtual members at all), and you can't have storage... and non-virtual
private members can AFAIK be added, changed and removed without
affecting BC, so I don't see that you gain much of value.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 17:45, Bo Persson wrote:
> On 2015-08-26 23:03, Izzy Coding wrote:
>> I fail to see the points against "properties" when people just say
>> that they hate them.  If that is the case then you don't have to use
>> them.
>
> So you don't expect the next proposal to be: "Now that we have these
> nifty properties in the language, why aren't they used by the standard
> library?"
>
> And then they will not be optional anymore.

*If* they are added, I would expect it would be in a way that is at
least SC if not BC, and therefore they *would* remain optional. (I can't
imagine any proposal to break SC of STL having much hope of success. Not
without very, very good reason, anyway, and I can't see properties being
such a reason.)

An interesting question is, can you turn an accessor into a property
while preserving SC? With *inline classes*, the answer is "yes" (just
add an operator()(...)). With "real properties"... um...

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-27 11:22, Adam Strzelecki wrote:
> Ok, so now we know that properties break ABI already, even we don't know how they exactly will be implemented and what will be the syntax. How this is possible? Clairvoyance, superpowers?
>
> Anyways, if we assume properties are just syntactic sugar around normal member calls, how this could break ABI?

The only way that will work is if a property get is a way of decorating
a member such that you can omit the ()'s when calling it. Which I
suspect is rife with problems:

  auto q = my_vector.size; // PTMF? size_t?

(Not to mention that for SC we need to allow a superfluous '()' after a
property name to be silently ignored. Which, for some data types, could
also cause a change in meaning...)

Otherwise, the reason we know there will be BC issues is that the member
'size' will newly be a property, where before it was a member function.
I doubt there is a miraculous way to avoid a BIC here *if* we insist
that things like std::vector::size become properties with the exact same
name.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-26 17:25, 'Matt Calabrese' wrote:
> I personally "hate" them because nobody has presented code where properties
> solve *anything* at all in a way that is simpler than what can already be
> done in the language, short of maybe removing "()".

I think the biggest advantage would be allowing arithmetic operations on
values that need to respond specially to changes, whether by bounds
checking, triggering events on change, etc. without forcing the user to
deal with differently named members for each possible operation, in
cases where it makes more sense for the special handling to be bound to
the owning class rather than wrapped in a value-like class.

IOW:

  class Player {
    class Health
    {
      /* operators */
    } health;
  };

- vs. -

  class Player
  {
    int health() const;
    void setHealth(int);
    void addHealth(int);
    void removeHealth(int);
  };

The first requires additional storage (the Player::Health instance needs
to know about the Player instance). The latter requires the user to know
multiple method names vs. using ordinary arithmetic operators. A
property / inline class gives the best of both.

> Please provide an example of:
>
> * A problem that properties solve that you can't already do with a similar
> amount of constructs in the language already.

I submit range-based for as a counterexample to that. It's syntax sugar
that (AFAIK) doesn't provide anything that isn't otherwise possible;
merely saves typing. Yet it was (rightly, IMO) felt useful enough to be
added.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-27 04:02, Magnus Fromreide wrote:
> On Wed, Aug 26, 2015 at 11:08:36AM -0700, Nicol Bolas wrote:
>> Ugh. I hate properties, but I hate hacks more. If properties are important
>> enough to have, then they should be exactly what they are: syntactic sugar
>> around syntax. `var.prop` as part of a non-assignment expression calls a
>> getter function. `var.prop` as part of an assignment expression calls a
>> setter function. One of the modifying assignment operators should
>> automatically work as a getter followed by the modification followed by the
>> setter.
>
> How would this interact with threads?

Hmm... good point. With an inline class, you can make an operator+= (for
example) that locks a mutex before doing anything. How would that work
with the above?

(For that matter, I don't think the above would work even if the
underlying member being modified is std::atomic, whereas an inline class
could potentially forward to the underlying member's atomic add operation.)

On 2015-08-27 08:25, Ville Voutilainen wrote:
> Thus far I have seen very little that really requires a language
> extension as opposed to a library utility type std::property<T>.

Where this gets tricks is overloading the property operators. You
*maybe* can do it with lambdas, or specialization (or using your own
class per property), but those solutions get ugly, have storage
complications (either a) the property object itself must store the
internal value, which won't work in all cases, or b) must store a
reference to either the underlying value or the parent class, which uses
additional storage), and make access protection more difficult.

An inline class has no access protection problems (it is implicitly a
friend of the containing class, (an inline class for example is
implicitly a friend of the containing class and can access its private
members, like any other nested class). It uses no additional storage
because its storage is the containing class, and therefore also
eliminates issues with where the underlying data lives. And operators
are defined inline in the normal manner, so no lambdas are needed.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5243_905407741.1440692503379
Content-Type: multipart/alternative;
 boundary="----=_Part_5244_439651201.1440692503379"

------=_Part_5244_439651201.1440692503379
Content-Type: text/plain; charset=UTF-8

On Thursday, August 27, 2015 at 12:04:04 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-26 17:25, 'Matt Calabrese' wrote:
> > I personally "hate" them because nobody has presented code where
> properties
> > solve *anything* at all in a way that is simpler than what can already
> be
> > done in the language, short of maybe removing "()".
>
> I think the biggest advantage would be allowing arithmetic operations on
> values that need to respond specially to changes, whether by bounds
> checking, triggering events on change, etc. without forcing the user to
> deal with differently named members for each possible operation, in
> cases where it makes more sense for the special handling to be bound to
> the owning class rather than wrapped in a value-like class.
>
> IOW:
>
>   class Player {
>     class Health
>     {
>       /* operators */
>     } health;
>   };
>
> - vs. -
>
>   class Player
>   {
>     int health() const;
>     void setHealth(int);
>     void addHealth(int);
>     void removeHealth(int);
>   };
>
> The first requires additional storage (the Player::Health instance needs
> to know about the Player instance). The latter requires the user to know
> multiple method names vs. using ordinary arithmetic operators. A
> property / inline class gives the best of both.
>

Unless "requiring the user to know multiple method names" is itself a
*feature* rather than a bug, of course. Being able to find things
operations easily should not be dismissed.


> > Please provide an example of:
> >
> > * A problem that properties solve that you can't already do with a
> similar
> > amount of constructs in the language already.
>
> I submit range-based for as a counterexample to that. It's syntax sugar
> that (AFAIK) doesn't provide anything that isn't otherwise possible;
> merely saves typing. Yet it was (rightly, IMO) felt useful enough to be
> added.
>

Range-based for does solve a problem. Namely, this one:

for(iterator_type curr = v.begin(); curr != v.end(); curr++)

This loop will call `v.end` a lot, once per element, which can be an
expensive operation. It will also post-increment the iterator, which may be
more expensive than pre-incrementing it (or even be unavailable). Also, you
have to get the reference yourself.

Syntactic sugar can be justified if it is replacing a frequently seen
coding pattern that is also frequently *mis*used.

I've seen very few large codebases that would be unable to use range-based
for to replace non-range fors (even if they're not using iterators).
Whereas I've seen lots of codebases that never came anywhere close to
implementing even the simplest form of properties.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Thursday, August 27, 2015 at 12:04:04 PM UTC-4, Matthew Woehlke wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-26 17:25, &#39;Matt C=
alabrese&#39; wrote:
<br>&gt; I personally &quot;hate&quot; them because nobody has presented co=
de where properties
<br>&gt; solve *anything* at all in a way that is simpler than what can alr=
eady be
<br>&gt; done in the language, short of maybe removing &quot;()&quot;.
<br>
<br>I think the biggest advantage would be allowing arithmetic operations o=
n
<br>values that need to respond specially to changes, whether by bounds
<br>checking, triggering events on change, etc. without forcing the user to
<br>deal with differently named members for each possible operation, in
<br>cases where it makes more sense for the special handling to be bound to
<br>the owning class rather than wrapped in a value-like class.
<br>
<br>IOW:
<br>
<br>=C2=A0 class Player {
<br>=C2=A0 =C2=A0 class Health
<br>=C2=A0 =C2=A0 {
<br>=C2=A0 =C2=A0 =C2=A0 /* operators */
<br>=C2=A0 =C2=A0 } health;
<br>=C2=A0 };
<br>
<br>- vs. -
<br>
<br>=C2=A0 class Player
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 int health() const;
<br>=C2=A0 =C2=A0 void setHealth(int);
<br>=C2=A0 =C2=A0 void addHealth(int);
<br>=C2=A0 =C2=A0 void removeHealth(int);
<br>=C2=A0 };
<br>
<br>The first requires additional storage (the Player::Health instance need=
s
<br>to know about the Player instance). The latter requires the user to kno=
w
<br>multiple method names vs. using ordinary arithmetic operators. A
<br>property / inline class gives the best of both.
<br></blockquote><div><br>Unless &quot;requiring the user to know multiple =
method names&quot; is itself a <i>feature</i> rather than a bug, of course.=
 Being able to find things operations easily should not be dismissed.<br><b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0=
..8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<br>&gt; Please provide an example of:
<br>&gt;=20
<br>&gt; * A problem that properties solve that you can&#39;t already do wi=
th a similar
<br>&gt; amount of constructs in the language already.
<br>
<br>I submit range-based for as a counterexample to that. It&#39;s syntax s=
ugar
<br>that (AFAIK) doesn&#39;t provide anything that isn&#39;t otherwise poss=
ible;
<br>merely saves typing. Yet it was (rightly, IMO) felt useful enough to be
<br>added.<br></blockquote><div><br>Range-based for does solve a problem. N=
amely, this one:<br><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">for</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">iter=
ator_type curr </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> v=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">begin</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> curr </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">!=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> v</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">.</span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">end</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">();</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> curr</span><span style=3D"color: #660;" class=3D"styled-by-prettify">++=
)</span></div></code></div><br>This loop will call `v.end` a lot, once per =
element, which can be an expensive operation. It will also post-increment t=
he iterator, which may be more expensive than pre-incrementing it (or even =
be unavailable). Also, you have to get the reference yourself.<br><br>Synta=
ctic sugar can be justified if it is replacing a frequently seen coding pat=
tern that is also frequently <i>mis</i>used.<br><br>I&#39;ve seen very few =
large codebases that would be unable to use range-based for to replace non-=
range fors (even if they&#39;re not using iterators). Whereas I&#39;ve seen=
 lots of codebases that never came anywhere close to implementing even the =
simplest form of properties.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5244_439651201.1440692503379--
------=_Part_5243_905407741.1440692503379--

.

On 2015-08-27 12:21, Nicol Bolas wrote:
> Unless "requiring the user to know multiple method names" is itself a
> *feature* rather than a bug, of course. Being able to find things
> operations easily should not be dismissed.

  grep -E '\.health\s*\+=' # vs. '\.addHealth'

....what's the problem, again?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_787_1801053074.1440694731206
Content-Type: multipart/alternative;
 boundary="----=_Part_788_663933610.1440694731206"

------=_Part_788_663933610.1440694731206
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-26 14:08, Nicol Bolas wrote:
> > On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4, Matthew Woehlke
> wrote:
> >> based on the recent discussions, it seems to me that *IF* we
> >> added properties, they should look something like:
> >
> > Ugh. I hate properties, but I hate hacks more. If properties are
> important
> > enough to have, then they should be exactly what they are: syntactic
> sugar
> > around syntax. `var.prop` as part of a non-assignment expression calls a
> > getter function. `var.prop` as part of an assignment expression calls a
> > setter function.
>
> That's exactly how an inline class *works*. You *MUST* define the
> get/set methods somewhere. At "best", by your logic, you would have:
>
>   class Foo {
>     int property bar get() const;
>     property bar set(int);
>   };
>
> I've suggested exactly the same thing, but with the property name as a
> scope, and reusing existing keywords and constructs rather than
> introducing new ones. Only my suggestion opens up a lot of *additional*
> possibilities.
>
> > One of the modifying assignment operators should automatically work
> > as a getter followed by the modification followed by the setter.
>
> This requires a substantial change to language semantics, and I'm not
> entirely convinced it is always TRTTD.
>

You're the one who wants properties. I'm just outlining what has to be done
to get them in a non-hacky way.


> With inline classes, you could achieve this easily with a mixin.
>
> > A "property" should not be some type that implements methods.
>
> Ignoring the second half of that,


No, you can't do that. That half of the statement is important. If you
ignore it, then the statement means something I wasn't saying.


> if it's not a type, how do you solve
> the problem of someone taking a reference to the property and
> subsequently modifying it?
>

Property methods return whatever they choose to return. If a getter returns
by value, then it returns by value. There are no syntactic guarantees in
properties that require a getter to return a real reference to an actual
value that will be updated when the value is changed.


>
> > It should not have storage.
>
> There has to be storage *somewhere*. Both properties and inline classes
> use the parent for that storage.
>

No, there doesn't.

You're thinking of properties as things that represent some type. But they
don't have to. C# properties do not *have* to be get/set pairs wrapped
around a particular variable. They're just functions, one returns a value,
the other is given a value. What you do internally is up to you.

Two separate properties could be using the same storage. A property could
be reading from/writing to multiple pieces of storage. Or one could be
making a value up entirely from whole cloth without any storage whatsoever.


> > It should not consist of anything more than 2 function
> > declarations/definitions.
>
> Most inline class "properties" won't.
>

It consists of a class definition. That makes it more than 2 function
definitions.

> To put it another way, we should not add a couple of special-case
> syntaxes
> > to make library property hacks work.
>
> That's not at all what I suggested. (I'll also point out that what I
> suggested was exactly *one* syntax, not "a couple". Nor did I at any
> point call on a library to provide boilerplate code.)
>
> I admit that trivial support for modifying operators may require some
> library help, but I think that's more than worth it, considering the
> advantages:
>
>  - No new keywords.
>
>  - Ability to reuse get/set logic for multiple properties, even in
>    multiple parent types.
>
>  - Additional potential use outside of "properties".
>
>  - Minimal changes to the language.
>
> The only language change for inline classes, really, is the new "inline
> class/struct" syntax, and the concept that the storage of such an object
> is the same as the parent. For "proper properties", besides the syntax
> (and I'm not sure how you'll avoid new keywords),


So what if it needs keywords? We should not implement a feature in an ugly
or unintuitive way (and it's hard to claim that your way of using type
conversion and having to overload every assignment operator is not
unintuitive) just because doing it right would using keywords. If the
feature is something worthwhile, then it is something worth using the
appropriate syntax for. Not merely the quickest syntax to get it
standardized.

Also, they could be contextual keywords.

Don't forget you've also introduces some new magical
> "property reference type" so that you can write 'auto& prop = foo.bar;
> prop += 4;'.


That one's not magic. `foo.bar`, when not used as the left side of an
assignment expression, calls the getter function. The getter will return
whatever it returns.


> Inline classes just leverage existing language features for
> all of this.
>
> > Unless there is some other use for these inline classes, I'm against
> using
> > them as a way to put properties into the language.
>
> Sort of related, but how about this?
>
>   auto c = get_color();
>   c.hsl.hue = 15;
>   cout << c.hcy.hue;
>
> The outer inline class is used to manipulate the object "as an X", i.e.
> such that various possibly X's have methods/"properties" of the same
> name, but different semantics. Something like a downcast, except you can
> "downcast" to multiple types at the same hierarchy level.
>

Any form of properties could do that. I asked if there was some
*non-property* use for inline classes. Are they a generic tool that could
be used for something other than kludging together a property solution?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-26 14:08, Nic=
ol Bolas wrote:
<br>&gt; On Wednesday, August 26, 2015 at 1:54:48 PM UTC-4, Matthew Woehlke=
 wrote:
<br>&gt;&gt; based on the recent discussions, it seems to me that *IF* we=
=20
<br>&gt;&gt; added properties, they should look something like:
<br>&gt;=20
<br>&gt; Ugh. I hate properties, but I hate hacks more. If properties are i=
mportant=20
<br>&gt; enough to have, then they should be exactly what they are: syntact=
ic sugar=20
<br>&gt; around syntax. `var.prop` as part of a non-assignment expression c=
alls a=20
<br>&gt; getter function. `var.prop` as part of an assignment expression ca=
lls a=20
<br>&gt; setter function.
<br>
<br>That&#39;s exactly how an inline class *works*. You *MUST* define the
<br>get/set methods somewhere. At &quot;best&quot;, by your logic, you woul=
d have:
<br>
<br>=C2=A0 class Foo {
<br>=C2=A0 =C2=A0 int property bar get() const;
<br>=C2=A0 =C2=A0 property bar set(int);
<br>=C2=A0 };
<br>
<br>I&#39;ve suggested exactly the same thing, but with the property name a=
s a
<br>scope, and reusing existing keywords and constructs rather than
<br>introducing new ones. Only my suggestion opens up a lot of *additional*
<br>possibilities.
<br>
<br>&gt; One of the modifying assignment operators should automatically wor=
k
<br>&gt; as a getter followed by the modification followed by the setter.
<br>
<br>This requires a substantial change to language semantics, and I&#39;m n=
ot
<br>entirely convinced it is always TRTTD.<br></blockquote><div><br>You&#39=
;re the one who wants properties. I&#39;m just outlining what has to be don=
e to get them in a non-hacky way.<br>=C2=A0<br></div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;">
With inline classes, you could achieve this easily with a mixin.
<br>
<br>&gt; A &quot;property&quot; should not be some type that implements met=
hods.
<br>
<br>Ignoring the second half of that,</blockquote><div><br>No, you can&#39;=
t do that. That half of the statement is important. If you ignore it, then =
the statement means something I wasn&#39;t saying.<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"> if it&#39;s not a type, how do you sol=
ve
<br>the problem of someone taking a reference to the property and
<br>subsequently modifying it?<br></blockquote><div><br>Property methods re=
turn whatever they choose to return. If a getter returns by value, then it =
returns by value. There are no syntactic guarantees in properties that requ=
ire a getter to return a real reference to an actual value that will be upd=
ated when the value is changed.<br>=C2=A0</div><blockquote class=3D"gmail_q=
uote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pad=
ding-left: 1ex;">
<br>&gt; It should not have storage.
<br>
<br>There has to be storage *somewhere*. Both properties and inline classes
<br>use the parent for that storage.<br></blockquote><div><br>No, there doe=
sn&#39;t.<br><br>You&#39;re thinking of properties as things that represent=
 some type. But they don&#39;t have to. C# properties do not <i>have</i> to=
 be get/set pairs wrapped around a particular variable. They&#39;re just fu=
nctions, one returns a value, the other is given a value. What you do inter=
nally is up to you.<br><br>Two separate properties could be using the same =
storage. A property could be reading from/writing to multiple pieces of sto=
rage. Or one could be making a value up entirely from whole cloth without a=
ny storage whatsoever.<br>=C2=A0</div><blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;">
&gt; It should not consist of anything more than 2 function=20
<br>&gt; declarations/definitions.
<br>
<br>Most inline class &quot;properties&quot; won&#39;t.<br></blockquote><di=
v><br>It consists of a class definition. That makes it more than 2 function=
 definitions.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; To put it another way, we should not add a couple of special-case synt=
axes=20
<br>&gt; to make library property hacks work.
<br>
<br>That&#39;s not at all what I suggested. (I&#39;ll also point out that w=
hat I
<br>suggested was exactly *one* syntax, not &quot;a couple&quot;. Nor did I=
 at any
<br>point call on a library to provide boilerplate code.)
<br>
<br>I admit that trivial support for modifying operators may require some
<br>library help, but I think that&#39;s more than worth it, considering th=
e
<br>advantages:
<br>
<br>=C2=A0- No new keywords.
<br>
<br>=C2=A0- Ability to reuse get/set logic for multiple properties, even in
<br>=C2=A0 =C2=A0multiple parent types.
<br>
<br>=C2=A0- Additional potential use outside of &quot;properties&quot;.
<br>
<br>=C2=A0- Minimal changes to the language.
<br>
<br>The only language change for inline classes, really, is the new &quot;i=
nline
<br>class/struct&quot; syntax, and the concept that the storage of such an =
object
<br>is the same as the parent. For &quot;proper properties&quot;, besides t=
he syntax
<br>(and I&#39;m not sure how you&#39;ll avoid new keywords),</blockquote><=
div><br>So what if it needs keywords? We should not implement a feature in =
an ugly or unintuitive way (and it&#39;s hard to claim that your way of usi=
ng type conversion and having to overload every assignment operator is not =
unintuitive) just because doing it right would using keywords. If the featu=
re is something worthwhile, then it is something worth using the appropriat=
e syntax for. Not merely the quickest syntax to get it standardized.<br><br=
>Also, they could be contextual keywords.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">Don&#39;t forget you&#39;ve also introduces some n=
ew magical
<br>&quot;property reference type&quot; so that you can write &#39;auto&amp=
; prop =3D foo.bar;
<br>prop +=3D 4;&#39;.</blockquote><div><br>That one&#39;s not magic. `foo.=
bar`, when not used as the left side of an assignment expression, calls the=
 getter function. The getter will return whatever it returns.<br>=C2=A0</di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"> Inline classes just leverag=
e existing language features for
<br>all of this.
<br>
<br>&gt; Unless there is some other use for these inline classes, I&#39;m a=
gainst using=20
<br>&gt; them as a way to put properties into the language.
<br>
<br>Sort of related, but how about this?
<br>
<br>=C2=A0 auto c =3D get_color();
<br>=C2=A0 c.hsl.hue =3D 15;
<br>=C2=A0 cout &lt;&lt; c.hcy.hue;
<br>
<br>The outer inline class is used to manipulate the object &quot;as an X&q=
uot;, i.e.
<br>such that various possibly X&#39;s have methods/&quot;properties&quot; =
of the same
<br>name, but different semantics. Something like a downcast, except you ca=
n
<br>&quot;downcast&quot; to multiple types at the same hierarchy level.<br>=
</blockquote><div><br>Any form of properties could do that. I asked if ther=
e was some <i>non-property</i> use for inline classes. Are they a generic t=
ool that could be used for something other than kludging together a propert=
y solution?<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_788_663933610.1440694731206--
------=_Part_787_1801053074.1440694731206--

.

------=_Part_6027_788845889.1440694896032
Content-Type: multipart/alternative;
 boundary="----=_Part_6028_2046035949.1440694896032"

------=_Part_6028_2046035949.1440694896032
Content-Type: text/plain; charset=UTF-8



On Wednesday, August 26, 2015 at 7:36:05 PM UTC-4, Christopher Horvath
wrote:
>
>
>
> On Wed, Aug 26, 2015 at 4:28 PM, Jim Porter <jvp...@g.rit.edu
> <javascript:>> wrote:
>
>> On 8/26/2015 6:23 PM, Christopher Horvath wrote:
>>
>>> ...and instead be able to just say any variation of this:
>>>
>>> class Something {
>>> public:
>>>      property Thing thing;
>>> };
>>>
>>
>> What does the "property" keyword here provide? Couldn't you just have a
>> public member variable? It seems to me that the benefit of properties is
>> being able to write a getter/setter, which would probably look a lot like
>> writing traditional getX/setX member functions.
>
>
> Hey Jim,
>
> I was doing notation handwaving, which I realize is contrary to the
> purpose of this list and this thread.  All I'm trying to get at is,
>
> "some way to indicate that I want a standard getter/setter wrapper around
> a struct member named 'thing', that only requires me to type the thing and
> its type once".
>
> with the added feature,
>
> "and I'm able to make a more complex wrapper in the future, should I need
> to".
>
> This comes up in geometry code all the time - a property (like length)
> goes from being a struct member to a derived quantity, or vice versa.
> That's why we don't just say:
>
> struct Something {
>     Thing thing;
> };
>
> Because we can never undo that, at an API level.  The functional thing()
> we can undo, but it is tedious to always write the getter/setter/value (or
> more, with const stuff) thing.
>

The problem is that you can't do that. You cannot have generic get/set
methods for a variable in such a way that you can later perform arbitrary
changes on the storage of that variable *without* changing the interface.

Oh, there are some changes. But the fact that you're returning a genuine
reference to the actual type of the variable in the getter means that it is
legal (and perfectly reasonable) for the user to do this:

const auto &foo = obj.getVal();
obj.setVal();
//foo's value has been updated.

However, if you change how the data is stored, if you change the internal
data type, then the get function can no longer return a genuine reference
to the actual type of the variable. And now this code is broken.

So in general, your goal for properties is not possible. Admittedly, there
are some ways to make properties such that the internals can be changed.
For example, if the getter returned a copy rather than a `const&`. Or if
the change returned an actual

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Wednesday, August 26, 2015 at 7:36:05 PM UTC-4, Christopher Horv=
ath wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><br=
><div><br><div class=3D"gmail_quote">On Wed, Aug 26, 2015 at 4:28 PM, Jim P=
orter <span dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-o=
bfuscated-mailto=3D"CtG1Xs92BgAJ" rel=3D"nofollow" onmousedown=3D"this.href=
=3D&#39;javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;">jvp...@g.rit.edu</a>&gt;</span> wrote:<br><blockquot=
e class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc sol=
id;padding-left:1ex">On 8/26/2015 6:23 PM, Christopher Horvath wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
....and instead be able to just say any variation of this:<span><br>
<br>
class Something {<br>
public:<br>
=C2=A0 =C2=A0 =C2=A0property Thing thing;<br>
};<br>
</span></blockquote>
<br>
What does the &quot;property&quot; keyword here provide? Couldn&#39;t you j=
ust have a public member variable? It seems to me that the benefit of prope=
rties is being able to write a getter/setter, which would probably look a l=
ot like writing traditional getX/setX member functions.</blockquote><div><b=
r></div><div>Hey Jim,</div><div><br></div><div>I was doing notation handwav=
ing, which I realize is contrary to the purpose of this list and this threa=
d.=C2=A0 All I&#39;m trying to get at is,</div><div><br></div><div>&quot;so=
me way to indicate that I want a standard getter/setter wrapper around a st=
ruct member named &#39;thing&#39;, that only requires me to type the thing =
and its type once&quot;.</div><div><br></div><div>with the added feature,</=
div><div><br></div><div>&quot;and I&#39;m able to make a more complex wrapp=
er in the future, should I need to&quot;.</div><div><br></div><div>This com=
es up in geometry code all the time - a property (like length) goes from be=
ing a struct member to a derived quantity, or vice versa.=C2=A0 That&#39;s =
why we don&#39;t just say:</div><div><br></div><div>struct Something {</div=
><div>=C2=A0 =C2=A0 Thing thing;</div><div>};</div><div><br></div><div>Beca=
use we can never undo that, at an API level.=C2=A0 The functional thing() w=
e can undo, but it is tedious to always write the getter/setter/value (or m=
ore, with const stuff) thing.</div></div></div></div></blockquote><div><br>=
The problem is that you can&#39;t do that. You cannot have generic get/set =
methods for a variable in such a way that you can later perform arbitrary c=
hanges on the storage of that variable <i>without</i> changing the interfac=
e.<br><br>Oh, there are some changes. But the fact that you&#39;re returnin=
g a genuine reference to the actual type of the variable in the getter mean=
s that it is legal (and perfectly reasonable) for the user to do this:<br><=
br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250)=
; border-color: rgb(187, 187, 187); border-style: solid; border-width: 1px;=
 word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">const</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">foo </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> obj</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify">getVal</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>();</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>ob=
j</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">setVal</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #800;" class=3D"styled-by-prettify">//foo&#39;s value has been updated=
..</span></div></code></div><br>However, if you change how the data is store=
d, if you change the internal data type, then the get function can no longe=
r return a genuine reference to the actual type of the variable. And now th=
is code is broken.<br><br>So in general, your goal for properties is not po=
ssible. Admittedly, there are some ways to make properties such that the in=
ternals can be changed. For example, if the getter returned a copy rather t=
han a `const&amp;`. Or if the change returned an actual <br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_6028_2046035949.1440694896032--
------=_Part_6027_788845889.1440694896032--

.

2015-08-27 19:01 GMT+02:00 Nicol Bolas <jmckesson@gmail.com>:
> const auto &foo = obj.getVal();
> obj.setVal();
> //foo's value has been updated.

setVal() on a const ref?

But yeah, properties and normal members aren't always interchangeable.


--
Olaf

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_5763_247180157.1440695302429
Content-Type: multipart/alternative;
 boundary="----=_Part_5764_1815574835.1440695302429"

------=_Part_5764_1815574835.1440695302429
Content-Type: text/plain; charset=UTF-8

On Thursday, August 27, 2015 at 12:48:31 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-27 12:21, Nicol Bolas wrote:
> > Unless "requiring the user to know multiple method names" is itself a
> > *feature* rather than a bug, of course. Being able to find things
> > operations easily should not be dismissed.
>
>   grep -E '\.health\s*\+=' # vs. '\.addHealth'
>
> ...what's the problem, again?
>

The fact that it misses this case:

entity.health = entity.health + 3;

Whereas searching for a particular method will always work.

Not only that, yours will pick up any += operators applied to any other
member that happens to be named .health. With modern IDEs, it's possible to
search for a specific method of a specific class, which uses language
syntax to ignore methods on different classes with the same name.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, August 27, 2015 at 12:48:31 PM UTC-4, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-27 1=
2:21, Nicol Bolas wrote:
<br>&gt; Unless &quot;requiring the user to know multiple method names&quot=
; is itself a=20
<br>&gt; *feature* rather than a bug, of course. Being able to find things=
=20
<br>&gt; operations easily should not be dismissed.
<br>
<br>=C2=A0 grep -E &#39;\.health\s*\+=3D&#39; # vs. &#39;\.addHealth&#39;
<br>
<br>...what&#39;s the problem, again?
<br></blockquote><div>=C2=A0</div><div>The fact that it misses this case:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #000;" class=3D"styled-by-prettify">entity=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify">health </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> entity</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">health </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">+</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span></div></code></div><br>Whereas searching for a particular met=
hod will always work.<br><br>Not only that, yours will pick up any +=3D ope=
rators applied to any other member that happens to be named .health. With m=
odern IDEs, it&#39;s possible to search for a specific method of a specific=
 class, which uses language syntax to ignore methods on different classes w=
ith the same name.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_5764_1815574835.1440695302429--
------=_Part_5763_247180157.1440695302429--

.

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

I don't understand these arguments...=20
Your grep also misses the case: entity.setHealth(entity.getHealth()+3);

If you have the notion of a health that can only be increased, but does not=
 allow for full manipulation, using no property (or a read-only property) p=
robably is the good choice.=20

Properties are not appropriate in all cases. They are not so usefull with c=
lasses that provide a very strong semantic.
When a class is an aggregate of decoupled data, properties are not usefull =
either: Just provide public members.
The cases where I've seen most uses of properties are for classes of loosel=
y coupled data, where we want to be able to manipulate the property indepen=
dently from the object that holds it.


---=20
Lo=C3=AFc


---- Message d'origine ----
De : "Nicol Bolas" <jmckesson@gmail.com>
=C3=80 : "ISO C++ Standard - Future Proposals" <std-proposals@isocpp.org>
Objet : [std-proposals] Re: "Properties" support in C++
Date : 27/08/2015 19:08:22 CEST
Copie =C3=A0 : mwoehlke.floss@gmail.com

On Thursday, August 27, 2015 at 12:48:31 PM UTC-4, Matthew Woehlke wrote:On=
 2015-08-27 12:21, Nicol Bolas wrote:=20
> Unless "requiring the user to know multiple method names" is itself a=20
> *feature* rather than a bug, of course. Being able to find things=20
> operations easily should not be dismissed.=20

=C2=A0 grep -E '\.health\s*\+=3D' # vs. '\.addHealth'=20

....what's the problem, again?=20

=C2=A0

The fact that it misses this case:

entity.health =3D entity.health + 3;





--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transational//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DUTF-8">
</HEAD>
<BODY>I don't understand these arguments... <br>Your grep also misses the c=
ase: entity.setHealth(entity.getHealth()+3);<br><br>If you have the notion =
of a health that can only be increased, but does not allow for full manipul=
ation, using no property (or a read-only property) probably is the good cho=
ice. <br><br>Properties are not appropriate in all cases. They are not so u=
sefull with classes that provide a very strong semantic.<br>When a class is=
 an aggregate of decoupled data, properties are not usefull either: Just pr=
ovide public members.<br>The cases where I've seen most uses of properties =
are for classes of loosely coupled data, where we want to be able to manipu=
late the property independently from the object that holds it.<br><br><br>-=
-- <br>Lo=C3=AFc<br><br><br>---- Message d'origine ----<br>
De : "Nicol Bolas" &lt;jmckesson@gmail.com&gt;<br>
=C3=80 : "ISO C++ Standard - Future Proposals" &lt;std-proposals@isocpp.org=
&gt;<br>
Objet : [std-proposals] Re: "Properties" support in C++<br>
Date : 27/08/2015 19:08:22 CEST<br>
Copie =C3=A0 : mwoehlke.floss@gmail.com<br>
<br>
<div dir=3D"ltr">On Thursday, August 27, 2015 at 12:48:31 PM UTC-4, Matthew=
 Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex;">On 2015-08-27 12:21=
, Nicol Bolas wrote:
<br>&gt; Unless "requiring the user to know multiple method names" is itsel=
f a=20
<br>&gt; *feature* rather than a bug, of course. Being able to find things=
=20
<br>&gt; operations easily should not be dismissed.
<br>
<br>&nbsp; grep -E '\.health\s*\+=3D' # vs. '\.addHealth'
<br>
<br>...what's the problem, again?
<br></blockquote><div>&nbsp;</div><div>The fact that it misses this case:<b=
r><br><div class=3D"prettyprint" style=3D"background-color:rgb(250, 250, 25=
0);border-color:rgb(187, 187, 187);border-style:solid;border-width:1px;word=
-wrap:break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color:#000;" class=3D"styled-by-prettify">entity</span><sp=
an style=3D"color:#660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color:#000;" class=3D"styled-by-prettify">health </span><span style=3D"=
color:#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color:#0=
00;" class=3D"styled-by-prettify"> entity</span><span style=3D"color:#660;"=
 class=3D"styled-by-prettify">.</span><span style=3D"color:#000;" class=3D"=
styled-by-prettify">health </span><span style=3D"color:#660;" class=3D"styl=
ed-by-prettify">+</span><span style=3D"color:#000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color:#066;" class=3D"styled-by-prettify">3</s=
pan><span style=3D"color:#660;" class=3D"styled-by-prettify">;</span></div>=
</code></div><br></div></div></BODY></HTML>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_NextPart_001_55df4adb_9df1_28ea7f19--


.

On 2015-08-27 13:08, Nicol Bolas wrote:
> On Thursday, August 27, 2015 at 12:48:31 PM UTC-4, Matthew Woehlke wrote:
>> On 2015-08-27 12:21, Nicol Bolas wrote:
>>> Unless "requiring the user to know multiple method names" is itself a
>>> *feature* rather than a bug, of course. Being able to find things
>>> operations easily should not be dismissed.
>>
>>   grep -E '\.health\s*\+=' # vs. '\.addHealth'
>>
>> ...what's the problem, again?
>
> The fact that it misses this case:
>
> entity.health = entity.health + 3;

You would not find 'e.setHealth(e.getHealth() + 3)' looking for
'addHealth', either. Conversely, consider 'health\s*(+=|-=|=)' vs.
'(add|remove|set)Health'.

> Not only that, yours will pick up any += operators applied to any other
> member that happens to be named .health. With modern IDEs, it's possible to
> search for a specific method of a specific class, which uses language
> syntax to ignore methods on different classes with the same name.

If the IDE can do this, why can it not find uses of operator+= of
Player::Health? Again, I don't see a problem here...

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a113ece661f358d051e4eabe8
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 27, 2015 at 5:25 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

>
> My personal view is that properties are still sold as a convenient way
> to turn data members
> into something more complicated without changing the syntax clients
> use for accessing
> them. I don't see that as a very convincing rationale. Thus far I have
> seen very little that
> really requires a language extension as opposed to a library utility
> type std::property<T>.
>
>
If there was a way to do this with a library utility, I think I would
prefer that. I don't see any reason why it needs to be a keyword or a
language extension, and in fact I think that could almost work against the
readability.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113ece661f358d051e4eabe8
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Thu, Aug 27, 2015 at 5:25 AM, Ville Voutilainen <span dir=3D"ltr">&l=
t;<a href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.vo=
utilainen@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quo=
te" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"=
><br>
My personal view is that properties are still sold as a convenient way<br>
to turn data members<br>
into something more complicated without changing the syntax clients<br>
use for accessing<br>
them. I don&#39;t see that as a very convincing rationale. Thus far I have<=
br>
seen very little that<br>
really requires a language extension as opposed to a library utility<br>
type std::property&lt;T&gt;.<br><div class=3D"HOEnZb"><div class=3D"h5"><br=
>
</div></div></blockquote></div><br></div><div class=3D"gmail_extra">If ther=
e was a way to do this with a library utility, I think I would prefer that.=
 I don&#39;t see any reason why it needs to be a keyword or a language exte=
nsion, and in fact I think that could almost work against the readability.<=
/div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ece661f358d051e4eabe8--

.

--089e013a2afa71817d051e4eccab
Content-Type: text/plain; charset=UTF-8

On Thu, Aug 27, 2015 at 9:03 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-08-26 17:25, 'Matt Calabrese' wrote:
> > I personally "hate" them because nobody has presented code where
> properties
> > solve *anything* at all in a way that is simpler than what can already be
> > done in the language, short of maybe removing "()".
>
> I think the biggest advantage would be allowing arithmetic operations on
> values that need to respond specially to changes, whether by bounds
> checking, triggering events on change, etc. without forcing the user to
> deal with differently named members for each possible operation, in
> cases where it makes more sense for the special handling to be bound to
> the owning class rather than wrapped in a value-like class.
>
> IOW:
>
>   class Player {
>     class Health
>     {
>       /* operators */
>     } health;
>   };
>
> - vs. -
>
>   class Player
>   {
>     int health() const;
>     void setHealth(int);
>     void addHealth(int);
>     void removeHealth(int);
>   };
>
> The first requires additional storage (the Player::Health instance needs
> to know about the Player instance). The latter requires the user to know
> multiple method names vs. using ordinary arithmetic operators. A
> property / inline class gives the best of both.
>

If you really are against having a higher-level API as was described
earlier by someone in a previous reply, you can still get exactly what you
want for the caller, just with an extra (). All you do is you make
Player.health() return a function object with your operator overloads. You
don't need to make a datamember called "health." All you get from that is
the ability to avoid writing "()" as the caller. Anyway, I wouldn't
recommend such an API, just as I wouldn't recommend properties, but since
they are functionally the same and you can already implement the latter
perfectly fine in C++ without changing the language, the thought that we
need to complicate the language for this is just silly to me. Why is:

////
player.health += 5;
////

so much better than

////
player.health() += 5;
////

It's trivial to do already, not that I'd personally consider it a good API.


> > Please provide an example of:
> >
> > * A problem that properties solve that you can't already do with a
> similar
> > amount of constructs in the language already.
>
> I submit range-based for as a counterexample to that. It's syntax sugar
> that (AFAIK) doesn't provide anything that isn't otherwise possible;
> merely saves typing. Yet it was (rightly, IMO) felt useful enough to be
> added.


That's much more than a syntactic translation -- it implements the guts of
the algorithm, keeping track of curr/end, iterating over the range, allows
break/continue, etc. If you compare "player.health += 5" to
"player.gainLife(5)", on the other hand, all you're really doing is
providing a different syntax for the function call. I get that you like
that syntax better, but it doesn't provide any additional functionality.
IMO, we do not need to add a new complicated feature to the language for
this. It's marketed fluff.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e013a2afa71817d051e4eccab
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Aug 27, 2015 at 9:03 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"ma=
rgin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D=
"">On 2015-08-26 17:25, &#39;Matt Calabrese&#39; wrote:<br>
&gt; I personally &quot;hate&quot; them because nobody has presented code w=
here properties<br>
&gt; solve *anything* at all in a way that is simpler than what can already=
 be<br>
&gt; done in the language, short of maybe removing &quot;()&quot;.<br>
<br>
</span>I think the biggest advantage would be allowing arithmetic operation=
s on<br>
values that need to respond specially to changes, whether by bounds<br>
checking, triggering events on change, etc. without forcing the user to<br>
deal with differently named members for each possible operation, in<br>
cases where it makes more sense for the special handling to be bound to<br>
the owning class rather than wrapped in a value-like class.<br>
<br>
IOW:<br>
<br>
=C2=A0 class Player {<br>
=C2=A0 =C2=A0 class Health<br>
=C2=A0 =C2=A0 {<br>
=C2=A0 =C2=A0 =C2=A0 /* operators */<br>
=C2=A0 =C2=A0 } health;<br>
=C2=A0 };<br>
<br>
- vs. -<br>
<br>
=C2=A0 class Player<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 int health() const;<br>
=C2=A0 =C2=A0 void setHealth(int);<br>
=C2=A0 =C2=A0 void addHealth(int);<br>
=C2=A0 =C2=A0 void removeHealth(int);<br>
=C2=A0 };<br>
<br>
The first requires additional storage (the Player::Health instance needs<br=
>
to know about the Player instance). The latter requires the user to know<br=
>
multiple method names vs. using ordinary arithmetic operators. A<br>
property / inline class gives the best of both.<br></blockquote><div><br></=
div><div>If you really are against having a higher-level API as was describ=
ed earlier by someone in a previous reply, you can still get exactly what y=
ou want for the caller, just with an extra (). All you do is you make Playe=
r.health() return a function object with your operator overloads. You don&#=
39;t need to make a datamember called &quot;health.&quot; All you get from =
that is the ability to avoid writing &quot;()&quot; as the caller. Anyway, =
I wouldn&#39;t recommend such an API, just as I wouldn&#39;t recommend prop=
erties, but since they are functionally the same and you can already implem=
ent the latter perfectly fine in C++ without changing the language, the tho=
ught that we need to complicate the language for this is just silly to me. =
Why is:</div><div><br></div><div>////</div><div>player.health +=3D 5;</div>=
<div>////</div><div><br></div><div>so much better than</div><div><br></div>=
<div>////</div><div>player.health() +=3D 5;</div><div>////</div><div><br></=
div><div>It&#39;s trivial to do already, not that I&#39;d personally consid=
er it a good API.</div><div><br></div><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=3D""><br>
&gt; Please provide an example of:<br>
&gt;<br>
&gt; * A problem that properties solve that you can&#39;t already do with a=
 similar<br>
&gt; amount of constructs in the language already.<br>
<br>
</span>I submit range-based for as a counterexample to that. It&#39;s synta=
x sugar<br>
that (AFAIK) doesn&#39;t provide anything that isn&#39;t otherwise possible=
;<br>
merely saves typing. Yet it was (rightly, IMO) felt useful enough to be<br>
added.</blockquote><div><br></div><div>That&#39;s much more than a syntacti=
c translation -- it implements the guts of the algorithm, keeping track of =
curr/end, iterating over the range, allows break/continue, etc. If you comp=
are &quot;player.health +=3D 5&quot; to &quot;player.gainLife(5)&quot;, on =
the other hand, all you&#39;re really doing is providing a different syntax=
 for the function call. I get that you like that syntax better, but it does=
n&#39;t provide any additional functionality. IMO, we do not need to add a =
new complicated feature to the language for this. It&#39;s marketed fluff.<=
/div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e013a2afa71817d051e4eccab--

.

------=_Part_2159_83156449.1440700712838
Content-Type: multipart/alternative;
 boundary="----=_Part_2160_765874119.1440700712838"

------=_Part_2160_765874119.1440700712838
Content-Type: text/plain; charset=UTF-8

On Thursday, August 27, 2015 at 1:55:12 PM UTC-4, Christopher Horvath wrote:
>
> On Thu, Aug 27, 2015 at 5:25 AM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>>
>> My personal view is that properties are still sold as a convenient way
>> to turn data members
>> into something more complicated without changing the syntax clients
>> use for accessing
>> them. I don't see that as a very convincing rationale. Thus far I have
>> seen very little that
>> really requires a language extension as opposed to a library utility
>> type std::property<T>.
>>
>>
> If there was a way to do this with a library utility, I think I would
> prefer that. I don't see any reason why it needs to be a keyword or a
> language extension, and in fact I think that could almost work against the
> readability.
>

Oh, there's a way to do it as C++ currently stands. It's just *incredibly*
ugly, requiring a huge amount of C++ verbiage (lambdas at class scope and
so forth). It gets to the point where beginning C++ programmers just can't
follow the code. Macros could help make it more palatable, but then you're
just using macros to cover for something hideous.

Oh, and even then, the abstraction is leaky. Since you can always get a
pointer/reference to the wrapper type. So yet again, you can't simply
replace a former variable with this wrapper without someone noticing what
you did.

So this is about as good a solution to properties as Boost.Lambda was for
actual lambda functions. The difference between them being that lambdas are
a highly useful feature... and properties are not.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Thursday, August 27, 2015 at 1:55:12 PM UTC-4, Christopher Horvath wrote=
:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div cl=
ass=3D"gmail_quote">On Thu, Aug 27, 2015 at 5:25 AM, Ville Voutilainen <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"qB9l1MmyBgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><br>
My personal view is that properties are still sold as a convenient way<br>
to turn data members<br>
into something more complicated without changing the syntax clients<br>
use for accessing<br>
them. I don&#39;t see that as a very convincing rationale. Thus far I have<=
br>
seen very little that<br>
really requires a language extension as opposed to a library utility<br>
type std::property&lt;T&gt;.<br><div><div><br>
</div></div></blockquote></div><br></div><div>If there was a way to do this=
 with a library utility, I think I would prefer that. I don&#39;t see any r=
eason why it needs to be a keyword or a language extension, and in fact I t=
hink that could almost work against the readability.</div></div></blockquot=
e><div><br>Oh, there&#39;s a way to do it as C++ currently stands. It&#39;s=
 just <i>incredibly</i> ugly, requiring a huge amount of C++ verbiage (lamb=
das at class scope and so forth). It gets to the point where beginning C++ =
programmers just can&#39;t follow the code. Macros could help make it more =
palatable, but then you&#39;re just using macros to cover for something hid=
eous.<br><br>Oh, and even then, the abstraction is leaky. <i></i>Since you =
can always get a pointer/reference to the wrapper type. So yet again, you c=
an&#39;t simply replace a former variable with this wrapper without someone=
 noticing what you did.<br><br>So this is about as good a solution to prope=
rties as Boost.Lambda was for actual lambda functions. The difference betwe=
en them being that lambdas are a highly useful feature... and properties ar=
e not.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2160_765874119.1440700712838--
------=_Part_2159_83156449.1440700712838--

.

On 2015-08-27 14:04, 'Matt Calabrese' wrote:
> If you really are against having a higher-level API as was described
> earlier by someone in a previous reply, you can still get exactly what you
> want for the caller, just with an extra (). All you do is you make
> Player.health() return a function object with your operator overloads.

That requires constructing a temporary object. You could achieve the
same thing *without* the ()'s by having the member *be* that function
object, which is the library properties solution possible already, but
you still have all the problems I previously explained with that approach.

>>> Please provide an example of:
>>>
>>> * A problem that properties solve that you can't already do with a
>>> similar amount of constructs in the language already.
>>
>> I submit range-based for as a counterexample to that. It's syntax sugar
>> that (AFAIK) doesn't provide anything that isn't otherwise possible;
>> merely saves typing. Yet it was (rightly, IMO) felt useful enough to be
>> added.
>
> That's much more than a syntactic translation -- it implements the guts of
> the algorithm, keeping track of curr/end, iterating over the range, allows
> break/continue, etc.

So are properties. You can implement range-based for as a macro (and
indeed at least boost and Qt have done so since a long time) and do all
that extra stuff.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-27 12:58, Nicol Bolas wrote:
> On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke wrote:
>> On 2015-08-26 14:08, Nicol Bolas wrote:
>>> A "property" should not be some type that implements methods.
>>
>> Ignoring the second half of that,
>
> No, you can't do that. That half of the statement is important. If you
> ignore it, then the statement means something I wasn't saying.

Sure I can :-). You made two assertions in that sentence. I chose to
respond only to the first. (Whether or not you intended for *that
sentence* to make both assertions, it's clear from your follow-up that
you do *mean* both assertions.)

That said, I don't see the problem with a "property" having methods. A
property is a value-type, is it not? Can't a value type have methods?

  class Foo
  {
    int_property a;
    point b;
  };

  // Why is this okay...
  foo.b.x();

  // ...but this isn't?
  foo.a.squared();

>> if it's not a type, how do you solve
>> the problem of someone taking a reference to the property and
>> subsequently modifying it?
>
> Property methods return whatever they choose to return.

You've previously established that returning a POD reference is broken.
(I'm not sure why; I also consider it broken, and am not sure who you
thought was suggesting a getter should ever return a reference.)

> If a getter returns
> by value, then it returns by value. There are no syntactic guarantees in
> properties that require a getter to return a real reference to an actual
> value that will be updated when the value is changed.

As previously illustrated, an inline class will still work with this code:

  auto& prop = foo.bar;
  prop = 5;

How will your "real properties" accomplish that? Remember, we've
established that decltype(foo.bar) != int&. If it's a reference to an
inline class / std::property<int> / etc., there is no problem.

>>> It should not have storage.
>>
>> There has to be storage *somewhere*. Both properties and inline classes
>> use the parent for that storage.
>
> No, there doesn't.

Um... okay, maybe if you're reading from an external input device, I'll
buy that. However, I'm talking about the typical case of e.g. the length
of a string. Either that length is stored somewhere (normally on the
string instance), or it is computed from other data stored on the string
instance. Especially in the former case, there *is* storage, it's just
that the storage is in the parent class, not the property itself.

>>> It should not consist of anything more than 2 function
>>> declarations/definitions.
>>
>> Most inline class "properties" won't.
>
> It consists of a class definition. That makes it more than 2 function
> definitions.

....which is potentially anonymous. Your choices are:

  property get int health() { ... }
  property set health(int) { ... }

....or:

  property health
  {
    int get() { ... }
    /*?*/ set(int) { ... }
  }

The latter is hardly different from a typical inline class "property",
which was the point.

> So what if it needs keywords?

Aren't you the one always harping on how "syntax is rare and precious"?
Adding keywords is a recipe for breaking existing code. Reusing existing
keywords in ways that aren't currently legal can't break old code.

> We should not implement a feature in an ugly or unintuitive way

I fail to see how "inline class" is unintuitive. It is a class whose
storage is "inline" in the parent. (And anyway, I'm not wedded to that
exact syntax, though I remain unconvinced that the cost of a new keyword
exceeds the alleged cost of "being unintuitive".)

> (and it's hard to claim that your way of using type conversion and
> having to overload every assignment operator is not unintuitive)

How is it not? An inline class is clearly an object, like any other
struct/class type, so when I write 'foo.bar', I clearly have a Foo::Bar
(assuming it is named and not anonymous). That being the case, it is
clear that if I want to change that, I would use an assignment operator.
Or if I want to use it as an int, I would use a conversion operator.

You don't need to overload *every* assignment operator, just the ones
you care about. And I fail to see how you would improve upon this. If
you actually need different behavior when assigning a temporary vs. a
copy to a property, you're going to have to provide setters for both
cases anyway, whether they look like "property set" or "operator=".

Again, inline classes have the HUGE benefit of reusing existing concepts
rather than inventing new ones.

> Also, they could be contextual keywords.

How? Again, I'm still waiting on a *concrete* proposal for an alternate
syntax. So far all I've heard is equivocating.

>>> Unless there is some other use for these inline classes, I'm against
>>> using them as a way to put properties into the language.
>>
>> Sort of related, but how about this?
>>
>>   auto c = get_color();
>>   c.hsl.hue = 15;
>>   cout << c.hcy.hue;
>
> Any form of properties could do that.

Please *show* how you would implement this with something other than
inline classes. (The color class may store RGB triples. The properties
may not have their own storage, nor may you create temporary non-POD
objects.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_88_2035740899.1440715025485
Content-Type: multipart/alternative;
 boundary="----=_Part_89_561104931.1440715025487"

------=_Part_89_561104931.1440715025487
Content-Type: text/plain; charset=UTF-8

On Thursday, August 27, 2015 at 4:20:10 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-27 12:58, Nicol Bolas wrote:
> > On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke
> wrote:
> >> On 2015-08-26 14:08, Nicol Bolas wrote:
> >>> A "property" should not be some type that implements methods.
> >>
> >> Ignoring the second half of that,
> >
> > No, you can't do that. That half of the statement is important. If you
> > ignore it, then the statement means something I wasn't saying.
>
> Sure I can :-). You made two assertions in that sentence. I chose to
> respond only to the first.


No, I made one assertion: "type that implements methods" is a single
phrase, to be taken as a whole.


> That said, I don't see the problem with a "property" having methods. A
> property is a value-type, is it not? Can't a value type have methods?
>
>   class Foo
>   {
>     int_property a;
>     point b;
>   };
>
>   // Why is this okay...
>   foo.b.x();
>
>   // ...but this isn't?
>   foo.a.squared();
>

See, your problem is that you're not separating the *concept* of a property
from your proposed implementation.

The *concept* of a property is nothing more than a syntax translator,
converting x.y into x.y_get(), or converting x.y = z into x.y_set(z).
Whether it's calling methods with those names, or methods of some other
type, is irrelevant. What matters is that the input syntax results in
specific function calls in specific scenarios.

Your proposed implementation does this conversion by making properties into
an *object*. That is, the property is an object, which is in some way
distinct from the data storage accessed/modified by that property.

And this implementation is a very leaky abstraction. It has a lot of
baggage associated with it.

For example, while thinking about what has to happen to make your inline
classes work, I realized something. Any class that contains an inline class *cannot
be trivially copyable*. Why? Because inline classes must have an internal
`this` pointer, which refers to the containing object. So you cannot simply
do a memcpy on them; the pointer has to be updated to refer to the new
object. And that requires the generation of a special copy constructor that
uses the new `this` object.

And you can't do something like pass the correct `this` pointer from the
source of the call. The reason being that you can get references to inline
classes, and those still need to be connected to the originating object
(your `auto& prop` code below captures the issue quite well). So the `this`
pointer *must* be a member of the inline class type. So there's no getting
around it; holders of inline classes cannot be trivially copied.

Do you really want to sacrifice trivial copies and moves just so you don't
have to type `()`? I personally think that's too high a price for mere
syntactic sugar.

And note, this is not because the concept of properties requires it. It is
a limitation of your proposed implementation.

A *pure* property implementation would make them what they are: a syntactic
transformation. And thus, you wouldn't have this problem. Properties
themselves would not be C++ objects; they'd just be compiler notifiers for
syntactic transforms.


> >> if it's not a type, how do you solve
> >> the problem of someone taking a reference to the property and
> >> subsequently modifying it?
> >
> > Property methods return whatever they choose to return.
>
> You've previously established that returning a POD reference is broken.
> (I'm not sure why; I also consider it broken, and am not sure who you
> thought was suggesting a getter should ever return a reference.)
>

I never said that returning a reference was broken. What's broken is
*changing* an interface from returning a reference to returning a proxy
object. Returning references is a common C++ idiom. Just check various
APIs; most getters return by `const&`.

It only becomes broken when you need to change the internal representation
of the object.

> If a getter returns
> > by value, then it returns by value. There are no syntactic guarantees in
> > properties that require a getter to return a real reference to an actual
> > value that will be updated when the value is changed.
>
> As previously illustrated, an inline class will still work with this code:
>
>   auto& prop = foo.bar;
>   prop = 5;
>

But it wouldn't work on this:

float &prop = foo.bar;

Not everyone uses auto everywhere. Nor should they be required to.


> How will your "real properties" accomplish that? Remember, we've
> established that decltype(foo.bar) != int&. If it's a reference to an
> inline class / std::property<int> / etc., there is no problem.
>

Again, you're confusing concept with implementation.

Your proposed implementation makes `foo.bar` resolve to an inline class
value, who's various member functions implement property mechanics. The
pure implementation is for `foo.bar` to automatically be transformed by the
compiler into a function call to either the property getter or property
setter function, based on the expression containing `foo.bar`.

So under those rules, `auto &x = foo.bar` will result in a reference to
whatever the getter for foo.bar returns. If it returns a `float &`, then
that's what will be stored. If it returns a `float` by value, then this
will result in a reference to the temporary float.


> >>> It should not have storage.
> >>
> >> There has to be storage *somewhere*. Both properties and inline classes
> >> use the parent for that storage.
> >
> > No, there doesn't.
>
> Um... okay, maybe if you're reading from an external input device, I'll
> buy that. However, I'm talking about the typical case of e.g. the length
> of a string. Either that length is stored somewhere (normally on the
> string instance), or it is computed from other data stored on the string
> instance. Especially in the former case, there *is* storage, it's just
> that the storage is in the parent class, not the property itself.
>

There's a difference between the storage for the implementation of the
property, and the storage for the *data* itself. In your inline class case,
your property implementation takes up at least one byte, because properties
are objects (separate from any data storage). And in C++, object members of
a class must take up at least one byte.

A pure property implementation means that there is only the data storage
(if any). The property itself has no storage, because the property *is not
an object*.

>>> It should not consist of anything more than 2 function
> >>> declarations/definitions.
> >>
> >> Most inline class "properties" won't.
> >
> > It consists of a class definition. That makes it more than 2 function
> > definitions.
>
> ...which is potentially anonymous. Your choices are:
>
>   property get int health() { ... }
>   property set health(int) { ... }
>
> ...or:
>
>   property health
>   {
>     int get() { ... }
>     /*?*/ set(int) { ... }
>   }
>
> The latter is hardly different from a typical inline class "property",
> which was the point.
>

Let's see. Here's what pure property syntax might look like:

struct T
{
  int getHealth() property(health) {return _health;}
  void setHealth(int h) property(health) {_health = h;}

private:
  int _health;
};

Here is what your inline class syntax would have to do to be equivalent
with that:

struct T
{
  inline class
  {
    operator int() {return this->_health;}
    int operator= (int h) {_health = h; return _health;}
    int operator+= (int h) {_health += h; return _health;}
    int operator-= (int h) {_health -= h; return _health;}
    int operator*= (int h) {_health *= h; return _health;}
    int operator/= (int h) {_health /= h; return _health;}
  } health;
};

Even if we ignore the fact that you have to implement all those forms of
equality assignment if you want users to be able to use it, you've still
caused confusion. The "getter" method isn't called "get". Indeed, it
doesn't even have a name; it's `operator int`, for some reason. The
"setter" method also doesn't have a name; you instead overload operator=.

That's not exactly something the neophyte C++ programmer will understand.
People coming from languages with pure property support will expect
something rather different in terms of syntax.


> > So what if it needs keywords?
>
> Aren't you the one always harping on how "syntax is rare and precious"?
> Adding keywords is a recipe for breaking existing code. Reusing existing
> keywords in ways that aren't currently legal can't break old code.
>
> > We should not implement a feature in an ugly or unintuitive way
>
> I fail to see how "inline class" is unintuitive. It is a class whose
> storage is "inline" in the parent. (And anyway, I'm not wedded to that
> exact syntax, though I remain unconvinced that the cost of a new keyword
> exceeds the alleged cost of "being unintuitive".)
>
> > (and it's hard to claim that your way of using type conversion and
> > having to overload every assignment operator is not unintuitive)
>
> How is it not? An inline class is clearly an object, like any other
> struct/class type, so when I write 'foo.bar', I clearly have a Foo::Bar
> (assuming it is named and not anonymous). That being the case, it is
> clear that if I want to change that, I would use an assignment operator.
> Or if I want to use it as an int, I would use a conversion operator.
>
> You don't need to overload *every* assignment operator, just the ones
> you care about.


If it's more than one, it's too many. You don't see other languages
implementing properties that way. You implement one getter and one setter,
period.


> And I fail to see how you would improve upon this.


Because you only have to implement a single getter and a single setter.
Supporting += requires no effort; the compiler handles it for you, so long
as the type returned by the getter supports operator+.

Also, there's explicit syntax for declaring a property, rather than
building a type and piggybacking some syntax off of implicit conversions or
operator= or whatever. It looks like a real language feature.

If
> you actually need different behavior when assigning a temporary vs. a
> copy to a property, you're going to have to provide setters for both
> cases anyway, whether they look like "property set" or "operator=".
>

Why would you need different behavior?


> Again, inline classes have the HUGE benefit of reusing existing concepts
> rather than inventing new ones.
>
> > Also, they could be contextual keywords.
>
> How? Again, I'm still waiting on a *concrete* proposal for an alternate
> syntax. So far all I've heard is equivocating.
>

You don't seem to understand what I'm saying here. I'm saying these two
things:

#1: I don't think properties belong in C++.

#2: If properties are important enough to be taken into the standard, then
they should be important enough to be done correctly.

Because of #1, I have no desire to provide a full proposal for a pure
implementation of properties. Because of #2, I oppose your proposed
solution because it's a hack designed to be the minimally offensive to the
committee, not a natural way to implement the feature.

>>> Unless there is some other use for these inline classes, I'm against
> >>> using them as a way to put properties into the language.
> >>
> >> Sort of related, but how about this?
> >>
> >>   auto c = get_color();
> >>   c.hsl.hue = 15;
> >>   cout << c.hcy.hue;
> >
> > Any form of properties could do that.
>
> Please *show* how you would implement this with something other than
> inline classes. (The color class may store RGB triples. The properties
> may not have their own storage, nor may you create temporary non-POD
> objects.)
>

Why are those solutions not allowed? Remember what properties are: a
shorthand syntax for calling getters/setters. So `c.hsl.hue = ...`
conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.

*That's what properties are for.*

In order to implement this using function call syntax, I would return
appropriate proxy objects, which are non-PODs that contain references to
data. The presence or absence of properties, of any form, does not how one
goes about solving the problem. Your solution uses proxy objects too; it
just so happens that your proxy objects are permanent fixtures of an
object, rather than temporaries created on the stack.

Proxy objects are proxy objects no matter where they come from.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, August 27, 2015 at 4:20:10 PM UTC-4, Matthew =
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-27 12=
:58, Nicol Bolas wrote:
<br>&gt; On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke=
 wrote:
<br>&gt;&gt; On 2015-08-26 14:08, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; A &quot;property&quot; should not be some type that implem=
ents methods.=20
<br>&gt;&gt;
<br>&gt;&gt; Ignoring the second half of that,
<br>&gt;=20
<br>&gt; No, you can&#39;t do that. That half of the statement is important=
.. If you=20
<br>&gt; ignore it, then the statement means something I wasn&#39;t saying.
<br>
<br>Sure I can :-). You made two assertions in that sentence. I chose to
<br>respond only to the first.</blockquote><div><br>No, I made one assertio=
n: &quot;type that implements methods&quot; is a single phrase, to be taken=
 as a whole.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> T=
hat said, I don&#39;t see the problem with a &quot;property&quot; having me=
thods. A
<br>property is a value-type, is it not? Can&#39;t a value type have method=
s?
<br>
<br>=C2=A0 class Foo
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 int_property a;
<br>=C2=A0 =C2=A0 point b;
<br>=C2=A0 };
<br>
<br>=C2=A0 // Why is this okay...
<br>=C2=A0 foo.b.x();
<br>
<br>=C2=A0 // ...but this isn&#39;t?
<br>=C2=A0 foo.a.squared();
<br></blockquote><div><br>See, your problem is that you&#39;re not separati=
ng the <i>concept</i> of a property from your proposed implementation.<br><=
br>The <i>concept</i> of a property is nothing more than a syntax translato=
r, converting x.y into x.y_get(), or converting x.y =3D z into x.y_set(z). =
Whether it&#39;s calling methods with those names, or methods of some other=
 type, is irrelevant. What matters is that the input syntax results in spec=
ific function calls in specific scenarios.<br><br>Your proposed implementat=
ion does this conversion by making properties into an <i>object</i>. That i=
s, the property is an object, which is in some way distinct from the data s=
torage accessed/modified by that property.<br><br>And this implementation i=
s a very leaky abstraction. It has a lot of baggage associated with it.<br>=
<br>For example, while thinking about what has to happen to make your inlin=
e classes work, I realized something. Any class that contains an inline cla=
ss <i>cannot be trivially copyable</i>. Why? Because inline classes must ha=
ve an internal `this` pointer, which refers to the containing object. So yo=
u cannot simply do a memcpy on them; the pointer has to be updated to refer=
 to the new object. And that requires the generation of a special copy cons=
tructor that uses the new `this` object.<br><br>And you can&#39;t do someth=
ing like pass the correct `this` pointer from the source of the call. The r=
eason being that you can get references to inline classes, and those still =
need to be connected to the originating object (your `auto&amp; prop` code =
below captures the issue quite well). So the `this` pointer <i>must</i> be =
a member of the inline class type. So there&#39;s no getting around it; hol=
ders of inline classes cannot be trivially copied.<br><br>Do you really wan=
t to sacrifice trivial copies and moves just so you don&#39;t have to type =
`()`? I personally think that&#39;s too high a price for mere syntactic sug=
ar.<br><br>And note, this is not because the concept of properties requires=
 it. It is a limitation of your proposed implementation.<br><br>A <i>pure</=
i> property implementation would make them what they are: a syntactic trans=
formation. And thus, you wouldn&#39;t have this problem. Properties themsel=
ves would not be C++ objects; they&#39;d just be compiler notifiers for syn=
tactic transforms.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
&gt;&gt; if it&#39;s not a type, how do you solve=20
<br>&gt;&gt; the problem of someone taking a reference to the property and=
=20
<br>&gt;&gt; subsequently modifying it?
<br>&gt;=20
<br>&gt; Property methods return whatever they choose to return.
<br>
<br>You&#39;ve previously established that returning a POD reference is bro=
ken.
<br>(I&#39;m not sure why; I also consider it broken, and am not sure who y=
ou
<br>thought was suggesting a getter should ever return a reference.)<br></b=
lockquote><div><br>I never said that returning a reference was broken. What=
&#39;s broken is <i>changing</i> an interface from returning a reference to=
 returning a proxy object. Returning references is a common C++ idiom. Just=
 check various APIs; most getters return by `const&amp;`.<br><br>It only be=
comes broken when you need to change the internal representation of the obj=
ect.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt; If a getter returns=20
<br>&gt; by value, then it returns by value. There are no syntactic guarant=
ees in=20
<br>&gt; properties that require a getter to return a real reference to an =
actual=20
<br>&gt; value that will be updated when the value is changed.
<br>
<br>As previously illustrated, an inline class will still work with this co=
de:
<br>
<br>=C2=A0 auto&amp; prop =3D foo.bar;
<br>=C2=A0 prop =3D 5;
<br></blockquote><div><br>But it wouldn&#39;t work on this:<br><br><div cla=
ss=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-co=
lor: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap:=
 break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">prop </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> foo</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">bar</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span></div></code></div><br>Not everyone uses auto everywhere. Nor sho=
uld they be required to.<br>=C2=A0</div><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
How will your &quot;real properties&quot; accomplish that? Remember, we&#39=
;ve
<br>established that decltype(foo.bar) !=3D int&amp;. If it&#39;s a referen=
ce to an
<br>inline class / std::property&lt;int&gt; / etc., there is no problem.<br=
></blockquote><div><br>Again, you&#39;re confusing concept with implementat=
ion.<br><br>Your proposed implementation makes `foo.bar` resolve to an inli=
ne class value, who&#39;s various member functions implement property mecha=
nics. The pure implementation is for `foo.bar` to automatically be transfor=
med by the compiler into a function call to either the property getter or p=
roperty setter function, based on the expression containing `foo.bar`.<br><=
br>So under those rules, `auto &amp;x =3D foo.bar` will result in a referen=
ce to whatever the getter for foo.bar returns. If it returns a `float &amp;=
`, then that&#39;s what will be stored. If it returns a `float` by value, t=
hen this will result in a reference to the temporary float.<br>=C2=A0</div>=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;">
&gt;&gt;&gt; It should not have storage.=20
<br>&gt;&gt;
<br>&gt;&gt; There has to be storage *somewhere*. Both properties and inlin=
e classes=20
<br>&gt;&gt; use the parent for that storage.
<br>&gt;=20
<br>&gt; No, there doesn&#39;t.
<br>
<br>Um... okay, maybe if you&#39;re reading from an external input device, =
I&#39;ll
<br>buy that. However, I&#39;m talking about the typical case of e.g. the l=
ength
<br>of a string. Either that length is stored somewhere (normally on the
<br>string instance), or it is computed from other data stored on the strin=
g
<br>instance. Especially in the former case, there *is* storage, it&#39;s j=
ust
<br>that the storage is in the parent class, not the property itself.<br></=
blockquote><div><br>There&#39;s a difference between the storage for the im=
plementation of the property, and the storage for the <i>data</i> itself. I=
n your inline class case, your property implementation takes up at least on=
e byte, because properties are objects (separate from any data storage). An=
d in C++, object members of a class must take up at least one byte.<br><br>=
A pure property implementation means that there is only the data storage (i=
f any). The property itself has no storage, because the property <i>is not =
an object</i>.<br><br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
&gt;&gt;&gt; It should not consist of anything more than 2 function=20
<br>&gt;&gt;&gt; declarations/definitions.=20
<br>&gt;&gt;
<br>&gt;&gt; Most inline class &quot;properties&quot; won&#39;t.
<br>&gt;=20
<br>&gt; It consists of a class definition. That makes it more than 2 funct=
ion=20
<br>&gt; definitions.
<br>
<br>...which is potentially anonymous. Your choices are:
<br>
<br>=C2=A0 property get int health() { ... }
<br>=C2=A0 property set health(int) { ... }
<br>
<br>...or:
<br>
<br>=C2=A0 property health
<br>=C2=A0 {
<br>=C2=A0 =C2=A0 int get() { ... }
<br>=C2=A0 =C2=A0 /*?*/ set(int) { ... }
<br>=C2=A0 }
<br>
<br>The latter is hardly different from a typical inline class &quot;proper=
ty&quot;,
<br>which was the point.<br></blockquote><div><br>Let&#39;s see. Here&#39;s=
 what pure property syntax might look like:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> T<br></span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> getHealth</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> property</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
health</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> _health</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #008;=
" class=3D"styled-by-prettify">void</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> setHealth</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> h</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> propert=
y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">health</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">_health </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> h</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">p=
rivate</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> _health</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">};</span></div></code></div><br>He=
re is what your inline class syntax would have to do to be equivalent with =
that:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250,=
 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-w=
idth: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
T<br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">inline</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">class</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">{</span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">this</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">-&gt;</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">_health</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> h</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">_health </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> h</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> _health</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">int</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">operato=
r</span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> h</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
_health </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> h</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">return</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> _health</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;}</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">operator</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">-=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> h</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">_health </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">-=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> h</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">retur=
n</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> _health<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">*=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> h</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify">_health </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">*=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> h</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> _health</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify=
">operator</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
/=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"> h</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">_health </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">/=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> h</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">return</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> _health</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> health</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">};</span></div></code></div><br>Even if we ignore the fact tha=
t you have to implement all those forms of equality assignment if you want =
users to be able to use it, you&#39;ve still caused confusion. The &quot;ge=
tter&quot; method isn&#39;t called &quot;get&quot;. Indeed, it doesn&#39;t =
even have a name; it&#39;s `operator int`, for some reason. The &quot;sette=
r&quot; method also doesn&#39;t have a name; you instead overload operator=
=3D.<br><br>That&#39;s not exactly something the neophyte C++ programmer wi=
ll understand. People coming from languages with pure property support will=
 expect something rather different in terms of syntax.<br>=C2=A0</div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">
&gt; So what if it needs keywords?
<br>
<br>Aren&#39;t you the one always harping on how &quot;syntax is rare and p=
recious&quot;?
<br>Adding keywords is a recipe for breaking existing code. Reusing existin=
g
<br>keywords in ways that aren&#39;t currently legal can&#39;t break old co=
de.
<br>
<br>&gt; We should not implement a feature in an ugly or unintuitive way
<br>
<br>I fail to see how &quot;inline class&quot; is unintuitive. It is a clas=
s whose
<br>storage is &quot;inline&quot; in the parent. (And anyway, I&#39;m not w=
edded to that
<br>exact syntax, though I remain unconvinced that the cost of a new keywor=
d
<br>exceeds the alleged cost of &quot;being unintuitive&quot;.)
<br>
<br>&gt; (and it&#39;s hard to claim that your way of using type conversion=
 and
<br>&gt; having to overload every assignment operator is not unintuitive)
<br>
<br>How is it not? An inline class is clearly an object, like any other
<br>struct/class type, so when I write &#39;foo.bar&#39;, I clearly have a =
Foo::Bar
<br>(assuming it is named and not anonymous). That being the case, it is
<br>clear that if I want to change that, I would use an assignment operator=
..
<br>Or if I want to use it as an int, I would use a conversion operator.
<br>
<br>You don&#39;t need to overload *every* assignment operator, just the on=
es
<br>you care about.</blockquote><div><br>If it&#39;s more than one, it&#39;=
s too many. You don&#39;t see other languages implementing properties that =
way. You implement one getter and one setter, period.<br>=C2=A0</div><block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"> And I fail to see how you would imp=
rove upon this.</blockquote><div><br>Because you only have to implement a s=
ingle getter and a single setter. Supporting +=3D requires no effort; the c=
ompiler handles it for you, so long as the type returned by the getter supp=
orts operator+.<br><br>Also, there&#39;s explicit syntax for declaring a pr=
operty, rather than building a type and piggybacking some syntax off of imp=
licit conversions or operator=3D or whatever. It looks like a real language=
 feature.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"> If
<br>you actually need different behavior when assigning a temporary vs. a
<br>copy to a property, you&#39;re going to have to provide setters for bot=
h
<br>cases anyway, whether they look like &quot;property set&quot; or &quot;=
operator=3D&quot;.<br></blockquote><div><br>Why would you need different be=
havior?<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
Again, inline classes have the HUGE benefit of reusing existing concepts
<br>rather than inventing new ones.
<br>
<br>&gt; Also, they could be contextual keywords.
<br>
<br>How? Again, I&#39;m still waiting on a *concrete* proposal for an alter=
nate
<br>syntax. So far all I&#39;ve heard is equivocating.<br></blockquote><div=
><br>You don&#39;t seem to understand what I&#39;m saying here. I&#39;m say=
ing these two things:<br><br>#1: I don&#39;t think properties belong in C++=
..<br><br>#2: If properties are important enough to be taken into the standa=
rd, then they should be important enough to be done correctly.<br><br>Becau=
se of #1, I have no desire to provide a full proposal for a pure implementa=
tion of properties. Because of #2, I oppose your proposed solution because =
it&#39;s a hack designed to be the minimally offensive to the committee, no=
t a natural way to implement the feature.<br><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;">
&gt;&gt;&gt; Unless there is some other use for these inline classes, I&#39=
;m against=20
<br>&gt;&gt;&gt; using them as a way to put properties into the language.=
=20
<br>&gt;&gt;
<br>&gt;&gt; Sort of related, but how about this?=20
<br>&gt;&gt;
<br>&gt;&gt; =C2=A0 auto c =3D get_color();=20
<br>&gt;&gt; =C2=A0 c.hsl.hue =3D 15;=20
<br>&gt;&gt; =C2=A0 cout &lt;&lt; c.hcy.hue;=20
<br>&gt;=20
<br>&gt; Any form of properties could do that.
<br>
<br>Please *show* how you would implement this with something other than
<br>inline classes. (The color class may store RGB triples. The properties
<br>may not have their own storage, nor may you create temporary non-POD
<br>objects.)
<br></blockquote><div><br>Why are those solutions not allowed? Remember wha=
t properties are: a shorthand syntax for calling getters/setters. So `c.hsl=
..hue =3D ...` conceptually transforms to `c.hsl_get().hue_set(...);` And so=
 forth.<br><br><i>That&#39;s what properties are for.</i><br><br>In order t=
o implement this using function call syntax, I would return appropriate pro=
xy objects, which are non-PODs that contain references to data. The presenc=
e or absence of properties, of any form, does not how one goes about solvin=
g the problem. Your solution uses proxy objects too; it just so happens tha=
t your proxy objects are permanent fixtures of an object, rather than tempo=
raries created on the stack.<br><br>Proxy objects are proxy objects no matt=
er where they come from.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_89_561104931.1440715025487--
------=_Part_88_2035740899.1440715025485--

.

--047d7bdc12eae19947051e52f225
Content-Type: text/plain; charset=UTF-8

With respect to:

>> There has to be storage *somewhere*. Both properties and inline classes
> >> use the parent for that storage.
> >
> > No, there doesn't.
>
> Um... okay, maybe if you're reading from an external input device, I'll
> buy that


I'm not a big fan of properties, and I'm not convinced they're a good fit
for C++ (although inline classes are intriguing) but (a) they do fit well
in some languages (code in C# with properties tends to be -- subjective
position here -- nicer to read and write than Java with getters and
setters) and (b) they don't need to be associated with specific state. The
following C# code is legal and resasonable

class Rectangle
{
   public int Height { get; private set; } // here, there's underlying state
   public int Width { get; private set; } // likewise
   public int Area { get { return Width * Height; } } // no need for state
here
   public int Perimeter { get { return 2 * (Width + Height); } } // likewise
   // etc.
}

Some properties are essentially getters that rely on others, not on
specifically precomputed state. A property could conceivably be constexpr
and expose a statically known constant, for example.

Cheers!



2015-08-27 16:16 GMT-04:00 Matthew Woehlke <mwoehlke.floss@gmail.com>:

> On 2015-08-27 12:58, Nicol Bolas wrote:
> > On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke wrote:
> >> On 2015-08-26 14:08, Nicol Bolas wrote:
> >>> A "property" should not be some type that implements methods.
> >>
> >> Ignoring the second half of that,
> >
> > No, you can't do that. That half of the statement is important. If you
> > ignore it, then the statement means something I wasn't saying.
>
> Sure I can :-). You made two assertions in that sentence. I chose to
> respond only to the first. (Whether or not you intended for *that
> sentence* to make both assertions, it's clear from your follow-up that
> you do *mean* both assertions.)
>
> That said, I don't see the problem with a "property" having methods. A
> property is a value-type, is it not? Can't a value type have methods?
>
>   class Foo
>   {
>     int_property a;
>     point b;
>   };
>
>   // Why is this okay...
>   foo.b.x();
>
>   // ...but this isn't?
>   foo.a.squared();
>
> >> if it's not a type, how do you solve
> >> the problem of someone taking a reference to the property and
> >> subsequently modifying it?
> >
> > Property methods return whatever they choose to return.
>
> You've previously established that returning a POD reference is broken.
> (I'm not sure why; I also consider it broken, and am not sure who you
> thought was suggesting a getter should ever return a reference.)
>
> > If a getter returns
> > by value, then it returns by value. There are no syntactic guarantees in
> > properties that require a getter to return a real reference to an actual
> > value that will be updated when the value is changed.
>
> As previously illustrated, an inline class will still work with this code:
>
>   auto& prop = foo.bar;
>   prop = 5;
>
> How will your "real properties" accomplish that? Remember, we've
> established that decltype(foo.bar) != int&. If it's a reference to an
> inline class / std::property<int> / etc., there is no problem.
>
> >>> It should not have storage.
> >>
> >> There has to be storage *somewhere*. Both properties and inline classes
> >> use the parent for that storage.
> >
> > No, there doesn't.
>
> Um... okay, maybe if you're reading from an external input device, I'll
> buy that. However, I'm talking about the typical case of e.g. the length
> of a string. Either that length is stored somewhere (normally on the
> string instance), or it is computed from other data stored on the string
> instance. Especially in the former case, there *is* storage, it's just
> that the storage is in the parent class, not the property itself.
>
> >>> It should not consist of anything more than 2 function
> >>> declarations/definitions.
> >>
> >> Most inline class "properties" won't.
> >
> > It consists of a class definition. That makes it more than 2 function
> > definitions.
>
> ...which is potentially anonymous. Your choices are:
>
>   property get int health() { ... }
>   property set health(int) { ... }
>
> ...or:
>
>   property health
>   {
>     int get() { ... }
>     /*?*/ set(int) { ... }
>   }
>
> The latter is hardly different from a typical inline class "property",
> which was the point.
>
> > So what if it needs keywords?
>
> Aren't you the one always harping on how "syntax is rare and precious"?
> Adding keywords is a recipe for breaking existing code. Reusing existing
> keywords in ways that aren't currently legal can't break old code.
>
> > We should not implement a feature in an ugly or unintuitive way
>
> I fail to see how "inline class" is unintuitive. It is a class whose
> storage is "inline" in the parent. (And anyway, I'm not wedded to that
> exact syntax, though I remain unconvinced that the cost of a new keyword
> exceeds the alleged cost of "being unintuitive".)
>
> > (and it's hard to claim that your way of using type conversion and
> > having to overload every assignment operator is not unintuitive)
>
> How is it not? An inline class is clearly an object, like any other
> struct/class type, so when I write 'foo.bar', I clearly have a Foo::Bar
> (assuming it is named and not anonymous). That being the case, it is
> clear that if I want to change that, I would use an assignment operator.
> Or if I want to use it as an int, I would use a conversion operator.
>
> You don't need to overload *every* assignment operator, just the ones
> you care about. And I fail to see how you would improve upon this. If
> you actually need different behavior when assigning a temporary vs. a
> copy to a property, you're going to have to provide setters for both
> cases anyway, whether they look like "property set" or "operator=".
>
> Again, inline classes have the HUGE benefit of reusing existing concepts
> rather than inventing new ones.
>
> > Also, they could be contextual keywords.
>
> How? Again, I'm still waiting on a *concrete* proposal for an alternate
> syntax. So far all I've heard is equivocating.
>
> >>> Unless there is some other use for these inline classes, I'm against
> >>> using them as a way to put properties into the language.
> >>
> >> Sort of related, but how about this?
> >>
> >>   auto c = get_color();
> >>   c.hsl.hue = 15;
> >>   cout << c.hcy.hue;
> >
> > Any form of properties could do that.
>
> Please *show* how you would implement this with something other than
> inline classes. (The color class may store RGB triples. The properties
> may not have their own storage, nor may you create temporary non-POD
> objects.)
>
> --
> Matthew
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bdc12eae19947051e52f225
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">With respect to:<br><div><br><blockquote style=3D"margin:0=
px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" c=
lass=3D"gmail_quote">&gt;&gt; There has to be storage *somewhere*. Both pro=
perties and inline classes<br>
&gt;&gt; use the parent for that storage.<br>
&gt;<br>
&gt; No, there doesn&#39;t.<br>
<br>
Um... okay, maybe if you&#39;re reading from an external input device, I&#3=
9;ll<br>
buy that</blockquote><div><br></div><div>I&#39;m not a big fan of propertie=
s, and I&#39;m not convinced they&#39;re a good fit for C++ (although inlin=
e classes are intriguing) but (a) they do fit well in some languages (code =
in C# with properties tends to be -- subjective position here -- nicer to r=
ead and write than Java with getters and setters) and (b) they don&#39;t ne=
ed to be associated with specific state. The following C# code is legal and=
 resasonable<br><br></div><div>class Rectangle<br>{<br></div><div>=C2=A0=C2=
=A0 public int Height { get; private set; } // here, there&#39;s underlying=
 state<br></div><div>=C2=A0=C2=A0 public int Width { get; private set; } //=
 likewise<br></div><div>=C2=A0=C2=A0 public int Area { get { return Width *=
 Height; } } // no need for state here<br></div><div>=C2=A0=C2=A0 public in=
t Perimeter { get { return 2 * (Width + Height); } } // likewise<br></div><=
div>=C2=A0=C2=A0 // etc.<br></div><div>}<br><br></div><div>Some properties =
are essentially getters that rely on others, not on specifically precompute=
d state. A property could conceivably be constexpr and expose a statically =
known constant, for example.<br><br></div><div>Cheers!<br></div><div><br></=
div><div><br></div></div></div><div class=3D"gmail_extra"><br><div class=3D=
"gmail_quote">2015-08-27 16:16 GMT-04:00 Matthew Woehlke <span dir=3D"ltr">=
&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.=
floss@gmail.com</a>&gt;</span>:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2015-=
08-27 12:58, Nicol Bolas wrote:<br>
&gt; On Wednesday, August 26, 2015 at 2:45:47 PM UTC-4, Matthew Woehlke wro=
te:<br>
&gt;&gt; On 2015-08-26 14:08, Nicol Bolas wrote:<br>
&gt;&gt;&gt; A &quot;property&quot; should not be some type that implements=
 methods.<br>
&gt;&gt;<br>
&gt;&gt; Ignoring the second half of that,<br>
&gt;<br>
&gt; No, you can&#39;t do that. That half of the statement is important. If=
 you<br>
&gt; ignore it, then the statement means something I wasn&#39;t saying.<br>
<br>
Sure I can :-). You made two assertions in that sentence. I chose to<br>
respond only to the first. (Whether or not you intended for *that<br>
sentence* to make both assertions, it&#39;s clear from your follow-up that<=
br>
you do *mean* both assertions.)<br>
<br>
That said, I don&#39;t see the problem with a &quot;property&quot; having m=
ethods. A<br>
property is a value-type, is it not? Can&#39;t a value type have methods?<b=
r>
<br>
=C2=A0 class Foo<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 int_property a;<br>
=C2=A0 =C2=A0 point b;<br>
=C2=A0 };<br>
<br>
=C2=A0 // Why is this okay...<br>
=C2=A0 foo.b.x();<br>
<br>
=C2=A0 // ...but this isn&#39;t?<br>
=C2=A0 foo.a.squared();<br>
<br>
&gt;&gt; if it&#39;s not a type, how do you solve<br>
&gt;&gt; the problem of someone taking a reference to the property and<br>
&gt;&gt; subsequently modifying it?<br>
&gt;<br>
&gt; Property methods return whatever they choose to return.<br>
<br>
You&#39;ve previously established that returning a POD reference is broken.=
<br>
(I&#39;m not sure why; I also consider it broken, and am not sure who you<b=
r>
thought was suggesting a getter should ever return a reference.)<br>
<br>
&gt; If a getter returns<br>
&gt; by value, then it returns by value. There are no syntactic guarantees =
in<br>
&gt; properties that require a getter to return a real reference to an actu=
al<br>
&gt; value that will be updated when the value is changed.<br>
<br>
As previously illustrated, an inline class will still work with this code:<=
br>
<br>
=C2=A0 auto&amp; prop =3D foo.bar;<br>
=C2=A0 prop =3D 5;<br>
<br>
How will your &quot;real properties&quot; accomplish that? Remember, we&#39=
;ve<br>
established that decltype(foo.bar) !=3D int&amp;. If it&#39;s a reference t=
o an<br>
inline class / std::property&lt;int&gt; / etc., there is no problem.<br>
<br>
&gt;&gt;&gt; It should not have storage.<br>
&gt;&gt;<br>
&gt;&gt; There has to be storage *somewhere*. Both properties and inline cl=
asses<br>
&gt;&gt; use the parent for that storage.<br>
&gt;<br>
&gt; No, there doesn&#39;t.<br>
<br>
Um... okay, maybe if you&#39;re reading from an external input device, I&#3=
9;ll<br>
buy that. However, I&#39;m talking about the typical case of e.g. the lengt=
h<br>
of a string. Either that length is stored somewhere (normally on the<br>
string instance), or it is computed from other data stored on the string<br=
>
instance. Especially in the former case, there *is* storage, it&#39;s just<=
br>
that the storage is in the parent class, not the property itself.<br>
<br>
&gt;&gt;&gt; It should not consist of anything more than 2 function<br>
&gt;&gt;&gt; declarations/definitions.<br>
&gt;&gt;<br>
&gt;&gt; Most inline class &quot;properties&quot; won&#39;t.<br>
&gt;<br>
&gt; It consists of a class definition. That makes it more than 2 function<=
br>
&gt; definitions.<br>
<br>
....which is potentially anonymous. Your choices are:<br>
<br>
=C2=A0 property get int health() { ... }<br>
=C2=A0 property set health(int) { ... }<br>
<br>
....or:<br>
<br>
=C2=A0 property health<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 int get() { ... }<br>
=C2=A0 =C2=A0 /*?*/ set(int) { ... }<br>
=C2=A0 }<br>
<br>
The latter is hardly different from a typical inline class &quot;property&q=
uot;,<br>
which was the point.<br>
<br>
&gt; So what if it needs keywords?<br>
<br>
Aren&#39;t you the one always harping on how &quot;syntax is rare and preci=
ous&quot;?<br>
Adding keywords is a recipe for breaking existing code. Reusing existing<br=
>
keywords in ways that aren&#39;t currently legal can&#39;t break old code.<=
br>
<br>
&gt; We should not implement a feature in an ugly or unintuitive way<br>
<br>
I fail to see how &quot;inline class&quot; is unintuitive. It is a class wh=
ose<br>
storage is &quot;inline&quot; in the parent. (And anyway, I&#39;m not wedde=
d to that<br>
exact syntax, though I remain unconvinced that the cost of a new keyword<br=
>
exceeds the alleged cost of &quot;being unintuitive&quot;.)<br>
<br>
&gt; (and it&#39;s hard to claim that your way of using type conversion and=
<br>
&gt; having to overload every assignment operator is not unintuitive)<br>
<br>
How is it not? An inline class is clearly an object, like any other<br>
struct/class type, so when I write &#39;foo.bar&#39;, I clearly have a Foo:=
:Bar<br>
(assuming it is named and not anonymous). That being the case, it is<br>
clear that if I want to change that, I would use an assignment operator.<br=
>
Or if I want to use it as an int, I would use a conversion operator.<br>
<br>
You don&#39;t need to overload *every* assignment operator, just the ones<b=
r>
you care about. And I fail to see how you would improve upon this. If<br>
you actually need different behavior when assigning a temporary vs. a<br>
copy to a property, you&#39;re going to have to provide setters for both<br=
>
cases anyway, whether they look like &quot;property set&quot; or &quot;oper=
ator=3D&quot;.<br>
<br>
Again, inline classes have the HUGE benefit of reusing existing concepts<br=
>
rather than inventing new ones.<br>
<br>
&gt; Also, they could be contextual keywords.<br>
<br>
How? Again, I&#39;m still waiting on a *concrete* proposal for an alternate=
<br>
syntax. So far all I&#39;ve heard is equivocating.<br>
<br>
&gt;&gt;&gt; Unless there is some other use for these inline classes, I&#39=
;m against<br>
&gt;&gt;&gt; using them as a way to put properties into the language.<br>
&gt;&gt;<br>
&gt;&gt; Sort of related, but how about this?<br>
&gt;&gt;<br>
&gt;&gt;=C2=A0 =C2=A0auto c =3D get_color();<br>
&gt;&gt;=C2=A0 =C2=A0c.hsl.hue =3D 15;<br>
&gt;&gt;=C2=A0 =C2=A0cout &lt;&lt; c.hcy.hue;<br>
&gt;<br>
&gt; Any form of properties could do that.<br>
<br>
Please *show* how you would implement this with something other than<br>
inline classes. (The color class may store RGB triples. The properties<br>
may not have their own storage, nor may you create temporary non-POD<br>
objects.)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
Matthew<br>
<br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bdc12eae19947051e52f225--

.

--047d7b4142f0eee05a051e7d00bb
Content-Type: text/plain; charset=UTF-8

On 28 Aug 2015 12:37 am, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> The concept of a property is nothing more than a syntax translator,
converting x.y into x.y_get(), or converting x.y = z into x.y_set(z).
Whether it's calling methods with those names, or methods of some other
type, is irrelevant. What matters is that the input syntax results in
specific function calls in specific scenarios.

A property at minimum translates syntax, but it can be much more than that.
For example, Python implements properties via a library function used as a
method decorator, implementing the descriptor protocol, a very hairy
language feature akin to operator dot. That's two highly powerful language
features combined via a library function to provide properties in a recipe
that beginners can use without full understanding. And Python is much more
a beginner-friendly language than C++ aspires to be.

> For example, while thinking about what has to happen to make your inline
classes work, I realized something. Any class that contains an inline class
cannot be trivially copyable. Why? Because inline classes must have an
internal `this` pointer, which refers to the containing object. So you
cannot simply do a memcpy on them; the pointer has to be updated to refer
to the new object. And that requires the generation of a special copy
constructor that uses the new `this` object.

Not true; an inline class has no storage or identity of its own, so a
pointer to an inline class can have the same value as a pointer to the
parent object. Note that within an inline class method "this" refers to the
parent object.

> And you can't do something like pass the correct `this` pointer from the
source of the call. The reason being that you can get references to inline
classes, and those still need to be connected to the originating object
(your `auto& prop` code below captures the issue quite well). So the `this`
pointer must be a member of the inline class type. So there's no getting
around it; holders of inline classes cannot be trivially copied.

Similarly, a reference to an inline class can have the same value as a
reference to the parent object. (It doesn't have to have that value, but
that's the simplest implementation.)

Also, there's no need to allow forming a reference or pointer to an inline
class at all; just as a member function access expression is required to be
subject to a function call operation, an inline class access expression
could be required to be subject to a conversion or operation.

>> >> if it's not a type, how do you solve
>> >> the problem of someone taking a reference to the property and
>> >> subsequently modifying it?
>> >
>> > Property methods return whatever they choose to return.
>>
>> You've previously established that returning a POD reference is broken.
>> (I'm not sure why; I also consider it broken, and am not sure who you
>> thought was suggesting a getter should ever return a reference.)
>
>
> I never said that returning a reference was broken. What's broken is
changing an interface from returning a reference to returning a proxy
object. Returning references is a common C++ idiom. Just check various
APIs; most getters return by `const&`.
>
> It only becomes broken when you need to change the internal
representation of the object.

That would continue to work if the inline class has a conversion to the
appropriate value or const reference; reference binding is allowed to
invoke a conversion function.

>> > If a getter returns
>> > by value, then it returns by value. There are no syntactic guarantees
in
>> > properties that require a getter to return a real reference to an
actual
>> > value that will be updated when the value is changed.
>>
>> As previously illustrated, an inline class will still work with this
code:
>>
>>   auto& prop = foo.bar;
>>   prop = 5;
>
>
> But it wouldn't work on this:
>
> float &prop = foo.bar;
>
> Not everyone uses auto everywhere. Nor should they be required to.

That won't work for any implementation of properties where the getter
returns a value or const reference. So it won't work for your pure
properties either.

>>
>> How will your "real properties" accomplish that? Remember, we've
>> established that decltype(foo.bar) != int&. If it's a reference to an
>> inline class / std::property<int> / etc., there is no problem.
>
>
> Again, you're confusing concept with implementation.
>
> Your proposed implementation makes `foo.bar` resolve to an inline class
value, who's various member functions implement property mechanics. The
pure implementation is for `foo.bar` to automatically be transformed by the
compiler into a function call to either the property getter or property
setter function, based on the expression containing `foo.bar`.
>
> So under those rules, `auto &x = foo.bar` will result in a reference to
whatever the getter for foo.bar returns. If it returns a `float &`, then
that's what will be stored. If it returns a `float` by value, then this
will result in a reference to the temporary float.

You can't form a non-const lvalue reference to a temporary value.

>>
>> >>> It should not have storage.
>> >>
>> >> There has to be storage *somewhere*. Both properties and inline
classes
>> >> use the parent for that storage.
>> >
>> > No, there doesn't.
>>
>> Um... okay, maybe if you're reading from an external input device, I'll
>> buy that. However, I'm talking about the typical case of e.g. the length
>> of a string. Either that length is stored somewhere (normally on the
>> string instance), or it is computed from other data stored on the string
>> instance. Especially in the former case, there *is* storage, it's just
>> that the storage is in the parent class, not the property itself.
>
>
> There's a difference between the storage for the implementation of the
property, and the storage for the data itself. In your inline class case,
your property implementation takes up at least one byte, because properties
are objects (separate from any data storage). And in C++, object members of
a class must take up at least one byte.
>
> A pure property implementation means that there is only the data storage
(if any). The property itself has no storage, because the property is not
an object.

If I understand the proposal correctly, inline classes are either not
objects, or have an exemption from the storage requirement analogous to the
empty base class optimization.

>> >>> It should not consist of anything more than 2 function
>> >>> declarations/definitions.
>> >>
>> >> Most inline class "properties" won't.
>> >
>> > It consists of a class definition. That makes it more than 2 function
>> > definitions.
>>
>> ...which is potentially anonymous. Your choices are:
>>
>>   property get int health() { ... }
>>   property set health(int) { ... }
>>
>> ...or:
>>
>>   property health
>>   {
>>     int get() { ... }
>>     /*?*/ set(int) { ... }
>>   }
>>
>> The latter is hardly different from a typical inline class "property",
>> which was the point.
>
>
> Let's see. Here's what pure property syntax might look like:
>
> struct T
> {
>   int getHealth() property(health) {return _health;}
>   void setHealth(int h) property(health) {_health = h;}
>
> private:
>   int _health;
> };
>
> Here is what your inline class syntax would have to do to be equivalent
with that:
>
> struct T
> {
>   inline class
>   {
>     operator int() {return this->_health;}
>     int operator= (int h) {_health = h; return _health;}
>     int operator+= (int h) {_health += h; return _health;}
>     int operator-= (int h) {_health -= h; return _health;}
>     int operator*= (int h) {_health *= h; return _health;}
>     int operator/= (int h) {_health /= h; return _health;}
>   } health;
> };
>
> Even if we ignore the fact that you have to implement all those forms of
equality assignment if you want users to be able to use it, you've still
caused confusion. The "getter" method isn't called "get". Indeed, it
doesn't even have a name; it's `operator int`, for some reason. The
"setter" method also doesn't have a name; you instead overload operator=.
>
> That's not exactly something the neophyte C++ programmer will understand.
People coming from languages with pure property support will expect
something rather different in terms of syntax.

Does that matter? As mentioned above beginner Python programmers aren't
expected to understand how properties work; they just use them.

Also, the operator overloads could be provided by a library facility to
forward to named getter and setter.

>> > So what if it needs keywords?
>>
>> Aren't you the one always harping on how "syntax is rare and precious"?
>> Adding keywords is a recipe for breaking existing code. Reusing existing
>> keywords in ways that aren't currently legal can't break old code.
>>
>> > We should not implement a feature in an ugly or unintuitive way
>>
>> I fail to see how "inline class" is unintuitive. It is a class whose
>> storage is "inline" in the parent. (And anyway, I'm not wedded to that
>> exact syntax, though I remain unconvinced that the cost of a new keyword
>> exceeds the alleged cost of "being unintuitive".)
>>
>> > (and it's hard to claim that your way of using type conversion and
>> > having to overload every assignment operator is not unintuitive)
>>
>> How is it not? An inline class is clearly an object, like any other
>> struct/class type, so when I write 'foo.bar', I clearly have a Foo::Bar
>> (assuming it is named and not anonymous). That being the case, it is
>> clear that if I want to change that, I would use an assignment operator.
>> Or if I want to use it as an int, I would use a conversion operator.
>>
>> You don't need to overload *every* assignment operator, just the ones
>> you care about.
>
>
> If it's more than one, it's too many. You don't see other languages
implementing properties that way. You implement one getter and one setter,
period.
>
>>
>> And I fail to see how you would improve upon this.
>
>
> Because you only have to implement a single getter and a single setter.
Supporting += requires no effort; the compiler handles it for you, so long
as the type returned by the getter supports operator+.

That's rarely what you actually want, though. Consider health: setting
health greater than the max value is an error, but increasing it by 10 just
clips at the maximum. So not only do we need a user-defined operator+=, it
needs its own code that is not just a forward to operator=.

Sure, you could have the getter return a proxy object with an operator+
that performs the clipping, and a conversion function to int. But how
confusing would that be?

> Also, there's explicit syntax for declaring a property, rather than
building a type and piggybacking some syntax off of implicit conversions or
operator= or whatever. It looks like a real language feature.

It looks like shoehorning in a narrow solution to a very specific problem,
that doesn't even fully solve that problem. (The health += issue, above.)

By contrast, consider the general problem of properties: we want a class
member access to result in an entity that invokes user code when used as an
rvalue, and (different) user code when used as the LHS of an assignment. To
this problem, inline classes or something similar are a natural solution.

>> If
>> you actually need different behavior when assigning a temporary vs. a
>> copy to a property, you're going to have to provide setters for both
>> cases anyway, whether they look like "property set" or "operator=".
>
>
> Why would you need different behavior?
>
>>
>> Again, inline classes have the HUGE benefit of reusing existing concepts
>> rather than inventing new ones.
>>
>> > Also, they could be contextual keywords.
>>
>> How? Again, I'm still waiting on a *concrete* proposal for an alternate
>> syntax. So far all I've heard is equivocating.
>
>
> You don't seem to understand what I'm saying here. I'm saying these two
things:
>
> #1: I don't think properties belong in C++.
>
> #2: If properties are important enough to be taken into the standard,
then they should be important enough to be done correctly.
>
> Because of #1, I have no desire to provide a full proposal for a pure
implementation of properties. Because of #2, I oppose your proposed
solution because it's a hack designed to be the minimally offensive to the
committee, not a natural way to implement the feature.
>
>> >>> Unless there is some other use for these inline classes, I'm against
>> >>> using them as a way to put properties into the language.
>> >>
>> >> Sort of related, but how about this?
>> >>
>> >>   auto c = get_color();
>> >>   c.hsl.hue = 15;
>> >>   cout << c.hcy.hue;
>> >
>> > Any form of properties could do that.
>>
>> Please *show* how you would implement this with something other than
>> inline classes. (The color class may store RGB triples. The properties
>> may not have their own storage, nor may you create temporary non-POD
>> objects.)
>
>
> Why are those solutions not allowed? Remember what properties are: a
shorthand syntax for calling getters/setters. So `c.hsl.hue = ...`
conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.
>
> That's what properties are for.
>
> In order to implement this using function call syntax, I would return
appropriate proxy objects, which are non-PODs that contain references to
data. The presence or absence of properties, of any form, does not how one
goes about solving the problem. Your solution uses proxy objects too; it
just so happens that your proxy objects are permanent fixtures of an
object, rather than temporaries created on the stack.

Inline classes are not proxy objects. Possibly they are subobjects, but
there is no proxying involved.

> Proxy objects are proxy objects no matter where they come from.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7b4142f0eee05a051e7d00bb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 28 Aug 2015 12:37 am, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmck=
esson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; The concept of a property is nothing more than a syntax translator, co=
nverting x.y into x.y_get(), or converting x.y =3D z into x.y_set(z). Wheth=
er it&#39;s calling methods with those names, or methods of some other type=
, is irrelevant. What matters is that the input syntax results in specific =
function calls in specific scenarios.</p>
<p dir=3D"ltr">A property at minimum translates syntax, but it can be much =
more than that. For example, Python implements properties via a library fun=
ction used as a method decorator, implementing the descriptor protocol, a v=
ery hairy language feature akin to operator dot. That&#39;s two highly powe=
rful language features combined via a library function to provide propertie=
s in a recipe that beginners can use without full understanding. And Python=
 is much more a beginner-friendly language than C++ aspires to be. </p>
<p dir=3D"ltr">&gt; For example, while thinking about what has to happen to=
 make your inline classes work, I realized something. Any class that contai=
ns an inline class cannot be trivially copyable. Why? Because inline classe=
s must have an internal `this` pointer, which refers to the containing obje=
ct. So you cannot simply do a memcpy on them; the pointer has to be updated=
 to refer to the new object. And that requires the generation of a special =
copy constructor that uses the new `this` object.</p>
<p dir=3D"ltr">Not true; an inline class has no storage or identity of its =
own, so a pointer to an inline class can have the same value as a pointer t=
o the parent object. Note that within an inline class method &quot;this&quo=
t; refers to the parent object. </p>
<p dir=3D"ltr">&gt; And you can&#39;t do something like pass the correct `t=
his` pointer from the source of the call. The reason being that you can get=
 references to inline classes, and those still need to be connected to the =
originating object (your `auto&amp; prop` code below captures the issue qui=
te well). So the `this` pointer must be a member of the inline class type. =
So there&#39;s no getting around it; holders of inline classes cannot be tr=
ivially copied.</p>
<p dir=3D"ltr">Similarly, a reference to an inline class can have the same =
value as a reference to the parent object. (It doesn&#39;t have to have tha=
t value, but that&#39;s the simplest implementation.) </p>
<p dir=3D"ltr">Also, there&#39;s no need to allow forming a reference or po=
inter to an inline class at all; just as a member function access expressio=
n is required to be subject to a function call operation, an inline class a=
ccess expression could be required to be subject to a conversion or operati=
on. </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; if it&#39;s not a type, how do you solve <=
br>
&gt;&gt; &gt;&gt; the problem of someone taking a reference to the property=
 and <br>
&gt;&gt; &gt;&gt; subsequently modifying it? <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; Property methods return whatever they choose to return. <br>
&gt;&gt;<br>
&gt;&gt; You&#39;ve previously established that returning a POD reference i=
s broken. <br>
&gt;&gt; (I&#39;m not sure why; I also consider it broken, and am not sure =
who you <br>
&gt;&gt; thought was suggesting a getter should ever return a reference.)<b=
r>
&gt;<br>
&gt;<br>
&gt; I never said that returning a reference was broken. What&#39;s broken =
is changing an interface from returning a reference to returning a proxy ob=
ject. Returning references is a common C++ idiom. Just check various APIs; =
most getters return by `const&amp;`.<br>
&gt;<br>
&gt; It only becomes broken when you need to change the internal representa=
tion of the object.</p>
<p dir=3D"ltr">That would continue to work if the inline class has a conver=
sion to the appropriate value or const reference; reference binding is allo=
wed to invoke a conversion function. </p>
<p dir=3D"ltr">&gt;&gt; &gt; If a getter returns <br>
&gt;&gt; &gt; by value, then it returns by value. There are no syntactic gu=
arantees in <br>
&gt;&gt; &gt; properties that require a getter to return a real reference t=
o an actual <br>
&gt;&gt; &gt; value that will be updated when the value is changed. <br>
&gt;&gt;<br>
&gt;&gt; As previously illustrated, an inline class will still work with th=
is code: <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 auto&amp; prop =3D foo.bar; <br>
&gt;&gt; =C2=A0 prop =3D 5; <br>
&gt;<br>
&gt;<br>
&gt; But it wouldn&#39;t work on this:<br>
&gt;<br>
&gt; float &amp;prop =3D foo.bar;<br>
&gt;<br>
&gt; Not everyone uses auto everywhere. Nor should they be required to.</p>
<p dir=3D"ltr">That won&#39;t work for any implementation of properties whe=
re the getter returns a value or const reference. So it won&#39;t work for =
your pure properties either. </p>
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; How will your &quot;real properties&quot; accomplish that? Remembe=
r, we&#39;ve <br>
&gt;&gt; established that decltype(foo.bar) !=3D int&amp;. If it&#39;s a re=
ference to an <br>
&gt;&gt; inline class / std::property&lt;int&gt; / etc., there is no proble=
m.<br>
&gt;<br>
&gt;<br>
&gt; Again, you&#39;re confusing concept with implementation.<br>
&gt;<br>
&gt; Your proposed implementation makes `foo.bar` resolve to an inline clas=
s value, who&#39;s various member functions implement property mechanics. T=
he pure implementation is for `foo.bar` to automatically be transformed by =
the compiler into a function call to either the property getter or property=
 setter function, based on the expression containing `foo.bar`.<br>
&gt;<br>
&gt; So under those rules, `auto &amp;x =3D foo.bar` will result in a refer=
ence to whatever the getter for foo.bar returns. If it returns a `float &am=
p;`, then that&#39;s what will be stored. If it returns a `float` by value,=
 then this will result in a reference to the temporary float.</p>
<p dir=3D"ltr">You can&#39;t form a non-const lvalue reference to a tempora=
ry value. </p>
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; It should not have storage. <br>
&gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; There has to be storage *somewhere*. Both properties and =
inline classes <br>
&gt;&gt; &gt;&gt; use the parent for that storage. <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; No, there doesn&#39;t. <br>
&gt;&gt;<br>
&gt;&gt; Um... okay, maybe if you&#39;re reading from an external input dev=
ice, I&#39;ll <br>
&gt;&gt; buy that. However, I&#39;m talking about the typical case of e.g. =
the length <br>
&gt;&gt; of a string. Either that length is stored somewhere (normally on t=
he <br>
&gt;&gt; string instance), or it is computed from other data stored on the =
string <br>
&gt;&gt; instance. Especially in the former case, there *is* storage, it&#3=
9;s just <br>
&gt;&gt; that the storage is in the parent class, not the property itself.<=
br>
&gt;<br>
&gt;<br>
&gt; There&#39;s a difference between the storage for the implementation of=
 the property, and the storage for the data itself. In your inline class ca=
se, your property implementation takes up at least one byte, because proper=
ties are objects (separate from any data storage). And in C++, object membe=
rs of a class must take up at least one byte.<br>
&gt;<br>
&gt; A pure property implementation means that there is only the data stora=
ge (if any). The property itself has no storage, because the property is no=
t an object.</p>
<p dir=3D"ltr">If I understand the proposal correctly, inline classes are e=
ither not objects, or have an exemption from the storage requirement analog=
ous to the empty base class optimization. </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt;&gt; It should not consist of anything more=
 than 2 function <br>
&gt;&gt; &gt;&gt;&gt; declarations/definitions. <br>
&gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; Most inline class &quot;properties&quot; won&#39;t. <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; It consists of a class definition. That makes it more than 2 =
function <br>
&gt;&gt; &gt; definitions. <br>
&gt;&gt;<br>
&gt;&gt; ...which is potentially anonymous. Your choices are: <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 property get int health() { ... } <br>
&gt;&gt; =C2=A0 property set health(int) { ... } <br>
&gt;&gt;<br>
&gt;&gt; ...or: <br>
&gt;&gt;<br>
&gt;&gt; =C2=A0 property health <br>
&gt;&gt; =C2=A0 { <br>
&gt;&gt; =C2=A0 =C2=A0 int get() { ... } <br>
&gt;&gt; =C2=A0 =C2=A0 /*?*/ set(int) { ... } <br>
&gt;&gt; =C2=A0 } <br>
&gt;&gt;<br>
&gt;&gt; The latter is hardly different from a typical inline class &quot;p=
roperty&quot;, <br>
&gt;&gt; which was the point.<br>
&gt;<br>
&gt;<br>
&gt; Let&#39;s see. Here&#39;s what pure property syntax might look like:<b=
r>
&gt;<br>
&gt; struct T<br>
&gt; {<br>
&gt; =C2=A0 int getHealth() property(health) {return _health;}<br>
&gt; =C2=A0 void setHealth(int h) property(health) {_health =3D h;}<br>
&gt;<br>
&gt; private:<br>
&gt; =C2=A0 int _health;<br>
&gt; };<br>
&gt;<br>
&gt; Here is what your inline class syntax would have to do to be equivalen=
t with that:<br>
&gt;<br>
&gt; struct T<br>
&gt; {<br>
&gt; =C2=A0 inline class<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 operator int() {return this-&gt;_health;}<br>
&gt; =C2=A0 =C2=A0 int operator=3D (int h) {_health =3D h; return _health;}=
<br>
&gt; =C2=A0 =C2=A0 int operator+=3D (int h) {_health +=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator-=3D (int h) {_health -=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator*=3D (int h) {_health *=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator/=3D (int h) {_health /=3D h; return _health=
;}<br>
&gt; =C2=A0 } health;<br>
&gt; };<br>
&gt;<br>
&gt; Even if we ignore the fact that you have to implement all those forms =
of equality assignment if you want users to be able to use it, you&#39;ve s=
till caused confusion. The &quot;getter&quot; method isn&#39;t called &quot=
;get&quot;. Indeed, it doesn&#39;t even have a name; it&#39;s `operator int=
`, for some reason. The &quot;setter&quot; method also doesn&#39;t have a n=
ame; you instead overload operator=3D.<br>
&gt;<br>
&gt; That&#39;s not exactly something the neophyte C++ programmer will unde=
rstand. People coming from languages with pure property support will expect=
 something rather different in terms of syntax.</p>
<p dir=3D"ltr">Does that matter? As mentioned above beginner Python program=
mers aren&#39;t expected to understand how properties work; they just use t=
hem. </p>
<p dir=3D"ltr">Also, the operator overloads could be provided by a library =
facility to forward to named getter and setter.</p>
<p dir=3D"ltr">&gt;&gt; &gt; So what if it needs keywords? <br>
&gt;&gt;<br>
&gt;&gt; Aren&#39;t you the one always harping on how &quot;syntax is rare =
and precious&quot;? <br>
&gt;&gt; Adding keywords is a recipe for breaking existing code. Reusing ex=
isting <br>
&gt;&gt; keywords in ways that aren&#39;t currently legal can&#39;t break o=
ld code. <br>
&gt;&gt;<br>
&gt;&gt; &gt; We should not implement a feature in an ugly or unintuitive w=
ay <br>
&gt;&gt;<br>
&gt;&gt; I fail to see how &quot;inline class&quot; is unintuitive. It is a=
 class whose <br>
&gt;&gt; storage is &quot;inline&quot; in the parent. (And anyway, I&#39;m =
not wedded to that <br>
&gt;&gt; exact syntax, though I remain unconvinced that the cost of a new k=
eyword <br>
&gt;&gt; exceeds the alleged cost of &quot;being unintuitive&quot;.) <br>
&gt;&gt;<br>
&gt;&gt; &gt; (and it&#39;s hard to claim that your way of using type conve=
rsion and <br>
&gt;&gt; &gt; having to overload every assignment operator is not unintuiti=
ve) <br>
&gt;&gt;<br>
&gt;&gt; How is it not? An inline class is clearly an object, like any othe=
r <br>
&gt;&gt; struct/class type, so when I write &#39;foo.bar&#39;, I clearly ha=
ve a Foo::Bar <br>
&gt;&gt; (assuming it is named and not anonymous). That being the case, it =
is <br>
&gt;&gt; clear that if I want to change that, I would use an assignment ope=
rator. <br>
&gt;&gt; Or if I want to use it as an int, I would use a conversion operato=
r. <br>
&gt;&gt;<br>
&gt;&gt; You don&#39;t need to overload *every* assignment operator, just t=
he ones <br>
&gt;&gt; you care about.<br>
&gt;<br>
&gt;<br>
&gt; If it&#39;s more than one, it&#39;s too many. You don&#39;t see other =
languages implementing properties that way. You implement one getter and on=
e setter, period.<br>
&gt;<br>
&gt;&gt;<br>
&gt;&gt; And I fail to see how you would improve upon this.<br>
&gt;<br>
&gt;<br>
&gt; Because you only have to implement a single getter and a single setter=
.. Supporting +=3D requires no effort; the compiler handles it for you, so l=
ong as the type returned by the getter supports operator+.</p>
<p dir=3D"ltr">That&#39;s rarely what you actually want, though. Consider h=
ealth: setting health greater than the max value is an error, but increasin=
g it by 10 just clips at the maximum. So not only do we need a user-defined=
 operator+=3D, it needs its own code that is not just a forward to operator=
=3D.</p>
<p dir=3D"ltr">Sure, you could have the getter return a proxy object with a=
n operator+ that performs the clipping, and a conversion function to int. B=
ut how confusing would that be? </p>
<p dir=3D"ltr">&gt; Also, there&#39;s explicit syntax for declaring a prope=
rty, rather than building a type and piggybacking some syntax off of implic=
it conversions or operator=3D or whatever. It looks like a real language fe=
ature.</p>
<p dir=3D"ltr">It looks like shoehorning in a narrow solution to a very spe=
cific problem, that doesn&#39;t even fully solve that problem. (The health =
+=3D issue, above.) </p>
<p dir=3D"ltr">By contrast, consider the general problem of properties: we =
want a class member access to result in an entity that invokes user code wh=
en used as an rvalue, and (different) user code when used as the LHS of an =
assignment. To this problem, inline classes or something similar are a natu=
ral solution.</p>
<p dir=3D"ltr">&gt;&gt; If <br>
&gt;&gt; you actually need different behavior when assigning a temporary vs=
.. a <br>
&gt;&gt; copy to a property, you&#39;re going to have to provide setters fo=
r both <br>
&gt;&gt; cases anyway, whether they look like &quot;property set&quot; or &=
quot;operator=3D&quot;.<br>
&gt;<br>
&gt;<br>
&gt; Why would you need different behavior?<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; Again, inline classes have the HUGE benefit of reusing existing co=
ncepts <br>
&gt;&gt; rather than inventing new ones. <br>
&gt;&gt;<br>
&gt;&gt; &gt; Also, they could be contextual keywords. <br>
&gt;&gt;<br>
&gt;&gt; How? Again, I&#39;m still waiting on a *concrete* proposal for an =
alternate <br>
&gt;&gt; syntax. So far all I&#39;ve heard is equivocating.<br>
&gt;<br>
&gt;<br>
&gt; You don&#39;t seem to understand what I&#39;m saying here. I&#39;m say=
ing these two things:<br>
&gt;<br>
&gt; #1: I don&#39;t think properties belong in C++.<br>
&gt;<br>
&gt; #2: If properties are important enough to be taken into the standard, =
then they should be important enough to be done correctly.<br>
&gt;<br>
&gt; Because of #1, I have no desire to provide a full proposal for a pure =
implementation of properties. Because of #2, I oppose your proposed solutio=
n because it&#39;s a hack designed to be the minimally offensive to the com=
mittee, not a natural way to implement the feature.<br>
&gt;<br>
&gt;&gt; &gt;&gt;&gt; Unless there is some other use for these inline class=
es, I&#39;m against <br>
&gt;&gt; &gt;&gt;&gt; using them as a way to put properties into the langua=
ge. <br>
&gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; Sort of related, but how about this? <br>
&gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; =C2=A0 auto c =3D get_color(); <br>
&gt;&gt; &gt;&gt; =C2=A0 c.hsl.hue =3D 15; <br>
&gt;&gt; &gt;&gt; =C2=A0 cout &lt;&lt; c.hcy.hue; <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; Any form of properties could do that. <br>
&gt;&gt;<br>
&gt;&gt; Please *show* how you would implement this with something other th=
an <br>
&gt;&gt; inline classes. (The color class may store RGB triples. The proper=
ties <br>
&gt;&gt; may not have their own storage, nor may you create temporary non-P=
OD <br>
&gt;&gt; objects.) <br>
&gt;<br>
&gt;<br>
&gt; Why are those solutions not allowed? Remember what properties are: a s=
horthand syntax for calling getters/setters. So `c.hsl.hue =3D ...` concept=
ually transforms to `c.hsl_get().hue_set(...);` And so forth.<br>
&gt;<br>
&gt; That&#39;s what properties are for.<br>
&gt;<br>
&gt; In order to implement this using function call syntax, I would return =
appropriate proxy objects, which are non-PODs that contain references to da=
ta. The presence or absence of properties, of any form, does not how one go=
es about solving the problem. Your solution uses proxy objects too; it just=
 so happens that your proxy objects are permanent fixtures of an object, ra=
ther than temporaries created on the stack.</p>
<p dir=3D"ltr">Inline classes are not proxy objects. Possibly they are subo=
bjects, but there is no proxying involved. </p>
<p dir=3D"ltr">&gt; Proxy objects are proxy objects no matter where they co=
me from.<br>
</p>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7b4142f0eee05a051e7d00bb--

.

------=_Part_489_1357704064.1440905822206
Content-Type: multipart/alternative;
 boundary="----=_Part_490_1432935414.1440905822207"

------=_Part_490_1432935414.1440905822207
Content-Type: text/plain; charset=UTF-8

On Saturday, August 29, 2015 at 9:12:00 PM UTC-4, Edward Catmur wrote:
>
>
> On 28 Aug 2015 12:37 am, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> > The concept of a property is nothing more than a syntax translator,
> converting x.y into x.y_get(), or converting x.y = z into x.y_set(z).
> Whether it's calling methods with those names, or methods of some other
> type, is irrelevant. What matters is that the input syntax results in
> specific function calls in specific scenarios.
>
> A property at minimum translates syntax, but it can be much more than
> that. For example, Python implements properties via a library function used
> as a method decorator, implementing the descriptor protocol, a very hairy
> language feature akin to operator dot. That's two highly powerful language
> features combined via a library function to provide properties in a recipe
> that beginners can use without full understanding. And Python is much more
> a beginner-friendly language than C++ aspires to be
>

Um, I'm not sure what you're responding to here. I explained what
properties are, conceptually as a feature. You immediately started talking
about an *implementation* of them.

My entire point was to talk about the difference between "what you want"
and "how you go about getting it". The fact that Python has a particular
way of "how you go about getting it" that is conceptually complicated yet
wrapped up in a nice library function is essentially irrelevant to this
part of the discussion.

Yes, the implementation has consequences, but this is usually in the scope
of a larger construct. Languages that use duck typing tend to get
properties as a natural outgrowth of a flexible type system. That changes
nothing about the concept of properties.

Also, you have yet to show me *one useful thing* that inline classes can do
that don't involve properties. Whereas duck typing is absurdly useful and
frequently self-justifying. The same feature that makes properties work in
Python makes about 10,000 other things work in Python.

What else can inline classes do besides properties?


> > For example, while thinking about what has to happen to make your inline
> classes work, I realized something. Any class that contains an inline class
> cannot be trivially copyable. Why? Because inline classes must have an
> internal `this` pointer, which refers to the containing object. So you
> cannot simply do a memcpy on them; the pointer has to be updated to refer
> to the new object. And that requires the generation of a special copy
> constructor that uses the new `this` object.
>
> Not true; an inline class has no storage or identity of its own, so a
> pointer to an inline class can have the same value as a pointer to the
> parent object. Note that within an inline class method "this" refers to the
> parent object.
>

OK, now you're just Calvinballing: inventing arbitrary features every time
someone comes along and explains why what you want doesn't work.

And like with most Calvinballs, I don't think you thought that idea
through. Ignoring any potential strict aliasing minefields with this,
you're basically saying that you can't pass a property by reference to any
function if the type of that argument is deduced.

With concepts and terse template syntax coming along... that's going to be
an increasingly large number of functions. That's a substantial weakness of
this property implementation.


> > And you can't do something like pass the correct `this` pointer from the
> source of the call. The reason being that you can get references to inline
> classes, and those still need to be connected to the originating object
> (your `auto& prop` code below captures the issue quite well). So the `this`
> pointer must be a member of the inline class type. So there's no getting
> around it; holders of inline classes cannot be trivially copied.
>
> Similarly, a reference to an inline class can have the same value as a
> reference to the parent object. (It doesn't have to have that value, but
> that's the simplest implementation.)
>
Also, there's no need to allow forming a reference or pointer to an inline
> class at all; just as a member function access expression is required to be
> subject to a function call operation, an inline class access expression
> could be required to be subject to a conversion or operation.
>

OK, so I can't get a pointer to it. I can't get a reference to it. It
doesn't have a typename. It doesn't have a size.

How is an inline class *an object at all?* Because C++ is quite clear about
this: "An object is a region of storage". You can't have a region of 0. So
these inline classes are not a region of storage, and therefore they are
not objects.

Or are you going to Calvinball a new definition for the C++ term "object"
so that it applies to inline classes? Because types only apply to objects,
references, or functions. And inline classes, as you have defined them, are
none of those. Therefore, they cannot have types. And they cannot
participate in things like operator overloading and so forth.

When you're putting this many hacks into something just to make it do what
you want it to, you should stop and reconsider if this is the right way to
achieve the desired goal.

>>
> >> >>> It should not have storage.
> >> >>
> >> >> There has to be storage *somewhere*. Both properties and inline
> classes
> >> >> use the parent for that storage.
> >> >
> >> > No, there doesn't.
> >>
> >> Um... okay, maybe if you're reading from an external input device, I'll
> >> buy that. However, I'm talking about the typical case of e.g. the
> length
> >> of a string. Either that length is stored somewhere (normally on the
> >> string instance), or it is computed from other data stored on the
> string
> >> instance. Especially in the former case, there *is* storage, it's just
> >> that the storage is in the parent class, not the property itself.
> >
> >
> > There's a difference between the storage for the implementation of the
> property, and the storage for the data itself. In your inline class case,
> your property implementation takes up at least one byte, because properties
> are objects (separate from any data storage). And in C++, object members of
> a class must take up at least one byte.
> >
> > A pure property implementation means that there is only the data storage
> (if any). The property itself has no storage, because the property is not
> an object.
>
> If I understand the proposal correctly, inline classes are either not
> objects, or have an exemption from the storage requirement analogous to the
> empty base class optimization.
>

If "inline classes" are not objects, then they should not use the word
"class" to declare/define them.

EBO gymnastics might work (the type has the minimum storage requirements,
but in its current use, it doesn't take up any), but remember that EBO is
not required from compilers (except for standard layout types). Also, it is
not clear what the strict aliasing issues with this would be.

> Let's see. Here's what pure property syntax might look like:
> >
> > struct T
> > {
> >   int getHealth() property(health) {return _health;}
> >   void setHealth(int h) property(health) {_health = h;}
> >
> > private:
> >   int _health;
> > };
> >
> > Here is what your inline class syntax would have to do to be equivalent
> with that:
> >
> > struct T
> > {
> >   inline class
> >   {
> >     operator int() {return this->_health;}
> >     int operator= (int h) {_health = h; return _health;}
> >     int operator+= (int h) {_health += h; return _health;}
> >     int operator-= (int h) {_health -= h; return _health;}
> >     int operator*= (int h) {_health *= h; return _health;}
> >     int operator/= (int h) {_health /= h; return _health;}
> >   } health;
> > };
> >
> > Even if we ignore the fact that you have to implement all those forms of
> equality assignment if you want users to be able to use it, you've still
> caused confusion. The "getter" method isn't called "get". Indeed, it
> doesn't even have a name; it's `operator int`, for some reason. The
> "setter" method also doesn't have a name; you instead overload operator=.
> >
> > That's not exactly something the neophyte C++ programmer will
> understand. People coming from languages with pure property support will
> expect something rather different in terms of syntax.
>
> Does that matter? As mentioned above beginner Python programmers aren't
> expected to understand how properties work; they just use them.
>

Um, Python property syntax looks like this:

@property
def x(self):
  ...

@x.setter
def x(self, x):
  ...

See how it involves actual words like "property" and "set" and so forth?
The syntax you're suggesting for C++ involves words like "inline class" and
"operator Typename". None of which have anything to do with the concept of
properties, getters, setters, etc.

Neophytes may not know what a "descriptor" is or what `@***` actually is
doing, but at least it's using words that they understand.

Also, the operator overloads could be provided by a library facility to
> forward to named getter and setter.
>

Let me guess. You want to have inline classes able to derive from some
std::property library class. You want an anonymous class with no storage...
to have a base class.

That opens up an entire avenue of problems. The defining feature of inline
classes is that their `this` pointer points to the owning object. This
effectively means that they can't even call other methods on themselves.
Well... how does that work with base classes? How can their base class get
a `this` pointer that points to its own type, but the derived inline class
cannot? How can the base class call a member of a class that doesn't even
have a `this` pointer?

What will you want next? When you realize that you can't have this
hypothetical `std::property` object actually call members on its derived
type, will you decide you need *virtual* functions on these supposedly
stateless objects? Where does the hacking end?

Can you not see how far you're reaching to force this implementation to
actually implement properties? It's an object, but you can't get a
pointer/reference to it. It's an object, but it doesn't take up actual
space. It's a class, but it doesn't have its own `this` pointer. And so
forth.

You're giving inline classes about as many special-case rules as lambdas.
And those are *far more* generally useful than inline classes.

What functionality does inline classes provide that *justifies* this level
of special-caseness? And if your only answer is "it lets us have
properties"... well, no, that's not good enough.


> >> And I fail to see how you would improve upon this.
> >
> >
> > Because you only have to implement a single getter and a single setter.
> Supporting += requires no effort; the compiler handles it for you, so long
> as the type returned by the getter supports operator+.
>
> That's rarely what you actually want, though. Consider health: setting
> health greater than the max value is an error,
>

If I allow adding health to clamp, and I want to allow directly setting
health... why would I *not* want it to clamp too? It makes no sense to have
adding health to clamp, yet setting health error out.

Furthermore, I would say that it is *extremely rude* for x += y to have
different behavior from x = x + y. I think it's reasonable to forbid one or
the other. But if you allow both, then both should result in the exact same
thing. The former can be *faster*, but it should *never* be a different
result.

And I would point out that C# works this way too. So that would be expected
by those users.

> Also, there's explicit syntax for declaring a property, rather than
> building a type and piggybacking some syntax off of implicit conversions or
> operator= or whatever. It looks like a real language feature.
>
> It looks like shoehorning in a narrow solution to a very specific problem,
> that doesn't even fully solve that problem. (The health += issue, above.)
>
By contrast, consider the general problem of properties: we want a class
> member access to result in an entity
>

No, we do not, and this is where you keep getting confused about the
difference between "implementation" and "concept".

The core concept of properties is to turn accessing a non-function member
of a class into a function call. "result in an entity" is an implementation
detail, *not* a core part of the idea. And it's an unnecessary
implementation detail, since the compiler could have performed the
transformation just fine by itself.

You're limiting yourself by thinking that the only way to make properties
work is by using existing C++ mechanics.

>>
> >> Please *show* how you would implement this with something other than
> >> inline classes. (The color class may store RGB triples. The properties
> >> may not have their own storage, nor may you create temporary non-POD
> >> objects.)
> >
> >
> > Why are those solutions not allowed? Remember what properties are: a
> shorthand syntax for calling getters/setters. So `c.hsl.hue = ...`
> conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.
> >
> > That's what properties are for.
> >
> > In order to implement this using function call syntax, I would return
> appropriate proxy objects, which are non-PODs that contain references to
> data. The presence or absence of properties, of any form, does not how one
> goes about solving the problem. Your solution uses proxy objects too; it
> just so happens that your proxy objects are permanent fixtures of an
> object, rather than temporaries created on the stack.
>
> Inline classes are not proxy objects. Possibly they are subobjects, but
> there is no proxying involved.
>

A proxy object is an object that stands in for another, which can be used
like the other while forward commands to it to the actual object.

That is *exactly* what an inline class is doing. The "getter" works by
being implicitly converted to the expected type. Thus, it can stand for the
reference to the actual data. The "setter" works by operator overloading,
again based on the expected type. It again can act as though it were the
expected type.

It fits every definition of a proxy object. It may be a reference to a
proxy object rather than one created on the stack. But it does everything a
proxy needs do.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Saturday, August 29, 2015 at 9:12:00 PM UTC-4, Edward Catmur wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"><br>
On 28 Aug 2015 12:37 am, &quot;Nicol Bolas&quot; &lt;<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"X71DCclnBwAJ" rel=3D"nofollow"=
 onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"=
this.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; w=
rote:<br>
&gt; The concept of a property is nothing more than a syntax translator, co=
nverting x.y into x.y_get(), or converting x.y =3D z into x.y_set(z). Wheth=
er it&#39;s calling methods with those names, or methods of some other type=
, is irrelevant. What matters is that the input syntax results in specific =
function calls in specific scenarios.</p>
<p dir=3D"ltr">A property at minimum translates syntax, but it can be much =
more than that. For example, Python implements properties via a library fun=
ction used as a method decorator, implementing the descriptor protocol, a v=
ery hairy language feature akin to operator dot. That&#39;s two highly powe=
rful language features combined via a library function to provide propertie=
s in a recipe that beginners can use without full understanding. And Python=
 is much more a beginner-friendly language than C++ aspires to be</p></bloc=
kquote><div><br>Um, I&#39;m not sure what you&#39;re responding to here. I =
explained what properties are, conceptually as a feature. You immediately s=
tarted talking about an <i>implementation</i> of them.<br><br>My entire poi=
nt was to talk about the difference between &quot;what you want&quot; and &=
quot;how you go about getting it&quot;. The fact that Python has a particul=
ar way of &quot;how you go about getting it&quot; that is conceptually comp=
licated yet wrapped up in a nice library function is essentially irrelevant=
 to this part of the discussion.<br><br>Yes, the implementation has consequ=
ences, but this is usually in the scope of a larger construct. Languages th=
at use duck typing tend to get properties as a natural outgrowth of a flexi=
ble type system. That changes nothing about the concept of properties.<br><=
br>Also, you have yet to show me <i>one useful thing</i> that inline classe=
s can do that don&#39;t involve properties. Whereas duck typing is absurdly=
 useful and frequently self-justifying. The same feature that makes propert=
ies work in Python makes about 10,000 other things work in Python.<br><br>W=
hat else can inline classes do besides properties?<br>=C2=A0</div><blockquo=
te class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left:=
 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt; For example, while thinking about what has to happen to=
 make your inline classes work, I realized something. Any class that contai=
ns an inline class cannot be trivially copyable. Why? Because inline classe=
s must have an internal `this` pointer, which refers to the containing obje=
ct. So you cannot simply do a memcpy on them; the pointer has to be updated=
 to refer to the new object. And that requires the generation of a special =
copy constructor that uses the new `this` object.</p>
<p dir=3D"ltr">Not true; an inline class has no storage or identity of its =
own, so a pointer to an inline class can have the same value as a pointer t=
o the parent object. Note that within an inline class method &quot;this&quo=
t; refers to the parent object. </p></blockquote><div><br>OK, now you&#39;r=
e just Calvinballing: inventing arbitrary features every=20
time someone comes along and explains why what you want doesn&#39;t work.<b=
r><br>And like with most Calvinballs, I don&#39;t think you thought that id=
ea through. Ignoring any potential strict aliasing minefields with this, yo=
u&#39;re basically saying that you can&#39;t pass a property by reference t=
o any function if the type of that argument is deduced.<br><br>With concept=
s and terse template syntax coming along... that&#39;s going to be an incre=
asingly large number of functions. That&#39;s a substantial weakness of thi=
s property implementation.<br>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;">
<p dir=3D"ltr">&gt; And you can&#39;t do something like pass the correct `t=
his` pointer from the source of the call. The reason being that you can get=
 references to inline classes, and those still need to be connected to the =
originating object (your `auto&amp; prop` code below captures the issue qui=
te well). So the `this` pointer must be a member of the inline class type. =
So there&#39;s no getting around it; holders of inline classes cannot be tr=
ivially copied.</p>
<p dir=3D"ltr">Similarly, a reference to an inline class can have the same =
value as a reference to the parent object. (It doesn&#39;t have to have tha=
t value, but that&#39;s the simplest implementation.)=C2=A0</p></blockquote=
><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bo=
rder-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">Also, there&#39;s no need to allow forming a reference or po=
inter to an inline class at all; just as a member function access expressio=
n is required to be subject to a function call operation, an inline class a=
ccess expression could be required to be subject to a conversion or operati=
on. </p></blockquote><div><br>OK, so I can&#39;t get a pointer to it. I can=
&#39;t get a reference to it. It doesn&#39;t have a typename. It doesn&#39;=
t have a size.<br><br>How is an inline class <i>an object at all?</i> Becau=
se C++ is quite clear about this: &quot;An object is a region of storage&qu=
ot;. You can&#39;t have a region of 0. So these inline classes are not a re=
gion of storage, and therefore they are not objects.<br><br>Or are you goin=
g to Calvinball a new definition for the C++ term &quot;object&quot; so tha=
t it applies to inline classes? Because types only apply to objects, refere=
nces, or functions. And inline classes, as you have defined them, are none =
of those. Therefore, they cannot have types. And they cannot participate in=
 things like operator overloading and so forth.<br><br>When you&#39;re putt=
ing this many hacks into something just to make it do what you want it to, =
you should stop and reconsider if this is the right way to achieve the desi=
red goal.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=
=3D"ltr"> </p><p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; &gt;&gt;&gt; It should not have storage. <br>
&gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; There has to be storage *somewhere*. Both properties and =
inline classes <br>
&gt;&gt; &gt;&gt; use the parent for that storage. <br>
&gt;&gt; &gt; <br>
&gt;&gt; &gt; No, there doesn&#39;t. <br>
&gt;&gt;<br>
&gt;&gt; Um... okay, maybe if you&#39;re reading from an external input dev=
ice, I&#39;ll <br>
&gt;&gt; buy that. However, I&#39;m talking about the typical case of e.g. =
the length <br>
&gt;&gt; of a string. Either that length is stored somewhere (normally on t=
he <br>
&gt;&gt; string instance), or it is computed from other data stored on the =
string <br>
&gt;&gt; instance. Especially in the former case, there *is* storage, it&#3=
9;s just <br>
&gt;&gt; that the storage is in the parent class, not the property itself.<=
br>
&gt;<br>
&gt;<br>
&gt; There&#39;s a difference between the storage for the implementation of=
 the property, and the storage for the data itself. In your inline class ca=
se, your property implementation takes up at least one byte, because proper=
ties are objects (separate from any data storage). And in C++, object membe=
rs of a class must take up at least one byte.<br>
&gt;<br>
&gt; A pure property implementation means that there is only the data stora=
ge (if any). The property itself has no storage, because the property is no=
t an object.</p>
<p dir=3D"ltr">If I understand the proposal correctly, inline classes are e=
ither not objects, or have an exemption from the storage requirement analog=
ous to the empty base class optimization.</p></blockquote><div><br>If &quot=
;inline classes&quot; are not objects, then they should not use the word &q=
uot;class&quot; to declare/define them.<br><br>EBO gymnastics might work (t=
he type has the minimum storage requirements, but in its current use, it do=
esn&#39;t take up any), but remember that EBO is not required from compiler=
s (except for standard layout types). Also, it is not clear what the strict=
 aliasing issues with this would be.<br><br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt; Let&#39;s see. Here&#39;s what pure property syntax mig=
ht look like:<br>
&gt;<br>
&gt; struct T<br>
&gt; {<br>
&gt; =C2=A0 int getHealth() property(health) {return _health;}<br>
&gt; =C2=A0 void setHealth(int h) property(health) {_health =3D h;}<br>
&gt;<br>
&gt; private:<br>
&gt; =C2=A0 int _health;<br>
&gt; };<br>
&gt;<br>
&gt; Here is what your inline class syntax would have to do to be equivalen=
t with that:<br>
&gt;<br>
&gt; struct T<br>
&gt; {<br>
&gt; =C2=A0 inline class<br>
&gt; =C2=A0 {<br>
&gt; =C2=A0 =C2=A0 operator int() {return this-&gt;_health;}<br>
&gt; =C2=A0 =C2=A0 int operator=3D (int h) {_health =3D h; return _health;}=
<br>
&gt; =C2=A0 =C2=A0 int operator+=3D (int h) {_health +=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator-=3D (int h) {_health -=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator*=3D (int h) {_health *=3D h; return _health=
;}<br>
&gt; =C2=A0 =C2=A0 int operator/=3D (int h) {_health /=3D h; return _health=
;}<br>
&gt; =C2=A0 } health;<br>
&gt; };<br>
&gt;<br>
&gt; Even if we ignore the fact that you have to implement all those forms =
of equality assignment if you want users to be able to use it, you&#39;ve s=
till caused confusion. The &quot;getter&quot; method isn&#39;t called &quot=
;get&quot;. Indeed, it doesn&#39;t even have a name; it&#39;s `operator int=
`, for some reason. The &quot;setter&quot; method also doesn&#39;t have a n=
ame; you instead overload operator=3D.<br>
&gt;<br>
&gt; That&#39;s not exactly something the neophyte C++ programmer will unde=
rstand. People coming from languages with pure property support will expect=
 something rather different in terms of syntax.</p>
<p dir=3D"ltr">Does that matter? As mentioned above beginner Python program=
mers aren&#39;t expected to understand how properties work; they just use t=
hem.</p></blockquote><div><br>Um, Python property syntax looks like this:<b=
r><br><div class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 2=
50); border-color: rgb(187, 187, 187); border-style: solid; border-width: 1=
px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subpr=
ettyprint"><span style=3D"color: #066;" class=3D"styled-by-prettify">@prope=
rty</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">def</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">self</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">):</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br></span><span style=3D"color: #066;" class=3D"styl=
ed-by-prettify">@x</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">s=
etter<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
ef</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">self</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> x</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">):</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">...</span></div></code></div><br>See how it involves ac=
tual words like &quot;property&quot; and &quot;set&quot; and so forth? The =
syntax you&#39;re suggesting for C++ involves words like &quot;inline class=
&quot; and &quot;operator Typename&quot;. None of which have anything to do=
 with the concept of properties, getters, setters, etc.<br><br>Neophytes ma=
y not know what a &quot;descriptor&quot; is or what `@***` actually is doin=
g, but at least it&#39;s using words that they understand.<br><br><i></i></=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex=
;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">Also, the operator overloads could be provided by a library =
facility to forward to named getter and setter.</p></blockquote><div><br>Le=
t me guess. You want to have inline classes able to derive from some std::p=
roperty library class. You want an anonymous class with no storage... to ha=
ve a base class.<br><br>That opens up an entire avenue of problems. The def=
ining feature of inline classes is that their `this` pointer points to the =
owning object. This effectively means that they can&#39;t even call other m=
ethods on themselves. Well... how does that work with base classes? How can=
 their base class get a `this` pointer that points to its own type, but the=
 derived inline class cannot? How can the base class call a member of a cla=
ss that doesn&#39;t even have a `this` pointer?<br><br>What will you want n=
ext? When you realize that you can&#39;t have this hypothetical `std::prope=
rty` object actually call members on its derived type, will you decide you =
need <i>virtual</i> functions on these supposedly stateless objects? Where =
does the hacking end?<br><br>Can you not see how far you&#39;re reaching to=
 force this implementation to actually implement properties? It&#39;s an ob=
ject, but you can&#39;t get a pointer/reference to it. It&#39;s an object, =
but it doesn&#39;t take up actual space. It&#39;s a class, but it doesn&#39=
;t have its own `this` pointer. And so forth.<br><br>You&#39;re giving inli=
ne classes about as many special-case rules as lambdas. And those are <i>fa=
r more</i> generally useful than inline classes.<br><br>What functionality =
does inline classes provide that <i>justifies</i> this level of special-cas=
eness? And if your only answer is &quot;it lets us have properties&quot;...=
 well, no, that&#39;s not good enough.<br>=C2=A0</div><blockquote class=3D"=
gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc so=
lid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;&gt; And I fail to see how you would improve upon this.<=
br>
&gt;<br>
&gt;<br>
&gt; Because you only have to implement a single getter and a single setter=
.. Supporting +=3D requires no effort; the compiler handles it for you, so l=
ong as the type returned by the getter supports operator+.</p>
<p dir=3D"ltr">That&#39;s rarely what you actually want, though. Consider h=
ealth: setting health greater than the max value is an error,</p></blockquo=
te><div><br>If I allow adding health to clamp, and I want to allow directly=
 setting health... why would I <i>not</i> want it to clamp too? It makes no=
 sense to have adding health to clamp, yet setting health error out.<br><br=
>Furthermore, I would say that it is <i>extremely rude</i> for x +=3D y to =
have different behavior from x =3D x + y. I think it&#39;s reasonable to fo=
rbid one or the other. But if you allow both, then both should result in th=
e exact same thing. The former can be <i>faster</i>, but it should <i>never=
</i> be a different result.<br><br>And I would point out that C# works this=
 way too. So that would be expected by those users.<br><br></div><blockquot=
e class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: =
1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">&gt; Also, there&#39;s ex=
plicit syntax for declaring a property, rather than building a type and pig=
gybacking some syntax off of implicit conversions or operator=3D or whateve=
r. It looks like a real language feature.</p>
<p dir=3D"ltr">It looks like shoehorning in a narrow solution to a very spe=
cific problem, that doesn&#39;t even fully solve that problem. (The health =
+=3D issue, above.)<br></p></blockquote><blockquote class=3D"gmail_quote" s=
tyle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-le=
ft: 1ex;">
<p dir=3D"ltr">By contrast, consider the general problem of properties: we =
want a class member access to result in an entity</p></blockquote><div><br>=
No, we do not, and this is where you keep getting confused about the differ=
ence between &quot;implementation&quot; and &quot;concept&quot;.<br><br>The=
 core concept of properties is to turn accessing a non-function member of a=
 class into a function call. &quot;result in an entity&quot; is an implemen=
tation detail, <i>not</i> a core part of the idea. And it&#39;s an unnecess=
ary implementation detail, since the compiler could have performed the tran=
sformation just fine by itself.<br><br>You&#39;re limiting yourself by thin=
king that the only way to make properties work is by using existing C++ mec=
hanics.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; Please *show* how you would implement this with something other th=
an <br>
&gt;&gt; inline classes. (The color class may store RGB triples. The proper=
ties <br>
&gt;&gt; may not have their own storage, nor may you create temporary non-P=
OD <br>
&gt;&gt; objects.) <br>
&gt;<br>
&gt;<br>
&gt; Why are those solutions not allowed? Remember what properties are: a s=
horthand syntax for calling getters/setters. So `c.hsl.hue =3D ...` concept=
ually transforms to `c.hsl_get().hue_set(...);` And so forth.<br>
&gt;<br>
&gt; That&#39;s what properties are for.<br>
&gt;<br>
&gt; In order to implement this using function call syntax, I would return =
appropriate proxy objects, which are non-PODs that contain references to da=
ta. The presence or absence of properties, of any form, does not how one go=
es about solving the problem. Your solution uses proxy objects too; it just=
 so happens that your proxy objects are permanent fixtures of an object, ra=
ther than temporaries created on the stack.</p>
<p dir=3D"ltr">Inline classes are not proxy objects. Possibly they are subo=
bjects, but there is no proxying involved.</p></blockquote><div><br>A proxy=
 object is an object that stands in for another, which can be used like the=
 other while forward commands to it to the actual object.<br><br>That is <i=
>exactly</i> what an inline class is doing. The &quot;getter&quot; works by=
 being implicitly converted to the expected type. Thus, it can stand for th=
e reference to the actual data. The &quot;setter&quot; works by operator ov=
erloading, again based on the expected type. It again can act as though it =
were the expected type.<br><br>It fits every definition of a proxy object. =
It may be a reference to a proxy object rather than one created on the stac=
k. But it does everything a proxy needs do. <br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_490_1432935414.1440905822207--
------=_Part_489_1357704064.1440905822206--

.

Nicol, I think you misunderstand the concept of inline classes as
discussed here, thought wasn't very well explained to be honest.

Inline classes (like nested classes in Java) can only exist as part of
their parent class and can access all their members and methods. Because
they can only exist as part of their containing class there is no need
for a this pointer, or storage if they have no members. The compiler can
convert all access to the inline class to access to the parent object.
Maybe translated to C++ the concept is more like a class-local
namespace, but not quite. It cannot be copied out of a class because it
can only exist as part of its containing object.

Whether calling it "class" or something else, is really just
bikeshedding. One should first determine its conceptual and technical
properties before starting the naming debate. I don't claim to have all
the answers when it comes to applying this concept to C++ and I don't
claim there aren't C++ specificy problems that need solving. It just
felt like the concept wasn't explained very much and therfore caused
ambiguity.

Here some hypothetical example code:

class A {
   int x_data;
public:
   inline struct x {
     x& operator=(int value) {
       x_data = value; // Can access members of containing class
       return *this; // "this" can be impl converted A* <-> A::x*
     }
     int operator int() const { return x_data; }
   };
};
A a;
a.x = 5; // Converted to a.x_operator=(5)
cout << a.x; // Converted to a.x_operator_int()

Even though the setter returns A::x&, the inline class A::x can only
ever exist as reference/pointer outside of A and is only copyable as
part of its containing object, therefore it is not a proxy. To the
compiler A* and A::x* are the same value, they only change what
operations are allowed on the target. In this example A::x has no data
members therefore it conceptually doesn't require storage and &a.x ==
&b.x is only ever true if &a == &b.

A different example where the inline class does have members:

class B {
public:
   inline struct x {
     x& operator=(int value) { x_data = value; return *this; }
     int operator int() const { return x_data; }
   private:
     int data;
   };
   int foo() {
     return x.data * 2;
   }
};
B b;
b.x = 5;
cout << b.foo();

Besides a way to implement properties inline classes can serve to group
membes/methods the same way a non-inline nested class currently does
except it drops the requirement for a this member pointing to the
parent. Even if there was a dedicated property keyword/whatever the
implementation technique could be inline classes and thefore kept open
for advanced users that want more than just the default getter/setter
implementation.

I hope this adequately explains what is meant by inline classes. It just
seemed like it wasn't described very well and people were talking past
each other.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--089e0158bb203fe147051e87d051
Content-Type: text/plain; charset=UTF-8

I think your inline class idea better have it's own discussion thread so
that exploring the concept can be focused on it.
Another point: it seems to me that the definition of such construct could
be reused inside the same class or inside several classes.
So finding a way to avoid having to redefine it all the time would be more
interesting, I think.

On 30 August 2015 at 13:51, Miro Knejp <miro.knejp@gmail.com> wrote:

> Nicol, I think you misunderstand the concept of inline classes as
> discussed here, thought wasn't very well explained to be honest.
>
> Inline classes (like nested classes in Java) can only exist as part of
> their parent class and can access all their members and methods. Because
> they can only exist as part of their containing class there is no need for
> a this pointer, or storage if they have no members. The compiler can
> convert all access to the inline class to access to the parent object.
> Maybe translated to C++ the concept is more like a class-local namespace,
> but not quite. It cannot be copied out of a class because it can only exist
> as part of its containing object.
>
> Whether calling it "class" or something else, is really just bikeshedding.
> One should first determine its conceptual and technical properties before
> starting the naming debate. I don't claim to have all the answers when it
> comes to applying this concept to C++ and I don't claim there aren't C++
> specificy problems that need solving. It just felt like the concept wasn't
> explained very much and therfore caused ambiguity.
>
> Here some hypothetical example code:
>
> class A {
>   int x_data;
> public:
>   inline struct x {
>     x& operator=(int value) {
>       x_data = value; // Can access members of containing class
>       return *this; // "this" can be impl converted A* <-> A::x*
>     }
>     int operator int() const { return x_data; }
>   };
> };
> A a;
> a.x = 5; // Converted to a.x_operator=(5)
> cout << a.x; // Converted to a.x_operator_int()
>
> Even though the setter returns A::x&, the inline class A::x can only ever
> exist as reference/pointer outside of A and is only copyable as part of its
> containing object, therefore it is not a proxy. To the compiler A* and
> A::x* are the same value, they only change what operations are allowed on
> the target. In this example A::x has no data members therefore it
> conceptually doesn't require storage and &a.x == &b.x is only ever true if
> &a == &b.
>
> A different example where the inline class does have members:
>
> class B {
> public:
>   inline struct x {
>     x& operator=(int value) { x_data = value; return *this; }
>     int operator int() const { return x_data; }
>   private:
>     int data;
>   };
>   int foo() {
>     return x.data * 2;
>   }
> };
> B b;
> b.x = 5;
> cout << b.foo();
>
> Besides a way to implement properties inline classes can serve to group
> membes/methods the same way a non-inline nested class currently does except
> it drops the requirement for a this member pointing to the parent. Even if
> there was a dedicated property keyword/whatever the implementation
> technique could be inline classes and thefore kept open for advanced users
> that want more than just the default getter/setter implementation.
>
> I hope this adequately explains what is meant by inline classes. It just
> seemed like it wasn't described very well and people were talking past each
> other.
>
>
> --
>
> --- 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--089e0158bb203fe147051e87d051
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I think your inline class idea better have it&#39;s own di=
scussion thread so that exploring the concept can be focused on it.<div>Ano=
ther point: it seems to me that the definition of such construct could be r=
eused inside the same class or inside several classes.</div><div>So finding=
 a way to avoid having to redefine it all the time would be more interestin=
g, I think.</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On 30 August 2015 at 13:51, Miro Knejp <span dir=3D"ltr">&lt;<a href=
=3D"mailto:miro.knejp@gmail.com" target=3D"_blank">miro.knejp@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Nicol, I think you mis=
understand the concept of inline classes as discussed here, thought wasn&#3=
9;t very well explained to be honest.<br>
<br>
Inline classes (like nested classes in Java) can only exist as part of thei=
r parent class and can access all their members and methods. Because they c=
an only exist as part of their containing class there is no need for a this=
 pointer, or storage if they have no members. The compiler can convert all =
access to the inline class to access to the parent object. Maybe translated=
 to C++ the concept is more like a class-local namespace, but not quite. It=
 cannot be copied out of a class because it can only exist as part of its c=
ontaining object.<br>
<br>
Whether calling it &quot;class&quot; or something else, is really just bike=
shedding. One should first determine its conceptual and technical propertie=
s before starting the naming debate. I don&#39;t claim to have all the answ=
ers when it comes to applying this concept to C++ and I don&#39;t claim the=
re aren&#39;t C++ specificy problems that need solving. It just felt like t=
he concept wasn&#39;t explained very much and therfore caused ambiguity.<br=
>
<br>
Here some hypothetical example code:<br>
<br>
class A {<br>
=C2=A0 int x_data;<br>
public:<br>
=C2=A0 inline struct x {<br>
=C2=A0 =C2=A0 x&amp; operator=3D(int value) {<br>
=C2=A0 =C2=A0 =C2=A0 x_data =3D value; // Can access members of containing =
class<br>
=C2=A0 =C2=A0 =C2=A0 return *this; // &quot;this&quot; can be impl converte=
d A* &lt;-&gt; A::x*<br>
=C2=A0 =C2=A0 }<br>
=C2=A0 =C2=A0 int operator int() const { return x_data; }<br>
=C2=A0 };<br>
};<br>
A a;<br>
a.x =3D 5; // Converted to a.x_operator=3D(5)<br>
cout &lt;&lt; a.x; // Converted to a.x_operator_int()<br>
<br>
Even though the setter returns A::x&amp;, the inline class A::x can only ev=
er exist as reference/pointer outside of A and is only copyable as part of =
its containing object, therefore it is not a proxy. To the compiler A* and =
A::x* are the same value, they only change what operations are allowed on t=
he target. In this example A::x has no data members therefore it conceptual=
ly doesn&#39;t require storage and &amp;a.x =3D=3D &amp;b.x is only ever tr=
ue if &amp;a =3D=3D &amp;b.<br>
<br>
A different example where the inline class does have members:<br>
<br>
class B {<br>
public:<br>
=C2=A0 inline struct x {<br>
=C2=A0 =C2=A0 x&amp; operator=3D(int value) { x_data =3D value; return *thi=
s; }<br>
=C2=A0 =C2=A0 int operator int() const { return x_data; }<br>
=C2=A0 private:<br>
=C2=A0 =C2=A0 int data;<br>
=C2=A0 };<br>
=C2=A0 int foo() {<br>
=C2=A0 =C2=A0 return x.data * 2;<br>
=C2=A0 }<br>
};<br>
B b;<br>
b.x =3D 5;<br>
cout &lt;&lt; b.foo();<br>
<br>
Besides a way to implement properties inline classes can serve to group mem=
bes/methods the same way a non-inline nested class currently does except it=
 drops the requirement for a this member pointing to the parent. Even if th=
ere was a dedicated property keyword/whatever the implementation technique =
could be inline classes and thefore kept open for advanced users that want =
more than just the default getter/setter implementation.<br>
<br>
I hope this adequately explains what is meant by inline classes. It just se=
emed like it wasn&#39;t described very well and people were talking past ea=
ch other.<div class=3D"HOEnZb"><div class=3D"h5"><br>
<br>
-- <br>
<br>
--- You received this message because you are subscribed to the Google Grou=
ps &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%2Bunsubscribe@isocpp.org" target=3D=
"_blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--089e0158bb203fe147051e87d051--

.

------=_Part_2190_1460756402.1440953022631
Content-Type: multipart/alternative;
 boundary="----=_Part_2191_540207534.1440953022631"

------=_Part_2191_540207534.1440953022631
Content-Type: text/plain; charset=UTF-8

On Sunday, August 30, 2015 at 7:50:24 AM UTC-4, Miro Knejp wrote:
>
> Nicol, I think you misunderstand the concept of inline classes as
> discussed here, thought wasn't very well explained to be honest.
>
> Inline classes (like nested classes in Java) can only exist as part of
> their parent class and can access all their members and methods.


That's not how Java's inner classes work. Inner classes require a pointer
to the owning class to be created, but they are still independent classes.
You can create objects of their type and use them however you want. They
are associated with an object, but they are not necessarily an indivisible
*part* of their owning objects. That's certainly one way to use them (if
they are private and the class has a public member of their type
available), but that is not the *only* way they can be used.

These "inline classes", as originally proposed, are very much a part of
their owning object. You can't allocate them on the heap (since that would
require that they be named). You can't do a whole lot of things with them
that you can with Java inner classes.

I hope this adequately explains what is meant by inline classes. It just
> seemed like it wasn't described very well and people were talking past
> each other.
>

I understand the concept of "inline classes" quite well. That doesn't
change anything I said about them. Though you got the syntax wrong: inline
classes don't have typenames, and the name of the variables of that type go
at the end, before the semicolon.

However, you did add this:


> Besides a way to implement properties inline classes can serve to group
> membes/methods the same way a non-inline nested class currently does
> except it drops the requirement for a this member pointing to the
> parent.


Is that a feature anyone is actually looking for? Is it solving a problem
that needs to be solved?


> Even if there was a dedicated property keyword/whatever the
> implementation technique could be inline classes and thefore kept open
> for advanced users that want more than just the default getter/setter
> implementation.
>

What advanced usage would come of this? The closest thing to a use other
than properties that people have come up with is what you said before about
logical grouping of members.

And I don't think that's solving a significant enough problem to be worth
adding inline classes.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Sunday, August 30, 2015 at 7:50:24 AM UTC-4, Miro Knejp=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Nicol, I think you misu=
nderstand the concept of inline classes as=20
<br>discussed here, thought wasn&#39;t very well explained to be honest.
<br>
<br>Inline classes (like nested classes in Java) can only exist as part of=
=20
<br>their parent class and can access all their members and methods.</block=
quote><div><br>That&#39;s not how Java&#39;s inner classes work. Inner clas=
ses require a pointer to the owning class to be created, but they are still=
 independent classes. You can create objects of their type and use them how=
ever you want. They are associated with an object, but they are not necessa=
rily an indivisible <i>part</i> of their owning objects. That&#39;s certain=
ly one way to use them (if they are private and the class has a public memb=
er of their type available), but that is not the <i>only</i> way they can b=
e used.<br><br>These &quot;inline classes&quot;, as originally proposed, ar=
e very much a part of their owning object. You can&#39;t allocate them on t=
he heap (since that would require that they be named). You can&#39;t do a w=
hole lot of things with them that you can with Java inner classes.<br><br><=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;">I hope this adequately explains=
 what is meant by inline classes. It just=20
<br>seemed like it wasn&#39;t described very well and people were talking p=
ast=20
<br>each other.<br></blockquote><br>I understand the concept of &quot;inlin=
e classes&quot; quite well. That doesn&#39;t change anything I said about t=
hem. Though you got the syntax wrong: inline classes don&#39;t have typenam=
es, and the name of the variables of that type go at the end, before the se=
micolon.<br><br>However, you did add this:<br>=C2=A0<br></div><blockquote c=
lass=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px=
 #ccc solid;padding-left: 1ex;">Besides a way to implement properties inlin=
e classes can serve to group=20
<br>membes/methods the same way a non-inline nested class currently does=20
<br>except it drops the requirement for a this member pointing to the=20
<br>parent.</blockquote><div><br>Is that a feature anyone is actually looki=
ng for? Is it solving a problem that needs to be solved?<br>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">Even if there was a dedicated pro=
perty keyword/whatever the=20
<br>implementation technique could be inline classes and thefore kept open=
=20
<br>for advanced users that want more than just the default getter/setter=
=20
<br>implementation.<br></blockquote><div><br>What advanced usage would come=
 of this? The closest thing to a use other than properties that people have=
 come up with is what you said before about logical grouping of members.<br=
><br>And I don&#39;t think that&#39;s solving a significant enough problem =
to be worth adding inline classes.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2191_540207534.1440953022631--
------=_Part_2190_1460756402.1440953022631--

.

------=_Part_2379_2001585569.1440953370259
Content-Type: multipart/alternative;
 boundary="----=_Part_2380_220650083.1440953370259"

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

On Sunday, August 30, 2015 at 10:05:49 AM UTC-4, Klaim - Jo=C3=ABl Lamotte =
wrote:
>
> I think your inline class idea better have it's own discussion thread so=
=20
> that exploring the concept can be focused on it.
>

The thing it most needs is justification is why we need such a feature. Can=
=20
it do something more than give us property hack fixes?

A more useful thing to explore is the concept of empty member optimizations=
=20
(which would be necessary to make properties worthwhile with these). It=20
wouldn't be acceptable to have the standard suddenly break lots of code by=
=20
declaring that all empty classes that are members of other classes no=20
longer take up space.

But would it be possible to decorate a class (using contextual keywords ala=
=20
`final`) such that the class would be considered to be truly empty. And=20
that such truly empty classes would not take up space in structs. If that=
=20
is possible, it could have a multitude of uses.
=20

> Another point: it seems to me that the definition of such construct could=
=20
> be reused inside the same class or inside several classes.
> So finding a way to avoid having to redefine it all the time would be mor=
e=20
> interesting, I think.
>

That doesn't make sense, at least not for building properties out of them.=
=20
With properties, you need to access *variables* from the owning class. And=
=20
there's no way to do that with template metaprogramming. So each=20
property-via-inline-class would have to be unique, coded for a specific=20
variable or variables.

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

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

<div dir=3D"ltr">On Sunday, August 30, 2015 at 10:05:49 AM UTC-4, Klaim - J=
o=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0=
;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div di=
r=3D"ltr">I think your inline class idea better have it&#39;s own discussio=
n thread so that exploring the concept can be focused on it.</div></blockqu=
ote><div><br>The thing it most needs is justification is why we need such a=
 feature. Can it do something more than give us property hack fixes?<br><br=
>A more useful thing to explore is the concept of empty member optimization=
s (which would be necessary to make properties worthwhile with these). It w=
ouldn&#39;t be acceptable to have the standard suddenly break lots of code =
by declaring that all empty classes that are members of other classes no lo=
nger take up space.<br><br>But would it be possible to decorate a class (us=
ing contextual keywords ala `final`) such that the class would be considere=
d to be truly empty. And that such truly empty classes would not take up sp=
ace in structs. If that is possible, it could have a multitude of uses.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div>Another point: it seems to me that the definition of such construct cou=
ld be reused inside the same class or inside several classes.</div><div>So =
finding a way to avoid having to redefine it all the time would be more int=
eresting, I think.</div></div></blockquote><div><br>That doesn&#39;t make s=
ense, at least not for building properties out of them. With properties, yo=
u need to access <i>variables</i> from the owning class. And there&#39;s no=
 way to do that with template metaprogramming. So each property-via-inline-=
class would have to be unique, coded for a specific variable or variables.<=
/div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2380_220650083.1440953370259--
------=_Part_2379_2001585569.1440953370259--

.

--001a113ed558798d1d051e8eecff
Content-Type: text/plain; charset=UTF-8

On 30 Aug 2015 5:37 am, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> My entire point was to talk about the difference between "what you want"
and "how you go about getting it". The fact that Python has a particular
way of "how you go about getting it" that is conceptually complicated yet
wrapped up in a nice library function is essentially irrelevant to this
part of the discussion.

It's relevant because it demonstrates that the language support for
properties as a feature doesn't need to be solely aimed at that feature but
can have its own logic.

> Yes, the implementation has consequences, but this is usually in the
scope of a larger construct. Languages that use duck typing tend to get
properties as a natural outgrowth of a flexible type system. That changes
nothing about the concept of properties.

How does duck typing imply properties? Javascript is duck typed, but it
doesn't have properties. Generic C++ is duck typed, but it doesn't have
properties. Python needed the descriptor protocol to make properties work,
but that's a feature of its object system, not its type system.

> Also, you have yet to show me one useful thing that inline classes can do
that don't involve properties. Whereas duck typing is absurdly useful and
frequently self-justifying. The same feature that makes properties work in
Python makes about 10,000 other things work in Python.

Which feature? Decorators or the descriptor protocol? Assuming you mean the
descriptor protocol, all I'm aware of that being key to is partially bound
methods.

> What else can inline classes do besides properties?
>
>> > For example, while thinking about what has to happen to make your
inline classes work, I realized something. Any class that contains an
inline class cannot be trivially copyable. Why? Because inline classes must
have an internal `this` pointer, which refers to the containing object. So
you cannot simply do a memcpy on them; the pointer has to be updated to
refer to the new object. And that requires the generation of a special copy
constructor that uses the new `this` object.
>>
>> Not true; an inline class has no storage or identity of its own, so a
pointer to an inline class can have the same value as a pointer to the
parent object. Note that within an inline class method "this" refers to the
parent object.
>
>
> OK, now you're just Calvinballing: inventing arbitrary features every
time someone comes along and explains why what you want doesn't work.

I'm fairly sure that was in the original proposal.

> And like with most Calvinballs, I don't think you thought that idea
through. Ignoring any potential strict aliasing minefields with this,
you're basically saying that you can't pass a property by reference to any
function if the type of that argument is deduced.

Why does that follow? And why would that be a bad thing? If you want to
pass by value, call the getter and pass the result; if you want to pass by
need, pass a lambda.

> With concepts and terse template syntax coming along... that's going to
be an increasingly large number of functions. That's a substantial weakness
of this property implementation.
>
>>
>> > And you can't do something like pass the correct `this` pointer from
the source of the call. The reason being that you can get references to
inline classes, and those still need to be connected to the originating
object (your `auto& prop` code below captures the issue quite well). So the
`this` pointer must be a member of the inline class type. So there's no
getting around it; holders of inline classes cannot be trivially copied.
>>
>> Similarly, a reference to an inline class can have the same value as a
reference to the parent object. (It doesn't have to have that value, but
that's the simplest implementation.)
>>
>> Also, there's no need to allow forming a reference or pointer to an
inline class at all; just as a member function access expression is
required to be subject to a function call operation, an inline class access
expression could be required to be subject to a conversion or operation.
>
>
> OK, so I can't get a pointer to it. I can't get a reference to it. It
doesn't have a typename. It doesn't have a size.
>
> How is an inline class an object at all? Because C++ is quite clear about
this: "An object is a region of storage". You can't have a region of 0. So
these inline classes are not a region of storage, and therefore they are
not objects.
>
> Or are you going to Calvinball a new definition for the C++ term "object"
so that it applies to inline classes? Because types only apply to objects,
references, or functions. And inline classes, as you have defined them, are
none of those. Therefore, they cannot have types. And they cannot
participate in things like operator overloading and so forth.

Also subobjects, prvalues, non-type template parameters, void -expressions
and probably some other entities. Of these, inline classes are most similar
to subobjects; perhaps they are subobjects.

> When you're putting this many hacks into something just to make it do
what you want it to, you should stop and reconsider if this is the right
way to achieve the desired goal.
>
>> >>
>> >> >>> It should not have storage.
>> >> >>
>> >> >> There has to be storage *somewhere*. Both properties and inline
classes
>> >> >> use the parent for that storage.
>> >> >
>> >> > No, there doesn't.
>> >>
>> >> Um... okay, maybe if you're reading from an external input device,
I'll
>> >> buy that. However, I'm talking about the typical case of e.g. the
length
>> >> of a string. Either that length is stored somewhere (normally on the
>> >> string instance), or it is computed from other data stored on the
string
>> >> instance. Especially in the former case, there *is* storage, it's
just
>> >> that the storage is in the parent class, not the property itself.
>> >
>> >
>> > There's a difference between the storage for the implementation of the
property, and the storage for the data itself. In your inline class case,
your property implementation takes up at least one byte, because properties
are objects (separate from any data storage). And in C++, object members of
a class must take up at least one byte.
>> >
>> > A pure property implementation means that there is only the data
storage (if any). The property itself has no storage, because the property
is not an object.
>>
>> If I understand the proposal correctly, inline classes are either not
objects, or have an exemption from the storage requirement analogous to the
empty base class optimization.
>
>
> If "inline classes" are not objects, then they should not use the word
"class" to declare/define them.

Maybe. But in other respects they behave like class types, and not every
instance of a class type is an object.

> EBO gymnastics might work (the type has the minimum storage requirements,
but in its current use, it doesn't take up any), but remember that EBO is
not required from compilers (except for standard layout types). Also, it is
not clear what the strict aliasing issues with this would be.

I don't think there would be any; all of the objects or subobjects with the
same address as the full object have distinct types.

Also, it might be possible to relax the no-storage requirement; the only
totally necessary requirement is that all direct inline class members
should have distinct types. This requirement seems to work OK for direct
base classes.

>> > Let's see. Here's what pure property syntax might look like:
>> >
>> > struct T
>> > {
>> >   int getHealth() property(health) {return _health;}
>> >   void setHealth(int h) property(health) {_health = h;}
>> >
>> > private:
>> >   int _health;
>> > };
>> >
>> > Here is what your inline class syntax would have to do to be
equivalent with that:
>> >
>> > struct T
>> > {
>> >   inline class
>> >   {
>> >     operator int() {return this->_health;}
>> >     int operator= (int h) {_health = h; return _health;}
>> >     int operator+= (int h) {_health += h; return _health;}
>> >     int operator-= (int h) {_health -= h; return _health;}
>> >     int operator*= (int h) {_health *= h; return _health;}
>> >     int operator/= (int h) {_health /= h; return _health;}
>> >   } health;
>> > };
>> >
>> > Even if we ignore the fact that you have to implement all those forms
of equality assignment if you want users to be able to use it, you've still
caused confusion. The "getter" method isn't called "get". Indeed, it
doesn't even have a name; it's `operator int`, for some reason. The
"setter" method also doesn't have a name; you instead overload operator=.
>> >
>> > That's not exactly something the neophyte C++ programmer will
understand. People coming from languages with pure property support will
expect something rather different in terms of syntax.
>>
>> Does that matter? As mentioned above beginner Python programmers aren't
expected to understand how properties work; they just use them.
>
>
> Um, Python property syntax looks like this:
>
> @property
> def x(self):
>   ...
>
> @x.setter
> def x(self, x):
>   ...
>
> See how it involves actual words like "property" and "set" and so forth?
The syntax you're suggesting for C++ involves words like "inline class" and
"operator Typename". None of which have anything to do with the concept of
properties, getters, setters, etc.
>
> Neophytes may not know what a "descriptor" is or what `@***` actually is
doing, but at least it's using words that they understand.

That's a fairly minor consideration. Look how C++ spells "lambda", or "pure
virtual".

>> Also, the operator overloads could be provided by a library facility to
forward to named getter and setter.
>
>
> Let me guess. You want to have inline classes able to derive from some
std::property library class. You want an anonymous class with no storage...
to have a base class.
>
> That opens up an entire avenue of problems. The defining feature of
inline classes is that their `this` pointer points to the owning object.
This effectively means that they can't even call other methods on
themselves. Well... how does that work with base classes? How can their
base class get a `this` pointer that points to its own type, but the
derived inline class cannot? How can the base class call a member of a
class that doesn't even have a `this` pointer?
>
> What will you want next? When you realize that you can't have this
hypothetical `std::property` object actually call members on its derived
type, will you decide you need virtual functions on these supposedly
stateless objects? Where does the hacking end?

Almost; it would have to use static polymorphism, not dynamic polymorphism.
That would require the inline class to be named, of course, but I don't see
that as an essential aspect of the proposal (apologies if it is).

> Can you not see how far you're reaching to force this implementation to
actually implement properties? It's an object, but you can't get a
pointer/reference to it. It's an object, but it doesn't take up actual
space. It's a class, but it doesn't have its own `this` pointer. And so
forth.
>
> You're giving inline classes about as many special-case rules as lambdas.
And those are far more generally useful than inline classes.
>
> What functionality does inline classes provide that justifies this level
of special-caseness? And if your only answer is "it lets us have
properties"... well, no, that's not good enough.

I don't see a collection of special cases; I see the logical corollaries of
having named subobjects with access to the parent class.

>>
>> >> And I fail to see how you would improve upon this.
>> >
>> >
>> > Because you only have to implement a single getter and a single
setter. Supporting += requires no effort; the compiler handles it for you,
so long as the type returned by the getter supports operator+.
>>
>> That's rarely what you actually want, though. Consider health: setting
health greater than the max value is an error,
>
>
> If I allow adding health to clamp, and I want to allow directly setting
health... why would I not want it to clamp too? It makes no sense to have
adding health to clamp, yet setting health error out.

Which way should it clamp? What if you performed arithmetic in an unsigned
type and it wrapped round? Erroring is the only safe option.

> Furthermore, I would say that it is extremely rude for x += y to have
different behavior from x = x + y. I think it's reasonable to forbid one or
the other. But if you allow both, then both should result in the exact same
thing. The former can be faster, but it should never be a different result.
>
> And I would point out that C# works this way too. So that would be
expected by those users.

That doesn't mean it's the right behavior. Python has different (and fairly
weird) behavior. C++ should be informed by existing languages but it
doesn't have to be the same.

>> > Also, there's explicit syntax for declaring a property, rather than
building a type and piggybacking some syntax off of implicit conversions or
operator= or whatever. It looks like a real language feature.
>>
>> It looks like shoehorning in a narrow solution to a very specific
problem, that doesn't even fully solve that problem. (The health += issue,
above.)
>>
>> By contrast, consider the general problem of properties: we want a class
member access to result in an entity
>
>
> No, we do not, and this is where you keep getting confused about the
difference between "implementation" and "concept".
>
> The core concept of properties is to turn accessing a non-function member
of a class into a function call. "result in an entity" is an implementation
detail, not a core part of the idea. And it's an unnecessary implementation
detail, since the compiler could have performed the transformation just
fine by itself.
>
> You're limiting yourself by thinking that the only way to make properties
work is by using existing C++ mechanics.

I'm starting to understand, I think. You want certain class member access
expressions to be replaced by (possibly multiple) method calls in... what,
an extra phase of translation? How on earth are you going to explain that
to current C++ programmers? Also, as just one objection of I'm sure many,
what happens to a class member access expression with object type a
template type parameter?

The mechanism for properties doesn't have to reuse existing mechanics, but
it should at least be friendly towards them. Your suggestion isn't even on
speaking terms with them.

>> >>
>> >> Please *show* how you would implement this with something other than
>> >> inline classes. (The color class may store RGB triples. The
properties
>> >> may not have their own storage, nor may you create temporary non-POD
>> >> objects.)
>> >
>> >
>> > Why are those solutions not allowed? Remember what properties are: a
shorthand syntax for calling getters/setters. So `c.hsl.hue = ...`
conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.
>> >
>> > That's what properties are for.
>> >
>> > In order to implement this using function call syntax, I would return
appropriate proxy objects, which are non-PODs that contain references to
data. The presence or absence of properties, of any form, does not how one
goes about solving the problem. Your solution uses proxy objects too; it
just so happens that your proxy objects are permanent fixtures of an
object, rather than temporaries created on the stack.
>>
>> Inline classes are not proxy objects. Possibly they are subobjects, but
there is no proxying involved.
>
>
> A proxy object is an object that stands in for another, which can be used
like the other while forward commands to it to the actual object.
>
> That is exactly what an inline class is doing. The "getter" works by
being implicitly converted to the expected type. Thus, it can stand for the
reference to the actual data. The "setter" works by operator overloading,
again based on the expected type. It again can act as though it were the
expected type.
>
> It fits every definition of a proxy object. It may be a reference to a
proxy object rather than one created on the stack. But it does everything a
proxy needs do.

If it's a proxy object, where is the object being proxied?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a113ed558798d1d051e8eecff
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 30 Aug 2015 5:37 am, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmcke=
sson@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; My entire point was to talk about the difference between &quot;what yo=
u want&quot; and &quot;how you go about getting it&quot;. The fact that Pyt=
hon has a particular way of &quot;how you go about getting it&quot; that is=
 conceptually complicated yet wrapped up in a nice library function is esse=
ntially irrelevant to this part of the discussion.</p>
<p dir=3D"ltr">It&#39;s relevant because it demonstrates that the language =
support for properties as a feature doesn&#39;t need to be solely aimed at =
that feature but can have its own logic. </p>
<p dir=3D"ltr">&gt; Yes, the implementation has consequences, but this is u=
sually in the scope of a larger construct. Languages that use duck typing t=
end to get properties as a natural outgrowth of a flexible type system. Tha=
t changes nothing about the concept of properties.</p>
<p dir=3D"ltr">How does duck typing imply properties? Javascript is duck ty=
ped, but it doesn&#39;t have properties. Generic C++ is duck typed, but it =
doesn&#39;t have properties. Python needed the descriptor protocol to make =
properties work, but that&#39;s a feature of its object system, not its typ=
e system. </p>
<p dir=3D"ltr">&gt; Also, you have yet to show me one useful thing that inl=
ine classes can do that don&#39;t involve properties. Whereas duck typing i=
s absurdly useful and frequently self-justifying. The same feature that mak=
es properties work in Python makes about 10,000 other things work in Python=
..</p>
<p dir=3D"ltr">Which feature? Decorators or the descriptor protocol? Assumi=
ng you mean the descriptor protocol, all I&#39;m aware of that being key to=
 is partially bound methods. </p>
<p dir=3D"ltr">&gt; What else can inline classes do besides properties?<br>
&gt; =C2=A0<br>
&gt;&gt; &gt; For example, while thinking about what has to happen to make =
your inline classes work, I realized something. Any class that contains an =
inline class cannot be trivially copyable. Why? Because inline classes must=
 have an internal `this` pointer, which refers to the containing object. So=
 you cannot simply do a memcpy on them; the pointer has to be updated to re=
fer to the new object. And that requires the generation of a special copy c=
onstructor that uses the new `this` object.<br>
&gt;&gt;<br>
&gt;&gt; Not true; an inline class has no storage or identity of its own, s=
o a pointer to an inline class can have the same value as a pointer to the =
parent object. Note that within an inline class method &quot;this&quot; ref=
ers to the parent object.<br>
&gt;<br>
&gt;<br>
&gt; OK, now you&#39;re just Calvinballing: inventing arbitrary features ev=
ery time someone comes along and explains why what you want doesn&#39;t wor=
k.</p>
<p dir=3D"ltr">I&#39;m fairly sure that was in the original proposal. </p>
<p dir=3D"ltr">&gt; And like with most Calvinballs, I don&#39;t think you t=
hought that idea through. Ignoring any potential strict aliasing minefields=
 with this, you&#39;re basically saying that you can&#39;t pass a property =
by reference to any function if the type of that argument is deduced.</p>
<p dir=3D"ltr">Why does that follow? And why would that be a bad thing? If =
you want to pass by value, call the getter and pass the result; if you want=
 to pass by need, pass a lambda. </p>
<p dir=3D"ltr">&gt; With concepts and terse template syntax coming along...=
 that&#39;s going to be an increasingly large number of functions. That&#39=
;s a substantial weakness of this property implementation.<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; &gt; And you can&#39;t do something like pass the correct `this` p=
ointer from the source of the call. The reason being that you can get refer=
ences to inline classes, and those still need to be connected to the origin=
ating object (your `auto&amp; prop` code below captures the issue quite wel=
l). So the `this` pointer must be a member of the inline class type. So the=
re&#39;s no getting around it; holders of inline classes cannot be triviall=
y copied.<br>
&gt;&gt;<br>
&gt;&gt; Similarly, a reference to an inline class can have the same value =
as a reference to the parent object. (It doesn&#39;t have to have that valu=
e, but that&#39;s the simplest implementation.)=C2=A0<br>
&gt;&gt;<br>
&gt;&gt; Also, there&#39;s no need to allow forming a reference or pointer =
to an inline class at all; just as a member function access expression is r=
equired to be subject to a function call operation, an inline class access =
expression could be required to be subject to a conversion or operation.<br=
>
&gt;<br>
&gt;<br>
&gt; OK, so I can&#39;t get a pointer to it. I can&#39;t get a reference to=
 it. It doesn&#39;t have a typename. It doesn&#39;t have a size.<br>
&gt;<br>
&gt; How is an inline class an object at all? Because C++ is quite clear ab=
out this: &quot;An object is a region of storage&quot;. You can&#39;t have =
a region of 0. So these inline classes are not a region of storage, and the=
refore they are not objects.<br>
&gt;<br>
&gt; Or are you going to Calvinball a new definition for the C++ term &quot=
;object&quot; so that it applies to inline classes? Because types only appl=
y to objects, references, or functions. And inline classes, as you have def=
ined them, are none of those. Therefore, they cannot have types. And they c=
annot participate in things like operator overloading and so forth.</p>
<p dir=3D"ltr">Also subobjects, prvalues, non-type template parameters, voi=
d -expressions and probably some other entities. Of these, inline classes a=
re most similar to subobjects; perhaps they are subobjects.</p>
<p dir=3D"ltr">&gt; When you&#39;re putting this many hacks into something =
just to make it do what you want it to, you should stop and reconsider if t=
his is the right way to achieve the desired goal.<br>
&gt;<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; It should not have storage. <br>
&gt;&gt; &gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; &gt;&gt; There has to be storage *somewhere*. Both proper=
ties and inline classes <br>
&gt;&gt; &gt;&gt; &gt;&gt; use the parent for that storage. <br>
&gt;&gt; &gt;&gt; &gt; <br>
&gt;&gt; &gt;&gt; &gt; No, there doesn&#39;t. <br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Um... okay, maybe if you&#39;re reading from an external =
input device, I&#39;ll <br>
&gt;&gt; &gt;&gt; buy that. However, I&#39;m talking about the typical case=
 of e.g. the length <br>
&gt;&gt; &gt;&gt; of a string. Either that length is stored somewhere (norm=
ally on the <br>
&gt;&gt; &gt;&gt; string instance), or it is computed from other data store=
d on the string <br>
&gt;&gt; &gt;&gt; instance. Especially in the former case, there *is* stora=
ge, it&#39;s just <br>
&gt;&gt; &gt;&gt; that the storage is in the parent class, not the property=
 itself.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There&#39;s a difference between the storage for the implemen=
tation of the property, and the storage for the data itself. In your inline=
 class case, your property implementation takes up at least one byte, becau=
se properties are objects (separate from any data storage). And in C++, obj=
ect members of a class must take up at least one byte.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A pure property implementation means that there is only the d=
ata storage (if any). The property itself has no storage, because the prope=
rty is not an object.<br>
&gt;&gt;<br>
&gt;&gt; If I understand the proposal correctly, inline classes are either =
not objects, or have an exemption from the storage requirement analogous to=
 the empty base class optimization.<br>
&gt;<br>
&gt;<br>
&gt; If &quot;inline classes&quot; are not objects, then they should not us=
e the word &quot;class&quot; to declare/define them.</p>
<p dir=3D"ltr">Maybe. But in other respects they behave like class types, a=
nd not every instance of a class type is an object. </p>
<p dir=3D"ltr">&gt; EBO gymnastics might work (the type has the minimum sto=
rage requirements, but in its current use, it doesn&#39;t take up any), but=
 remember that EBO is not required from compilers (except for standard layo=
ut types). Also, it is not clear what the strict aliasing issues with this =
would be.</p>
<p dir=3D"ltr">I don&#39;t think there would be any; all of the objects or =
subobjects with the same address as the full object have distinct types. </=
p>
<p dir=3D"ltr">Also, it might be possible to relax the no-storage requireme=
nt; the only totally necessary requirement is that all direct inline class =
members should have distinct types. This requirement seems to work OK for d=
irect base classes. </p>
<p dir=3D"ltr">&gt;&gt; &gt; Let&#39;s see. Here&#39;s what pure property s=
yntax might look like:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; struct T<br>
&gt;&gt; &gt; {<br>
&gt;&gt; &gt; =C2=A0 int getHealth() property(health) {return _health;}<br>
&gt;&gt; &gt; =C2=A0 void setHealth(int h) property(health) {_health =3D h;=
}<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; private:<br>
&gt;&gt; &gt; =C2=A0 int _health;<br>
&gt;&gt; &gt; };<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Here is what your inline class syntax would have to do to be =
equivalent with that:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; struct T<br>
&gt;&gt; &gt; {<br>
&gt;&gt; &gt; =C2=A0 inline class<br>
&gt;&gt; &gt; =C2=A0 {<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 operator int() {return this-&gt;_health;}<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 int operator=3D (int h) {_health =3D h; return =
_health;}<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 int operator+=3D (int h) {_health +=3D h; retur=
n _health;}<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 int operator-=3D (int h) {_health -=3D h; retur=
n _health;}<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 int operator*=3D (int h) {_health *=3D h; retur=
n _health;}<br>
&gt;&gt; &gt; =C2=A0 =C2=A0 int operator/=3D (int h) {_health /=3D h; retur=
n _health;}<br>
&gt;&gt; &gt; =C2=A0 } health;<br>
&gt;&gt; &gt; };<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Even if we ignore the fact that you have to implement all tho=
se forms of equality assignment if you want users to be able to use it, you=
&#39;ve still caused confusion. The &quot;getter&quot; method isn&#39;t cal=
led &quot;get&quot;. Indeed, it doesn&#39;t even have a name; it&#39;s `ope=
rator int`, for some reason. The &quot;setter&quot; method also doesn&#39;t=
 have a name; you instead overload operator=3D.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That&#39;s not exactly something the neophyte C++ programmer =
will understand. People coming from languages with pure property support wi=
ll expect something rather different in terms of syntax.<br>
&gt;&gt;<br>
&gt;&gt; Does that matter? As mentioned above beginner Python programmers a=
ren&#39;t expected to understand how properties work; they just use them.<b=
r>
&gt;<br>
&gt;<br>
&gt; Um, Python property syntax looks like this:<br>
&gt;<br>
&gt; @property<br>
&gt; def x(self):<br>
&gt; =C2=A0 ...<br>
&gt;<br>
&gt; @x.setter<br>
&gt; def x(self, x):<br>
&gt; =C2=A0 ...<br>
&gt;<br>
&gt; See how it involves actual words like &quot;property&quot; and &quot;s=
et&quot; and so forth? The syntax you&#39;re suggesting for C++ involves wo=
rds like &quot;inline class&quot; and &quot;operator Typename&quot;. None o=
f which have anything to do with the concept of properties, getters, setter=
s, etc.<br>
&gt;<br>
&gt; Neophytes may not know what a &quot;descriptor&quot; is or what `@***`=
 actually is doing, but at least it&#39;s using words that they understand.=
</p>
<p dir=3D"ltr">That&#39;s a fairly minor consideration. Look how C++ spells=
 &quot;lambda&quot;, or &quot;pure virtual&quot;.</p>
<p dir=3D"ltr">&gt;&gt; Also, the operator overloads could be provided by a=
 library facility to forward to named getter and setter.<br>
&gt;<br>
&gt;<br>
&gt; Let me guess. You want to have inline classes able to derive from some=
 std::property library class. You want an anonymous class with no storage..=
.. to have a base class.<br>
&gt;<br>
&gt; That opens up an entire avenue of problems. The defining feature of in=
line classes is that their `this` pointer points to the owning object. This=
 effectively means that they can&#39;t even call other methods on themselve=
s. Well... how does that work with base classes? How can their base class g=
et a `this` pointer that points to its own type, but the derived inline cla=
ss cannot? How can the base class call a member of a class that doesn&#39;t=
 even have a `this` pointer?<br>
&gt;<br>
&gt; What will you want next? When you realize that you can&#39;t have this=
 hypothetical `std::property` object actually call members on its derived t=
ype, will you decide you need virtual functions on these supposedly statele=
ss objects? Where does the hacking end?</p>
<p dir=3D"ltr">Almost; it would have to use static polymorphism, not dynami=
c polymorphism. That would require the inline class to be named, of course,=
 but I don&#39;t see that as an essential aspect of the proposal (apologies=
 if it is). </p>
<p dir=3D"ltr">&gt; Can you not see how far you&#39;re reaching to force th=
is implementation to actually implement properties? It&#39;s an object, but=
 you can&#39;t get a pointer/reference to it. It&#39;s an object, but it do=
esn&#39;t take up actual space. It&#39;s a class, but it doesn&#39;t have i=
ts own `this` pointer. And so forth.<br>
&gt;<br>
&gt; You&#39;re giving inline classes about as many special-case rules as l=
ambdas. And those are far more generally useful than inline classes.<br>
&gt;<br>
&gt; What functionality does inline classes provide that justifies this lev=
el of special-caseness? And if your only answer is &quot;it lets us have pr=
operties&quot;... well, no, that&#39;s not good enough.</p>
<p dir=3D"ltr">I don&#39;t see a collection of special cases; I see the log=
ical corollaries of having named subobjects with access to the parent class=
.. </p>
<p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; &gt;&gt; And I fail to see how you would improve upon this.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Because you only have to implement a single getter and a sing=
le setter. Supporting +=3D requires no effort; the compiler handles it for =
you, so long as the type returned by the getter supports operator+.<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s rarely what you actually want, though. Consider health:=
 setting health greater than the max value is an error,<br>
&gt;<br>
&gt;<br>
&gt; If I allow adding health to clamp, and I want to allow directly settin=
g health... why would I not want it to clamp too? It makes no sense to have=
 adding health to clamp, yet setting health error out.</p>
<p dir=3D"ltr">Which way should it clamp? What if you performed arithmetic =
in an unsigned type and it wrapped round? Erroring is the only safe option.=
 </p>
<p dir=3D"ltr">&gt; Furthermore, I would say that it is extremely rude for =
x +=3D y to have different behavior from x =3D x + y. I think it&#39;s reas=
onable to forbid one or the other. But if you allow both, then both should =
result in the exact same thing. The former can be faster, but it should nev=
er be a different result.<br>
&gt;<br>
&gt; And I would point out that C# works this way too. So that would be exp=
ected by those users.</p>
<p dir=3D"ltr">That doesn&#39;t mean it&#39;s the right behavior. Python ha=
s different (and fairly weird) behavior. C++ should be informed by existing=
 languages but it doesn&#39;t have to be the same. </p>
<p dir=3D"ltr">&gt;&gt; &gt; Also, there&#39;s explicit syntax for declarin=
g a property, rather than building a type and piggybacking some syntax off =
of implicit conversions or operator=3D or whatever. It looks like a real la=
nguage feature.<br>
&gt;&gt;<br>
&gt;&gt; It looks like shoehorning in a narrow solution to a very specific =
problem, that doesn&#39;t even fully solve that problem. (The health +=3D i=
ssue, above.)<br>
&gt;&gt;<br>
&gt;&gt; By contrast, consider the general problem of properties: we want a=
 class member access to result in an entity<br>
&gt;<br>
&gt;<br>
&gt; No, we do not, and this is where you keep getting confused about the d=
ifference between &quot;implementation&quot; and &quot;concept&quot;.<br>
&gt;<br>
&gt; The core concept of properties is to turn accessing a non-function mem=
ber of a class into a function call. &quot;result in an entity&quot; is an =
implementation detail, not a core part of the idea. And it&#39;s an unneces=
sary implementation detail, since the compiler could have performed the tra=
nsformation just fine by itself.<br>
&gt;<br>
&gt; You&#39;re limiting yourself by thinking that the only way to make pro=
perties work is by using existing C++ mechanics.</p>
<p dir=3D"ltr">I&#39;m starting to understand, I think. You want certain cl=
ass member access expressions to be replaced by (possibly multiple) method =
calls in... what, an extra phase of translation? How on earth are you going=
 to explain that to current C++ programmers? Also, as just one objection of=
 I&#39;m sure many, what happens to a class member access expression with o=
bject type a template type parameter? </p>
<p dir=3D"ltr">The mechanism for properties doesn&#39;t have to reuse exist=
ing mechanics, but it should at least be friendly towards them. Your sugges=
tion isn&#39;t even on speaking terms with them. </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Please *show* how you would implement this with something=
 other than <br>
&gt;&gt; &gt;&gt; inline classes. (The color class may store RGB triples. T=
he properties <br>
&gt;&gt; &gt;&gt; may not have their own storage, nor may you create tempor=
ary non-POD <br>
&gt;&gt; &gt;&gt; objects.) <br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Why are those solutions not allowed? Remember what properties=
 are: a shorthand syntax for calling getters/setters. So `c.hsl.hue =3D ...=
` conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That&#39;s what properties are for.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; In order to implement this using function call syntax, I woul=
d return appropriate proxy objects, which are non-PODs that contain referen=
ces to data. The presence or absence of properties, of any form, does not h=
ow one goes about solving the problem. Your solution uses proxy objects too=
; it just so happens that your proxy objects are permanent fixtures of an o=
bject, rather than temporaries created on the stack.<br>
&gt;&gt;<br>
&gt;&gt; Inline classes are not proxy objects. Possibly they are subobjects=
, but there is no proxying involved.<br>
&gt;<br>
&gt;<br>
&gt; A proxy object is an object that stands in for another, which can be u=
sed like the other while forward commands to it to the actual object.<br>
&gt;<br>
&gt; That is exactly what an inline class is doing. The &quot;getter&quot; =
works by being implicitly converted to the expected type. Thus, it can stan=
d for the reference to the actual data. The &quot;setter&quot; works by ope=
rator overloading, again based on the expected type. It again can act as th=
ough it were the expected type.<br>
&gt;<br>
&gt; It fits every definition of a proxy object. It may be a reference to a=
 proxy object rather than one created on the stack. But it does everything =
a proxy needs do. </p>
<p dir=3D"ltr">If it&#39;s a proxy object, where is the object being proxie=
d?</p>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a113ed558798d1d051e8eecff--

.

------=_Part_2824_849938226.1440996388950
Content-Type: multipart/alternative;
 boundary="----=_Part_2825_84485967.1440996388951"

------=_Part_2825_84485967.1440996388951
Content-Type: text/plain; charset=UTF-8

On Sunday, August 30, 2015 at 6:34:46 PM UTC-4, Edward Catmur wrote:
>
> On 30 Aug 2015 5:37 am, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> > My entire point was to talk about the difference between "what you want"
> and "how you go about getting it". The fact that Python has a particular
> way of "how you go about getting it" that is conceptually complicated yet
> wrapped up in a nice library function is essentially irrelevant to this
> part of the discussion.
>
> It's relevant because it demonstrates that the language support for
> properties as a feature doesn't need to be solely aimed at that feature but
> can have its own logic.
>

I didn't say that solutions for properties needed to be aimed solely at
that feature. But if you're going to add a feature and try to justify it by
saying that it solves properties *and* other stuff too, you need to prove
two things:

1) That it solves the property problem well.

2) That it solves other genuinely useful problems well.

Thus far, #2 is not in evidence, and #1 is in dispute (since it's a leaky
abstraction).

> Yes, the implementation has consequences, but this is usually in the
> scope of a larger construct. Languages that use duck typing tend to get
> properties as a natural outgrowth of a flexible type system. That changes
> nothing about the concept of properties.
>
> How does duck typing imply properties? Javascript is duck typed, but it
> doesn't have properties. Generic C++ is duck typed, but it doesn't have
> properties. Python needed the descriptor protocol to make properties work,
> but that's a feature of its object system, not its type system.
>

I never said that duck typing implies properties. I said "Languages that
use duck typing *tend to get* properties as a natural outgrowth of a
flexible type system." You don't need one to get the other, but duck typing
frequently makes properties easy to implement.


> > Also, you have yet to show me one useful thing that inline classes can
> do that don't involve properties. Whereas duck typing is absurdly useful
> and frequently self-justifying. The same feature that makes properties work
> in Python makes about 10,000 other things work in Python.
>
> Which feature? Decorators or the descriptor protocol?
>

Both. Admittedly, I know next to nothing about Python; I copied that
example from some site I found via Google. But if it works even remotely
like Lua (and the way "properties" work in that language), then those
mechanisms are general-purpose tools.

Unlike inline classes.

> What else can inline classes do besides properties?
> >
> >> > For example, while thinking about what has to happen to make your
> inline classes work, I realized something. Any class that contains an
> inline class cannot be trivially copyable. Why? Because inline classes must
> have an internal `this` pointer, which refers to the containing object. So
> you cannot simply do a memcpy on them; the pointer has to be updated to
> refer to the new object. And that requires the generation of a special copy
> constructor that uses the new `this` object.
> >>
> >> Not true; an inline class has no storage or identity of its own, so a
> pointer to an inline class can have the same value as a pointer to the
> parent object. Note that within an inline class method "this" refers to the
> parent object.
> >
> >
> > OK, now you're just Calvinballing: inventing arbitrary features every
> time someone comes along and explains why what you want doesn't work.
>
> I'm fairly sure that was in the original proposal.
>
> > And like with most Calvinballs, I don't think you thought that idea
> through. Ignoring any potential strict aliasing minefields with this,
> you're basically saying that you can't pass a property by reference to any
> function if the type of that argument is deduced.
>
> Why does that follow?
>

Because that's how C++ works.

Presumably, an inline class member has a type. That type will be deduced by
the type deduction system, even if its an anonymous type. Therefore, if a
function takes a `const T&`, it will be deduced as a `const&` to the inline
class type.

If taking a reference to an inline class results instead in a reference to
the owning class... then you haven't actually passed the property to the
function. Somehow passing `a.prop` is equivalent to passing `a`.

If taking a reference to an inline class results in a compiler error, then
you can't pass it by reference to any template function. And since they're
probably non-copyable, you can't pass them by value either.


> And why would that be a bad thing?
>

Because that's what users would expect. Calling `template_func(foo.min)`
ought to work. And if it doesn't, that would be very surprising for users.

If you want to pass by value, call the getter and pass the result;
>

Think about what you said for a minute. Your property implementation can
run into a problem, and your solution for this problem... is to *not use
properties*.

Doesn't that tell you that your property implementation is broken? Isn't
that what it means when you have to backdoor your own feature to make code
work?

>> > And you can't do something like pass the correct `this` pointer from
> the source of the call. The reason being that you can get references to
> inline classes, and those still need to be connected to the originating
> object (your `auto& prop` code below captures the issue quite well). So the
> `this` pointer must be a member of the inline class type. So there's no
> getting around it; holders of inline classes cannot be trivially copied.
> >>
> >> Similarly, a reference to an inline class can have the same value as a
> reference to the parent object. (It doesn't have to have that value, but
> that's the simplest implementation.)
> >>
> >> Also, there's no need to allow forming a reference or pointer to an
> inline class at all; just as a member function access expression is
> required to be subject to a function call operation, an inline class access
> expression could be required to be subject to a conversion or operation.
> >
> >
> > OK, so I can't get a pointer to it. I can't get a reference to it. It
> doesn't have a typename. It doesn't have a size.
> >
> > How is an inline class an object at all? Because C++ is quite clear
> about this: "An object is a region of storage". You can't have a region of
> 0. So these inline classes are not a region of storage, and therefore they
> are not objects.
> >
> > Or are you going to Calvinball a new definition for the C++ term
> "object" so that it applies to inline classes? Because types only apply to
> objects, references, or functions. And inline classes, as you have defined
> them, are none of those. Therefore, they cannot have types. And they cannot
> participate in things like operator overloading and so forth.
>
> Also subobjects, prvalues, non-type template parameters, void -expressions
> and probably some other entities. Of these, inline classes are most similar
> to subobjects; perhaps they are subobjects.
>

From the spec:

"Objects can contain other objects, called subobjects."

Subobjects, by definition, are *objects*.

But you are right that objects aren't the only things that have types.


> >> >>
> >> >> >>> It should not have storage.
> >> >> >>
> >> >> >> There has to be storage *somewhere*. Both properties and inline
> classes
> >> >> >> use the parent for that storage.
> >> >> >
> >> >> > No, there doesn't.
> >> >>
> >> >> Um... okay, maybe if you're reading from an external input device,
> I'll
> >> >> buy that. However, I'm talking about the typical case of e.g. the
> length
> >> >> of a string. Either that length is stored somewhere (normally on the
> >> >> string instance), or it is computed from other data stored on the
> string
> >> >> instance. Especially in the former case, there *is* storage, it's
> just
> >> >> that the storage is in the parent class, not the property itself.
> >> >
> >> >
> >> > There's a difference between the storage for the implementation of
> the property, and the storage for the data itself. In your inline class
> case, your property implementation takes up at least one byte, because
> properties are objects (separate from any data storage). And in C++, object
> members of a class must take up at least one byte.
> >> >
> >> > A pure property implementation means that there is only the data
> storage (if any). The property itself has no storage, because the property
> is not an object.
> >>
> >> If I understand the proposal correctly, inline classes are either not
> objects, or have an exemption from the storage requirement analogous to the
> empty base class optimization.
> >
> >
> > If "inline classes" are not objects, then they should not use the word
> "class" to declare/define them.
>
> Maybe. But in other respects they behave like class types, and not every
> instance of a class type is an object
>

I'm very curious to see a circumstance where you have an instance of a
class type that is not an object.


> >>
> >> Does that matter? As mentioned above beginner Python programmers aren't
> expected to understand how properties work; they just use them.
> >
> >
> > Um, Python property syntax looks like this:
> >
> > @property
> > def x(self):
> >   ...
> >
> > @x.setter
> > def x(self, x):
> >   ...
> >
> > See how it involves actual words like "property" and "set" and so forth?
> The syntax you're suggesting for C++ involves words like "inline class" and
> "operator Typename". None of which have anything to do with the concept of
> properties, getters, setters, etc.
> >
> > Neophytes may not know what a "descriptor" is or what `@***` actually is
> doing, but at least it's using words that they understand.
>
> That's a fairly minor consideration. Look how C++ spells "lambda", or
> "pure virtual".
>

Lambdas are terse because that's the point of lambdas. More importantly,
nothing else looks quite like a lambda inducer. Whereas a "property" looks
an awful lot like a struct definition. Because, you know, it *is* one.

And nobody has ever defended C++'s pure virtual syntax as being a positive
design feature of the language. Just because C++ has unpleasantness in it
does not justify deliberately adding more. Especially when there are
alternatives.


> >> Also, the operator overloads could be provided by a library facility to
> forward to named getter and setter.
> >
> >
> > Let me guess. You want to have inline classes able to derive from some
> std::property library class. You want an anonymous class with no storage...
> to have a base class.
> >
> > That opens up an entire avenue of problems. The defining feature of
> inline classes is that their `this` pointer points to the owning object.
> This effectively means that they can't even call other methods on
> themselves. Well... how does that work with base classes? How can their
> base class get a `this` pointer that points to its own type, but the
> derived inline class cannot? How can the base class call a member of a
> class that doesn't even have a `this` pointer?
> >
> > What will you want next? When you realize that you can't have this
> hypothetical `std::property` object actually call members on its derived
> type, will you decide you need virtual functions on these supposedly
> stateless objects? Where does the hacking end?
>
> Almost; it would have to use static polymorphism, not dynamic
> polymorphism. That would require the inline class to be named, of course,
> but I don't see that as an essential aspect of the proposal (apologies if
> it is).
>

So let's look at what you have to do to declare a property with this syntax:

inline struct Irrelevant : public std::property<Irrelevant>
{
  Type get() const {...}
  Type &set(const Type &t) {...}
} property_name;

There are 6 words in the first line; only one of them (property) actually
means something to the user. The rest are noise. "Irrelevant" is
particularly problematic, since you must provide a typename so that you can
pass it to the property template.

Admittedly, the rest looks at least sensible. But it still requires a lot
of noise.


> > Can you not see how far you're reaching to force this implementation to
> actually implement properties? It's an object, but you can't get a
> pointer/reference to it. It's an object, but it doesn't take up actual
> space. It's a class, but it doesn't have its own `this` pointer. And so
> forth.
> >
> > You're giving inline classes about as many special-case rules as
> lambdas. And those are far more generally useful than inline classes.
> >
> > What functionality does inline classes provide that justifies this level
> of special-caseness? And if your only answer is "it lets us have
> properties"... well, no, that's not good enough.
>
> I don't see a collection of special cases; I see the logical corollaries
> of having named subobjects with access to the parent class
>

My claim is essentially that inline classes are not a feature so much as
"whatever is needed to make library property implementations work." And
therefore they're a hodge-podge of functionality. You claim that inline
classes are their own feature, a whole and complete thought that is
designed for a purpose that is independent from properties. One that just
so happens to

So let's examine the proposal. Oh wait, there isn't one. There are multiple
people posting about it, each with their own idea of what it needs to have,
and some of those ideas are contradictory. So let's just examine some of
the things that have been said about it.

If all you really wanted was "named subobjects with access to the parent
class," why would it matter if inline classes are not trivially copyable?
The standard has plenty of non-trivially-copyable classes. There is no
fundamental problem with making inline classes non-trivially copyable.
Indeed, this would not be the first language feature that a priori makes a
class non-trivially copyable (virtual functions/bases, for example).

Oh sure, everyone likes for their classes to be trivially copyable. But
trivially copyable is a high bar to reach, and a whole lot of classes break
it. Indeed, most standard library classes are not trivially copyable. And
yet, you have people who want inline classes to be trivially copyable so
bad that they've suggested that it should be impossible to get
pointers/references to inline class members.

That's a blatant hack, one that is not strictly necessary.

Similarly, if all you really wanted was "named subobjects with access to
the parent class," why would people care if empty inline classes take up
storage in their owning classes? What does it matter? Especially if you've
already lost trivial copyability.

Such empty member optimization, limited only to inline classes, is yet
another blatant hack. And is no more necessary for the feature than the
latter.

If you just wanted "named subobjects with access to the parent class", you
wouldn't care about these hacks. But if you want a low-overhead
implementation of properties, then both of those hacks are *essential*.

So let us please dispense with the pretense that this idea is about
something other than building the specific features needed for implementing
properties through objects.

>>
> >> That's rarely what you actually want, though. Consider health: setting
> health greater than the max value is an error,
> >
> >
> > If I allow adding health to clamp, and I want to allow directly setting
> health... why would I not want it to clamp too? It makes no sense to have
> adding health to clamp, yet setting health error out.
>
> Which way should it clamp? What if you performed arithmetic in an unsigned
> type and it wrapped round? Erroring is the only safe option.
>

You could have done the exact same thing with += as well, only the wrap
around happened before += was evaluated (such as `health += a + b;`). Why
should `health = health + (a + b)` error, but not the former?

> Furthermore, I would say that it is extremely rude for x += y to have
> different behavior from x = x + y. I think it's reasonable to forbid one or
> the other. But if you allow both, then both should result in the exact same
> thing. The former can be faster, but it should never be a different result.
> >
> > And I would point out that C# works this way too. So that would be
> expected by those users.
>
> That doesn't mean it's the right behavior. Python has different (and
> fairly weird) behavior. C++ should be informed by existing languages but it
> doesn't have to be the same.
>

Maybe so, but you haven't come up with a good justification for why `x = x
+ y` should ever have different results from `x += y`.

>> > Also, there's explicit syntax for declaring a property, rather than
> building a type and piggybacking some syntax off of implicit conversions or
> operator= or whatever. It looks like a real language feature.
> >>
> >> It looks like shoehorning in a narrow solution to a very specific
> problem, that doesn't even fully solve that problem. (The health += issue,
> above.)
> >>
> >> By contrast, consider the general problem of properties: we want a
> class member access to result in an entity
> >
> >
> > No, we do not, and this is where you keep getting confused about the
> difference between "implementation" and "concept".
> >
> > The core concept of properties is to turn accessing a non-function
> member of a class into a function call. "result in an entity" is an
> implementation detail, not a core part of the idea. And it's an unnecessary
> implementation detail, since the compiler could have performed the
> transformation just fine by itself.
> >
> > You're limiting yourself by thinking that the only way to make
> properties work is by using existing C++ mechanics.
>
> I'm starting to understand, I think. You want certain class member access
> expressions to be replaced by (possibly multiple) method calls in... what,
> an extra phase of translation? How on earth are you going to explain that
> to current C++ programmers?
>

The exact same way you explain that this:

a += b

becomes this:

a.operator+=(b);

The concept is functionally no different: something becomes a function call
even though it doesn't look like one.


> Also, as just one objection of I'm sure many, what happens to a class
> member access expression with object type a template type parameter?
>

If you're asking the equivalent of what I asked about your system before
(passing a property proxy object to a template argument), the result is
quite simple. `template_func(a.prop)` does exactly what `a.prop` does when
it is not used in an assignment expression: it is converted into a function
call to the getter. So it becomes `template_func(a.getter())`.


> >> Inline classes are not proxy objects. Possibly they are subobjects, but
> there is no proxying involved.
> >
> >
> > A proxy object is an object that stands in for another, which can be
> used like the other while forward commands to it to the actual object.
> >
> > That is exactly what an inline class is doing. The "getter" works by
> being implicitly converted to the expected type. Thus, it can stand for the
> reference to the actual data. The "setter" works by operator overloading,
> again based on the expected type. It again can act as though it were the
> expected type.
> >
> > It fits every definition of a proxy object. It may be a reference to a
> proxy object rather than one created on the stack. But it does everything a
> proxy needs do.
>
> If it's a proxy object, where is the object being proxied?
>

It proxies an object of the type it converts/assigns to. This may be a real
object. It may be a constant value. It may be scattered throughout memory,
or a field in a database. But it is functionally no different from any
other proxy object: it is a stand-in for a real object.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Sunday, August 30, 2015 at 6:34:46 PM UTC-4, Edward Catmur wrote:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">
On 30 Aug 2015 5:37 am, &quot;Nicol Bolas&quot; &lt;<a href=3D"javascript:"=
 target=3D"_blank" gdf-obfuscated-mailto=3D"HZKCFMmtBwAJ" rel=3D"nofollow" =
onmousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"t=
his.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wr=
ote:<br>
&gt; My entire point was to talk about the difference between &quot;what yo=
u want&quot; and &quot;how you go about getting it&quot;. The fact that Pyt=
hon has a particular way of &quot;how you go about getting it&quot; that is=
 conceptually complicated yet wrapped up in a nice library function is esse=
ntially irrelevant to this part of the discussion.</p>
<p dir=3D"ltr">It&#39;s relevant because it demonstrates that the language =
support for properties as a feature doesn&#39;t need to be solely aimed at =
that feature but can have its own logic. </p></blockquote><div><br>I didn&#=
39;t say that solutions for properties needed to be aimed solely at that fe=
ature. But if you&#39;re going to add a feature and try to justify it by sa=
ying that it solves properties <i>and</i> other stuff too, you need to prov=
e two things:<br><br>1) That it solves the property problem well.<br><br>2)=
 That it solves other genuinely useful problems well.<br><br>Thus far, #2 i=
s not in evidence, and #1 is in dispute (since it&#39;s a leaky abstraction=
).<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt; Yes, the implementation has consequences, but this is u=
sually in the scope of a larger construct. Languages that use duck typing t=
end to get properties as a natural outgrowth of a flexible type system. Tha=
t changes nothing about the concept of properties.</p>
<p dir=3D"ltr">How does duck typing imply properties? Javascript is duck ty=
ped, but it doesn&#39;t have properties. Generic C++ is duck typed, but it =
doesn&#39;t have properties. Python needed the descriptor protocol to make =
properties work, but that&#39;s a feature of its object system, not its typ=
e system. </p></blockquote><div><br>I never said that duck typing implies p=
roperties. I said &quot;Languages that use duck typing <u>tend to get</u> p=
roperties as a natural outgrowth of a flexible type system.&quot; You don&#=
39;t need one to get the other, but duck typing frequently makes properties=
 easy to implement.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;">
<p dir=3D"ltr">&gt; Also, you have yet to show me one useful thing that inl=
ine classes can do that don&#39;t involve properties. Whereas duck typing i=
s absurdly useful and frequently self-justifying. The same feature that mak=
es properties work in Python makes about 10,000 other things work in Python=
..</p>
<p dir=3D"ltr">Which feature? Decorators or the descriptor protocol?</p></b=
lockquote><div><br>Both. Admittedly, I know next to nothing about Python; I=
 copied that example from some site I found via Google. But if it works eve=
n remotely like Lua (and the way &quot;properties&quot; work in that langua=
ge), then those mechanisms are general-purpose tools.<br><br>Unlike inline =
classes.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=
=3D"ltr"></p>
<p dir=3D"ltr">&gt; What else can inline classes do besides properties?<br>
&gt; =C2=A0<br>
&gt;&gt; &gt; For example, while thinking about what has to happen to make =
your inline classes work, I realized something. Any class that contains an =
inline class cannot be trivially copyable. Why? Because inline classes must=
 have an internal `this` pointer, which refers to the containing object. So=
 you cannot simply do a memcpy on them; the pointer has to be updated to re=
fer to the new object. And that requires the generation of a special copy c=
onstructor that uses the new `this` object.<br>
&gt;&gt;<br>
&gt;&gt; Not true; an inline class has no storage or identity of its own, s=
o a pointer to an inline class can have the same value as a pointer to the =
parent object. Note that within an inline class method &quot;this&quot; ref=
ers to the parent object.<br>
&gt;<br>
&gt;<br>
&gt; OK, now you&#39;re just Calvinballing: inventing arbitrary features ev=
ery time someone comes along and explains why what you want doesn&#39;t wor=
k.</p>
<p dir=3D"ltr">I&#39;m fairly sure that was in the original proposal. </p>
<p dir=3D"ltr">&gt; And like with most Calvinballs, I don&#39;t think you t=
hought that idea through. Ignoring any potential strict aliasing minefields=
 with this, you&#39;re basically saying that you can&#39;t pass a property =
by reference to any function if the type of that argument is deduced.</p>
<p dir=3D"ltr">Why does that follow?</p></blockquote><div><br>Because that&=
#39;s how C++ works.<br><br>Presumably, an inline class member has a type. =
That type will be deduced by the type deduction system, even if its an anon=
ymous type. Therefore, if a function takes a `const T&amp;`, it will be ded=
uced as a `const&amp;` to the inline class type.<br><br>If taking a referen=
ce to an inline class results instead in a reference to the owning class...=
 then you haven&#39;t actually passed the property to the function. Somehow=
 passing `a.prop` is equivalent to passing `a`.<br><br>If taking a referenc=
e to an inline class results in a compiler error, then you can&#39;t pass i=
t by reference to any template function. And since they&#39;re probably non=
-copyable, you can&#39;t pass them by value either.<br>=C2=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left=
: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">And why would that be a=
 bad thing?</p></blockquote><div><br>Because that&#39;s what users would ex=
pect. Calling `template_func(foo.min)` ought to work. And if it doesn&#39;t=
, that would be very surprising for users.<br><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #cc=
c solid;padding-left: 1ex;"><p dir=3D"ltr">If you want to pass by value, ca=
ll the getter and pass the result;</p></blockquote><div><br>Think about wha=
t you said for a minute. Your property implementation can run into a proble=
m, and your solution for this problem... is to <i>not use properties</i>.<b=
r><br>Doesn&#39;t that tell you that your property implementation is broken=
? Isn&#39;t that what it means when you have to backdoor your own feature t=
o make code work?<br><br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt;&gt; &gt; And you can&#39;t do something like pass the c=
orrect `this` pointer from the source of the call. The reason being that yo=
u can get references to inline classes, and those still need to be connecte=
d to the originating object (your `auto&amp; prop` code below captures the =
issue quite well). So the `this` pointer must be a member of the inline cla=
ss type. So there&#39;s no getting around it; holders of inline classes can=
not be trivially copied.<br>
&gt;&gt;<br>
&gt;&gt; Similarly, a reference to an inline class can have the same value =
as a reference to the parent object. (It doesn&#39;t have to have that valu=
e, but that&#39;s the simplest implementation.)=C2=A0<br>
&gt;&gt;<br>
&gt;&gt; Also, there&#39;s no need to allow forming a reference or pointer =
to an inline class at all; just as a member function access expression is r=
equired to be subject to a function call operation, an inline class access =
expression could be required to be subject to a conversion or operation.<br=
>
&gt;<br>
&gt;<br>
&gt; OK, so I can&#39;t get a pointer to it. I can&#39;t get a reference to=
 it. It doesn&#39;t have a typename. It doesn&#39;t have a size.<br>
&gt;<br>
&gt; How is an inline class an object at all? Because C++ is quite clear ab=
out this: &quot;An object is a region of storage&quot;. You can&#39;t have =
a region of 0. So these inline classes are not a region of storage, and the=
refore they are not objects.<br>
&gt;<br>
&gt; Or are you going to Calvinball a new definition for the C++ term &quot=
;object&quot; so that it applies to inline classes? Because types only appl=
y to objects, references, or functions. And inline classes, as you have def=
ined them, are none of those. Therefore, they cannot have types. And they c=
annot participate in things like operator overloading and so forth.</p>
<p dir=3D"ltr">Also subobjects, prvalues, non-type template parameters, voi=
d -expressions and probably some other entities. Of these, inline classes a=
re most similar to subobjects; perhaps they are subobjects.</p></blockquote=
><div><br>From the spec:<br><br>&quot;Objects can contain other objects, ca=
lled subobjects.&quot;<br><br>Subobjects, by definition, are <i>objects</i>=
..<br><br>But you are right that objects aren&#39;t the only things that hav=
e types.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt;&gt; It should not have storage. <br>
&gt;&gt; &gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; &gt;&gt; There has to be storage *somewhere*. Both proper=
ties and inline classes <br>
&gt;&gt; &gt;&gt; &gt;&gt; use the parent for that storage. <br>
&gt;&gt; &gt;&gt; &gt; <br>
&gt;&gt; &gt;&gt; &gt; No, there doesn&#39;t. <br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Um... okay, maybe if you&#39;re reading from an external =
input device, I&#39;ll <br>
&gt;&gt; &gt;&gt; buy that. However, I&#39;m talking about the typical case=
 of e.g. the length <br>
&gt;&gt; &gt;&gt; of a string. Either that length is stored somewhere (norm=
ally on the <br>
&gt;&gt; &gt;&gt; string instance), or it is computed from other data store=
d on the string <br>
&gt;&gt; &gt;&gt; instance. Especially in the former case, there *is* stora=
ge, it&#39;s just <br>
&gt;&gt; &gt;&gt; that the storage is in the parent class, not the property=
 itself.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; There&#39;s a difference between the storage for the implemen=
tation of the property, and the storage for the data itself. In your inline=
 class case, your property implementation takes up at least one byte, becau=
se properties are objects (separate from any data storage). And in C++, obj=
ect members of a class must take up at least one byte.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A pure property implementation means that there is only the d=
ata storage (if any). The property itself has no storage, because the prope=
rty is not an object.<br>
&gt;&gt;<br>
&gt;&gt; If I understand the proposal correctly, inline classes are either =
not objects, or have an exemption from the storage requirement analogous to=
 the empty base class optimization.<br>
&gt;<br>
&gt;<br>
&gt; If &quot;inline classes&quot; are not objects, then they should not us=
e the word &quot;class&quot; to declare/define them.</p>
<p dir=3D"ltr">Maybe. But in other respects they behave like class types, a=
nd not every instance of a class type is an object</p></blockquote><div><br=
>I&#39;m very curious to see a circumstance where you have an instance of a=
 class type that is not an object.<br>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><p dir=3D"ltr"> </p><p dir=3D"ltr">&gt;&gt;<br>
&gt;&gt; Does that matter? As mentioned above beginner Python programmers a=
ren&#39;t expected to understand how properties work; they just use them.<b=
r>
&gt;<br>
&gt;<br>
&gt; Um, Python property syntax looks like this:<br>
&gt;<br>
&gt; @property<br>
&gt; def x(self):<br>
&gt; =C2=A0 ...<br>
&gt;<br>
&gt; @x.setter<br>
&gt; def x(self, x):<br>
&gt; =C2=A0 ...<br>
&gt;<br>
&gt; See how it involves actual words like &quot;property&quot; and &quot;s=
et&quot; and so forth? The syntax you&#39;re suggesting for C++ involves wo=
rds like &quot;inline class&quot; and &quot;operator Typename&quot;. None o=
f which have anything to do with the concept of properties, getters, setter=
s, etc.<br>
&gt;<br>
&gt; Neophytes may not know what a &quot;descriptor&quot; is or what `@***`=
 actually is doing, but at least it&#39;s using words that they understand.=
</p>
<p dir=3D"ltr">That&#39;s a fairly minor consideration. Look how C++ spells=
 &quot;lambda&quot;, or &quot;pure virtual&quot;.</p></blockquote><div><br>=
Lambdas are terse because that&#39;s the point of lambdas. More importantly=
, nothing else looks quite like a lambda inducer. Whereas a &quot;property&=
quot; looks an awful lot like a struct definition. Because, you know, it <i=
>is</i> one.<br><br>And nobody has ever defended C++&#39;s pure virtual syn=
tax as being a positive design feature of the language. Just because C++ ha=
s unpleasantness in it does not justify deliberately adding more. Especiall=
y when there are alternatives.<br>=C2=A0</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;">
<p dir=3D"ltr">&gt;&gt; Also, the operator overloads could be provided by a=
 library facility to forward to named getter and setter.<br>
&gt;<br>
&gt;<br>
&gt; Let me guess. You want to have inline classes able to derive from some=
 std::property library class. You want an anonymous class with no storage..=
.. to have a base class.<br>
&gt;<br>
&gt; That opens up an entire avenue of problems. The defining feature of in=
line classes is that their `this` pointer points to the owning object. This=
 effectively means that they can&#39;t even call other methods on themselve=
s. Well... how does that work with base classes? How can their base class g=
et a `this` pointer that points to its own type, but the derived inline cla=
ss cannot? How can the base class call a member of a class that doesn&#39;t=
 even have a `this` pointer?<br>
&gt;<br>
&gt; What will you want next? When you realize that you can&#39;t have this=
 hypothetical `std::property` object actually call members on its derived t=
ype, will you decide you need virtual functions on these supposedly statele=
ss objects? Where does the hacking end?</p>
<p dir=3D"ltr">Almost; it would have to use static polymorphism, not dynami=
c polymorphism. That would require the inline class to be named, of course,=
 but I don&#39;t see that as an essential aspect of the proposal (apologies=
 if it is). </p></blockquote><div><br>So let&#39;s look at what you have to=
 do to declare a property with this syntax:<br><br><div class=3D"prettyprin=
t" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 18=
7, 187); border-style: solid; border-width: 1px; word-wrap: break-word;"><c=
ode class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Irrelevant</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">:</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">public</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">property</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Irrelevant</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #606;" class=3D=
"styled-by-prettify">Type</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(=
)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">const</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">{...}</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&amp;</span><span style=3D"color: #008;" class=3D"s=
tyled-by-prettify">set</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> <=
/span><span style=3D"color: #606;" class=3D"styled-by-prettify">Type</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">t</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{...}</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> pr=
operty_name</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>;</span></div></code></div><br>There are 6 words in the first line; only o=
ne of them (property) actually means something to the user. The rest are no=
ise. &quot;Irrelevant&quot; is particularly problematic, since you must pro=
vide a typename so that you can pass it to the property template.<br><br>Ad=
mittedly, the rest looks at least sensible. But it still requires a lot of =
noise.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt; Can you not see how far you&#39;re reaching to force th=
is implementation to actually implement properties? It&#39;s an object, but=
 you can&#39;t get a pointer/reference to it. It&#39;s an object, but it do=
esn&#39;t take up actual space. It&#39;s a class, but it doesn&#39;t have i=
ts own `this` pointer. And so forth.<br>
&gt;<br>
&gt; You&#39;re giving inline classes about as many special-case rules as l=
ambdas. And those are far more generally useful than inline classes.<br>
&gt;<br>
&gt; What functionality does inline classes provide that justifies this lev=
el of special-caseness? And if your only answer is &quot;it lets us have pr=
operties&quot;... well, no, that&#39;s not good enough.</p>
<p dir=3D"ltr">I don&#39;t see a collection of special cases; I see the log=
ical corollaries of having named subobjects with access to the parent class=
</p></blockquote><div><br>My claim is essentially that inline classes are n=
ot a feature so much as &quot;whatever is needed to make library property i=
mplementations work.&quot; And therefore they&#39;re a hodge-podge of funct=
ionality. You claim that inline classes are their own feature, a whole and =
complete thought that is designed for a purpose that is independent from pr=
operties. One that just so happens to <br><br>So let&#39;s examine the prop=
osal. Oh wait, there isn&#39;t one. There are multiple people posting about=
 it, each with their own idea of what it needs to have, and some of those i=
deas are contradictory. So let&#39;s just examine some of the things that h=
ave been said about it.<br><br>If all you really wanted was &quot;named sub=
objects with access to the parent class,&quot; why would it matter if inlin=
e classes are not trivially copyable? The standard has plenty of non-trivia=
lly-copyable classes. There is no fundamental problem with making inline cl=
asses non-trivially copyable. Indeed, this would not be the first language =
feature that a priori makes a class non-trivially copyable (virtual functio=
ns/bases, for example).<br><br>Oh sure, everyone likes for their classes to=
 be trivially copyable. But trivially copyable is a high bar to reach, and =
a whole lot of classes break it. Indeed, most standard library classes are =
not trivially copyable. And yet, you have people who want inline classes to=
 be trivially copyable so bad that they&#39;ve suggested that it should be =
impossible to get pointers/references to inline class members.<br><br>That&=
#39;s a blatant hack, one that is not strictly necessary.<br><br>Similarly,=
 if all you really wanted was &quot;named subobjects with access to the par=
ent class,&quot; why would people care if empty inline classes take up stor=
age in their owning classes? What does it matter? Especially if you&#39;ve =
already lost trivial copyability.<br><br>Such empty member optimization, li=
mited only to inline classes, is yet another blatant hack. And is no more n=
ecessary for the feature than the latter.<br><br>If you just wanted &quot;n=
amed subobjects with access to the parent class&quot;, you wouldn&#39;t car=
e about these hacks. But if you want a low-overhead implementation of prope=
rties, then both of those hacks are <i>essential</i>.<br><br>So let us plea=
se dispense with the pretense that this idea is about something other than =
building the specific features needed for implementing properties through o=
bjects.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D=
"ltr">
&gt;&gt;<br>
&gt;&gt; That&#39;s rarely what you actually want, though. Consider health:=
 setting health greater than the max value is an error,<br>
&gt;<br>
&gt;<br>
&gt; If I allow adding health to clamp, and I want to allow directly settin=
g health... why would I not want it to clamp too? It makes no sense to have=
 adding health to clamp, yet setting health error out.</p>
<p dir=3D"ltr">Which way should it clamp? What if you performed arithmetic =
in an unsigned type and it wrapped round? Erroring is the only safe option.=
</p></blockquote><div><br>You could have done the exact same thing with +=
=3D as well, only the wrap around happened before +=3D was evaluated (such =
as `health +=3D a + b;`). Why should `health =3D health + (a + b)` error, b=
ut not the former?<br><br></div><blockquote class=3D"gmail_quote" style=3D"=
margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;=
"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt; Furthermore, I would say that it is extremely rude for =
x +=3D y to have different behavior from x =3D x + y. I think it&#39;s reas=
onable to forbid one or the other. But if you allow both, then both should =
result in the exact same thing. The former can be faster, but it should nev=
er be a different result.<br>
&gt;<br>
&gt; And I would point out that C# works this way too. So that would be exp=
ected by those users.</p>
<p dir=3D"ltr">That doesn&#39;t mean it&#39;s the right behavior. Python ha=
s different (and fairly weird) behavior. C++ should be informed by existing=
 languages but it doesn&#39;t have to be the same.<br></p></blockquote><div=
><br>Maybe so, but you haven&#39;t come up with a good justification for wh=
y `x =3D x + y` should ever have different results from `x +=3D y`.<br><br>=
</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt;&gt; &gt; Also, there&#39;s explicit syntax for declarin=
g a property, rather than building a type and piggybacking some syntax off =
of implicit conversions or operator=3D or whatever. It looks like a real la=
nguage feature.<br>
&gt;&gt;<br>
&gt;&gt; It looks like shoehorning in a narrow solution to a very specific =
problem, that doesn&#39;t even fully solve that problem. (The health +=3D i=
ssue, above.)<br>
&gt;&gt;<br>
&gt;&gt; By contrast, consider the general problem of properties: we want a=
 class member access to result in an entity<br>
&gt;<br>
&gt;<br>
&gt; No, we do not, and this is where you keep getting confused about the d=
ifference between &quot;implementation&quot; and &quot;concept&quot;.<br>
&gt;<br>
&gt; The core concept of properties is to turn accessing a non-function mem=
ber of a class into a function call. &quot;result in an entity&quot; is an =
implementation detail, not a core part of the idea. And it&#39;s an unneces=
sary implementation detail, since the compiler could have performed the tra=
nsformation just fine by itself.<br>
&gt;<br>
&gt; You&#39;re limiting yourself by thinking that the only way to make pro=
perties work is by using existing C++ mechanics.</p>
<p dir=3D"ltr">I&#39;m starting to understand, I think. You want certain cl=
ass member access expressions to be replaced by (possibly multiple) method =
calls in... what, an extra phase of translation? How on earth are you going=
 to explain that to current C++ programmers?</p></blockquote><div><br>The e=
xact same way you explain that this:<br><br><div class=3D"prettyprint" styl=
e=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187)=
; border-style: solid; border-width: 1px; word-wrap: break-word;"><code cla=
ss=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #000=
;" class=3D"styled-by-prettify">a </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> b</span></div></code></div><br>becomes this:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #000;" class=3D"styled-by-prettify">a</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">+=3D(</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">b</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">);</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span></div></code></div><br>The concept is functiona=
lly no different: something becomes a function call even though it doesn&#3=
9;t look like one.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><p dir=3D"ltr">Also, as just one objection of I&#39;m sure many, what=
 happens to a class member access expression with object type a template ty=
pe parameter? </p></blockquote><div><br>If you&#39;re asking the equivalent=
 of what I asked about your system before (passing a property proxy object =
to a template argument), the result is quite simple. `template_func(a.prop)=
` does exactly what `a.prop` does when it is not used in an assignment expr=
ession: it is converted into a function call to the getter. So it becomes `=
template_func(a.getter())`.<br>=C2=A0</div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><p dir=3D"ltr">
&gt;&gt; Inline classes are not proxy objects. Possibly they are subobjects=
, but there is no proxying involved.<br>
&gt;<br>
&gt;<br>
&gt; A proxy object is an object that stands in for another, which can be u=
sed like the other while forward commands to it to the actual object.<br>
&gt;<br>
&gt; That is exactly what an inline class is doing. The &quot;getter&quot; =
works by being implicitly converted to the expected type. Thus, it can stan=
d for the reference to the actual data. The &quot;setter&quot; works by ope=
rator overloading, again based on the expected type. It again can act as th=
ough it were the expected type.<br>
&gt;<br>
&gt; It fits every definition of a proxy object. It may be a reference to a=
 proxy object rather than one created on the stack. But it does everything =
a proxy needs do. </p>
<p dir=3D"ltr">If it&#39;s a proxy object, where is the object being proxie=
d?</p></blockquote><div><br>It proxies an object of the type it converts/as=
signs to. This may be a real object. It may be a constant value. It may be =
scattered throughout memory, or a field in a database. But it is functional=
ly no different from any other proxy object: it is a stand-in for a real ob=
ject.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_2825_84485967.1440996388951--
------=_Part_2824_849938226.1440996388950--

.

--047d7bb04efebca0e3051e9c2ee2
Content-Type: text/plain; charset=UTF-8

On 31 Aug 2015 05:46, "Nicol Bolas" <jmckesson@gmail.com> wrote:
> I didn't say that solutions for properties needed to be aimed solely at
that feature. But if you're going to add a feature and try to justify it by
saying that it solves properties and other stuff too, you need to prove two
things:
>
> 1) That it solves the property problem well.
>
> 2) That it solves other genuinely useful problems well.
>
> Thus far, #2 is not in evidence, and #1 is in dispute (since it's a leaky
abstraction).

Thanks, that's a fair challenge and would have to be addressed for a
proposal to succeed. My answers would be:

1. This is a minimal proposal (relative to, say, operator dot); the
abstraction leakage of a property access expression result would occur
anyway (since I don't believe a pure syntax translation can succeed) and
this proposal at least make it explicit.
2. There are other benefits to grouping and encapsulating class members;
for example, in the implementation of service objects.

>> > Yes, the implementation has consequences, but this is usually in the
scope of a larger construct. Languages that use duck typing tend to get
properties as a natural outgrowth of a flexible type system. That changes
nothing about the concept of properties.
>>
>> How does duck typing imply properties? Javascript is duck typed, but it
doesn't have properties. Generic C++ is duck typed, but it doesn't have
properties. Python needed the descriptor protocol to make properties work,
but that's a feature of its object system, not its type system.
>
>
> I never said that duck typing implies properties. I said "Languages that
use duck typing tend to get properties as a natural outgrowth of a flexible
type system." You don't need one to get the other, but duck typing
frequently makes properties easy to implement.

Well, in that case C++'s duck typing should make properties easy to
implement.

>> > Also, you have yet to show me one useful thing that inline classes can
do that don't involve properties. Whereas duck typing is absurdly useful
and frequently self-justifying. The same feature that makes properties work
in Python makes about 10,000 other things work in Python.
>>
>> Which feature? Decorators or the descriptor protocol?
>
>
> Both. Admittedly, I know next to nothing about Python; I copied that
example from some site I found via Google. But if it works even remotely
like Lua (and the way "properties" work in that language), then those
mechanisms are general-purpose tools.
>
> Unlike inline classes.

OK, I took a look at Lua. Lua doesn't have properties! It has a general
mechanism for overriding member access, and a huge array of nonstandardized
libraries for using that mechanism to hack in properties. Does that mean
you would prefer operator dot?

>> > What else can inline classes do besides properties?
>> >
>> >> > For example, while thinking about what has to happen to make your
inline classes work, I realized something. Any class that contains an
inline class cannot be trivially copyable. Why? Because inline classes must
have an internal `this` pointer, which refers to the containing object. So
you cannot simply do a memcpy on them; the pointer has to be updated to
refer to the new object. And that requires the generation of a special copy
constructor that uses the new `this` object.
>> >>
>> >> Not true; an inline class has no storage or identity of its own, so a
pointer to an inline class can have the same value as a pointer to the
parent object. Note that within an inline class method "this" refers to the
parent object.
>> >
>> >
>> > OK, now you're just Calvinballing: inventing arbitrary features every
time someone comes along and explains why what you want doesn't work.
>>
>> I'm fairly sure that was in the original proposal.
>>
>> > And like with most Calvinballs, I don't think you thought that idea
through. Ignoring any potential strict aliasing minefields with this,
you're basically saying that you can't pass a property by reference to any
function if the type of that argument is deduced.
>>
>> Why does that follow?
>
>
> Because that's how C++ works.
>
> Presumably, an inline class member has a type. That type will be deduced
by the type deduction system, even if its an anonymous type. Therefore, if
a function takes a `const T&`, it will be deduced as a `const&` to the
inline class type.
>
> If taking a reference to an inline class results instead in a reference
to the owning class... then you haven't actually passed the property to the
function. Somehow passing `a.prop` is equivalent to passing `a`.

I didn't say that the references were the same, I said that they could have
the same value. The types are still distinct.

> If taking a reference to an inline class results in a compiler error,
then you can't pass it by reference to any template function. And since
they're probably non-copyable, you can't pass them by value either.
>
>>
>> And why would that be a bad thing?
>
>
> Because that's what users would expect. Calling `template_func(foo.min)`
ought to work. And if it doesn't, that would be very surprising for users.
>
>> If you want to pass by value, call the getter and pass the result;
>
>
> Think about what you said for a minute. Your property implementation can
run into a problem, and your solution for this problem... is to not use
properties.
>
> Doesn't that tell you that your property implementation is broken? Isn't
that what it means when you have to backdoor your own feature to make code
work?

The problem with passing `template_func(foo.min)` is that it's ambiguous;
do you mean the current value, or foo.min as a getter, or as a setter, or
both? This is a problem for any implementation of properties in C++. At
least by making foo.min an entity in the type system and data model we can
bring the ambiguity to the fore where it can be resolved.

>> >> > And you can't do something like pass the correct `this` pointer
from the source of the call. The reason being that you can get references
to inline classes, and those still need to be connected to the originating
object (your `auto& prop` code below captures the issue quite well). So the
`this` pointer must be a member of the inline class type. So there's no
getting around it; holders of inline classes cannot be trivially copied.
>> >>
>> >> Similarly, a reference to an inline class can have the same value as
a reference to the parent object. (It doesn't have to have that value, but
that's the simplest implementation.)
>> >>
>> >> Also, there's no need to allow forming a reference or pointer to an
inline class at all; just as a member function access expression is
required to be subject to a function call operation, an inline class access
expression could be required to be subject to a conversion or operation.
>> >
>> >
>> > OK, so I can't get a pointer to it. I can't get a reference to it. It
doesn't have a typename. It doesn't have a size.
>> >
>> > How is an inline class an object at all? Because C++ is quite clear
about this: "An object is a region of storage". You can't have a region of
0. So these inline classes are not a region of storage, and therefore they
are not objects.
>> >
>> > Or are you going to Calvinball a new definition for the C++ term
"object" so that it applies to inline classes? Because types only apply to
objects, references, or functions. And inline classes, as you have defined
them, are none of those. Therefore, they cannot have types. And they cannot
participate in things like operator overloading and so forth.
>>
>> Also subobjects, prvalues, non-type template parameters, void
-expressions and probably some other entities. Of these, inline classes are
most similar to subobjects; perhaps they are subobjects.
>
>
> From the spec:
>
> "Objects can contain other objects, called subobjects."
>
> Subobjects, by definition, are objects.
>
> But you are right that objects aren't the only things that have types.

I'm confused then; how can empty base subobjects be objects?

>> >> >>
>> >> >> >>> It should not have storage.
>> >> >> >>
>> >> >> >> There has to be storage *somewhere*. Both properties and inline
classes
>> >> >> >> use the parent for that storage.
>> >> >> >
>> >> >> > No, there doesn't.
>> >> >>
>> >> >> Um... okay, maybe if you're reading from an external input device,
I'll
>> >> >> buy that. However, I'm talking about the typical case of e.g. the
length
>> >> >> of a string. Either that length is stored somewhere (normally on
the
>> >> >> string instance), or it is computed from other data stored on the
string
>> >> >> instance. Especially in the former case, there *is* storage, it's
just
>> >> >> that the storage is in the parent class, not the property itself.
>> >> >
>> >> >
>> >> > There's a difference between the storage for the implementation of
the property, and the storage for the data itself. In your inline class
case, your property implementation takes up at least one byte, because
properties are objects (separate from any data storage). And in C++, object
members of a class must take up at least one byte.
>> >> >
>> >> > A pure property implementation means that there is only the data
storage (if any). The property itself has no storage, because the property
is not an object.
>> >>
>> >> If I understand the proposal correctly, inline classes are either not
objects, or have an exemption from the storage requirement analogous to the
empty base class optimization.
>> >
>> >
>> > If "inline classes" are not objects, then they should not use the word
"class" to declare/define them.
>>
>> Maybe. But in other respects they behave like class types, and not every
instance of a class type is an object
>
>
> I'm very curious to see a circumstance where you have an instance of a
class type that is not an object.

Empty base subobjects. Though see above.

>> >> Does that matter? As mentioned above beginner Python programmers
aren't expected to understand how properties work; they just use them.
>> >
>> >
>> > Um, Python property syntax looks like this:
>> >
>> > @property
>> > def x(self):
>> >   ...
>> >
>> > @x.setter
>> > def x(self, x):
>> >   ...
>> >
>> > See how it involves actual words like "property" and "set" and so
forth? The syntax you're suggesting for C++ involves words like "inline
class" and "operator Typename". None of which have anything to do with the
concept of properties, getters, setters, etc.
>> >
>> > Neophytes may not know what a "descriptor" is or what `@***` actually
is doing, but at least it's using words that they understand.
>>
>> That's a fairly minor consideration. Look how C++ spells "lambda", or
"pure virtual".
>
>
> Lambdas are terse because that's the point of lambdas. More importantly,
nothing else looks quite like a lambda inducer. Whereas a "property" looks
an awful lot like a struct definition. Because, you know, it is one.
>
> And nobody has ever defended C++'s pure virtual syntax as being a
positive design feature of the language. Just because C++ has
unpleasantness in it does not justify deliberately adding more. Especially
when there are alternatives.
>
>>
>> >> Also, the operator overloads could be provided by a library facility
to forward to named getter and setter.
>> >
>> >
>> > Let me guess. You want to have inline classes able to derive from some
std::property library class. You want an anonymous class with no storage...
to have a base class.
>> >
>> > That opens up an entire avenue of problems. The defining feature of
inline classes is that their `this` pointer points to the owning object.
This effectively means that they can't even call other methods on
themselves. Well... how does that work with base classes? How can their
base class get a `this` pointer that points to its own type, but the
derived inline class cannot? How can the base class call a member of a
class that doesn't even have a `this` pointer?
>> >
>> > What will you want next? When you realize that you can't have this
hypothetical `std::property` object actually call members on its derived
type, will you decide you need virtual functions on these supposedly
stateless objects? Where does the hacking end?
>>
>> Almost; it would have to use static polymorphism, not dynamic
polymorphism. That would require the inline class to be named, of course,
but I don't see that as an essential aspect of the proposal (apologies if
it is).
>
>
> So let's look at what you have to do to declare a property with this
syntax:
>
> inline struct Irrelevant : public std::property<Irrelevant>
> {
>   Type get() const {...}
>   Type &set(const Type &t) {...}
> } property_name;
>
> There are 6 words in the first line; only one of them (property) actually
means something to the user. The rest are noise. "Irrelevant" is
particularly problematic, since you must provide a typename so that you can
pass it to the property template.
>
> Admittedly, the rest looks at least sensible. But it still requires a lot
of noise.
>
>>
>> > Can you not see how far you're reaching to force this implementation
to actually implement properties? It's an object, but you can't get a
pointer/reference to it. It's an object, but it doesn't take up actual
space. It's a class, but it doesn't have its own `this` pointer. And so
forth.
>> >
>> > You're giving inline classes about as many special-case rules as
lambdas. And those are far more generally useful than inline classes.
>> >
>> > What functionality does inline classes provide that justifies this
level of special-caseness? And if your only answer is "it lets us have
properties"... well, no, that's not good enough.
>>
>> I don't see a collection of special cases; I see the logical corollaries
of having named subobjects with access to the parent class
>
>
> My claim is essentially that inline classes are not a feature so much as
"whatever is needed to make library property implementations work." And
therefore they're a hodge-podge of functionality. You claim that inline
classes are their own feature, a whole and complete thought that is
designed for a purpose that is independent from properties. One that just
so happens to
>
> So let's examine the proposal. Oh wait, there isn't one. There are
multiple people posting about it, each with their own idea of what it needs
to have, and some of those ideas are contradictory. So let's just examine
some of the things that have been said about it.
>
> If all you really wanted was "named subobjects with access to the parent
class," why would it matter if inline classes are not trivially copyable?
The standard has plenty of non-trivially-copyable classes. There is no
fundamental problem with making inline classes non-trivially copyable.
Indeed, this would not be the first language feature that a priori makes a
class non-trivially copyable (virtual functions/bases, for example).
>
> Oh sure, everyone likes for their classes to be trivially copyable. But
trivially copyable is a high bar to reach, and a whole lot of classes break
it. Indeed, most standard library classes are not trivially copyable. And
yet, you have people who want inline classes to be trivially copyable so
bad that they've suggested that it should be impossible to get
pointers/references to inline class members.
>
> That's a blatant hack, one that is not strictly necessary.

Right, it isn't necessary, since there's no need for pointers/references to
inline class members to interfere with trivial copyability.

> Similarly, if all you really wanted was "named subobjects with access to
the parent class," why would people care if empty inline classes take up
storage in their owning classes? What does it matter? Especially if you've
already lost trivial copyability.
>
> Such empty member optimization, limited only to inline classes, is yet
another blatant hack. And is no more necessary for the feature than the
latter.
>
> If you just wanted "named subobjects with access to the parent class",
you wouldn't care about these hacks. But if you want a low-overhead
implementation of properties, then both of those hacks are essential.
>
> So let us please dispense with the pretense that this idea is about
something other than building the specific features needed for implementing
properties through objects.

The less overhead a feature has, the more likely it is to be adopted. It
should be possible to guarantee to users that if they use inline classes in
a specific way, then there will be zero runtime overhead.

>> >>
>> >> That's rarely what you actually want, though. Consider health:
setting health greater than the max value is an error,
>> >
>> >
>> > If I allow adding health to clamp, and I want to allow directly
setting health... why would I not want it to clamp too? It makes no sense
to have adding health to clamp, yet setting health error out.
>>
>> Which way should it clamp? What if you performed arithmetic in an
unsigned type and it wrapped round? Erroring is the only safe option.
>
>
> You could have done the exact same thing with += as well, only the wrap
around happened before += was evaluated (such as `health += a + b;`). Why
should `health = health + (a + b)` error, but not the former?

In one there's a sensible and safe behavior, in the other there isn't.

>> > Furthermore, I would say that it is extremely rude for x += y to have
different behavior from x = x + y. I think it's reasonable to forbid one or
the other. But if you allow both, then both should result in the exact same
thing. The former can be faster, but it should never be a different result.
>> >
>> > And I would point out that C# works this way too. So that would be
expected by those users.
>>
>> That doesn't mean it's the right behavior. Python has different (and
fairly weird) behavior. C++ should be informed by existing languages but it
doesn't have to be the same.
>
>
> Maybe so, but you haven't come up with a good justification for why `x =
x + y` should ever have different results from `x += y`.

Conceptually, modifications to a property occur respecting class
invariants, while arithmetic on a property value occur in the underlying
type so cannot consider invariants.

>> >> > Also, there's explicit syntax for declaring a property, rather than
building a type and piggybacking some syntax off of implicit conversions or
operator= or whatever. It looks like a real language feature.
>> >>
>> >> It looks like shoehorning in a narrow solution to a very specific
problem, that doesn't even fully solve that problem. (The health += issue,
above.)
>> >>
>> >> By contrast, consider the general problem of properties: we want a
class member access to result in an entity
>> >
>> >
>> > No, we do not, and this is where you keep getting confused about the
difference between "implementation" and "concept".
>> >
>> > The core concept of properties is to turn accessing a non-function
member of a class into a function call. "result in an entity" is an
implementation detail, not a core part of the idea. And it's an unnecessary
implementation detail, since the compiler could have performed the
transformation just fine by itself.
>> >
>> > You're limiting yourself by thinking that the only way to make
properties work is by using existing C++ mechanics.
>>
>> I'm starting to understand, I think. You want certain class member
access expressions to be replaced by (possibly multiple) method calls in...
what, an extra phase of translation? How on earth are you going to explain
that to current C++ programmers?
>
>
> The exact same way you explain that this:
>
> a += b
>
> becomes this:
>
> a.operator+=(b);
>
> The concept is functionally no different: something becomes a function
call even though it doesn't look like one.

But operator overloading works by overload resolution on the types of the
operands; you've said that when a class member access expression results in
a property access there isn't a result, so no resulting entity, so no type
to perform overload resolution on. So no, the same explanation won't work.

>> Also, as just one objection of I'm sure many, what happens to a class
member access expression with object type a template type parameter?
>
>
> If you're asking the equivalent of what I asked about your system before
(passing a property proxy object to a template argument), the result is
quite simple. `template_func(a.prop)` does exactly what `a.prop` does when
it is not used in an assignment expression: it is converted into a function
call to the getter. So it becomes `template_func(a.getter())`.

That's not what I'm asking; I'm asking what happens when `a` has a type
dependent on a template parameter. You don't know whether `a.prop` is a
data member or a property until the template is instantiated, so you can't
perform the syntax transformation until after that stage of translation. So
how do you avoid the class member access expression resulting in an entity
of some kind?

>> >> Inline classes are not proxy objects. Possibly they are subobjects,
but there is no proxying involved.
>> >
>> >
>> > A proxy object is an object that stands in for another, which can be
used like the other while forward commands to it to the actual object.
>> >
>> > That is exactly what an inline class is doing. The "getter" works by
being implicitly converted to the expected type. Thus, it can stand for the
reference to the actual data. The "setter" works by operator overloading,
again based on the expected type. It again can act as though it were the
expected type.
>> >
>> > It fits every definition of a proxy object. It may be a reference to a
proxy object rather than one created on the stack. But it does everything a
proxy needs do.
>>
>> If it's a proxy object, where is the object being proxied?
>
>
> It proxies an object of the type it converts/assigns to. This may be a
real object. It may be a constant value. It may be scattered throughout
memory, or a field in a database. But it is functionally no different from
any other proxy object: it is a stand-in for a real object.

OK, that makes sense. I misunderstood; I thought you were saying that they
were a proxy to the parent object.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bb04efebca0e3051e9c2ee2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 31 Aug 2015 05:46, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckess=
on@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt; I didn&#39;t say that solutions for properties needed to be aimed sole=
ly at that feature. But if you&#39;re going to add a feature and try to jus=
tify it by saying that it solves properties and other stuff too, you need t=
o prove two things:<br>
&gt;<br>
&gt; 1) That it solves the property problem well.<br>
&gt;<br>
&gt; 2) That it solves other genuinely useful problems well.<br>
&gt;<br>
&gt; Thus far, #2 is not in evidence, and #1 is in dispute (since it&#39;s =
a leaky abstraction).</p>
<p dir=3D"ltr">Thanks, that&#39;s a fair challenge and would have to be add=
ressed for a proposal to succeed. My answers would be:</p>
<p dir=3D"ltr">1. This is a minimal proposal (relative to, say, operator do=
t); the abstraction leakage of a property access expression result would oc=
cur anyway (since I don&#39;t believe a pure syntax translation can succeed=
) and this proposal at least make it explicit. <br>
2. There are other benefits to grouping and encapsulating class members; fo=
r example, in the implementation of service objects. </p>
<p dir=3D"ltr">&gt;&gt; &gt; Yes, the implementation has consequences, but =
this is usually in the scope of a larger construct. Languages that use duck=
 typing tend to get properties as a natural outgrowth of a flexible type sy=
stem. That changes nothing about the concept of properties.<br>
&gt;&gt;<br>
&gt;&gt; How does duck typing imply properties? Javascript is duck typed, b=
ut it doesn&#39;t have properties. Generic C++ is duck typed, but it doesn&=
#39;t have properties. Python needed the descriptor protocol to make proper=
ties work, but that&#39;s a feature of its object system, not its type syst=
em.<br>
&gt;<br>
&gt;<br>
&gt; I never said that duck typing implies properties. I said &quot;Languag=
es that use duck typing tend to get properties as a natural outgrowth of a =
flexible type system.&quot; You don&#39;t need one to get the other, but du=
ck typing frequently makes properties easy to implement.</p>
<p dir=3D"ltr">Well, in that case C++&#39;s duck typing should make propert=
ies easy to implement. </p>
<p dir=3D"ltr">&gt;&gt; &gt; Also, you have yet to show me one useful thing=
 that inline classes can do that don&#39;t involve properties. Whereas duck=
 typing is absurdly useful and frequently self-justifying. The same feature=
 that makes properties work in Python makes about 10,000 other things work =
in Python.<br>
&gt;&gt;<br>
&gt;&gt; Which feature? Decorators or the descriptor protocol?<br>
&gt;<br>
&gt;<br>
&gt; Both. Admittedly, I know next to nothing about Python; I copied that e=
xample from some site I found via Google. But if it works even remotely lik=
e Lua (and the way &quot;properties&quot; work in that language), then thos=
e mechanisms are general-purpose tools.<br>
&gt;<br>
&gt; Unlike inline classes.</p>
<p dir=3D"ltr">OK, I took a look at Lua. Lua doesn&#39;t have properties! I=
t has a general mechanism for overriding member access, and a huge array of=
 nonstandardized libraries for using that mechanism to hack in properties. =
Does that mean you would prefer operator dot?</p>
<p dir=3D"ltr">&gt;&gt; &gt; What else can inline classes do besides proper=
ties?<br>
&gt;&gt; &gt; =C2=A0<br>
&gt;&gt; &gt;&gt; &gt; For example, while thinking about what has to happen=
 to make your inline classes work, I realized something. Any class that con=
tains an inline class cannot be trivially copyable. Why? Because inline cla=
sses must have an internal `this` pointer, which refers to the containing o=
bject. So you cannot simply do a memcpy on them; the pointer has to be upda=
ted to refer to the new object. And that requires the generation of a speci=
al copy constructor that uses the new `this` object.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Not true; an inline class has no storage or identity of i=
ts own, so a pointer to an inline class can have the same value as a pointe=
r to the parent object. Note that within an inline class method &quot;this&=
quot; refers to the parent object.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OK, now you&#39;re just Calvinballing: inventing arbitrary fe=
atures every time someone comes along and explains why what you want doesn&=
#39;t work.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m fairly sure that was in the original proposal.<br>
&gt;&gt;<br>
&gt;&gt; &gt; And like with most Calvinballs, I don&#39;t think you thought=
 that idea through. Ignoring any potential strict aliasing minefields with =
this, you&#39;re basically saying that you can&#39;t pass a property by ref=
erence to any function if the type of that argument is deduced.<br>
&gt;&gt;<br>
&gt;&gt; Why does that follow?<br>
&gt;<br>
&gt;<br>
&gt; Because that&#39;s how C++ works.<br>
&gt;<br>
&gt; Presumably, an inline class member has a type. That type will be deduc=
ed by the type deduction system, even if its an anonymous type. Therefore, =
if a function takes a `const T&amp;`, it will be deduced as a `const&amp;` =
to the inline class type.<br>
&gt;<br>
&gt; If taking a reference to an inline class results instead in a referenc=
e to the owning class... then you haven&#39;t actually passed the property =
to the function. Somehow passing `a.prop` is equivalent to passing `a`.</p>
<p dir=3D"ltr">I didn&#39;t say that the references were the same, I said t=
hat they could have the same value. The types are still distinct. </p>
<p dir=3D"ltr">&gt; If taking a reference to an inline class results in a c=
ompiler error, then you can&#39;t pass it by reference to any template func=
tion. And since they&#39;re probably non-copyable, you can&#39;t pass them =
by value either.<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; And why would that be a bad thing?<br>
&gt;<br>
&gt;<br>
&gt; Because that&#39;s what users would expect. Calling `template_func(foo=
..min)` ought to work. And if it doesn&#39;t, that would be very surprising =
for users.<br>
&gt;<br>
&gt;&gt; If you want to pass by value, call the getter and pass the result;=
<br>
&gt;<br>
&gt;<br>
&gt; Think about what you said for a minute. Your property implementation c=
an run into a problem, and your solution for this problem... is to not use =
properties.<br>
&gt;<br>
&gt; Doesn&#39;t that tell you that your property implementation is broken?=
 Isn&#39;t that what it means when you have to backdoor your own feature to=
 make code work?</p>
<p dir=3D"ltr">The problem with passing `template_func(foo.min)` is that it=
&#39;s ambiguous; do you mean the current value, or foo.min as a getter, or=
 as a setter, or both? This is a problem for any implementation of properti=
es in C++. At least by making foo.min an entity in the type system and data=
 model we can bring the ambiguity to the fore where it can be resolved. </p=
>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; &gt; And you can&#39;t do something like p=
ass the correct `this` pointer from the source of the call. The reason bein=
g that you can get references to inline classes, and those still need to be=
 connected to the originating object (your `auto&amp; prop` code below capt=
ures the issue quite well). So the `this` pointer must be a member of the i=
nline class type. So there&#39;s no getting around it; holders of inline cl=
asses cannot be trivially copied.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Similarly, a reference to an inline class can have the sa=
me value as a reference to the parent object. (It doesn&#39;t have to have =
that value, but that&#39;s the simplest implementation.)=C2=A0<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Also, there&#39;s no need to allow forming a reference or=
 pointer to an inline class at all; just as a member function access expres=
sion is required to be subject to a function call operation, an inline clas=
s access expression could be required to be subject to a conversion or oper=
ation.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OK, so I can&#39;t get a pointer to it. I can&#39;t get a ref=
erence to it. It doesn&#39;t have a typename. It doesn&#39;t have a size.<b=
r>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; How is an inline class an object at all? Because C++ is quite=
 clear about this: &quot;An object is a region of storage&quot;. You can&#3=
9;t have a region of 0. So these inline classes are not a region of storage=
, and therefore they are not objects.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Or are you going to Calvinball a new definition for the C++ t=
erm &quot;object&quot; so that it applies to inline classes? Because types =
only apply to objects, references, or functions. And inline classes, as you=
 have defined them, are none of those. Therefore, they cannot have types. A=
nd they cannot participate in things like operator overloading and so forth=
..<br>
&gt;&gt;<br>
&gt;&gt; Also subobjects, prvalues, non-type template parameters, void -exp=
ressions and probably some other entities. Of these, inline classes are mos=
t similar to subobjects; perhaps they are subobjects.<br>
&gt;<br>
&gt;<br>
&gt; From the spec:<br>
&gt;<br>
&gt; &quot;Objects can contain other objects, called subobjects.&quot;<br>
&gt;<br>
&gt; Subobjects, by definition, are objects.<br>
&gt;<br>
&gt; But you are right that objects aren&#39;t the only things that have ty=
pes.</p>
<p dir=3D"ltr">I&#39;m confused then; how can empty base subobjects be obje=
cts? </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt;&gt; It should not have storage. <br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; <br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; There has to be storage *somewhere*. Bo=
th properties and inline classes <br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt;&gt; use the parent for that storage. <br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; <br>
&gt;&gt; &gt;&gt; &gt;&gt; &gt; No, there doesn&#39;t. <br>
&gt;&gt; &gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; &gt;&gt; Um... okay, maybe if you&#39;re reading from an =
external input device, I&#39;ll <br>
&gt;&gt; &gt;&gt; &gt;&gt; buy that. However, I&#39;m talking about the typ=
ical case of e.g. the length <br>
&gt;&gt; &gt;&gt; &gt;&gt; of a string. Either that length is stored somewh=
ere (normally on the <br>
&gt;&gt; &gt;&gt; &gt;&gt; string instance), or it is computed from other d=
ata stored on the string <br>
&gt;&gt; &gt;&gt; &gt;&gt; instance. Especially in the former case, there *=
is* storage, it&#39;s just <br>
&gt;&gt; &gt;&gt; &gt;&gt; that the storage is in the parent class, not the=
 property itself.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; There&#39;s a difference between the storage for the=
 implementation of the property, and the storage for the data itself. In yo=
ur inline class case, your property implementation takes up at least one by=
te, because properties are objects (separate from any data storage). And in=
 C++, object members of a class must take up at least one byte.<br>
&gt;&gt; &gt;&gt; &gt;<br>
&gt;&gt; &gt;&gt; &gt; A pure property implementation means that there is o=
nly the data storage (if any). The property itself has no storage, because =
the property is not an object.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; If I understand the proposal correctly, inline classes ar=
e either not objects, or have an exemption from the storage requirement ana=
logous to the empty base class optimization.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If &quot;inline classes&quot; are not objects, then they shou=
ld not use the word &quot;class&quot; to declare/define them.<br>
&gt;&gt;<br>
&gt;&gt; Maybe. But in other respects they behave like class types, and not=
 every instance of a class type is an object<br>
&gt;<br>
&gt;<br>
&gt; I&#39;m very curious to see a circumstance where you have an instance =
of a class type that is not an object.</p>
<p dir=3D"ltr">Empty base subobjects. Though see above. </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; Does that matter? As mentioned above begin=
ner Python programmers aren&#39;t expected to understand how properties wor=
k; they just use them.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Um, Python property syntax looks like this:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; @property<br>
&gt;&gt; &gt; def x(self):<br>
&gt;&gt; &gt; =C2=A0 ...<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; @x.setter<br>
&gt;&gt; &gt; def x(self, x):<br>
&gt;&gt; &gt; =C2=A0 ...<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; See how it involves actual words like &quot;property&quot; an=
d &quot;set&quot; and so forth? The syntax you&#39;re suggesting for C++ in=
volves words like &quot;inline class&quot; and &quot;operator Typename&quot=
;. None of which have anything to do with the concept of properties, getter=
s, setters, etc.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Neophytes may not know what a &quot;descriptor&quot; is or wh=
at `@***` actually is doing, but at least it&#39;s using words that they un=
derstand.<br>
&gt;&gt;<br>
&gt;&gt; That&#39;s a fairly minor consideration. Look how C++ spells &quot=
;lambda&quot;, or &quot;pure virtual&quot;.<br>
&gt;<br>
&gt;<br>
&gt; Lambdas are terse because that&#39;s the point of lambdas. More import=
antly, nothing else looks quite like a lambda inducer. Whereas a &quot;prop=
erty&quot; looks an awful lot like a struct definition. Because, you know, =
it is one.<br>
&gt;<br>
&gt; And nobody has ever defended C++&#39;s pure virtual syntax as being a =
positive design feature of the language. Just because C++ has unpleasantnes=
s in it does not justify deliberately adding more. Especially when there ar=
e alternatives.<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; &gt;&gt; Also, the operator overloads could be provided by a libra=
ry facility to forward to named getter and setter.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; Let me guess. You want to have inline classes able to derive =
from some std::property library class. You want an anonymous class with no =
storage... to have a base class.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That opens up an entire avenue of problems. The defining feat=
ure of inline classes is that their `this` pointer points to the owning obj=
ect. This effectively means that they can&#39;t even call other methods on =
themselves. Well... how does that work with base classes? How can their bas=
e class get a `this` pointer that points to its own type, but the derived i=
nline class cannot? How can the base class call a member of a class that do=
esn&#39;t even have a `this` pointer?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What will you want next? When you realize that you can&#39;t =
have this hypothetical `std::property` object actually call members on its =
derived type, will you decide you need virtual functions on these supposedl=
y stateless objects? Where does the hacking end?<br>
&gt;&gt;<br>
&gt;&gt; Almost; it would have to use static polymorphism, not dynamic poly=
morphism. That would require the inline class to be named, of course, but I=
 don&#39;t see that as an essential aspect of the proposal (apologies if it=
 is).<br>
&gt;<br>
&gt;<br>
&gt; So let&#39;s look at what you have to do to declare a property with th=
is syntax:<br>
&gt;<br>
&gt; inline struct Irrelevant : public std::property&lt;Irrelevant&gt;<br>
&gt; {<br>
&gt; =C2=A0 Type get() const {...}<br>
&gt; =C2=A0 Type &amp;set(const Type &amp;t) {...}<br>
&gt; } property_name;<br>
&gt;<br>
&gt; There are 6 words in the first line; only one of them (property) actua=
lly means something to the user. The rest are noise. &quot;Irrelevant&quot;=
 is particularly problematic, since you must provide a typename so that you=
 can pass it to the property template.<br>
&gt;<br>
&gt; Admittedly, the rest looks at least sensible. But it still requires a =
lot of noise.<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; &gt; Can you not see how far you&#39;re reaching to force this imp=
lementation to actually implement properties? It&#39;s an object, but you c=
an&#39;t get a pointer/reference to it. It&#39;s an object, but it doesn&#3=
9;t take up actual space. It&#39;s a class, but it doesn&#39;t have its own=
 `this` pointer. And so forth.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You&#39;re giving inline classes about as many special-case r=
ules as lambdas. And those are far more generally useful than inline classe=
s.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What functionality does inline classes provide that justifies=
 this level of special-caseness? And if your only answer is &quot;it lets u=
s have properties&quot;... well, no, that&#39;s not good enough.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t see a collection of special cases; I see the logical c=
orollaries of having named subobjects with access to the parent class<br>
&gt;<br>
&gt;<br>
&gt; My claim is essentially that inline classes are not a feature so much =
as &quot;whatever is needed to make library property implementations work.&=
quot; And therefore they&#39;re a hodge-podge of functionality. You claim t=
hat inline classes are their own feature, a whole and complete thought that=
 is designed for a purpose that is independent from properties. One that ju=
st so happens to <br>
&gt;<br>
&gt; So let&#39;s examine the proposal. Oh wait, there isn&#39;t one. There=
 are multiple people posting about it, each with their own idea of what it =
needs to have, and some of those ideas are contradictory. So let&#39;s just=
 examine some of the things that have been said about it.<br>
&gt;<br>
&gt; If all you really wanted was &quot;named subobjects with access to the=
 parent class,&quot; why would it matter if inline classes are not triviall=
y copyable? The standard has plenty of non-trivially-copyable classes. Ther=
e is no fundamental problem with making inline classes non-trivially copyab=
le. Indeed, this would not be the first language feature that a priori make=
s a class non-trivially copyable (virtual functions/bases, for example).<br=
>
&gt;<br>
&gt; Oh sure, everyone likes for their classes to be trivially copyable. Bu=
t trivially copyable is a high bar to reach, and a whole lot of classes bre=
ak it. Indeed, most standard library classes are not trivially copyable. An=
d yet, you have people who want inline classes to be trivially copyable so =
bad that they&#39;ve suggested that it should be impossible to get pointers=
/references to inline class members.<br>
&gt;<br>
&gt; That&#39;s a blatant hack, one that is not strictly necessary.</p>
<p dir=3D"ltr">Right, it isn&#39;t necessary, since there&#39;s no need for=
 pointers/references to inline class members to interfere with trivial copy=
ability.</p>
<p dir=3D"ltr">&gt; Similarly, if all you really wanted was &quot;named sub=
objects with access to the parent class,&quot; why would people care if emp=
ty inline classes take up storage in their owning classes? What does it mat=
ter? Especially if you&#39;ve already lost trivial copyability.<br>
&gt;<br>
&gt; Such empty member optimization, limited only to inline classes, is yet=
 another blatant hack. And is no more necessary for the feature than the la=
tter.<br>
&gt;<br>
&gt; If you just wanted &quot;named subobjects with access to the parent cl=
ass&quot;, you wouldn&#39;t care about these hacks. But if you want a low-o=
verhead implementation of properties, then both of those hacks are essentia=
l.<br>
&gt;<br>
&gt; So let us please dispense with the pretense that this idea is about so=
mething other than building the specific features needed for implementing p=
roperties through objects.</p>
<p dir=3D"ltr">The less overhead a feature has, the more likely it is to be=
 adopted. It should be possible to guarantee to users that if they use inli=
ne classes in a specific way, then there will be zero runtime overhead. </p=
>
<p dir=3D"ltr">&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; That&#39;s rarely what you actually want, though. Conside=
r health: setting health greater than the max value is an error,<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; If I allow adding health to clamp, and I want to allow direct=
ly setting health... why would I not want it to clamp too? It makes no sens=
e to have adding health to clamp, yet setting health error out.<br>
&gt;&gt;<br>
&gt;&gt; Which way should it clamp? What if you performed arithmetic in an =
unsigned type and it wrapped round? Erroring is the only safe option.<br>
&gt;<br>
&gt;<br>
&gt; You could have done the exact same thing with +=3D as well, only the w=
rap around happened before +=3D was evaluated (such as `health +=3D a + b;`=
). Why should `health =3D health + (a + b)` error, but not the former?</p>
<p dir=3D"ltr">In one there&#39;s a sensible and safe behavior, in the othe=
r there isn&#39;t. </p>
<p dir=3D"ltr">&gt;&gt; &gt; Furthermore, I would say that it is extremely =
rude for x +=3D y to have different behavior from x =3D x + y. I think it&#=
39;s reasonable to forbid one or the other. But if you allow both, then bot=
h should result in the exact same thing. The former can be faster, but it s=
hould never be a different result.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; And I would point out that C# works this way too. So that wou=
ld be expected by those users.<br>
&gt;&gt;<br>
&gt;&gt; That doesn&#39;t mean it&#39;s the right behavior. Python has diff=
erent (and fairly weird) behavior. C++ should be informed by existing langu=
ages but it doesn&#39;t have to be the same.<br>
&gt;<br>
&gt;<br>
&gt; Maybe so, but you haven&#39;t come up with a good justification for wh=
y `x =3D x + y` should ever have different results from `x +=3D y`.</p>
<p dir=3D"ltr">Conceptually, modifications to a property occur respecting c=
lass invariants, while arithmetic on a property value occur in the underlyi=
ng type so cannot consider invariants. </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; &gt; Also, there&#39;s explicit syntax for=
 declaring a property, rather than building a type and piggybacking some sy=
ntax off of implicit conversions or operator=3D or whatever. It looks like =
a real language feature.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; It looks like shoehorning in a narrow solution to a very =
specific problem, that doesn&#39;t even fully solve that problem. (The heal=
th +=3D issue, above.)<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; By contrast, consider the general problem of properties: =
we want a class member access to result in an entity<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; No, we do not, and this is where you keep getting confused ab=
out the difference between &quot;implementation&quot; and &quot;concept&quo=
t;.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; The core concept of properties is to turn accessing a non-fun=
ction member of a class into a function call. &quot;result in an entity&quo=
t; is an implementation detail, not a core part of the idea. And it&#39;s a=
n unnecessary implementation detail, since the compiler could have performe=
d the transformation just fine by itself.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You&#39;re limiting yourself by thinking that the only way to=
 make properties work is by using existing C++ mechanics.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m starting to understand, I think. You want certain class me=
mber access expressions to be replaced by (possibly multiple) method calls =
in... what, an extra phase of translation? How on earth are you going to ex=
plain that to current C++ programmers?<br>
&gt;<br>
&gt;<br>
&gt; The exact same way you explain that this:<br>
&gt;<br>
&gt; a +=3D b<br>
&gt;<br>
&gt; becomes this:<br>
&gt;<br>
&gt; a.operator+=3D(b);<br>
&gt;<br>
&gt; The concept is functionally no different: something becomes a function=
 call even though it doesn&#39;t look like one.</p>
<p dir=3D"ltr">But operator overloading works by overload resolution on the=
 types of the operands; you&#39;ve said that when a class member access exp=
ression results in a property access there isn&#39;t a result, so no result=
ing entity, so no type to perform overload resolution on. So no, the same e=
xplanation won&#39;t work. </p>
<p dir=3D"ltr">&gt;&gt; Also, as just one objection of I&#39;m sure many, w=
hat happens to a class member access expression with object type a template=
 type parameter?<br>
&gt;<br>
&gt;<br>
&gt; If you&#39;re asking the equivalent of what I asked about your system =
before (passing a property proxy object to a template argument), the result=
 is quite simple. `template_func(a.prop)` does exactly what `a.prop` does w=
hen it is not used in an assignment expression: it is converted into a func=
tion call to the getter. So it becomes `template_func(a.getter())`.</p>
<p dir=3D"ltr">That&#39;s not what I&#39;m asking; I&#39;m asking what happ=
ens when `a` has a type dependent on a template parameter. You don&#39;t kn=
ow whether `a.prop` is a data member or a property until the template is in=
stantiated, so you can&#39;t perform the syntax transformation until after =
that stage of translation. So how do you avoid the class member access expr=
ession resulting in an entity of some kind? </p>
<p dir=3D"ltr">&gt;&gt; &gt;&gt; Inline classes are not proxy objects. Poss=
ibly they are subobjects, but there is no proxying involved.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; A proxy object is an object that stands in for another, which=
 can be used like the other while forward commands to it to the actual obje=
ct.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; That is exactly what an inline class is doing. The &quot;gett=
er&quot; works by being implicitly converted to the expected type. Thus, it=
 can stand for the reference to the actual data. The &quot;setter&quot; wor=
ks by operator overloading, again based on the expected type. It again can =
act as though it were the expected type.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; It fits every definition of a proxy object. It may be a refer=
ence to a proxy object rather than one created on the stack. But it does ev=
erything a proxy needs do.<br>
&gt;&gt;<br>
&gt;&gt; If it&#39;s a proxy object, where is the object being proxied?<br>
&gt;<br>
&gt;<br>
&gt; It proxies an object of the type it converts/assigns to. This may be a=
 real object. It may be a constant value. It may be scattered throughout me=
mory, or a field in a database. But it is functionally no different from an=
y other proxy object: it is a stand-in for a real object.</p>
<p dir=3D"ltr">OK, that makes sense. I misunderstood; I thought you were sa=
ying that they were a proxy to the parent object. </p>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb04efebca0e3051e9c2ee2--

.

On 2015-08-27 18:37, Nicol Bolas wrote:
> See, your problem is that you're not separating the *concept* of a proper=
ty=20
> from your proposed implementation.
>=20
> The *concept* of a property is nothing more than a syntax translator,=20
> converting x.y into x.y_get(), or converting x.y =3D z into x.y_set(z).=
=20
> Whether it's calling methods with those names, or methods of some other=
=20
> type, is irrelevant. What matters is that the input syntax results in=20
> specific function calls in specific scenarios.
>=20
> Your proposed implementation does this conversion by making properties in=
to=20
> an *object*. That is, the property is an object, which is in some way=20
> distinct from the data storage accessed/modified by that property.

Which is a *GOOD THING!* You can take a reference to a property. You
can't do that if a property is something that only exists as a concept
and is implemented by () omission. I've already explained *why* this is
important.

> For example, while thinking about what has to happen to make your inline=
=20
> classes work, I realized something. Any class that contains an inline cla=
ss *cannot=20
> be trivially copyable*. Why? Because inline classes must have an internal=
=20
> `this` pointer, which refers to the containing object.

See Edward's reply. Although...

On 2015-08-29 21:11, 'Edward Catmur' wrote:
> so a pointer to an inline class can have the same value as a pointer
> to the parent object.

s/can have/does have/

> So you cannot simply do a memcpy on them

You can't copy an inline class by itself, period. The operation is
meaningless, anyway, since it has no storage. (So... okay, there are
probably some details about how copying a class that contains inline
classes would work, but I don't see anything insurmountable there.
Probably they are just ignored. I expect the normal pattern is that a
property is not even assignable from another property of the same type,
but rather is assignable only by the logical value type.)

> I never said that returning a reference was broken. Returning
> references is a common C++ idiom. Just check various APIs; most
> getters return by `const&`.

Returning references *is* broken. It's not thread safe, for one. Also:

  auto& prop =3D obj.property();
  auto value =3D prop;
  assert(prop =3D=3D value); // we hope, but not thread safe!
  obj.frob();
  assert(prop =3D=3D value); // all bets are off

And yes, I've run into this in practice; a library I work with had to
change a bunch of reference returns to value returns because we were
seeing bugs with references being retained.

Never return references unless the purpose of the API is to obtain
access to a class's internal storage.

> What's broken is *changing* an interface from returning a reference
> to returning a proxy object.

How so? If you need to change the underlying representation, changing
from returning a reference to the underlying object, to returning a
reference to a proxy object, at least has a chance of continuing to work
correctly (i.e. if the receiver used 'auto').

> On Thursday, August 27, 2015 at 4:20:10 PM UTC-4, Matthew Woehlke wrote:
>> As previously illustrated, an inline class will still work with this cod=
e:=20
>>
>>   auto& prop =3D foo.bar;=20
>>   prop =3D 5;=20
>=20
> But it wouldn't work on this:
>=20
> float &prop =3D foo.bar;

Yes, but you'll get a compile error. If you need to change the
implementation, your example is just going to be broken, period.
Ideally, it will result in a compile error. I'm concerned that you would
turn it into a silent breakage of runtime behavior.

>> How will your "real properties" accomplish that? Remember, we've=20
>> established that decltype(foo.bar) !=3D int&. If it's a reference to an=
=20
>> inline class / std::property<int> / etc., there is no problem.
>=20
> Again, you're confusing concept with implementation.
>=20
> Your proposed implementation makes `foo.bar` resolve to an inline class=
=20
> value, who's various member functions implement property mechanics. The=
=20
> pure implementation is for `foo.bar` to automatically be transformed by t=
he=20
> compiler into a function call to either the property getter or property=
=20
> setter function, based on the expression containing `foo.bar`.

No, I'm not confusing them. Your "pure" way will either break ALL cases,
'auto' or not, or it will *SILENTLY HAVE WRONG BEHAVIOR*. The latter is
unacceptable. The former is tolerable, but unnecessary; my approach will
Just Work=E2=84=A2 with 'auto' (and, incidentally, is a great illustration =
of
one of the main benefits of AAA), and cannot cause a silent behavior change=
..

> So under those rules, `auto &x =3D foo.bar` will result in a reference to=
=20
> whatever the getter for foo.bar returns. If it returns a `float &`, then=
=20
> that's what will be stored. If it returns a `float` by value, then this=
=20
> will result in a reference to the temporary float.

(On what compiler? gcc 4.8.3 forbids conversion of an rvalue to a
reference. Thankfully. Because such a conversion is a recipe for disaster.)

> Let's see. Here's what pure property syntax might look like:
>=20
> struct T
> {
>   int getHealth() property(health) {return _health;}
>   void setHealth(int h) property(health) {_health =3D h;}
>=20
> private:
>   int _health;
> };

Hmm...

  int _get_health() property(health);
  int _set_health(int) property(health);
  int _set_health(health_t) property(health); // er...
  int _add_health(int) property(health); // uh oh
  int _remove_health(float percent) property(health); // oh dear...
  health_t _get_health_typed() property(health); // ...

How is that supposed to work? How does the compiler know what to call if
I want to handle '+=3D' or '*=3D' different from '=3D'?

Your suggested syntax looks like a recipe for making the compiler's life
near impossible w.r.t. choosing the right actual function based on how
the property is being used. Inline classes don't have that problem; they
use the same rules we've had since C++98.

> Even if we ignore the fact that you have to implement all those forms of=
=20
> equality assignment if you want users to be able to use it,

....which is handled by a mixin (as has been repeatedly stated). Which,
incidentally, could be useful to non-inline value type classes. (Boost
already has such a critter...)

> you've still caused confusion. The "getter" method isn't called
> "get".  Indeed, it doesn't even have a name; it's `operator int`, for
> some reason.

It's called by *what it does*; use a property as a value type. *And* I
can provide more than one conversion. How do you do that?

I don't know why you insist on claiming that features we've had since
C++98 are "confusing" and that using existing features to perform
exactly the tasks for which they exist is "without reason".

> That's not exactly something the neophyte C++ programmer will understand.=
=20
> People coming from languages with pure property support will expect=20
> something rather different in terms of syntax.

I seem to recall an objection to adding properties for the sake of
"dumbing down the language". You are insisting that we do exactly that?
And invent a totally new and different way to do things that we already
do, so that C++ programmers don't have to actually learn to use C++?

>> You don't need to overload *every* assignment operator, just the ones=20
>> you care about.
>=20
> If it's more than one, it's too many. You don't see other languages=20
> implementing properties that way. You implement one getter and one setter=
,=20
> period.

....and so you are hosed if you need to do something different for other
operators. Like, I don't know, *provide atomic operations*.

You are misrepresenting what I mean by "care" in the above. I mean
"handle specially", not "support". Other languages *don't support*
special handling of modifying assignments. Why should we (C++)
intentionally cripple ourselves in this manner?

> #1: I don't think properties belong in C++.
>=20
> #2: If properties are important enough to be taken into the standard, the=
n=20
> they should be important enough to be done correctly.
>=20
> Because of #1, I have no desire to provide a full proposal for a pure=20
> implementation of properties. Because of #2, I oppose your proposed=20
> solution because it's a hack designed to be the minimally offensive to th=
e=20
> committee, not a natural way to implement the feature.

You've made it *quite* clear that it isn't minimally offensive, thank
you. The point is to be minimally *invasive*, and *maximally useful*.
Reread the second half of that sentence a few times.

As for the first half, the objective is to conserve precious syntax,
reuse existing techniques (rather than inventing new ways to do the same
thing), and be easy for compilers to implement.

(Incidentally, it's interesting you call it a "hack". It *is* a hack...
in the pure sense, that is different from a "kludge". Hacks aren't
necessarily bad.)

>>>> Unless there is some other use for these inline classes, I'm against=
=20
>>>>> using them as a way to put properties into the language.=20
>>>>
>>>> Sort of related, but how about this?=20
>>>>
>>>>   auto c =3D get_color();=20
>>>>   c.hsl.hue =3D 15;=20
>>>>   cout << c.hcy.hue;=20
>>>
>>> Any form of properties could do that.=20
>>
>> Please *show* how you would implement this with something other than=20
>> inline classes. (The color class may store RGB triples. The properties=
=20
>> may not have their own storage, nor may you create temporary non-POD=20
>> objects.)=20
>=20
> Why are those solutions not allowed? Remember what properties are: a=20
> shorthand syntax for calling getters/setters. So `c.hsl.hue =3D ...`=20
> conceptually transforms to `c.hsl_get().hue_set(...);` And so forth.

It's not allowed because I said so: "The properties may not have their
own storage, nor may you create temporary non-POD objects". You failed
this criteria by returning a (non-zero-sized) proxy object from hsl_get().

> In order to implement this using function call syntax, I would return=20
> appropriate proxy objects, which are non-PODs that contain references to=
=20
> data.

Therefore you have incurred additional, and unnecessary, overhead.

> Your solution uses proxy objects too; it=20
> just so happens that your proxy objects are permanent fixtures of an=20
> object, rather than temporaries created on the stack.

....which means they have *zero overhead*. You can't provide that.

As I've tried - repeatedly - to explain, an inline class is a conceptual
downcast allowing the user to treat an object as a different type. In
the "property" case, the downcasted type is extremely limited... but it
doesn't have to be. In the above color example, the base color class
might have no (public) function except to provide inline class
interfaces (and trivial stuff like being copyable).

IOW, this:

  c.hsl.hue =3D ...;

....is conceptually:

  c.set_hue_hsl(...);

(And see also Edward's comment on the terminology.)

--=20
Matthew

--=20

---=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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.

On 2015-08-29 23:37, Nicol Bolas wrote:
> On Saturday, August 29, 2015 at 9:12:00 PM UTC-4, Edward Catmur wrote:
>> Not true; an inline class has no storage or identity of its own, so a
>> pointer to an inline class can have the same value as a pointer to the
>> parent object. Note that within an inline class method "this" refers to the
>> parent object.
>
> OK, now you're just Calvinballing: inventing arbitrary features every time
> someone comes along and explains why what you want doesn't work.

No, really, we aren't. This is the way the feature was *originally
suggested*. Go back and re-read my original post.

> Ignoring any potential strict aliasing minefields with this,

What would be the problem here? Inline classes are much more akin to
downcasting than aliasing. Last I knew, operating on an upcasted pointer
doesn't cause aliasing issues... why should inline classes?

> you're basically saying that you can't pass a property by reference to any
> function if the type of that argument is deduced.

Why not? How is it different from passing a concrete class type?

>> Also, there's no need to allow forming a reference or pointer to an inline
>> class at all; just as a member function access expression is required to be
>> subject to a function call operation, an inline class access expression
>> could be required to be subject to a conversion or operation.
>
> OK, so I can't get a pointer to it. I can't get a reference to it. It
> doesn't have a typename. It doesn't have a size.

You can (note that I elsewhere disagreed with this part of what Edward
wrote). It has a typename the same way an anonymous struct has a
typename, if not an actual typename. It has a size; the size is equal to
the size of the containing non-inline class.

> If "inline classes" are not objects, then they should not use the word
> "class" to declare/define them.

I think I already mentioned that I'm not wedded to the syntax. The main
benefit is that it uses existing keywords, and *I* don't find it as
confusing as you insist. I'd be okay using different (possibly new)
keywords if doing so doesn't cause worse problems. As Miro says, that's
something of a bikeshed. Attacking the suggestion on these grounds
verges on being a straw man attack.

> Let me guess. You want to have inline classes able to derive from some
> std::property library class. You want an anonymous class with no storage...
> to have a base class.

Base *inline* class, obviously. And it would need something like CRTP to
know how to actually do anything useful.

> That opens up an entire avenue of problems. The defining feature of inline
> classes is that their `this` pointer points to the owning object. This
> effectively means that they can't even call other methods on themselves.

Well... yeah...

Okay, since you made me think about it... obviously, an inline class
with no containing class still needs *some* 'this'. Equally obviously,
the type of said 'this' is undefined. If we permit casting it to the
real (derived) class type with reinterpret_cast, either directly or
through void*, it still seems to me like this would work. (And we know
the real class type thanks to CTRP.)

> If I allow adding health to clamp, and I want to allow directly setting
> health... why would I *not* want it to clamp too? It makes no sense to have
> adding health to clamp, yet setting health error out.

You can't know that. You are choosing an implementation that will impose
this limitation, whether or not it actually makes sense.

> Furthermore, I would say that it is *extremely rude* for x += y to have
> different behavior from x = x + y.

  auto __temporary1 = x.get();
  auto __temporary2 = __temporary1 + y;
  // God help you if the scheduler interrupts you here
  x.set(__temporary2);

- vs. -

  x.add(y); // acquires mutex internally

Seriously... why is this so hard to grasp?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-30 07:51, Miro Knejp wrote:
> Because [inline classes] can only exist as part of their containing class there is no need
> for a this pointer, or storage if they have no members.

They *can't* have members. If they did, they would need to also store a
pointer to either the parent class or the offset of their instance,
which sort of defeats the purpose. (At that point, just use a regular
class/struct.)

This *could* work if you forbid more than one instance of an inline
class, but I don't see the benefit being worth the restriction.

> Maybe translated to C++ the concept is more like a class-local
> namespace, but not quite.

Yes, that's another possible way of looking at them.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-30 12:49, Nicol Bolas wrote:
> The thing it most needs is justification is why we need such a feature. Can
> it do something more than give us property hack fixes?
>
> But would it be possible to decorate a class (using contextual keywords ala
> `final`) such that the class would be considered to be truly empty. And
> that such truly empty classes would not take up space in structs. If that
> is possible, it could have a multitude of uses.

Please give examples, and show how inline classes could not be used for
the same.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_520_68211926.1441043957858
Content-Type: multipart/alternative;
 boundary="----=_Part_521_1456701567.1441043957859"

------=_Part_521_1456701567.1441043957859
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 10:23:53 AM UTC-4, Edward Catmur wrote:
>
> On 31 Aug 2015 05:46, "Nicol Bolas" <jmck...@gmail.com <javascript:>>
> wrote:
> > I didn't say that solutions for properties needed to be aimed solely at
> that feature. But if you're going to add a feature and try to justify it by
> saying that it solves properties and other stuff too, you need to prove two
> things:
> >
> > 1) That it solves the property problem well.
> >
> > 2) That it solves other genuinely useful problems well.
> >
> > Thus far, #2 is not in evidence, and #1 is in dispute (since it's a
> leaky abstraction).
>
> Thanks, that's a fair challenge and would have to be addressed for a
> proposal to succeed. My answers would be:
>
> 1. This is a minimal proposal (relative to, say, operator dot); the
> abstraction leakage of a property access expression result would occur
> anyway (since I don't believe a pure syntax translation can succeed) and
> this proposal at least make it explicit.
>

operator. is not minimal because operator. isn't trying to make properties
happen. Operator. is more like the features of Python and Lua that allows
them to implement properties: features that have justifications for them
besides just making properties work.

Also, we have not yet established that inline classes are "minimal". At the
very least, you've already got to deal with empty members, as well as the
whole pointer/reference issue.

Those aren't "minimal" issues; they interact with some of the most basic
assumptions of the language.

2. There are other benefits to grouping and encapsulating class members;
> for example, in the implementation of service objects
>

Can you provide an example where it would be useful? Give us a use case.


> >> > Also, you have yet to show me one useful thing that inline classes
> can do that don't involve properties. Whereas duck typing is absurdly
> useful and frequently self-justifying. The same feature that makes
> properties work in Python makes about 10,000 other things work in Python.
> >>
> >> Which feature? Decorators or the descriptor protocol?
> >
> >
> > Both. Admittedly, I know next to nothing about Python; I copied that
> example from some site I found via Google. But if it works even remotely
> like Lua (and the way "properties" work in that language), then those
> mechanisms are general-purpose tools.
> >
> > Unlike inline classes.
>
> OK, I took a look at Lua. Lua doesn't have properties! It has a general
> mechanism for overriding member access, and a huge array of nonstandardized
> libraries for using that mechanism to hack in properties. Does that mean
> you would prefer operator dot?
>

I don't like operator. . However, between that and inline classes, I'd pick
operator. ten times over. It's a feature that has plenty of uses besides
properties. It solves a lot of problems. It's a general-purpose solution
which just so happens to make property implementations a bit easier.


> >> > What else can inline classes do besides properties?
> >> >
> >> >> > For example, while thinking about what has to happen to make your
> inline classes work, I realized something. Any class that contains an
> inline class cannot be trivially copyable. Why? Because inline classes must
> have an internal `this` pointer, which refers to the containing object. So
> you cannot simply do a memcpy on them; the pointer has to be updated to
> refer to the new object. And that requires the generation of a special copy
> constructor that uses the new `this` object.
> >> >>
> >> >> Not true; an inline class has no storage or identity of its own, so
> a pointer to an inline class can have the same value as a pointer to the
> parent object. Note that within an inline class method "this" refers to the
> parent object.
> >> >
> >> >
> >> > OK, now you're just Calvinballing: inventing arbitrary features every
> time someone comes along and explains why what you want doesn't work.
> >>
> >> I'm fairly sure that was in the original proposal.
> >>
> >> > And like with most Calvinballs, I don't think you thought that idea
> through. Ignoring any potential strict aliasing minefields with this,
> you're basically saying that you can't pass a property by reference to any
> function if the type of that argument is deduced.
> >>
> >> Why does that follow?
> >
> >
> > Because that's how C++ works.
> >
> > Presumably, an inline class member has a type. That type will be deduced
> by the type deduction system, even if its an anonymous type. Therefore, if
> a function takes a `const T&`, it will be deduced as a `const&` to the
> inline class type.
> >
> > If taking a reference to an inline class results instead in a reference
> to the owning class... then you haven't actually passed the property to the
> function. Somehow passing `a.prop` is equivalent to passing `a`.
>
> I didn't say that the references were the same, I said that they could
> have the same value. The types are still distinct.
>

References don't have values. Not unless you're talking about the
implementation of a reference, which is something the language doesn't know
or care about.

If you're saying that `&a.prop` should have the same value as `&a`, well,
that's an entirely different matter.

It's also *impossible* to implement (at least, as you have stated)*.* Why?
Consider this:

struct A
{
  inline struct
  {
    ...
    int val;
  } prop1, prop2;
};

A a;
auto &p1 = a.prop1;
auto &p2 = a.prop2;

If &p1 and &p2 are the same value, how can you have p1.val return a
different value from p2.val? How does the compiler know which specific
inline class object, of the same type, is being referenced? After all, the
references have the same "value".

You have exactly 3 options for resolving this problem:

1) Inline classes contain an implicit `this` pointer to their owner, thus
breaking trivial copyability.
2) You can't get ptrs/refs to inline class members at all.
3) Inline class members cannot have state.

Pick one.

> If taking a reference to an inline class results in a compiler error,
> then you can't pass it by reference to any template function. And since
> they're probably non-copyable, you can't pass them by value either.
> >
> >>
> >> And why would that be a bad thing?
> >
> >
> > Because that's what users would expect. Calling `template_func(foo.min)`
> ought to work. And if it doesn't, that would be very surprising for users.
> >
> >> If you want to pass by value, call the getter and pass the result;
> >
> >
> > Think about what you said for a minute. Your property implementation can
> run into a problem, and your solution for this problem... is to not use
> properties.
> >
> > Doesn't that tell you that your property implementation is broken? Isn't
> that what it means when you have to backdoor your own feature to make code
> work?
>
> The problem with passing `template_func(foo.min)` is that it's ambiguous;
> do you mean the current value, or foo.min as a getter, or as a setter, or
> both? This is a problem for any implementation of properties in C++.
>

In C#, it calls the getter. In Python, it calls the getter. In Lua, it
calls the getter.

Why should C++ behave *any differently* from the commonly accepted meaning
of this syntax? I would say that if the C++ implementation behaves
differently, then the C++ implementation is doing it wrong. People will
expect properties to work like they work in other languages.

Using syntactic transformation to implement them, it will work exactly as
expected. Using your leaky abstraction, it will not.

> From the spec:
> >
> > "Objects can contain other objects, called subobjects."
> >
> > Subobjects, by definition, are objects.
> >
> > But you are right that objects aren't the only things that have types.
>
> I'm confused then; how can empty base subobjects be objects?
>

Because they have storage. sizeof(EmptyClass) will not return 0.

The empty base optimization language allows implementations to decide that
empty base classes does not *increase* the storage requirements of the
derived class. That is, sizeof(DerivedClass) is not required to be larger
than sizeof(BaseClass). It can't be smaller, but it is not required to be
larger.


> >> > Can you not see how far you're reaching to force this implementation
> to actually implement properties? It's an object, but you can't get a
> pointer/reference to it. It's an object, but it doesn't take up actual
> space. It's a class, but it doesn't have its own `this` pointer. And so
> forth.
> >> >
> >> > You're giving inline classes about as many special-case rules as
> lambdas. And those are far more generally useful than inline classes.
> >> >
> >> > What functionality does inline classes provide that justifies this
> level of special-caseness? And if your only answer is "it lets us have
> properties"... well, no, that's not good enough.
> >>
> >> I don't see a collection of special cases; I see the logical
> corollaries of having named subobjects with access to the parent class
> >
> >
> > My claim is essentially that inline classes are not a feature so much as
> "whatever is needed to make library property implementations work." And
> therefore they're a hodge-podge of functionality. You claim that inline
> classes are their own feature, a whole and complete thought that is
> designed for a purpose that is independent from properties. One that just
> so happens to
> >
> > So let's examine the proposal. Oh wait, there isn't one. There are
> multiple people posting about it, each with their own idea of what it needs
> to have, and some of those ideas are contradictory. So let's just examine
> some of the things that have been said about it.
> >
> > If all you really wanted was "named subobjects with access to the parent
> class," why would it matter if inline classes are not trivially copyable?
> The standard has plenty of non-trivially-copyable classes. There is no
> fundamental problem with making inline classes non-trivially copyable.
> Indeed, this would not be the first language feature that a priori makes a
> class non-trivially copyable (virtual functions/bases, for example).
> >
> > Oh sure, everyone likes for their classes to be trivially copyable. But
> trivially copyable is a high bar to reach, and a whole lot of classes break
> it. Indeed, most standard library classes are not trivially copyable. And
> yet, you have people who want inline classes to be trivially copyable so
> bad that they've suggested that it should be impossible to get
> pointers/references to inline class members.
> >
> > That's a blatant hack, one that is not strictly necessary.
>
> Right, it isn't necessary, since there's no need for pointers/references
> to inline class members to interfere with trivial copyability.
>

Look back at the 3 options I presented you. Of them, option 1 (losing
trivial copyability) is the most natural outcome, just like virtual
functions break trivial copyability. Option 2 is very strange to most users
and will make some uses of the API non-functional. And option 3 *severely*
limits the use of inline classes.

Those sound rather like hacks to me.

>> > Furthermore, I would say that it is extremely rude for x += y to have
> different behavior from x = x + y. I think it's reasonable to forbid one or
> the other. But if you allow both, then both should result in the exact same
> thing. The former can be faster, but it should never be a different result.
> >> >
> >> > And I would point out that C# works this way too. So that would be
> expected by those users.
> >>
> >> That doesn't mean it's the right behavior. Python has different (and
> fairly weird) behavior. C++ should be informed by existing languages but it
> doesn't have to be the same.
> >
> >
> > Maybe so, but you haven't come up with a good justification for why `x =
> x + y` should ever have different results from `x += y`.
>
> Conceptually, modifications to a property occur respecting class
> invariants, while arithmetic on a property value occur in the underlying
> type so cannot consider invariants.
>

Welcome to missing the point. You're talking about properties; I'm talking
about *basic expression logic*. Users *expect* x += y to do the same thing
as x = x + y. Users know that the latter may be slower, but they should not
be different.

>> I'm starting to understand, I think. You want certain class member
> access expressions to be replaced by (possibly multiple) method calls in...
> what, an extra phase of translation? How on earth are you going to explain
> that to current C++ programmers?
> >
> >
> > The exact same way you explain that this:
> >
> > a += b
> >
> > becomes this:
> >
> > a.operator+=(b);
> >
> > The concept is functionally no different: something becomes a function
> call even though it doesn't look like one.
>
> But operator overloading works by overload resolution on the types of the
> operands;
>

The process of operator overloading *begins* by substituting the operator
expression with one or more function call forms. After that substitution,
the standard rules of function overloading take place.

That's syntactic transformation: one syntax (operator) becomes another
(function call). Properties are no different: one syntax (member access
expression) becomes another (function call).


> you've said that when a class member access expression results in a
> property access there isn't a result, so no resulting entity, so no type to
> perform overload resolution on. So no, the same explanation won't work.
>

Consider the expression `foo.bar`.

* If `bar` is a non-static data member, then the expression results in
accessing the non-static data member from `foo`.

* If `bar` is a static data member, then the expression results in
accessing the static data member from the class type of `foo`.

* If `bar` is a static member function, then the expression results in the
static member function from the class type of `foo`.

* If `bar` is a non-static member function, then the expression results in
the non-static member function from the class type of `foo`. The only valid
expression that this can be used in is `&` to get a member pointer.

All pure property syntax would add is one more condition:

* If `bar` is a property member of the class type of `foo`, then the
expression results in calling the assigned getter function.

>> Also, as just one objection of I'm sure many, what happens to a class
> member access expression with object type a template type parameter?
> >
> >
> > If you're asking the equivalent of what I asked about your system before
> (passing a property proxy object to a template argument), the result is
> quite simple. `template_func(a.prop)` does exactly what `a.prop` does when
> it is not used in an assignment expression: it is converted into a function
> call to the getter. So it becomes `template_func(a.getter())`.
>
> That's not what I'm asking; I'm asking what happens when `a` has a type
> dependent on a template parameter. You don't know whether `a.prop` is a
> data member or a property until the template is instantiated, so you can't
> perform the syntax transformation until after that stage of translation. So
> how do you avoid the class member access expression resulting in an entity
> of some kind
>

Template substitution already deals with this adequately. Expressions
involving template parameters cannot be resolved until the template is
substituted. Consider this template function:

template<typename T> auto plus(T a, T b) {return a + b;}

Will this use an overloaded operator+? Yes, but only if T has one. If T is
an `int`, it uses the default plus behavior, not an overloaded operator. If
you pass a T for which there is no default plus behavior or an overloaded
operator+, then you get a compile error.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, August 31, 2015 at 10:23:53 AM UTC-4, Edward Catmur wrote:<block=
quote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-le=
ft: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">
On 31 Aug 2015 05:46, &quot;Nicol Bolas&quot; &lt;<a href=3D"javascript:" t=
arget=3D"_blank" gdf-obfuscated-mailto=3D"2ovvNpThBwAJ" rel=3D"nofollow" on=
mousedown=3D"this.href=3D&#39;javascript:&#39;;return true;" onclick=3D"thi=
s.href=3D&#39;javascript:&#39;;return true;">jmck...@gmail.com</a>&gt; wrot=
e:<br>
&gt; I didn&#39;t say that solutions for properties needed to be aimed sole=
ly at that feature. But if you&#39;re going to add a feature and try to jus=
tify it by saying that it solves properties and other stuff too, you need t=
o prove two things:<br>
&gt;<br>
&gt; 1) That it solves the property problem well.<br>
&gt;<br>
&gt; 2) That it solves other genuinely useful problems well.<br>
&gt;<br>
&gt; Thus far, #2 is not in evidence, and #1 is in dispute (since it&#39;s =
a leaky abstraction).</p>
<p dir=3D"ltr">Thanks, that&#39;s a fair challenge and would have to be add=
ressed for a proposal to succeed. My answers would be:</p>
<p dir=3D"ltr">1. This is a minimal proposal (relative to, say, operator do=
t); the abstraction leakage of a property access expression result would oc=
cur anyway (since I don&#39;t believe a pure syntax translation can succeed=
) and this proposal at least make it explicit.<br></p></blockquote><div><br=
>operator. is not minimal because operator. isn&#39;t trying to make proper=
ties happen. Operator. is more like the features of Python and Lua that all=
ows them to implement properties: features that have justifications for the=
m besides just making properties work.<br><br>Also, we have not yet establi=
shed that inline classes are &quot;minimal&quot;. At the very least, you&#3=
9;ve already got to deal with empty members, as well as the whole pointer/r=
eference issue.<br><br>Those aren&#39;t &quot;minimal&quot; issues; they in=
teract with some of the most basic assumptions of the language.<br><br></di=
v><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">
2. There are other benefits to grouping and encapsulating class members; fo=
r example, in the implementation of service objects</p></blockquote><div><b=
r>Can you provide an example where it would be useful? Give us a use case.<=
br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D"ltr">=
 </p><p dir=3D"ltr">&gt;&gt; &gt; Also, you have yet to show me one useful =
thing that inline classes can do that don&#39;t involve properties. Whereas=
 duck typing is absurdly useful and frequently self-justifying. The same fe=
ature that makes properties work in Python makes about 10,000 other things =
work in Python.<br>
&gt;&gt;<br>
&gt;&gt; Which feature? Decorators or the descriptor protocol?<br>
&gt;<br>
&gt;<br>
&gt; Both. Admittedly, I know next to nothing about Python; I copied that e=
xample from some site I found via Google. But if it works even remotely lik=
e Lua (and the way &quot;properties&quot; work in that language), then thos=
e mechanisms are general-purpose tools.<br>
&gt;<br>
&gt; Unlike inline classes.</p>
<p dir=3D"ltr">OK, I took a look at Lua. Lua doesn&#39;t have properties! I=
t has a general mechanism for overriding member access, and a huge array of=
 nonstandardized libraries for using that mechanism to hack in properties. =
Does that mean you would prefer operator dot?</p></blockquote><div><br>I do=
n&#39;t like operator. . However, between that and inline classes, I&#39;d =
pick operator. ten times over. It&#39;s a feature that has plenty of uses b=
esides properties. It solves a lot of problems. It&#39;s a general-purpose =
solution which just so happens to make property implementations a bit easie=
r.<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;&gt; &gt; What else can inline classes do besides proper=
ties?<br>
&gt;&gt; &gt; =C2=A0<br>
&gt;&gt; &gt;&gt; &gt; For example, while thinking about what has to happen=
 to make your inline classes work, I realized something. Any class that con=
tains an inline class cannot be trivially copyable. Why? Because inline cla=
sses must have an internal `this` pointer, which refers to the containing o=
bject. So you cannot simply do a memcpy on them; the pointer has to be upda=
ted to refer to the new object. And that requires the generation of a speci=
al copy constructor that uses the new `this` object.<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Not true; an inline class has no storage or identity of i=
ts own, so a pointer to an inline class can have the same value as a pointe=
r to the parent object. Note that within an inline class method &quot;this&=
quot; refers to the parent object.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; OK, now you&#39;re just Calvinballing: inventing arbitrary fe=
atures every time someone comes along and explains why what you want doesn&=
#39;t work.<br>
&gt;&gt;<br>
&gt;&gt; I&#39;m fairly sure that was in the original proposal.<br>
&gt;&gt;<br>
&gt;&gt; &gt; And like with most Calvinballs, I don&#39;t think you thought=
 that idea through. Ignoring any potential strict aliasing minefields with =
this, you&#39;re basically saying that you can&#39;t pass a property by ref=
erence to any function if the type of that argument is deduced.<br>
&gt;&gt;<br>
&gt;&gt; Why does that follow?<br>
&gt;<br>
&gt;<br>
&gt; Because that&#39;s how C++ works.<br>
&gt;<br>
&gt; Presumably, an inline class member has a type. That type will be deduc=
ed by the type deduction system, even if its an anonymous type. Therefore, =
if a function takes a `const T&amp;`, it will be deduced as a `const&amp;` =
to the inline class type.<br>
&gt;<br>
&gt; If taking a reference to an inline class results instead in a referenc=
e to the owning class... then you haven&#39;t actually passed the property =
to the function. Somehow passing `a.prop` is equivalent to passing `a`.</p>
<p dir=3D"ltr">I didn&#39;t say that the references were the same, I said t=
hat they could have the same value. The types are still distinct. </p></blo=
ckquote><div><br>References don&#39;t have values. Not unless you&#39;re ta=
lking about the implementation of a reference, which is something the langu=
age doesn&#39;t know or care about.<br><br>If you&#39;re saying that `&amp;=
a.prop` should have the same value as `&amp;a`, well, that&#39;s an entirel=
y different matter.<br><br>It&#39;s also <i>impossible</i> to implement (at=
 least, as you have stated)<i>.</i> Why? Consider this:<br><br><div class=
=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-colo=
r: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: b=
reak-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span=
 style=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> A<br></span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">inline</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> val</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br>=C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> prop=
1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> prop2</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"><br><br>A a</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-prettify">p1=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">prop1</span><span style=3D"color:=
 #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br></span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&amp;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">p2 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify">prop2</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>If &amp=
;p1 and &amp;p2 are the same value, how can you have p1.val return a differ=
ent value from p2.val? How does the compiler know which specific inline cla=
ss object, of the same type, is being referenced? After all, the references=
 have the same &quot;value&quot;.<br><br>You have exactly 3 options for res=
olving this problem:<br><br>1) Inline classes contain an implicit `this` po=
inter to their owner, thus breaking trivial copyability.<br>2) You can&#39;=
t get ptrs/refs to inline class members at all.<br>3) Inline class members =
cannot have state.<br><br>Pick one.<br><br></div><blockquote class=3D"gmail=
_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;p=
adding-left: 1ex;">
<p dir=3D"ltr">&gt; If taking a reference to an inline class results in a c=
ompiler error, then you can&#39;t pass it by reference to any template func=
tion. And since they&#39;re probably non-copyable, you can&#39;t pass them =
by value either.<br>
&gt; =C2=A0<br>
&gt;&gt;<br>
&gt;&gt; And why would that be a bad thing?<br>
&gt;<br>
&gt;<br>
&gt; Because that&#39;s what users would expect. Calling `template_func(foo=
..min)` ought to work. And if it doesn&#39;t, that would be very surprising =
for users.<br>
&gt;<br>
&gt;&gt; If you want to pass by value, call the getter and pass the result;=
<br>
&gt;<br>
&gt;<br>
&gt; Think about what you said for a minute. Your property implementation c=
an run into a problem, and your solution for this problem... is to not use =
properties.<br>
&gt;<br>
&gt; Doesn&#39;t that tell you that your property implementation is broken?=
 Isn&#39;t that what it means when you have to backdoor your own feature to=
 make code work?</p>
<p dir=3D"ltr">The problem with passing `template_func(foo.min)` is that it=
&#39;s ambiguous; do you mean the current value, or foo.min as a getter, or=
 as a setter, or both? This is a problem for any implementation of properti=
es in C++.</p></blockquote><div><br>In C#, it calls the getter. In Python, =
it calls the getter. In Lua, it calls the getter.<br><br>Why should C++ beh=
ave <i>any differently</i> from the commonly accepted meaning of this synta=
x? I would say that if the C++ implementation behaves differently, then the=
 C++ implementation is doing it wrong. People will expect properties to wor=
k like they work in other languages.<br><br>Using syntactic transformation =
to implement them, it will work exactly as expected. Using your leaky abstr=
action, it will not.<br><br></div><blockquote class=3D"gmail_quote" style=
=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: =
1ex;"><p dir=3D"ltr">&gt; From the spec:<br>
&gt;<br>
&gt; &quot;Objects can contain other objects, called subobjects.&quot;<br>
&gt;<br>
&gt; Subobjects, by definition, are objects.<br>
&gt;<br>
&gt; But you are right that objects aren&#39;t the only things that have ty=
pes.</p>
<p dir=3D"ltr">I&#39;m confused then; how can empty base subobjects be obje=
cts?</p></blockquote><div><br>Because they have storage. sizeof(EmptyClass)=
 will not return 0.<br><br>The empty base optimization language allows impl=
ementations to decide that empty base classes does not <i>increase</i> the =
storage requirements of the derived class. That is, sizeof(DerivedClass) is=
 not required to be larger than sizeof(BaseClass). It can&#39;t be smaller,=
 but it is not required to be larger.<br>=C2=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc sol=
id;padding-left: 1ex;"><p dir=3D"ltr"> </p><p dir=3D"ltr">&gt;&gt; &gt; Can=
 you not see how far you&#39;re reaching to force this implementation to ac=
tually implement properties? It&#39;s an object, but you can&#39;t get a po=
inter/reference to it. It&#39;s an object, but it doesn&#39;t take up actua=
l space. It&#39;s a class, but it doesn&#39;t have its own `this` pointer. =
And so forth.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; You&#39;re giving inline classes about as many special-case r=
ules as lambdas. And those are far more generally useful than inline classe=
s.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; What functionality does inline classes provide that justifies=
 this level of special-caseness? And if your only answer is &quot;it lets u=
s have properties&quot;... well, no, that&#39;s not good enough.<br>
&gt;&gt;<br>
&gt;&gt; I don&#39;t see a collection of special cases; I see the logical c=
orollaries of having named subobjects with access to the parent class<br>
&gt;<br>
&gt;<br>
&gt; My claim is essentially that inline classes are not a feature so much =
as &quot;whatever is needed to make library property implementations work.&=
quot; And therefore they&#39;re a hodge-podge of functionality. You claim t=
hat inline classes are their own feature, a whole and complete thought that=
 is designed for a purpose that is independent from properties. One that ju=
st so happens to <br>
&gt;<br>
&gt; So let&#39;s examine the proposal. Oh wait, there isn&#39;t one. There=
 are multiple people posting about it, each with their own idea of what it =
needs to have, and some of those ideas are contradictory. So let&#39;s just=
 examine some of the things that have been said about it.<br>
&gt;<br>
&gt; If all you really wanted was &quot;named subobjects with access to the=
 parent class,&quot; why would it matter if inline classes are not triviall=
y copyable? The standard has plenty of non-trivially-copyable classes. Ther=
e is no fundamental problem with making inline classes non-trivially copyab=
le. Indeed, this would not be the first language feature that a priori make=
s a class non-trivially copyable (virtual functions/bases, for example).<br=
>
&gt;<br>
&gt; Oh sure, everyone likes for their classes to be trivially copyable. Bu=
t trivially copyable is a high bar to reach, and a whole lot of classes bre=
ak it. Indeed, most standard library classes are not trivially copyable. An=
d yet, you have people who want inline classes to be trivially copyable so =
bad that they&#39;ve suggested that it should be impossible to get pointers=
/references to inline class members.<br>
&gt;<br>
&gt; That&#39;s a blatant hack, one that is not strictly necessary.</p>
<p dir=3D"ltr">Right, it isn&#39;t necessary, since there&#39;s no need for=
 pointers/references to inline class members to interfere with trivial copy=
ability.</p></blockquote><div><br>Look back at the 3 options I presented yo=
u. Of them, option 1 (losing trivial copyability) is the most natural outco=
me, just like virtual functions break trivial copyability. Option 2 is very=
 strange to most users and will make some uses of the API non-functional. A=
nd option 3 <i>severely</i> limits the use of inline classes.<br><br>Those =
sound rather like hacks to me.<br><br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;paddin=
g-left: 1ex;"><p dir=3D"ltr">&gt;&gt; &gt; Furthermore, I would say that it=
 is extremely rude for x +=3D y to have different behavior from x =3D x + y=
.. I think it&#39;s reasonable to forbid one or the other. But if you allow =
both, then both should result in the exact same thing. The former can be fa=
ster, but it should never be a different result.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; And I would point out that C# works this way too. So that wou=
ld be expected by those users.<br>
&gt;&gt;<br>
&gt;&gt; That doesn&#39;t mean it&#39;s the right behavior. Python has diff=
erent (and fairly weird) behavior. C++ should be informed by existing langu=
ages but it doesn&#39;t have to be the same.<br>
&gt;<br>
&gt;<br>
&gt; Maybe so, but you haven&#39;t come up with a good justification for wh=
y `x =3D x + y` should ever have different results from `x +=3D y`.</p>
<p dir=3D"ltr">Conceptually, modifications to a property occur respecting c=
lass invariants, while arithmetic on a property value occur in the underlyi=
ng type so cannot consider invariants.</p></blockquote><div><br>Welcome to =
missing the point. You&#39;re talking about properties; I&#39;m talking abo=
ut <i>basic expression logic</i>. Users <i>expect</i> x +=3D y to do the sa=
me thing as x =3D x + y. Users know that the latter may be slower, but they=
 should not be different.<br><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><p dir=3D"ltr"> </p>
<p dir=3D"ltr">&gt;&gt; I&#39;m starting to understand, I think. You want c=
ertain class member access expressions to be replaced by (possibly multiple=
) method calls in... what, an extra phase of translation? How on earth are =
you going to explain that to current C++ programmers?<br>
&gt;<br>
&gt;<br>
&gt; The exact same way you explain that this:<br>
&gt;<br>
&gt; a +=3D b<br>
&gt;<br>
&gt; becomes this:<br>
&gt;<br>
&gt; a.operator+=3D(b);<br>
&gt;<br>
&gt; The concept is functionally no different: something becomes a function=
 call even though it doesn&#39;t look like one.</p>
<p dir=3D"ltr">But operator overloading works by overload resolution on the=
 types of the operands;</p></blockquote><div><br>The process of operator ov=
erloading <i>begins</i> by substituting the operator expression with one or=
 more function call forms. After that substitution, the standard rules of f=
unction overloading take place.<br><br>That&#39;s syntactic transformation:=
 one syntax (operator) becomes another (function call). Properties are no d=
ifferent: one syntax (member access expression) becomes another (function c=
all).<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><p dir=3D=
"ltr"> you&#39;ve said that when a class member access expression results i=
n a property access there isn&#39;t a result, so no resulting entity, so no=
 type to perform overload resolution on. So no, the same explanation won&#3=
9;t work. </p></blockquote><div><br>Consider the expression `foo.bar`.<br><=
br>* If `bar` is a non-static data member, then the expression results in a=
ccessing the non-static data member from `foo`.<br><br>* If `bar` is a stat=
ic data member, then the expression results in accessing the static data me=
mber from the class type of `foo`.<br><br>* If `bar` is a static member fun=
ction, then the expression results in the static member function from the c=
lass type of `foo`.<br><br>* If `bar` is a non-static member function, then=
 the expression results in the non-static member function from the class
 type of `foo`. The only valid expression that this can be used in is `&amp=
;` to get a member pointer.<br><br>All pure property syntax would add is on=
e more condition:<br><br>* If `bar` is a property member of the class type =
of `foo`, then the expression results in  calling the assigned getter funct=
ion.<br><br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<p dir=3D"ltr">&gt;&gt; Also, as just one objection of I&#39;m sure many, w=
hat happens to a class member access expression with object type a template=
 type parameter?<br>
&gt;<br>
&gt;<br>
&gt; If you&#39;re asking the equivalent of what I asked about your system =
before (passing a property proxy object to a template argument), the result=
 is quite simple. `template_func(a.prop)` does exactly what `a.prop` does w=
hen it is not used in an assignment expression: it is converted into a func=
tion call to the getter. So it becomes `template_func(a.getter())`.</p>
<p dir=3D"ltr">That&#39;s not what I&#39;m asking; I&#39;m asking what happ=
ens when `a` has a type dependent on a template parameter. You don&#39;t kn=
ow whether `a.prop` is a data member or a property until the template is in=
stantiated, so you can&#39;t perform the syntax transformation until after =
that stage of translation. So how do you avoid the class member access expr=
ession resulting in an entity of some kind</p></blockquote><div><br>Templat=
e substitution already deals with this adequately. Expressions=20
involving template parameters cannot be resolved until the template is=20
substituted. Consider this template function:<br><br><div class=3D"prettypr=
int" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, =
187, 187); border-style: solid; border-width: 1px; word-wrap: break-word;">=
<code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">template</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> plus</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">T a</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> T b</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> a </span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">+</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> b</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">;}</span></di=
v></code></div><br>Will this use an overloaded operator+? Yes, but only if =
T has one. If T is an `int`, it uses the default plus behavior, not an over=
loaded operator. If you pass a T for which there is no default plus behavio=
r or an overloaded operator+, then you get a compile error.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_521_1456701567.1441043957859--
------=_Part_520_68211926.1441043957858--

.

------=_Part_3524_998062181.1441044223069
Content-Type: multipart/alternative;
 boundary="----=_Part_3525_2068532072.1441044223069"

------=_Part_3525_2068532072.1441044223069
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-30 12:49, Nicol Bolas wrote:
> > The thing it most needs is justification is why we need such a feature.
> Can
> > it do something more than give us property hack fixes?
> >
> > But would it be possible to decorate a class (using contextual keywords
> ala
> > `final`) such that the class would be considered to be truly empty. And
> > that such truly empty classes would not take up space in structs. If
> that
> > is possible, it could have a multitude of uses.
>
> Please give examples, and show how inline classes could not be used for
> the same.
>

struct EmptyNotInAClass empty
{
};

class NeedsEmpty
{
  EmptyNotInAClass a;
};

class AlsoNeedsEmpty
{
  EmptyNotInAClass b;
};

There are innumerable reasons for not defining one class inside another.
Maybe the two are not associated with one another, outside of having a
member in common. Who knows.

Considering how often people have wanted empty members to take up no space
in a type, it seems clear that it's a desired feature. One that has nothing
specifically to do with *where* the class is declared. Or where the empty
class's `this` pointer points.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-08-30 12:49, Nicol Bolas wr=
ote:
<br>&gt; The thing it most needs is justification is why we need such a fea=
ture. Can=20
<br>&gt; it do something more than give us property hack fixes?
<br>&gt;=20
<br>&gt; But would it be possible to decorate a class (using contextual key=
words ala=20
<br>&gt; `final`) such that the class would be considered to be truly empty=
.. And=20
<br>&gt; that such truly empty classes would not take up space in structs. =
If that=20
<br>&gt; is possible, it could have a multitude of uses.
<br>
<br>Please give examples, and show how inline classes could not be used for
<br>the same.<br></blockquote><div><br><div class=3D"prettyprint" style=3D"=
background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); bor=
der-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D=
"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">EmptyNotInAClass</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> empty<br></span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r><br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">clas=
s</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><=
span style=3D"color: #606;" class=3D"styled-by-prettify">NeedsEmpty</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">EmptyNotInAClass</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> a</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">class</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">AlsoNeedsEmpty</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"><br></span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">EmptyN=
otInAClass</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 b</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">};</span></div></code><=
/div><br>There are innumerable reasons for not defining one class inside an=
other. Maybe the two are not associated with one another, outside of having=
 a member in common. Who knows.<br><br>Considering how often people have wa=
nted empty members to take up no space in a type, it seems clear that it&#3=
9;s a desired feature. One that has nothing specifically to do with <i>wher=
e</i> the class is declared. Or where the empty class&#39;s `this` pointer =
points.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3525_2068532072.1441044223069--
------=_Part_3524_998062181.1441044223069--

.

On 2015-08-31 00:46, Nicol Bolas wrote:
> Presumably, an inline class member has a type. That type will be deduced by
> the type deduction system, even if its an anonymous type. Therefore, if a
> function takes a `const T&`, it will be deduced as a `const&` to the inline
> class type.

Right.

> If taking a reference to an inline class results instead in a reference to
> the owning class... then you haven't actually passed the property to the
> function. Somehow passing `a.prop` is equivalent to passing `a`.

Er... at the machine level, yes; the same memory address is passed in
either case. At the conceptual level, no; the first has type A::Prop,
the second has type A.

> So let's look at what you have to do to declare a property with this syntax:
>
> inline struct Irrelevant : public std::property<Irrelevant>
> {
>   Type get() const {...}
>   Type &set(const Type &t) {...}
> } property_name;
>
> There are 6 words in the first line; only one of them (property) actually
> means something to the user. The rest are noise. "Irrelevant" is
> particularly problematic, since you must provide a typename so that you can
> pass it to the property template.

So... my *original point* was that if we have properties, they ought to
look like:

  <stuff>
  {
    Type <get>();
    auto& <set>(Type);
    // possibly other operator overloads
  } [<name>]; // name could go with <stuff> at top

Using the above for <stuff> results in the least conceptual change to
the language. I'm not opposed to having ways to shorten it, as long as
it doesn't sacrifice the flexibility of being able to overload operators
individually on an as-needed basis.

(Besides, there's always PP macros to shorten things ;-).)

> So let's examine the proposal. Oh wait, there isn't one. There are multiple
> people posting about it, each with their own idea of what it needs to have,
> and some of those ideas are contradictory.

You don't exactly provide good motivation to work on producing a formal
proposal. And isn't that the point of this list; to discuss things prior
to making the effort to write them up formally?

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-08-31 13:59, Nicol Bolas wrote:
> On Monday, August 31, 2015 at 10:23:53 AM UTC-4, Edward Catmur wrote:
>> 2. There are other benefits to grouping and encapsulating class members;
>> for example, in the implementation of service objects
>
> Can you provide an example where it would be useful? Give us a use case.

I'm not sure what Edward means by "service object", but it sounds
suspiciously similar to the Color example I gave.

> If you're saying that `&a.prop` should have the same value as `&a`, well,
> that's an entirely different matter.

Add a static_cast<void*>, and sure, I'll say that. The types are
otherwise still different.

> It's also *impossible* to implement (at least, as you have stated)*.* Why?
> Consider this:
>
> struct A
> {
>   inline struct
>   {
>     ...
>     int val;
>   } prop1, prop2;
> };

I have, and...

> You have exactly 3 options for resolving this problem:
>
> 1) Inline classes contain an implicit `this` pointer to their owner, thus
> breaking trivial copyability.
> 2) You can't get ptrs/refs to inline class members at all.
> 3) Inline class members cannot have state.

....have previously stated a preference for #3.

>> The problem with passing `template_func(foo.min)` is that it's ambiguous;
>> do you mean the current value, or foo.min as a getter, or as a setter, or
>> both? This is a problem for any implementation of properties in C++.
>
> Why should C++ behave *any differently* from the commonly accepted meaning
> of this syntax? I would say that if the C++ implementation behaves
> differently, then the C++ implementation is doing it wrong. People will
> expect properties to work like they work in other languages.
>
> Using syntactic transformation to implement them, it will work exactly as
> expected. Using your leaky abstraction, it will not.

So how does one obtain a reference to a property, i.e. some "handle"
that can be passed to a function that needs to modify the property?
Remember, calling the property set is *mandatory*; you can't pass a
reference to the object's internal storage.

By your suggestion, the compiler would have to dynamically construct
some sort of proxy object when you take the address of a property. And
you could never pass a property by reference, only by pointer.

> In Python, it calls the getter.

....and in Python, you do the above like 'func(foo, "min")', because
Python doesn't differentiate between symbols named at compile time and
symbols named at run time (duck punching).

> Consider the expression `foo.bar`.
>
> * If `bar` is a non-static data member, then the expression results in
> accessing the non-static data member from `foo`.
>
> * If `bar` is a static data member, then the expression results in
> accessing the static data member from the class type of `foo`.
>
> * If `bar` is a static member function, then the expression results in the
> static member function from the class type of `foo`.
>
> * If `bar` is a non-static member function, then the expression results in
> the non-static member function from the class type of `foo`. The only valid
> expression that this can be used in is `&` to get a member pointer.
>
> All pure property syntax would add is one more condition:
>
> * If `bar` is a property member of the class type of `foo`, then the
> expression results in calling the assigned getter function.

....unless followed by an assignment operation. (BTW, I've heard compiler
writers *hate* anything that requires look-ahead.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

--001a1141cf783c7ca9051e9f8cc3
Content-Type: text/plain; charset=UTF-8

Hey Everyone,

I'd like to say that I'm surprised at the level of venom that this topic
seems to be generating.  I've found the discussion extremely interesting
and informative. I don't have (nor claim to have) the level of expertise to
contribute when it comes to the deep technical specification, and I don't
know the corner cases.  But I'm a decent proxy of a "representative user",
and this discussion has been incredibly informative.  I would not have
understood the problems with a std::property<> approach before reading this
discussion, and many of the points being brought up recently have been
informative.

Why, then, does this topic seem to generate so much anger? No-one is being
hasty, or recklessly producing distraction.

I would love this topic to continue, so I can continue to learn from it. I
hope that this can continue to happen in a civil and enthusiastic manner.

Chris

On Mon, Aug 31, 2015 at 11:09 AM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-08-31 00:46, Nicol Bolas wrote:
> > Presumably, an inline class member has a type. That type will be deduced
> by
> > the type deduction system, even if its an anonymous type. Therefore, if a
> > function takes a `const T&`, it will be deduced as a `const&` to the
> inline
> > class type.
>
> Right.
>
> > If taking a reference to an inline class results instead in a reference
> to
> > the owning class... then you haven't actually passed the property to the
> > function. Somehow passing `a.prop` is equivalent to passing `a`.
>
> Er... at the machine level, yes; the same memory address is passed in
> either case. At the conceptual level, no; the first has type A::Prop,
> the second has type A.
>
> > So let's look at what you have to do to declare a property with this
> syntax:
> >
> > inline struct Irrelevant : public std::property<Irrelevant>
> > {
> >   Type get() const {...}
> >   Type &set(const Type &t) {...}
> > } property_name;
> >
> > There are 6 words in the first line; only one of them (property) actually
> > means something to the user. The rest are noise. "Irrelevant" is
> > particularly problematic, since you must provide a typename so that you
> can
> > pass it to the property template.
>
> So... my *original point* was that if we have properties, they ought to
> look like:
>
>   <stuff>
>   {
>     Type <get>();
>     auto& <set>(Type);
>     // possibly other operator overloads
>   } [<name>]; // name could go with <stuff> at top
>
> Using the above for <stuff> results in the least conceptual change to
> the language. I'm not opposed to having ways to shorten it, as long as
> it doesn't sacrifice the flexibility of being able to overload operators
> individually on an as-needed basis.
>
> (Besides, there's always PP macros to shorten things ;-).)
>
> > So let's examine the proposal. Oh wait, there isn't one. There are
> multiple
> > people posting about it, each with their own idea of what it needs to
> have,
> > and some of those ideas are contradictory.
>
> You don't exactly provide good motivation to work on producing a formal
> proposal. And isn't that the point of this list; to discuss things prior
> to making the effort to write them up formally?
>
> --
> Matthew
>
> --
>
> ---
> 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.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1141cf783c7ca9051e9f8cc3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hey Everyone,</div><div><br></div>I&#39;d like to say=
 that I&#39;m surprised at the level of venom that this topic seems to be g=
enerating.=C2=A0 I&#39;ve found the discussion extremely interesting and in=
formative. I don&#39;t have (nor claim to have) the level of expertise to c=
ontribute when it comes to the deep technical specification, and I don&#39;=
t know the corner cases.=C2=A0 But I&#39;m a decent proxy of a &quot;repres=
entative user&quot;, and this discussion has been incredibly informative.=
=C2=A0 I would not have understood the problems with a std::property&lt;&gt=
; approach before reading this discussion, and many of the points being bro=
ught up recently have been informative.<div><br></div><div>Why, then, does =
this topic seem to generate so much anger? No-one is being hasty, or reckle=
ssly producing distraction.</div><div><br></div><div>I would love this topi=
c to continue, so I can continue to learn from it. I hope that this can con=
tinue to happen in a civil and enthusiastic manner.</div><div><br></div><di=
v>Chris</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote=
">On Mon, Aug 31, 2015 at 11:09 AM, Matthew Woehlke <span dir=3D"ltr">&lt;<=
a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss=
@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span cl=
ass=3D"">On 2015-08-31 00:46, Nicol Bolas wrote:<br>
&gt; Presumably, an inline class member has a type. That type will be deduc=
ed by<br>
&gt; the type deduction system, even if its an anonymous type. Therefore, i=
f a<br>
&gt; function takes a `const T&amp;`, it will be deduced as a `const&amp;` =
to the inline<br>
&gt; class type.<br>
<br>
</span>Right.<br>
<span class=3D""><br>
&gt; If taking a reference to an inline class results instead in a referenc=
e to<br>
&gt; the owning class... then you haven&#39;t actually passed the property =
to the<br>
&gt; function. Somehow passing `a.prop` is equivalent to passing `a`.<br>
<br>
</span>Er... at the machine level, yes; the same memory address is passed i=
n<br>
either case. At the conceptual level, no; the first has type A::Prop,<br>
the second has type A.<br>
<span class=3D""><br>
&gt; So let&#39;s look at what you have to do to declare a property with th=
is syntax:<br>
&gt;<br>
&gt; inline struct Irrelevant : public std::property&lt;Irrelevant&gt;<br>
&gt; {<br>
&gt;=C2=A0 =C2=A0Type get() const {...}<br>
&gt;=C2=A0 =C2=A0Type &amp;set(const Type &amp;t) {...}<br>
&gt; } property_name;<br>
&gt;<br>
&gt; There are 6 words in the first line; only one of them (property) actua=
lly<br>
&gt; means something to the user. The rest are noise. &quot;Irrelevant&quot=
; is<br>
&gt; particularly problematic, since you must provide a typename so that yo=
u can<br>
&gt; pass it to the property template.<br>
<br>
</span>So... my *original point* was that if we have properties, they ought=
 to<br>
look like:<br>
<br>
=C2=A0 &lt;stuff&gt;<br>
=C2=A0 {<br>
=C2=A0 =C2=A0 Type &lt;get&gt;();<br>
=C2=A0 =C2=A0 auto&amp; &lt;set&gt;(Type);<br>
=C2=A0 =C2=A0 // possibly other operator overloads<br>
=C2=A0 } [&lt;name&gt;]; // name could go with &lt;stuff&gt; at top<br>
<br>
Using the above for &lt;stuff&gt; results in the least conceptual change to=
<br>
the language. I&#39;m not opposed to having ways to shorten it, as long as<=
br>
it doesn&#39;t sacrifice the flexibility of being able to overload operator=
s<br>
individually on an as-needed basis.<br>
<br>
(Besides, there&#39;s always PP macros to shorten things ;-).)<br>
<span class=3D""><br>
&gt; So let&#39;s examine the proposal. Oh wait, there isn&#39;t one. There=
 are multiple<br>
&gt; people posting about it, each with their own idea of what it needs to =
have,<br>
&gt; and some of those ideas are contradictory.<br>
<br>
</span>You don&#39;t exactly provide good motivation to work on producing a=
 formal<br>
proposal. And isn&#39;t that the point of this list; to discuss things prio=
r<br>
to making the effort to write them up formally?<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
Matthew<br>
</font></span><div class=3D"HOEnZb"><div class=3D"h5"><br>
--<br>
<br>
---<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%2Bunsubscribe@isocpp.org">std-propo=
sals+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>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" rel=3D"noreferrer" target=3D"_blank">http://groups.google.c=
om/a/isocpp.org/group/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1141cf783c7ca9051e9f8cc3--

.

On 2015-08-31 14:03, Nicol Bolas wrote:
> On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
>> Please give examples, and show how inline classes could not be used for
>> the same.
>
> struct EmptyNotInAClass empty
> {
> };
>
> class NeedsEmpty
> {
>   EmptyNotInAClass a;
> };
>
> class AlsoNeedsEmpty
> {
>   EmptyNotInAClass b;
> };

....but what can you *do* with EmptyNotInAClass? It doesn't have storage,
or it wouldn't be empty. As a result, it can't meaningfully use it's 'this'.

I don't see why this can't be done making EmptyNotInAClass an inline
struct. (The resulting members would continue to be unable to
meaningfully use 'this', but that's the case anyway...)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_849_642699624.1441049272715
Content-Type: multipart/alternative;
 boundary="----=_Part_850_1761969274.1441049272716"

------=_Part_850_1761969274.1441049272716
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-31 14:03, Nicol Bolas wrote:
> > On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
> >> Please give examples, and show how inline classes could not be used for
> >> the same.
> >
> > struct EmptyNotInAClass empty
> > {
> > };
> >
> > class NeedsEmpty
> > {
> >   EmptyNotInAClass a;
> > };
> >
> > class AlsoNeedsEmpty
> > {
> >   EmptyNotInAClass b;
> > };
>
> ...but what can you *do* with EmptyNotInAClass? It doesn't have storage,
> or it wouldn't be empty. As a result, it can't meaningfully use it's
> 'this'.
>

It most certainly can meaningfully use `this`. It can call other member
functions of itself, base class members of itself, and *empty* data members
of itself.


> I don't see why this can't be done making EmptyNotInAClass an inline
> struct. (The resulting members would continue to be unable to
> meaningfully use 'this', but that's the case anyway...)
>

You can't do this:

template<typename T> struct Foo
{
  T t;
  OtherMember b;
};

And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens to be
empty. This would be useful for implementations of tuples (including
optional/expected), variants, or many other things.

This way, you don't have to jump through a bunch of hoops to implement
empty optimizations.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2015-08-31 14:0=
3, Nicol Bolas wrote:
<br>&gt; On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wr=
ote:
<br>&gt;&gt; Please give examples, and show how inline classes could not be=
 used for=20
<br>&gt;&gt; the same.
<br>&gt;=20
<br>&gt; struct EmptyNotInAClass empty
<br>&gt; {
<br>&gt; };
<br>&gt;
<br>&gt; class NeedsEmpty
<br>&gt; {
<br>&gt; =C2=A0 EmptyNotInAClass a;
<br>&gt; };
<br>&gt;=20
<br>&gt; class AlsoNeedsEmpty
<br>&gt; {
<br>&gt; =C2=A0 EmptyNotInAClass b;
<br>&gt; };
<br>
<br>...but what can you *do* with EmptyNotInAClass? It doesn&#39;t have sto=
rage,
<br>or it wouldn&#39;t be empty. As a result, it can&#39;t meaningfully use=
 it&#39;s &#39;this&#39;.<br></blockquote><div><br>It most certainly can me=
aningfully use `this`. It can call other member functions of itself, base c=
lass members of itself, and <i>empty</i> data members of itself.<br>=C2=A0<=
/div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;">I don&#39;t see why this =
can&#39;t be done making EmptyNotInAClass an inline
<br>struct. (The resulting members would continue to be unable to
<br>meaningfully use &#39;this&#39;, but that&#39;s the case anyway...)
<br></blockquote><div><br>You can&#39;t do this:<br><br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">template</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"color: =
#008;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Fo=
o</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 T t</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 </span><span styl=
e=3D"color: #606;" class=3D"styled-by-prettify">OtherMember</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> b</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">};</span></div></code></div><br>And allow `sizeof=
(Foo)` to be `sizeof(OtherMember)` if `T` happens to be empty. This would b=
e useful for implementations of tuples (including optional/expected), varia=
nts, or many other things.<br><br>This way, you don&#39;t have to jump thro=
ugh a bunch of hoops to implement empty optimizations.<br></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_850_1761969274.1441049272716--
------=_Part_849_642699624.1441049272715--

.

--001a1130c8c62993c3051ea09aca
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 31, 2015 at 7:22 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> On 2015-08-31 13:59, Nicol Bolas wrote:
> > On Monday, August 31, 2015 at 10:23:53 AM UTC-4, Edward Catmur wrote:
> >> 2. There are other benefits to grouping and encapsulating class members;
> >> for example, in the implementation of service objects
> >
> > Can you provide an example where it would be useful? Give us a use case.
>
> I'm not sure what Edward means by "service object", but it sounds
> suspiciously similar to the Color example I gave.


It's more about implementing server programs (web services, etc.); a
typical pattern is to create one instance per client of a service class;
the service object owns the socket connection to the client and has
non-owning pointers to resources. Requests from the client invoke methods
on the service object. The problem is that large services (necessary for
business reasons) result in service objects with large numbers of methods;
moving each method and its supporting logic into an inline class could
combat this without introducing overhead in dispatching requests and
accessing resources.


> > You have exactly 3 options for resolving this problem:
> >
> > 1) Inline classes contain an implicit `this` pointer to their owner, thus
> > breaking trivial copyability.
> > 2) You can't get ptrs/refs to inline class members at all.
> > 3) Inline class members cannot have state.
>
> ...have previously stated a preference for #3.


Two more options:
4) Inline class members must have distinct types.
5) Inline classes contain an implicit offset to their owner, that can be
subtracted from a `this` pointer.

I quite like #4; it's a reasonable restriction as it applies already to
direct base classes.


> >> The problem with passing `template_func(foo.min)` is that it's
> ambiguous;
> >> do you mean the current value, or foo.min as a getter, or as a setter,
> or
> >> both? This is a problem for any implementation of properties in C++.
> >
> > Why should C++ behave *any differently* from the commonly accepted
> meaning
> > of this syntax? I would say that if the C++ implementation behaves
> > differently, then the C++ implementation is doing it wrong. People will
> > expect properties to work like they work in other languages.
> >
> > Using syntactic transformation to implement them, it will work exactly as
> > expected. Using your leaky abstraction, it will not.
>
> So how does one obtain a reference to a property, i.e. some "handle"
> that can be passed to a function that needs to modify the property?
> Remember, calling the property set is *mandatory*; you can't pass a
> reference to the object's internal storage.
>

And these other languages don't have references; it's totally alien to a
Python programmer that assigning to a function argument could have effects
outside that function, but that's totally accepted behavior in C++ (if
deprecated by some style guides that prefer pointers for modifiable
parameters). I'm not familiar with Lua; I dimly recollect that C# has
syntax for reference parameters, but can those be deduced?

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--001a1130c8c62993c3051ea09aca
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Aug 31, 2015 at 7:22 PM, Matthew Woehlke <span dir=
=3D"ltr">&lt;<a href=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">=
mwoehlke.floss@gmail.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra=
"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"=
">On 2015-08-31 13:59, Nicol Bolas wrote:<br>
&gt; On Monday, August 31, 2015 at 10:23:53 AM UTC-4, Edward Catmur wrote:<=
br>
</span><span class=3D"">&gt;&gt; 2. There are other benefits to grouping an=
d encapsulating class members;<br>
&gt;&gt; for example, in the implementation of service objects<br>
&gt;<br>
&gt; Can you provide an example where it would be useful? Give us a use cas=
e.<br>
<br>
</span>I&#39;m not sure what Edward means by &quot;service object&quot;, bu=
t it sounds<br>
suspiciously similar to the Color example I gave.</blockquote><div><br></di=
v><div>It&#39;s more about implementing server programs (web services, etc.=
); a typical pattern is to create one instance per client of a service clas=
s; the service object owns the socket connection to the client and has non-=
owning pointers to resources. Requests from the client invoke methods on th=
e service object. The problem is that large services (necessary for busines=
s reasons) result in service objects with large numbers of methods; moving =
each method and its supporting logic into an inline class could combat this=
 without introducing overhead in dispatching requests and accessing resourc=
es.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">&=
gt; You have exactly 3 options for resolving this problem:<br>
&gt;<br>
&gt; 1) Inline classes contain an implicit `this` pointer to their owner, t=
hus<br>
&gt; breaking trivial copyability.<br>
&gt; 2) You can&#39;t get ptrs/refs to inline class members at all.<br>
&gt; 3) Inline class members cannot have state.<br>
<br>
</span>...have previously stated a preference for #3.</blockquote><div><br>=
</div><div>Two more options:</div><div>4) Inline class members must have di=
stinct types.</div><div>5) Inline classes contain an implicit offset to the=
ir owner, that can be subtracted from a `this` pointer.</div><div><br></div=
><div>I quite like #4; it&#39;s a reasonable restriction as it applies alre=
ady to direct base classes.</div><div>=C2=A0</div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><span class=3D"">
&gt;&gt; The problem with passing `template_func(foo.min)` is that it&#39;s=
 ambiguous;<br>
&gt;&gt; do you mean the current value, or foo.min as a getter, or as a set=
ter, or<br>
&gt;&gt; both? This is a problem for any implementation of properties in C+=
+.<br>
&gt;<br>
</span>&gt; Why should C++ behave *any differently* from the commonly accep=
ted meaning<br>
<span class=3D"">&gt; of this syntax? I would say that if the C++ implement=
ation behaves<br>
&gt; differently, then the C++ implementation is doing it wrong. People wil=
l<br>
&gt; expect properties to work like they work in other languages.<br>
&gt;<br>
&gt; Using syntactic transformation to implement them, it will work exactly=
 as<br>
&gt; expected. Using your leaky abstraction, it will not.<br>
<br>
</span>So how does one obtain a reference to a property, i.e. some &quot;ha=
ndle&quot;<br>
that can be passed to a function that needs to modify the property?<br>
Remember, calling the property set is *mandatory*; you can&#39;t pass a<br>
reference to the object&#39;s internal storage.<br></blockquote><div><br></=
div><div>And these other languages don&#39;t have references; it&#39;s tota=
lly alien to a Python programmer that assigning to a function argument coul=
d have effects outside that function, but that&#39;s totally accepted behav=
ior in C++ (if deprecated by some style guides that prefer pointers for mod=
ifiable parameters). I&#39;m not familiar with Lua; I dimly recollect that =
C# has syntax for reference parameters, but can those be deduced?</div><div=
>=C2=A0</div></div></div></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--001a1130c8c62993c3051ea09aca--

.

------=_Part_3621_1895870611.1441050180508
Content-Type: multipart/alternative;
 boundary="----=_Part_3622_231856465.1441050180508"

------=_Part_3622_231856465.1441050180508
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 2:22:49 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-31 13:59, Nicol Bolas wrote:
> >> The problem with passing `template_func(foo.min)` is that it's
> ambiguous;
> >> do you mean the current value, or foo.min as a getter, or as a setter,
> or
> >> both? This is a problem for any implementation of properties in C++.
> >
> > Why should C++ behave *any differently* from the commonly accepted
> meaning
> > of this syntax? I would say that if the C++ implementation behaves
> > differently, then the C++ implementation is doing it wrong. People will
> > expect properties to work like they work in other languages.
> >
> > Using syntactic transformation to implement them, it will work exactly
> as
> > expected. Using your leaky abstraction, it will not.
>
> So how does one obtain a reference to a property, i.e. some "handle"
> that can be passed to a function that needs to modify the property?
>

The same way you do in C#. Or Python. Or Lua.

*You don't*.

I mean sure, you could pass some lambda that the caller would have to call
which resolves to the property. Or some similar construct. But you can't
pass a property *transparently* to another function, such that the
receiving function uses it exactly like any other variable. By default, the
expression transmits the result of the getter.

This is the behavior that users of the feature will *expect*. They will not
expect that you can interact with a property as a free-standing construct.
Therefore, there's no need for a pure property implementation to generate a
proxy; it just calls the getter.

The leaks in your abstraction are still leaks, even if you want to call
them features.


> > * If `bar` is a property member of the class type of `foo`, then the
> > expression results in calling the assigned getter function.
>
> ...unless followed by an assignment operation. (BTW, I've heard compiler
> writers *hate* anything that requires look-ahead.)
>

That's... a fair point.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, August 31, 2015 at 2:22:49 PM UTC-4, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-08-31 13:59, Nicol Bolas wr=
ote:
<br>&gt;&gt; The problem with passing `template_func(foo.min)` is that it&#=
39;s ambiguous;=20
<br>&gt;&gt; do you mean the current value, or foo.min as a getter, or as a=
 setter, or=20
<br>&gt;&gt; both? This is a problem for any implementation of properties i=
n C++.
<br>&gt;=20
<br>&gt; Why should C++ behave *any differently* from the commonly accepted=
 meaning=20
<br>&gt; of this syntax? I would say that if the C++ implementation behaves=
=20
<br>&gt; differently, then the C++ implementation is doing it wrong. People=
 will=20
<br>&gt; expect properties to work like they work in other languages.
<br>&gt;=20
<br>&gt; Using syntactic transformation to implement them, it will work exa=
ctly as=20
<br>&gt; expected. Using your leaky abstraction, it will not.
<br>
<br>So how does one obtain a reference to a property, i.e. some &quot;handl=
e&quot;
<br>that can be passed to a function that needs to modify the property?<br>=
</blockquote><div><br>The same way you do in C#. Or Python. Or Lua.<br><br>=
<i>You don&#39;t</i>.<br><br>I mean sure, you could pass some lambda that t=
he caller would have to call which resolves to the property. Or some simila=
r construct. But you can&#39;t pass a property <i>transparently</i> to anot=
her function, such that the receiving function uses it exactly like any oth=
er variable. By default, the expression transmits the result of the getter.=
<br><br>This is the behavior that users of the feature will <i>expect</i>. =
They will not expect that you can interact with a property as a free-standi=
ng construct. Therefore, there&#39;s no need for a pure property implementa=
tion to generate a proxy; it just calls the getter.<br><br>The leaks in you=
r abstraction are still leaks, even if you want to call them features.<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">&gt; * If `bar` is=
 a property member of the class type of `foo`, then the=20
<br>&gt; expression results in calling the assigned getter function.
<br>
<br>...unless followed by an assignment operation. (BTW, I&#39;ve heard com=
piler
<br>writers *hate* anything that requires look-ahead.)<br></blockquote><div=
><br>That&#39;s... a fair point.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_3622_231856465.1441050180508--
------=_Part_3621_1895870611.1441050180508--

.

On 2015-08-31 15:27, Nicol Bolas wrote:
> On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wrote:
>> On 2015-08-31 14:03, Nicol Bolas wrote:
>>> On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
>>>> Please give examples, and show how inline classes could not be used for
>>>> the same.
>>>
>>> struct EmptyNotInAClass empty
>>> {
>>> };
>>>
>>> class NeedsEmpty
>>> {
>>>   EmptyNotInAClass a;
>>> };
>>>
>>> class AlsoNeedsEmpty
>>> {
>>>   EmptyNotInAClass b;
>>> };
>>
>> ...but what can you *do* with EmptyNotInAClass? It doesn't have storage,
>> or it wouldn't be empty. As a result, it can't meaningfully use it's
>> 'this'.
>
> It most certainly can meaningfully use `this`. It can call other member
> functions of itself, base class members of itself, and *empty* data members
> of itself.

Ah... okay, but there's no technical reason an inline class - even one
outside a concrete class - can't do all of those things too.

>> I don't see why this can't be done making EmptyNotInAClass an inline
>> struct. (The resulting members would continue to be unable to
>> meaningfully use 'this', but that's the case anyway...)
>
> You can't do this:
>
> template <typename T> struct Foo
> {
>   T t;
>   OtherMember b;
> };
>
> And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens to be
> empty.

If T is an inline class, why not? In fact, I would expect that if T is
an inline class, sizeof(Foo) does indeed equal sizeof(OtherMember) (or
at least, is the same size as if the member 't' wasn't present).

(That said, I'm not certain if this would be permissible as-is, but
certainly you could subclass T as a local inline class.)

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_709_1717108575.1441053109421
Content-Type: multipart/alternative;
 boundary="----=_Part_710_2068626528.1441053109421"

------=_Part_710_2068626528.1441053109421
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 3:56:29 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-31 15:27, Nicol Bolas wrote:
> > On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wrote:
> >> On 2015-08-31 14:03, Nicol Bolas wrote:
> >>> On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
> >> I don't see why this can't be done making EmptyNotInAClass an inline
> >> struct. (The resulting members would continue to be unable to
> >> meaningfully use 'this', but that's the case anyway...)
> >
> > You can't do this:
> >
> > template <typename T> struct Foo
> > {
> >   T t;
> >   OtherMember b;
> > };
> >
> > And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens to be
> > empty.
>
> If T is an inline class, why not?


Um, if inline classes have to be declared within classes, how could T be an
inline class of `Foo`? Because your description of inline classes made it
abundantly clear that they had to be declared inside of the class in which
they exist.

Hence the use of the keyword `inline`. Not to mention the fact that every
example you've shown puts them inside the class (and doesn't give them a
name). Oh, and the very concept is nonsensical outside of the class in
which they exist, because the implementation of inline class members makes
direct reference to a particular `this` of a concrete type. Unless you're
now saying that every inline class is automatically a template.

So I fail to see how `T` could be an inline class of `Foo`.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, August 31, 2015 at 3:56:29 PM UTC-4, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-08-31 15:27, Nicol Bolas wr=
ote:
<br>&gt; On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wr=
ote:
<br>&gt;&gt; On 2015-08-31 14:03, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Wo=
ehlke wrote:=20
<br>&gt;&gt; I don&#39;t see why this can&#39;t be done making EmptyNotInAC=
lass an inline=20
<br>&gt;&gt; struct. (The resulting members would continue to be unable to=
=20
<br>&gt;&gt; meaningfully use &#39;this&#39;, but that&#39;s the case anywa=
y...)=20
<br>&gt;=20
<br>&gt; You can&#39;t do this:
<br>&gt;=20
<br>&gt; template &lt;typename T&gt; struct Foo
<br>&gt; {
<br>&gt; =C2=A0 T t;
<br>&gt; =C2=A0 OtherMember b;
<br>&gt; };
<br>&gt;=20
<br>&gt; And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens=
 to be=20
<br>&gt; empty.
<br>
<br>If T is an inline class, why not?</blockquote><div><br>Um, if inline cl=
asses have to be declared within classes, how could T be an inline class of=
 `Foo`? Because your description of inline classes made it abundantly clear=
 that they had to be declared inside of the class in which they exist.<br><=
br>Hence the use of the keyword `inline`. Not to mention the fact that ever=
y example you&#39;ve shown puts them inside the class (and doesn&#39;t give=
 them a name). Oh, and the very concept is nonsensical outside of the class=
 in which they exist, because the implementation of inline class members ma=
kes direct reference to a particular `this` of a concrete type. Unless you&=
#39;re now saying that every inline class is automatically a template.<br><=
/div><br>So I fail to see how `T` could be an inline class of `Foo`.<br>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_710_2068626528.1441053109421--
------=_Part_709_1717108575.1441053109421--

.

--047d7bb04efe2d85cd051ea1c8cb
Content-Type: text/plain; charset=UTF-8

On 31 Aug 2015 20:43, "Nicol Bolas" <jmckesson@gmail.com> wrote:
>
> On Monday, August 31, 2015 at 2:22:49 PM UTC-4, Matthew Woehlke wrote:
>> So how does one obtain a reference to a property, i.e. some "handle"
>> that can be passed to a function that needs to modify the property?
>
>
> The same way you do in C#. Or Python. Or Lua.
>
> You don't.
>
> I mean sure, you could pass some lambda that the caller would have to
call which resolves to the property. Or some similar construct. But you
can't pass a property transparently to another function, such that the
receiving function uses it exactly like any other variable. By default, the
expression transmits the result of the getter.
>
> This is the behavior that users of the feature will expect. They will not
expect that you can interact with a property as a free-standing construct.
Therefore, there's no need for a pure property implementation to generate a
proxy; it just calls the getter.

Maybe, if they're C#, or Python, or Lua programmers. But those languages
have different data models to C++; in C++ pass by reference is the norm for
deduced parameters.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--047d7bb04efe2d85cd051ea1c8cb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr"><br>
On 31 Aug 2015 20:43, &quot;Nicol Bolas&quot; &lt;<a href=3D"mailto:jmckess=
on@gmail.com">jmckesson@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; On Monday, August 31, 2015 at 2:22:49 PM UTC-4, Matthew Woehlke wrote:=
<br>
&gt;&gt; So how does one obtain a reference to a property, i.e. some &quot;=
handle&quot; <br>
&gt;&gt; that can be passed to a function that needs to modify the property=
?<br>
&gt;<br>
&gt;<br>
&gt; The same way you do in C#. Or Python. Or Lua.<br>
&gt;<br>
&gt; You don&#39;t.<br>
&gt;<br>
&gt; I mean sure, you could pass some lambda that the caller would have to =
call which resolves to the property. Or some similar construct. But you can=
&#39;t pass a property transparently to another function, such that the rec=
eiving function uses it exactly like any other variable. By default, the ex=
pression transmits the result of the getter.<br>
&gt;<br>
&gt; This is the behavior that users of the feature will expect. They will =
not expect that you can interact with a property as a free-standing constru=
ct. Therefore, there&#39;s no need for a pure property implementation to ge=
nerate a proxy; it just calls the getter.</p>
<p dir=3D"ltr">Maybe, if they&#39;re C#, or Python, or Lua programmers. But=
 those languages have different data models to C++; in C++ pass by referenc=
e is the norm for deduced parameters. </p>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

--047d7bb04efe2d85cd051ea1c8cb--

.

On 2015-08-31 16:31, Nicol Bolas wrote:
> On Monday, August 31, 2015 at 3:56:29 PM UTC-4, Matthew Woehlke wrote:
>> On 2015-08-31 15:27, Nicol Bolas wrote:
>>> On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wrote:
>>>> On 2015-08-31 14:03, Nicol Bolas wrote:
>>>>> On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke wrote:
>>>> I don't see why this can't be done making EmptyNotInAClass an inline
>>>> struct. (The resulting members would continue to be unable to
>>>> meaningfully use 'this', but that's the case anyway...)
>>>
>>> You can't do this:
>>>
>>> template <typename T> struct Foo
>>> {
>>>   T t;
>>>   OtherMember b;
>>> };
>>>
>>> And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens to be
>>> empty.
>>
>> If T is an inline class, why not?
>
> Um, if inline classes have to be declared within classes, how could T be an
> inline class of `Foo`?

I may have said that originally. It should be obvious by now that I've
since relaxed that. An inline class that does not have a concrete
ancestor cannot be instantiated, however, as there would be no place for
"its storage" to live.

IOW, this is legal:

  inline class Base { ... };

  class Foo
  {
    inline class Derived : Base { ... };
  };

....but this is not:

  Base b; // error: inline class cannot be instantiated directly

In fact, the rule would be simply that an inline class can only be
instantiated within a concrete class. (Also, a concrete class can only
contain instances of freestanding or its own inline classes. Using
inline classes from other contexts would be Bad.)

(This should go without saying at this point, but to be clear, I am
using "class" to mean "class or struct" throughout.)

> Hence the use of the keyword `inline`. Not to mention the fact that every
> example you've shown puts them inside the class (and doesn't give them a
> name).

I've given at least one example where an inline class type is named.
They don't *need* to be named, but neither do concrete classes.
Certainly it isn't intended that they *can't* be named.

With CRTP, obviously, they'd *need* to be named. (Although... that feels
like a defect to me. In CRTP, not inline classes. Might be interesting
to pursue that in an orthogonal proposal.)

> Oh, and the very concept is nonsensical outside of the class in which
> they exist, because the implementation of inline class members makes
> direct reference to a particular `this` of a concrete type. Unless
> you're now saying that every inline class is automatically a
> template.

No. That's not even necessary for freestanding inline classes, although
CRTP likely gives more use cases for those.

(Moreover, a freestanding inline class should act more like a namespace.
In particular, taking its size is illegal. Specifying it as a function
parameter is also likely problematic, but I can't think why it would be
useful to do so, and should probably also be disallowed. The type name
of an inline class member of a concrete class would also need to be a
"magic" type that relates the type of the containing class.)

> So I fail to see how `T` could be an inline class of `Foo`.

A freestanding inline class has unspecified storage and cannot be casted
(except via reinterpret_cast through void, with the usual caveats about
type punning), but can access its own members. The address of such an
object is, as always, the address of the concrete object that contains
it. So without CTRP, it has no way to access "actual storage", but hey,
if you have a T for which that works...

I don't think there should a problem with CRTP and aliasing... that
operation is just an unchecked downcast, which folks have been doing for
ages.

--
Matthew

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_934_124907256.1441058127667
Content-Type: multipart/alternative;
 boundary="----=_Part_935_800777403.1441058127675"

------=_Part_935_800777403.1441058127675
Content-Type: text/plain; charset=UTF-8

On Monday, August 31, 2015 at 5:10:24 PM UTC-4, Matthew Woehlke wrote:
>
> On 2015-08-31 16:31, Nicol Bolas wrote:
> > On Monday, August 31, 2015 at 3:56:29 PM UTC-4, Matthew Woehlke wrote:
> >> On 2015-08-31 15:27, Nicol Bolas wrote:
> >>> On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Woehlke wrote:
> >>>> On 2015-08-31 14:03, Nicol Bolas wrote:
> >>>>> On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Matthew Woehlke
> wrote:
> >>>> I don't see why this can't be done making EmptyNotInAClass an inline
> >>>> struct. (The resulting members would continue to be unable to
> >>>> meaningfully use 'this', but that's the case anyway...)
> >>>
> >>> You can't do this:
> >>>
> >>> template <typename T> struct Foo
> >>> {
> >>>   T t;
> >>>   OtherMember b;
> >>> };
> >>>
> >>> And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T` happens to
> be
> >>> empty.
> >>
> >> If T is an inline class, why not?
> >
> > Um, if inline classes have to be declared within classes, how could T be
> an
> > inline class of `Foo`?
>
> I may have said that originally. It should be obvious by now that I've
> since relaxed that.


OK, could you go over the entire, current version of this idea in the other
thread? Because it's pretty clear that everyone seems to have a different
idea of what this feature actually is.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Monday, August 31, 2015 at 5:10:24 PM UTC-4, Matthew Woehlke wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;">On 2015-08-31 16:31, Nicol Bolas wr=
ote:
<br>&gt; On Monday, August 31, 2015 at 3:56:29 PM UTC-4, Matthew Woehlke wr=
ote:
<br>&gt;&gt; On 2015-08-31 15:27, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt; On Monday, August 31, 2015 at 2:30:11 PM UTC-4, Matthew Wo=
ehlke wrote:=20
<br>&gt;&gt;&gt;&gt; On 2015-08-31 14:03, Nicol Bolas wrote:=20
<br>&gt;&gt;&gt;&gt;&gt; On Monday, August 31, 2015 at 1:51:06 PM UTC-4, Ma=
tthew Woehlke wrote:=20
<br>&gt;&gt;&gt;&gt; I don&#39;t see why this can&#39;t be done making Empt=
yNotInAClass an inline=20
<br>&gt;&gt;&gt;&gt; struct. (The resulting members would continue to be un=
able to=20
<br>&gt;&gt;&gt;&gt; meaningfully use &#39;this&#39;, but that&#39;s the ca=
se anyway...)=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; You can&#39;t do this:=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; template &lt;typename T&gt; struct Foo=20
<br>&gt;&gt;&gt; {=20
<br>&gt;&gt;&gt; =C2=A0 T t;=20
<br>&gt;&gt;&gt; =C2=A0 OtherMember b;=20
<br>&gt;&gt;&gt; };=20
<br>&gt;&gt;&gt;
<br>&gt;&gt;&gt; And allow `sizeof(Foo)` to be `sizeof(OtherMember)` if `T`=
 happens to be=20
<br>&gt;&gt;&gt; empty.=20
<br>&gt;&gt;
<br>&gt;&gt; If T is an inline class, why not?
<br>&gt;=20
<br>&gt; Um, if inline classes have to be declared within classes, how coul=
d T be an=20
<br>&gt; inline class of `Foo`?
<br>
<br>I may have said that originally. It should be obvious by now that I&#39=
;ve
<br>since relaxed that.</blockquote><div><br>OK, could you go over the enti=
re, current version of this idea in the other thread? Because it&#39;s pret=
ty clear that everyone seems to have a different idea of what this feature =
actually is.<br></div>

<p></p>

-- <br />
<br />
--- <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 />
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />

------=_Part_935_800777403.1441058127675--
------=_Part_934_124907256.1441058127667--

.

This is a multi-part message in MIME format.
--------------020405070602040302050306
Content-Type: text/plain; charset=UTF-8; format=flowed

Am 31.08.2015 um 19:59 schrieb Nicol Bolas:
> (...)
>
> Welcome to missing the point. You're talking about properties; I'm
> talking about /basic expression logic/. Users /expect/ x += y to do
> the same thing as x = x + y. Users know that the latter may be slower,
> but they should not be different.
atomic<int> x;
x += y;
x = x + y;
These don't do the same thing. And yes, I am well aware that if you have
to use atomic you should know what you're doing and be careful and bla
bla. That's not the point. If you're in an expert domain you have
different conventions and everyday assumptions may no longer hold.

--

---
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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.

--------------020405070602040302050306
Content-Type: text/html; charset=UTF-8

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Am 31.08.2015 um 19:59 schrieb Nicol Bolas:<br>
    <blockquote
      cite="mid:e0978e10-e1a7-4057-b82d-4775fd9a80d7@isocpp.org"
      type="cite">
      <div>(...)</div>
      <div><br>
        Welcome to missing the point. You're talking about properties;
        I'm talking about <i>basic expression logic</i>. Users <i>expect</i>
        x += y to do the same thing as x = x + y. Users know that the
        latter may be slower, but they should not be different.<br>
      </div>
    </blockquote>
    atomic&lt;int&gt; x;<br>
    x += y;<br>
    x = x + y;<br>
    These don't do the same thing. And yes, I am well aware that if you
    have to use atomic you should know what you're doing and be careful
    and bla bla. That's not the point. If you're in an expert domain you
    have different conventions and everyday assumptions may no longer
    hold.<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
<br />
--- <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 email to <a href="mailto:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href="mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />

--------------020405070602040302050306--

.

------=_Part_469_465971197.1538680912933
Content-Type: multipart/alternative;
 boundary="----=_Part_470_1825848890.1538680912933"

------=_Part_470_1825848890.1538680912933
Content-Type: text/plain; charset="UTF-8"



On Thursday, June 5, 2014 at 9:07:36 PM UTC-7, Andrew Tomazos wrote:
>
>
> We already have this in C++:
>
>
> class TimePeriod
> {
>     double seconds;
>
> public:
>
>    struct {
>        operator double() { return seconds / 3600; }
>        void operator=(double value) { seconds = value * 3600; }
>    } Hours;
> };
>

Please provide a working example.

Also, saying that it can be done using the existing standard except with
extra syntax is like saying we don't need to add classes to C since the
equivalent can be done in C except using extra syntax.

--
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/ff09be9e-27d5-4990-aca1-52a98ddd0f07%40isocpp.org.

------=_Part_470_1825848890.1538680912933
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><br><br>On Thursday, June 5, 2014 at 9:07:36 PM UTC-7, And=
rew Tomazos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div><br></div><div><pre style=3D"padding:5px;margin-top:0px;margin-bo=
ttom:0px;overflow:auto;word-wrap:normal;color:rgb(0,0,0);font-size:13px;lin=
e-height:17.549999237060547px;font-family:Consolas,Courier,monospace!import=
ant">We already have this in C++:<br></pre><div><br></div><div>class TimePe=
riod</div><div>{</div><div>=C2=A0 =C2=A0 double seconds;</div><div><br></di=
v><div>public:</div><div><br></div><div>=C2=A0 =C2=A0struct {</div><div>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0operator double() { return seconds / 3600; }</div>
<div>=C2=A0 =C2=A0 =C2=A0 =C2=A0void operator=3D(double value) { seconds =
=3D value * 3600; }</div><div>=C2=A0 =C2=A0} Hours;</div><div>};</div></div=
></div></blockquote><div>=C2=A0</div><div>Please provide a working example.=
</div><div><br></div><div>Also, saying that it can be done using the existi=
ng standard except with extra syntax is like saying we don&#39;t need to ad=
d classes to C since the equivalent can be done in C except using extra syn=
tax.</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/ff09be9e-27d5-4990-aca1-52a98ddd0f07%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ff09be9e-27d5-4990-aca1-52a98ddd0f07=
%40isocpp.org</a>.<br />

------=_Part_470_1825848890.1538680912933--

------=_Part_469_465971197.1538680912933--

.