Topic: Properties Syntax
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Tue, 27 Aug 2013 08:04:42 -0700 (PDT)
Raw View
------=_Part_361_31906575.1377615882779
Content-Type: text/plain; charset=ISO-8859-1
Has anyone considered using "auto" as a qualifier to specify that a
function is a property?
The D programming language uses a similar approach, except that "@property"
is used in front of the function. The "property" keyword is already in use
in Objective-C++ and CLI, so instead, the auto keyword could be used as a
qualifier.
I remember reading a paper somewhere that suggested something similar to
this, but it used a new keyword "implicit" in place of auto. I believe this
still clear enough, and avoids the need for another keyword.
class Test
{
int _number;
std::pair<int, int> _twoNumbers;
public:
// getter
int number() auto {
return _number;
}
// setter
int number(int number) auto {
return _number = number;
}
// getter by reference
const pair<int, int> &twoNumbers() const auto {
return _twoNumbers;
}
// setter
const pair<int, int> &twoNumbers(const pair<int, int> &tn) auto {
return (_twoNumbers = tn);
}
};
/////////////////////////
Test test;
test.number = 5;
//same as: test.number(5);
int a = test.number;
// same as: int a = test.number();
test.number += 5;
// same as: test.number( test.number() + 5 );
int a = 1 + test.number + 3;
// same as: int a = 1 + test.number() + 3;
cout << number.twoNumbers.first << endl;
// same as: cout << number.twoNumbers().first << endl;
--
---
You received this message because you are 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_361_31906575.1377615882779
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Has anyone considered using "auto" as a qualifier to =
specify that a function is a property?<br></div><div><br></div><div>The D p=
rogramming language uses a similar approach, except that "@property" is use=
d in front of the function. The "property" keyword is already in use =
in Objective-C++ and CLI, so instead, the auto keyword could be used as a q=
ualifier.<div><br></div><div>I remember reading a paper somewhere that sugg=
ested something similar to this, but it used a new keyword "implicit" in pl=
ace of auto. I believe this still clear enough, and avoids the need for ano=
ther keyword.</div><div><br></div><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"subprett=
yprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Test</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><span style=3D"color: #000=
;" class=3D"styled-by-prettify"><br> </span><span style=3D"col=
or: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> _number</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">pair</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">,</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"> _twoNumbers</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: #008;" class=3D"styled-by-prettify">public</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: =
#800;" class=3D"styled-by-prettify">// getter</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br> </span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> number</span><span style=3D"color: #66=
0;" 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">auto</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>&nbs=
p; </span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> _number</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> <br> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">// setter</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> number</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> number</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><s=
pan 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> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> _number </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> number</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> <=
/span><span style=3D"color: #800;" class=3D"styled-by-prettify">// getter b=
y reference</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
><br> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">const</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> pair</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&=
lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</sp=
an><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">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=
"styled-by-prettify">&</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify">twoNumbers</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">c=
onst</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</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> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> _twoNumbers</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">}</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> <br> =
; </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> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> pair</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: #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">int</span><span style=3D"color: #66=
0;" 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-prettify">twoNumbers</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by-pretti=
fy">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
pair</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</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=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">></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=
-prettify">tn</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</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> </spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">return</span><s=
pan 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">_twoNumbers </span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> tn</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> </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">}</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br></span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"><br><br><br></span><span style=3D"color: #800;" class=3D"styled-by-prett=
ify">/////////////////////////</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"styled=
-by-prettify">Test</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> test</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><b=
r><br>test</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
..</span><span style=3D"color: #000;" class=3D"styled-by-prettify">number </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #066;" class=3D"styled-by-prettify">5</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: #800;" class=
=3D"styled-by-prettify">//same as: test.number(5);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br><br><br></span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"c=
olor: #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;" c=
lass=3D"styled-by-prettify"> test</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">number</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: #800;" class=3D"styled-by-prettify">// s=
ame as: int a =3D test.number();</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br><br>test</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">number </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-p=
rettify">5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">// same as: &nb=
sp;test.number( test.number() + 5 );</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><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"styled-by-pre=
ttify"> </span><span style=3D"color: #066;" class=3D"styled-by-prettify">1<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">+</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> test</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify">number </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"styled-b=
y-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></=
span><span style=3D"color: #800;" class=3D"styled-by-prettify">// same as: =
int a =3D 1 + test.number() + 3;</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"><br><br><br>cout </span><span style=3D"color: #=
660;" class=3D"styled-by-prettify"><<</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> number</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">twoNumbers</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">first </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify"><<</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> endl</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: #800;" class=3D"styled-by-prettify">// same as: &n=
bsp;cout << number.twoNumbers().first << endl;</span></div></co=
de></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_361_31906575.1377615882779--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 27 Aug 2013 17:24:45 +0200
Raw View
2013/8/27 Nick <nicolas.jinchereau@gmail.com>:
> Has anyone considered using "auto" as a qualifier to specify that a function
> is a property?
I'm not aware of anyone.
> The D programming language uses a similar approach, except that "@property"
> is used in front of the function. The "property" keyword is already in use
> in Objective-C++ and CLI, so instead, the auto keyword could be used as a
> qualifier.
It could, presumable, but IMO the syntax becomes easy to mix-up with
auto return types. I would prefer a clearer difference. Among other
choices, C++ could introduce a contextual keyword "property" (or
"auto_property") than can only be used in way that is syntactically
different from CLI.
- 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/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 27 Aug 2013 09:49:24 -0700 (PDT)
Raw View
------=_Part_9_31970201.1377622164661
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
C++ does not need properties. It needs reflection capabilities to give the=
=20
benefits of properties, but the language is already _far_ more flexible=20
than any new property syntax could allow.
A property system needs to deal with multiple types of return values,=20
multiple types of parameters, cv-qualified functions, etc.
The problem with C++ is not that we lack an easy way to define properties=
=20
(we have it, and the STL even uses it, see below), but that there is no way=
=20
to group all the functions of a property together logically for=20
serialization systems and the like.
class my_type {
std::vector<int> _foo;
public:
const std::vector<int>& foo() const { return _foo; }
my_type& foo(std::vector<int>&& v) { _foo =3D std::move(v); return *this;=
}
my_type& foo(const std::vector<int>& v) { _foo =3D v; return *this; }
};
my_type mt;
// getter
auto v =3D mt.foo();
// setters
mt.foo(v);
mt.foo(std::move(v));
Note that the existing C++ approach avoids all the nastines of "is this a=
=20
plain old data member or a property that does a bunch of work behind my=20
back?" problem that C# suffers from.
On Tuesday, August 27, 2013 8:24:45 AM UTC-7, Daniel Kr=FCgler wrote:
>
> 2013/8/27 Nick <nicolas.j...@gmail.com <javascript:>>:=20
> > Has anyone considered using "auto" as a qualifier to specify that a=20
> function=20
> > is a property?=20
>
> I'm not aware of anyone.=20
>
> > The D programming language uses a similar approach, except that=20
> "@property"=20
> > is used in front of the function. The "property" keyword is already in=
=20
> use=20
> > in Objective-C++ and CLI, so instead, the auto keyword could be used as=
=20
> a=20
> > qualifier.=20
>
> It could, presumable, but IMO the syntax becomes easy to mix-up with=20
> auto return types. I would prefer a clearer difference. Among other=20
> choices, C++ could introduce a contextual keyword "property" (or=20
> "auto_property") than can only be used in way that is syntactically=20
> different from CLI.=20
>
> - Daniel=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_9_31970201.1377622164661
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">C++ does not need properties. It needs reflection ca=
pabilities to give the benefits of properties, but the language is already =
_far_ more flexible than any new property syntax could allow.<div><br></div=
><div>A property system needs to deal with multiple types of return values,=
multiple types of parameters, cv-qualified functions, etc.</div><div><br><=
/div><div>The problem with C++ is not that we lack an easy way to define pr=
operties (we have it, and the STL even uses it, see below), but that there =
is no way to group all the functions of a property together logically for s=
erialization systems and the like.</div><div><br></div><div>class my_type {=
</div><div> std::vector<int> _foo;</div><div>public:</div><div>=
const std::vector<int>& foo() const { return _foo; }</div>=
<div> my_type& foo(std::vector<int>&& v) { _foo =3D=
std::move(v); return *this; }</div><div> my_type& foo(const std:=
:vector<int>& v) { _foo =3D v; return *this; }</div><div>};</div>=
<div><br></div><div>my_type mt;</div><div>// getter</div><div>auto v =3D mt=
..foo();</div><div>// setters</div><div>mt.foo(v);</div><div>mt.foo(std::mov=
e(v));<br><br>Note that the existing C++ approach avoids all the nastines o=
f "is this a plain old data member or a property that does a bunch of work =
behind my back?" problem that C# suffers from.<br><br>On Tuesday, August 27=
, 2013 8:24:45 AM UTC-7, Daniel Kr=FCgler wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;pa=
dding-left: 1ex;">2013/8/27 Nick <<a href=3D"javascript:" target=3D"_bla=
nk" gdf-obfuscated-mailto=3D"1vbXbLZqynoJ">nicolas.j...@gmail.com</a>><w=
br>:
<br>> Has anyone considered using "auto" as a qualifier to specify that =
a function
<br>> is a property?
<br>
<br>I'm not aware of anyone.
<br>
<br>> The D programming language uses a similar approach, except that "@=
property"
<br>> is used in front of the function. The "property" keyword is =
already in use
<br>> in Objective-C++ and CLI, so instead, the auto keyword could be us=
ed as a
<br>> qualifier.
<br>
<br>It could, presumable, but IMO the syntax becomes easy to mix-up with
<br>auto return types. I would prefer a clearer difference. Among other
<br>choices, C++ could introduce a contextual keyword "property" (or
<br>"auto_property") than can only be used in way that is syntactically
<br>different from CLI.
<br>
<br>- Daniel
<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_9_31970201.1377622164661--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Tue, 27 Aug 2013 11:41:38 -0700
Raw View
--089e013a171e2a525004e4f23957
Content-Type: text/plain; charset=ISO-8859-1
#include <functional>
#include <utility>
#include <iostream>
template<typename T> struct property {
std::function<T()> get;
std::function<void(T)> set;
property(const property&) = delete;
property(property&&) = delete;
property &operator=(const property&) = delete;
property &operator=(property&&) = delete;
operator T() { return get(); }
template<typename U>
property &operator=(U &&u) { set(std::forward<U>(u)); return *this; }
};
class Test {
int _number;
std::pair<int, int> _twoNumbers = { 3, 4 };
public:
property<int> number = {
[&]() { return _number; },
[&](int number) { _number = number; }
};
property<std::pair<int, int>> twoNumbers = {
[&]() { return _twoNumbers; },
[&](const std::pair<int, int> &tn) { _twoNumbers = tn; }
};
};
int main() {
Test test;
test.number = 5;
int a = test.number;
std::cout << test.twoNumbers.get().first << " " << a << std::endl;
};
On Tue, Aug 27, 2013 at 8:04 AM, Nick <nicolas.jinchereau@gmail.com> wrote:
> Has anyone considered using "auto" as a qualifier to specify that a
> function is a property?
>
> The D programming language uses a similar approach, except that
> "@property" is used in front of the function. The "property" keyword is
> already in use in Objective-C++ and CLI, so instead, the auto keyword could
> be used as a qualifier.
>
> I remember reading a paper somewhere that suggested something similar to
> this, but it used a new keyword "implicit" in place of auto. I believe this
> still clear enough, and avoids the need for another keyword.
>
> class Test
> {
> int _number;
> std::pair<int, int> _twoNumbers;
> public:
> // getter
> int number() auto {
> return _number;
> }
>
> // setter
> int number(int number) auto {
> return _number = number;
> }
>
> // getter by reference
> const pair<int, int> &twoNumbers() const auto {
> return _twoNumbers;
> }
>
> // setter
> const pair<int, int> &twoNumbers(const pair<int, int> &tn) auto {
> return (_twoNumbers = tn);
> }
> };
>
>
> /////////////////////////
> Test test;
>
>
> test.number = 5;
> //same as: test.number(5);
>
>
> int a = test.number;
> // same as: int a = test.number();
>
>
> test.number += 5;
> // same as: test.number( test.number() + 5 );
>
>
> int a = 1 + test.number + 3;
> // same as: int a = 1 + test.number() + 3;
>
>
> cout << number.twoNumbers.first << endl;
> // same as: cout << number.twoNumbers().first << endl;
>
> --
>
> ---
> You received this message because you are 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/.
--089e013a171e2a525004e4f23957
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>#include <functional></div><div>#include <ut=
ility></div><div>#include <iostream></div><div><br></div><div>temp=
late<typename T> struct property {</div><div>=A0 std::function<T()=
> get;</div>
<div>=A0 std::function<void(T)> set;</div><div><br></div><div>=A0 pro=
perty(const property&) =3D delete;</div><div>=A0 property(property&=
&) =3D delete;</div><div>=A0 property &operator=3D(const property&a=
mp;) =3D delete;</div>
<div>=A0 property &operator=3D(property&&) =3D delete;</div><di=
v><br></div><div>=A0 operator T() { return get(); }</div><div><br></div><di=
v>=A0 template<typename U></div><div>=A0 property &operator=3D(U =
&&u) { set(std::forward<U>(u)); return *this; }</div>
<div>};</div><div><br></div><div>class Test {</div><div>=A0 int _number;</d=
iv><div>=A0 std::pair<int, int> _twoNumbers =3D { 3, 4 };</div><div><=
br></div><div>public:</div><div>=A0 property<int> number =3D {</div><=
div>=A0 =A0 [&]() { return _number; },</div>
<div>=A0 =A0 [&](int number) { _number =3D number; }</div><div>=A0 };</=
div><div><br></div><div>=A0 property<std::pair<int, int>> twoNu=
mbers =3D {</div><div>=A0 =A0 [&]() { return _twoNumbers; },</div><div>=
=A0 =A0 [&](const std::pair<int, int> &tn) { _twoNumbers =3D =
tn; }</div>
<div>=A0 };</div><div>};</div><div><br></div><div>int main() {</div><div>=
=A0 Test test;</div><div>=A0 test.number =3D 5;</div><div>=A0 int a =3D tes=
t.number;</div><div>=A0 std::cout << test.twoNumbers.get().first <=
< " " << a << std::endl;</div>
<div>};</div><div><br></div><div class=3D"gmail_extra"><div class=3D"gmail_=
quote">On Tue, Aug 27, 2013 at 8:04 AM, Nick <span dir=3D"ltr"><<a href=
=3D"mailto:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchere=
au@gmail.com</a>></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>Has anyone considered using "au=
to" as a qualifier to specify that a function is a property?<br>
</div><div><br></div><div>The D programming language uses a similar approac=
h, except that "@property" is used in front of the function. =A0T=
he "property" keyword is already in use in Objective-C++ and CLI,=
so instead, the auto keyword could be used as a qualifier.<div>
<br></div><div>I remember reading a paper somewhere that suggested somethin=
g similar to this, but it used a new keyword "implicit" in place =
of auto. I believe this still clear enough, and avoids the need for another=
keyword.</div>
<div><br></div><div><div style=3D"background-color:rgb(250,250,250);border:=
1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=3D"=
color:rgb(0,0,136)">class</span><span style> </span><span style=3D"color:rg=
b(102,0,102)">Test</span><span style><br>
</span><span style=3D"color:rgb(102,102,0)">{</span><span style><br>=A0 =A0=
</span><span style=3D"color:rgb(0,0,136)">int</span><span style> _number</=
span><span style=3D"color:rgb(102,102,0)">;</span><span style><br>=A0 =A0 s=
td</span><span style=3D"color:rgb(102,102,0)">::</span><span style>pair</sp=
an><span style=3D"color:rgb(102,102,0)"><</span><span style=3D"color:rgb=
(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">,</span><span sty=
le> </span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"colo=
r:rgb(102,102,0)">></span><span style> _twoNumbers</span><span style=3D"=
color:rgb(102,102,0)">;</span><span style><br>
</span><span style=3D"color:rgb(0,0,136)">public</span><span style=3D"color=
:rgb(102,102,0)">:</span><span style><br>=A0 =A0 </span><span style=3D"colo=
r:rgb(136,0,0)">// getter</span><span style><br>=A0 =A0 </span><span style=
=3D"color:rgb(0,0,136)">int</span><span style> number</span><span style=3D"=
color:rgb(102,102,0)">()</span><span style> </span><span style=3D"color:rgb=
(0,0,136)">auto</span><span style> </span><span style=3D"color:rgb(102,102,=
0)">{</span><span style><br>
=A0 =A0 =A0 =A0 </span><span style=3D"color:rgb(0,0,136)">return</span><spa=
n style> _number</span><span style=3D"color:rgb(102,102,0)">;</span><span s=
tyle><br>=A0 =A0 </span><span style=3D"color:rgb(102,102,0)">}</span><span =
style><br>=A0 =A0 <br>
=A0 =A0 </span><span style=3D"color:rgb(136,0,0)">// setter</span><span sty=
le><br>=A0 =A0 </span><span style=3D"color:rgb(0,0,136)">int</span><span st=
yle> number</span><span style=3D"color:rgb(102,102,0)">(</span><span style=
=3D"color:rgb(0,0,136)">int</span><span style> number</span><span style=3D"=
color:rgb(102,102,0)">)</span><span style> </span><span style=3D"color:rgb(=
0,0,136)">auto</span><span style> </span><span style=3D"color:rgb(102,102,0=
)">{</span><span style><br>
=A0 =A0 =A0 =A0 </span><span style=3D"color:rgb(0,0,136)">return</span><spa=
n style> _number </span><span style=3D"color:rgb(102,102,0)">=3D</span><spa=
n style> number</span><span style=3D"color:rgb(102,102,0)">;</span><span st=
yle><br>=A0 =A0 </span><span style=3D"color:rgb(102,102,0)">}</span><span s=
tyle><br>
=A0 =A0 <br>=A0 =A0 </span><span style=3D"color:rgb(136,0,0)">// getter by =
reference</span><span style><br>=A0 =A0 </span><span style=3D"color:rgb(0,0=
,136)">const</span><span style> pair</span><span style=3D"color:rgb(102,102=
,0)"><</span><span style=3D"color:rgb(0,0,136)">int</span><span style=3D=
"color:rgb(102,102,0)">,</span><span style> </span><span style=3D"color:rgb=
(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">></span><span =
style> </span><span style=3D"color:rgb(102,102,0)">&</span><span style>=
twoNumbers</span><span style=3D"color:rgb(102,102,0)">()</span><span style>=
</span><span style=3D"color:rgb(0,0,136)">const</span><span style> </span>=
<span style=3D"color:rgb(0,0,136)">auto</span><span style> </span><span sty=
le=3D"color:rgb(102,102,0)">{</span><span style><br>
=A0 =A0 =A0 =A0 </span><span style=3D"color:rgb(0,0,136)">return</span><spa=
n style> _twoNumbers</span><span style=3D"color:rgb(102,102,0)">;</span><sp=
an style><br>=A0 =A0 </span><span style=3D"color:rgb(102,102,0)">}</span><s=
pan style><br>
=A0 =A0 <br>=A0 =A0 </span><span style=3D"color:rgb(136,0,0)">// setter</sp=
an><span style><br>=A0 =A0 </span><span style=3D"color:rgb(0,0,136)">const<=
/span><span style> pair</span><span style=3D"color:rgb(102,102,0)"><</sp=
an><span style=3D"color:rgb(0,0,136)">int</span><span style=3D"color:rgb(10=
2,102,0)">,</span><span style> </span><span style=3D"color:rgb(0,0,136)">in=
t</span><span style=3D"color:rgb(102,102,0)">></span><span style> </span=
><span style=3D"color:rgb(102,102,0)">&</span><span style>twoNumbers</s=
pan><span style=3D"color:rgb(102,102,0)">(</span><span style=3D"color:rgb(0=
,0,136)">const</span><span style> pair</span><span style=3D"color:rgb(102,1=
02,0)"><</span><span style=3D"color:rgb(0,0,136)">int</span><span style=
=3D"color:rgb(102,102,0)">,</span><span style> </span><span style=3D"color:=
rgb(0,0,136)">int</span><span style=3D"color:rgb(102,102,0)">></span><sp=
an style> </span><span style=3D"color:rgb(102,102,0)">&</span><span sty=
le>tn</span><span style=3D"color:rgb(102,102,0)">)</span><span style> </spa=
n><span style=3D"color:rgb(0,0,136)">auto</span><span style> </span><span s=
tyle=3D"color:rgb(102,102,0)">{</span><span style><br>
=A0 =A0 =A0 =A0 </span><span style=3D"color:rgb(0,0,136)">return</span><spa=
n style> </span><span style=3D"color:rgb(102,102,0)">(</span><span style>_t=
woNumbers </span><span style=3D"color:rgb(102,102,0)">=3D</span><span style=
> tn</span><span style=3D"color:rgb(102,102,0)">);</span><span style><br>
=A0 =A0 </span><span style=3D"color:rgb(102,102,0)">}</span><span style><br=
></span><span style=3D"color:rgb(102,102,0)">};</span><span style><br><br><=
br></span><span style=3D"color:rgb(136,0,0)">/////////////////////////</spa=
n><span style><br>
</span><span style=3D"color:rgb(102,0,102)">Test</span><span style> test</s=
pan><span style=3D"color:rgb(102,102,0)">;</span><span style><br><br><br>te=
st</span><span style=3D"color:rgb(102,102,0)">.</span><span style>number </=
span><span style=3D"color:rgb(102,102,0)">=3D</span><span style> </span><sp=
an style=3D"color:rgb(0,102,102)">5</span><span style=3D"color:rgb(102,102,=
0)">;</span><span style><br>
</span><span style=3D"color:rgb(136,0,0)">//same as: =A0test.number(5);</sp=
an><span style><br><br><br></span><span style=3D"color:rgb(0,0,136)">int</s=
pan><span style> a </span><span style=3D"color:rgb(102,102,0)">=3D</span><s=
pan style> test</span><span style=3D"color:rgb(102,102,0)">.</span><span st=
yle>number</span><span style=3D"color:rgb(102,102,0)">;</span><span style><=
br>
</span><span style=3D"color:rgb(136,0,0)">// same as: =A0int a =3D test.num=
ber();</span><span style><br><br><br>test</span><span style=3D"color:rgb(10=
2,102,0)">.</span><span style>number </span><span style=3D"color:rgb(102,10=
2,0)">+=3D</span><span style> </span><span style=3D"color:rgb(0,102,102)">5=
</span><span style=3D"color:rgb(102,102,0)">;</span><span style><br>
</span><span style=3D"color:rgb(136,0,0)">// same as: =A0test.number( test.=
number() + 5 );</span><span style><br><br><br></span><span style=3D"color:r=
gb(0,0,136)">int</span><span style> a </span><span style=3D"color:rgb(102,1=
02,0)">=3D</span><span style> </span><span style=3D"color:rgb(0,102,102)">1=
</span><span style> </span><span style=3D"color:rgb(102,102,0)">+</span><sp=
an style> test</span><span style=3D"color:rgb(102,102,0)">.</span><span sty=
le>number </span><span style=3D"color:rgb(102,102,0)">+</span><span style> =
</span><span style=3D"color:rgb(0,102,102)">3</span><span style=3D"color:rg=
b(102,102,0)">;</span><span style><br>
</span><span style=3D"color:rgb(136,0,0)">// same as: =A0int a =3D 1 + test=
..number() + 3;</span><span style><br><br><br>cout </span><span style=3D"col=
or:rgb(102,102,0)"><<</span><span style> number</span><span style=3D"=
color:rgb(102,102,0)">.</span><span style>twoNumbers</span><span style=3D"c=
olor:rgb(102,102,0)">.</span><span style>first </span><span style=3D"color:=
rgb(102,102,0)"><<</span><span style> endl</span><span style=3D"color=
:rgb(102,102,0)">;</span><span style><br>
</span><span style=3D"color:rgb(136,0,0)">// same as: =A0cout << numb=
er.twoNumbers().first << endl;</span></div></code></div><span class=
=3D""><font color=3D"#888888"><div><br></div></font></span></div></div></di=
v><span class=3D""><font color=3D"#888888">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</font></span></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e013a171e2a525004e4f23957--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 27 Aug 2013 21:30:55 +0200
Raw View
2013/8/27 Richard Smith <richard@metafoo.co.uk>:
> #include <functional>
> #include <utility>
> #include <iostream>
>
> template<typename T> struct property {
> std::function<T()> get;
> std::function<void(T)> set;
>
> property(const property&) = delete;
> property(property&&) = delete;
> property &operator=(const property&) = delete;
> property &operator=(property&&) = delete;
>
> operator T() { return get(); }
>
> template<typename U>
> property &operator=(U &&u) { set(std::forward<U>(u)); return *this; }
> };
>
> class Test {
> int _number;
> std::pair<int, int> _twoNumbers = { 3, 4 };
>
> public:
> property<int> number = {
> [&]() { return _number; },
> [&](int number) { _number = number; }
> };
>
> property<std::pair<int, int>> twoNumbers = {
> [&]() { return _twoNumbers; },
> [&](const std::pair<int, int> &tn) { _twoNumbers = tn; }
> };
> };
>
> int main() {
> Test test;
> test.number = 5;
> int a = test.number;
> std::cout << test.twoNumbers.get().first << " " << a << std::endl;
> };
Nice example! The expressiveness of the language is really great, but
I suspect that the outcome of the following expression test:
decltype(test.number)
is one of the main reasons why several people have been asking for
properties expressed by a core language construction instead of a
library solution. I guess that no-one seriously would want to change
decltype to make above type query return 'int'.
Just my personal opinion: I had worked quite a long time with Delphi
(to my knowledge one of Borland's main language architects were
involved in large parts with the language design of C# much later),
and it provided properties very early. It was great, because it was
natural to use them combined with the IDE. In C++ I seriously never
missed them not to exist, my guess is, because of the lack of this
kind of integration. But maybe I had not considered to use them in
other contexts than as members of classes. Maybe they could be useful
even in namespace scope when a could be used to make a function call
look like an object expression? (E.g. for constants)
- 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/.
.
Author: nicolas.jinchereau@gmail.com
Date: Tue, 27 Aug 2013 12:46:12 -0700 (PDT)
Raw View
------=_Part_2212_33335724.1377632772895
Content-Type: text/plain; charset=ISO-8859-1
First of all, I appreciate everyone taking the time to respond. However, I
still stand by my suggested implementation of properties.
Daniel,
I do agree that there is a small chance for a mix-up, but any new
language feature would introduce some kind of learning curve. Considering
the current usage of const, virtual, default, and delete, I think that the
relative complexity of a second usage of auto is very low, due to the fact
that the current usage of 'auto' is very localized(used only in the place
of a type).
Also, I do agree that giving properties their own contextual keyword
would be ideal, but considering that a new keyword may break existing code,
I would favor using 'auto', because less conservative proposals for
properties have already been rejected. Also, aside from the actual meaning
of 'property' in Objective-C++ and CLI, there are many library based
implementations(Like Richard's) which are called 'property'.
Sean,
Properties are meant to aid in encapsulation, and code readability.
Reflection is unrelated to this issue.
Saying that "C++ doesn't need properties" is like saying "C++ doesn't
need lambda functions" or "C++ doesn't need range-based for loops", There
are many cases where properties would allow for cleaner code that is easier
to read, and easier to write.
The case for properties has already been made. Java, C#, C++/CLI,
Objective-C, and D all benefit from properties, and if C++ were to include
them, a great many people would happily adopt them into their coding style.
The amount of questions and library-based solutions you can find on Google
should be more than enough to make that point.
As far as why not to have properties:
I am not suggesting the C# property syntax. (in response to your recent
blog post)
The method outlined in my original post does account for multiple return
types, multiple parameter types, and cv-qualified functions through
overloading.
I have seen the argument about properties hiding complexity many times, and
it's still wrong. In a managed language like C# or Java, I might be
concerned about abusive use of complex properties, because of the way that
the language is designed to be used, but I am sure that the C++ community
could handle them just fine. And if someone was careless enough to be
bitten by complex properties, I would be much more worried about them
forgetting to call delete on their raw pointers, or trying to implement
concurrency.
Above all, the complexity is *not *hidden. All properties would be clearly
marked as such in the header file, and provide the same guarantee about
their complexity as would a function. And when the situation arose that a
property was unusually complex, it could simply be omitted the same way
that the standard omits the std::forward_list::size(). The declaration
syntax I am suggesting also looks like a function, yet another clue about
it's complexity.
And for serialization, C++ properties would not provide any complication
that doesn't already exist in a class with functions-properties.
Richard,
The library approach is already well known, and suffers from several
problems:
-memory usage
-extra indirection
-more complicated syntax
-inability to use them in all cases that a variable would be allowed
And even though your code is relatively clean, the compiler couldn't
optimize it much without changing the observable size of the object.
Please say say If I have failed to comment, or misinterpreted any of your
concerns,
Thanks
--
---
You received this message because you are 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_2212_33335724.1377632772895
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">First of all, I appreciate everyone taking the time to res=
pond. However, I still stand by my suggested implementation of properties.<=
div><div><br></div><div>Daniel,</div><div><br></div><div> I do agree =
that there is a small chance for a mix-up, but any new language feature wou=
ld introduce some kind of learning curve. Considering the current usage of =
const, virtual, default, and delete, I think that the relative complexity o=
f a second usage of auto is very low, due to the fact that the current usag=
e of 'auto' is very localized(used only in the place of a type).</div><div>=
<br></div><div> Also, I do agree that giving properties their own con=
textual keyword would be ideal, but considering that a new keyword may brea=
k existing code, I would favor using 'auto', because less conservative prop=
osals for properties have already been rejected. Also, aside from the actua=
l meaning of 'property' in Objective-C++ and CLI, there are many library ba=
sed implementations(Like Richard's) which are called 'property'.</div><div>=
<br></div><div><br></div><div>Sean,</div><div><br></div><div> Propert=
ies are meant to aid in encapsulation, and code readability. Reflection is =
unrelated to this issue.</div><div><br></div><div> Saying that "C++ d=
oesn't need properties" is like saying "C++ doesn't need lambda functions" =
or "C++ doesn't need range-based for loops", There are many cases where pro=
perties would allow for cleaner code that is easier to read, and easier to =
write.</div><div><br></div><div> The case for properties has already =
been made. Java, C#, C++/CLI, Objective-C, and D all benefit from propertie=
s, and if C++ were to include them, a great many people would happily=
adopt them into their coding style. The amount of questions and library-ba=
sed solutions you can find on Google should be more than enough to make tha=
t point.</div><div><br></div><div>As far as why not to have properties:</di=
v><div><br></div><div>I am not suggesting the C# property syntax. (in respo=
nse to your recent blog post)</div><div>The method outlined in my original =
post does account for multiple return types, multiple parameter types, and =
cv-qualified functions through overloading.</div><div><br></div><div>I have=
seen the argument about properties hiding complexity many times, and it's =
still wrong. In a managed language like C# or Java, I might be concerned ab=
out abusive use of complex properties, because of the way that the language=
is designed to be used, but I am sure that the C++ community could handle =
them just fine. And if someone was careless enough to be bitten by complex =
properties, I would be much more worried about them forgetting to call dele=
te on their raw pointers, or trying to implement concurrency.</div><div><br=
></div><div>Above all, the complexity is <b>not </b>hidden. All p=
roperties would be clearly marked as such in the header file, and provide t=
he same guarantee about their complexity as would a function. And when the =
situation arose that a property was unusually complex, it could simply be o=
mitted the same way that the standard omits the std::forward_list::size(). =
The declaration syntax I am suggesting also looks like a function, yet anot=
her clue about it's complexity.</div><div><br></div><div>And for serializat=
ion, C++ properties would not provide any complication that doesn't already=
exist in a class with functions-properties.</div><div><br></div><div><br><=
/div><div>Richard,</div><div><br></div><div>The library approach is already=
well known, and suffers from several problems:</div><div>-memory usage</di=
v><div>-extra indirection</div><div>-more complicated syntax</div><div>-ina=
bility to use them in all cases that a variable would be allowed</div></div=
><div><br></div><div>And even though your code is relatively clean, the com=
piler couldn't optimize it much without changing the observable size of the=
object.</div><div><br></div><div><br></div><div><br></div><div>Please say =
say If I have failed to comment, or misinterpreted any of your concerns,</d=
iv><div><br></div><div> Thanks</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2212_33335724.1377632772895--
.
Author: =?ISO-8859-1?Q?Daniel_Kr=FCgler?= <daniel.kruegler@gmail.com>
Date: Tue, 27 Aug 2013 21:49:51 +0200
Raw View
2013/8/27 <nicolas.jinchereau@gmail.com>:
> Also, I do agree that giving properties their own contextual keyword would
> be ideal, but considering that a new keyword may break existing code,
Could you please explain the risk of code breakage assuming a
contextual keyword? (If you have macros in your mind, I would agree,
but at the moment I don't think you mean them here).
- 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/.
.
Author: nicolas.jinchereau@gmail.com
Date: Tue, 27 Aug 2013 13:42:32 -0700 (PDT)
Raw View
------=_Part_4748_19064790.1377636152738
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Daniel,
Actually, you are correct. I was mistaken about the usage of contextual=20
keywords. But if another keyword were to be introduced, I don't think=20
property would be the best candidate because of it's varied usage in=20
different dialects of C++.
Objective-C++:
@property (getter=3DgetNumber) int number;
C++ CLI:
property int number { int get() { return x; } }
GCC also has __attribute__ (alias (...)); which I believe can be used like=
=20
a property.
auto_property as a contextual keyword would be fine by me though.
I also wonder if anyone would consider 'auto_' to be indicative of the=20
possible performance implications.
On Tuesday, 27 August 2013 15:49:51 UTC-4, Daniel Kr=FCgler wrote:
>
> 2013/8/27 <nicolas.j...@gmail.com <javascript:>>:=20
> > Also, I do agree that giving properties their own contextual keyword=
=20
> would=20
> > be ideal, but considering that a new keyword may break existing code,=
=20
>
> Could you please explain the risk of code breakage assuming a=20
> contextual keyword? (If you have macros in your mind, I would agree,=20
> but at the moment I don't think you mean them here).=20
>
> - Daniel=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_4748_19064790.1377636152738
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Daniel,</div><div><br></div>Actually, you are correct=
.. I was mistaken about the usage of contextual keywords. But if another key=
word were to be introduced, I don't think property would be the best candid=
ate because of it's varied usage in different dialects of C++.<div><br></di=
v><div>Objective-C++:</div><div>@property (getter=3DgetNumber) int number;<=
/div><div><br></div><div>C++ CLI:</div><div>property int number { int get()=
{ return x; } }</div><div><div><br></div><div>GCC also has __attribute__ (=
alias (...)); which I believe can be used like a property.</div><div><br></=
div><div><br></div><div>auto_property as a contextual keyword would be fine=
by me though.</div><div><br></div><div>I also wonder if anyone would consi=
der 'auto_' to be indicative of the possible performance implications.</div=
><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div=
><div><br>On Tuesday, 27 August 2013 15:49:51 UTC-4, Daniel Kr=FCgler wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;b=
order-left: 1px #ccc solid;padding-left: 1ex;">2013/8/27 <<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"2irLVjaw1AsJ">n=
icolas.j...@gmail.com</a><wbr>>:
<br>> Also, I do agree that giving properties their own contextua=
l keyword would
<br>> be ideal, but considering that a new keyword may break existing co=
de,
<br>
<br>Could you please explain the risk of code breakage assuming a
<br>contextual keyword? (If you have macros in your mind, I would agree,
<br>but at the moment I don't think you mean them here).
<br>
<br>- Daniel
<br></blockquote></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4748_19064790.1377636152738--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Tue, 27 Aug 2013 13:48:44 -0700
Raw View
On ter=E7a-feira, 27 de agosto de 2013 13:42:32, nicolas.jinchereau@gmail.c=
om=20
wrote:
> auto_property as a contextual keyword would be fine by me though.
>=20
> I also wonder if anyone would consider 'auto_' to be indicative of the
> possible performance implications.
Given past extensions, I guess we would choose a property with no "_" in th=
e=20
name. From C++11 language extensions, the only place where I remember seein=
g _=20
was in attributes (carries_dependency) and even then it was not in all case=
s=20
([[noreturn]]).
So, given the precedent created by "noexcept" and "constexpr", I believe th=
e=20
keyword should be "autoprop". :-)
--=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/.
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Tue, 27 Aug 2013 15:59:52 -0500
Raw View
Thiago Macieira <thiago@macieira.org> writes:
| On ter=E7a-feira, 27 de agosto de 2013 13:42:32, nicolas.jinchereau@gmail=
..com=20
| wrote:
| > auto_property as a contextual keyword would be fine by me though.
| >=20
| > I also wonder if anyone would consider 'auto_' to be indicative of the
| > possible performance implications.
|=20
| Given past extensions, I guess we would choose a property with no "_" in =
the=20
| name. From C++11 language extensions, the only place where I remember see=
ing _=20
| was in attributes (carries_dependency) and even then it was not in all ca=
ses=20
| ([[noreturn]]).
or static_assert.
| So, given the precedent created by "noexcept" and "constexpr", I believe =
the=20
| keyword should be "autoprop". :-)
is that for something that propulses itself?
--=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/.
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 27 Aug 2013 16:31:26 -0700 (PDT)
Raw View
------=_Part_5213_29679091.1377646287119
Content-Type: text/plain; charset=ISO-8859-1
On Tuesday, August 27, 2013 12:46:12 PM UTC-7, Nick wrote:
> The case for properties has already been made. Java, C#, C++/CLI,
> Objective-C, and D all benefit from properties, and if C++ were to include
> them, a great many people would happily adopt them into their coding style.
> The amount of questions and library-based solutions you can find on Google
> should be more than enough to make that point.
>
No, the case for properties in Java, C#, C++/CLI, Objective-C, and D is
made. The case for them in C++ is not.
That a great many people would adopt them is also not an issue. A great
many people would adopt eval() if it were somehow added. Doesn't make it
automatically a great idea. You need to prove properties are actually
beneficial in some way besides "hey, those other guys did it and some
people like it."
You'll also need to think about issues like how property overriding/hiding
interacts (with and without virtual), and how overloading interacts (can I
define three different setters for the same property?), what taking the
address of a property means (address of the getter? of the setter? which
one?), how you can directly access a getter or setter as a method for
template metaprogramming, etc. This is not a trivial set of problems to
solve. They're solvable, but realize you'll need to do that to make a
decent proposal paper for the 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/.
------=_Part_5213_29679091.1377646287119
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Tuesday, August 27, 2013 12:46:12 PM UTC-7, Nick wrote:=
<div> </div><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><div> The case for properties has already been made. Java, C=
#, C++/CLI, Objective-C, and D all benefit from properties, and if C+=
+ were to include them, a great many people would happily adopt them into t=
heir coding style. The amount of questions and library-based solutions you =
can find on Google should be more than enough to make that point.</div></di=
v></div></blockquote><div><br></div><div>No, the case for properties in Jav=
a, C#, C++/CLI, Objective-C, and D is made. The case for them in C++ =
is not.</div><div><br></div><div>That a great many people would adopt them =
is also not an issue. A great many people would adopt eval() if it we=
re somehow added. Doesn't make it automatically a great idea. Y=
ou need to prove properties are actually beneficial in some way besides "he=
y, those other guys did it and some people like it."</div><div><br></div><d=
iv>You'll also need to think about issues like how property overriding/hidi=
ng interacts (with and without virtual), and how overloading interacts (can=
I define three different setters for the same property?), what taking the =
address of a property means (address of the getter? of the setter? &n=
bsp;which one?), how you can directly access a getter or setter as a method=
for template metaprogramming, etc. This is not a trivial set of prob=
lems to solve. They're solvable, but realize you'll need to do that t=
o make a decent proposal paper for the committee.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_5213_29679091.1377646287119--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Tue, 27 Aug 2013 17:23:07 -0700 (PDT)
Raw View
------=_Part_886_3906664.1377649388055
Content-Type: text/plain; charset=ISO-8859-1
Sean,
I don't see a problem with a property behaving exactly as a regular
getter/setter function with respect to hiding, overriding, overloading,
etc. They are basically declared as functions, but with an extra keyword
modifying them, and I think it would be counter-intuitive to implement
their declaration in any other way.
The difference with properties, would be how they behaved in code. They
would behave mostly like a variable, but with one restriction. At each
instance where a variable would be retrieved or stored, the respective
overload of the getter or setter would be called instead. If the address of
a property was taken, it would be equivalent to taking the address of a
function. Unless the return type was a reference, the behavior exhibited
would be that of taking the address of a temporary returned from a function.
In terms of interaction with templates, I don't see any reason they
couldn't use the same syntax as functions, but without the braces "()". The
same rules for template deduction of a function parameter would apply to
the right hand side of a property assignment.
For example,
object.property = 5; // deduced as int
int a = object.property<int>; // if a templated getter was declared.
I don't think that specifying the semantics for a property are trivial, but
I don't believe they are a journey into the unknown either. The semantics
of the language have already been decided, and a property would be nothing
more than a mixture of the semantics of a function declaration, and the
semantics of variable usage, with a small overlap of the function semantics
towards the side of usage.
If the time came for me to write a proposal, I am confident I could
describe the semantics of properties in full.
Could anyone with compiler experience comment on the difficulty of
implementing something like this?
--
---
You received this message because you are 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_886_3906664.1377649388055
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Sean,</div><div><br></div><div>I don't see a problem =
with a property behaving exactly as a regular getter/setter function with r=
espect to hiding, overriding, overloading, etc. They are basically declared=
as functions, but with an extra keyword modifying them, and I think it wou=
ld be counter-intuitive to implement their declaration in any other way.</d=
iv><div><br></div><div>The difference with properties, would be how they be=
haved in code. They would behave mostly like a variable, but with one restr=
iction. At each instance where a variable would be retrieved or stored, the=
respective overload of the getter or setter would be called instead. If th=
e address of a property was taken, it would be equivalent to taking the add=
ress of a function. Unless the return type was a reference, the behavior ex=
hibited would be that of taking the address of a temporary returned from a =
function.</div><div><br></div><div>In terms of interaction with templates, =
I don't see any reason they couldn't use the same syntax as functions, but =
without the braces "()". The same rules for template deduction of a functio=
n parameter would apply to the right hand side of a property assignment.</d=
iv><div><br></div><div>For example,</div><div>object.property =3D 5; // ded=
uced as int</div><div>int a =3D object.property<int>; // if a templat=
ed getter was declared.</div><div><br></div><div><br></div><div>I don't thi=
nk that specifying the semantics for a property are trivial, but I don't be=
lieve they are a journey into the unknown either. The semantics of the lang=
uage have already been decided, and a property would be nothing more than a=
mixture of the semantics of a function declaration, and the semantics of v=
ariable usage, with a small overlap of the function semantics towards the s=
ide of usage.</div><div><br></div><div>If the time came for me to write a p=
roposal, I am confident I could describe the semantics of properties in ful=
l.</div><div><br></div><div><br></div>Could anyone with compiler experience=
comment on the difficulty of implementing something like this?</div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_886_3906664.1377649388055--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 28 Aug 2013 09:47:00 +0200
Raw View
How about doing the change in the other end:
Don't change anything in the class head, but allow an implicit=20
transformation:
object.property =3D value;
to
object.property(value);
IFF property is a function which has an overload that can be called with=20
a single parameter of value's type.
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!
The getter case is a little harder to accept for me, but I think it=20
would be possible to allow:
int value =3D 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=20
method without a leading & is not allowed when you really want to get at=20
the method pointer, so this should not be ambiguous. In contrast, it=20
would not be possible to omit the trailing () for a global function as=20
(due to feature inheritance from C) this means the address of the=20
function (correct me if I'm wrong on this).
Personally I am so entrenched with C++ that I don't really understand=20
how property syntax would improve the world, but if it is to enter the=20
language it seems that it can be done without adding keywords or=20
additional messy declarations in the headers. I do think that my=20
suggested approach could have some inherent dangers that I don't see=20
right now, especially the getter part of it.
Even if properties implemented like this could be parsed unambiguously=20
there is also the risk of too little redundancy: If every possible=20
combination of letters has a valid meaning there will be no error=20
messages to warn you when you are doing the wrong things with unexpected=20
results.
--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com
--=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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Aug 2013 11:12:33 +0300
Raw View
--001a11c212202fd70604e4fd8d8c
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 10:47, Bengt Gustafsson <bengt.gustafsson@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).
>
>
>
This would nicely take care of using properties, but the usual lure of
properties in other languages is that
they are very easy to define, too.
--
---
You received this message because you are 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/.
--001a11c212202fd70604e4fd8d8c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 August 2013 10:47, Bengt Gustafsson <span dir=3D"ltr"><<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">How about doing the change in the other end:=
<br>
<br>
Don't change anything in the class head, but allow an implicit transfor=
mation:<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 =
can interfer with an assignment that is allowed today. Also this is consist=
ent 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 method w=
ithout a leading & is not allowed when you really want to get at the me=
thod 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).<br>
<br><br></blockquote><div><br></div><div>This would nicely take care of usi=
ng properties, but the usual lure of properties in other languages is that<=
br>they are very easy to define, too. <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c212202fd70604e4fd8d8c--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Wed, 28 Aug 2013 13:50:04 +0200
Raw View
This is a multi-part message in MIME format.
--------------050104070808090006030005
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
Do they really have syntax which is significiantly simpler than the=20
classic setter/getter pair of C++?
Here is Microsoft's example for C#:
class TimePeriod
{
private double seconds;
public double Hours
{
get {return seconds / 3600; }
set { seconds =3D value * 3600; }
}
}
The only advantage would be that you only have to mention the name Hours=20
once. Instead you get an extra brace level and the keywords get and set.=20
To me that's about even, and I think the C++ class head would look much=20
cleaner:
class TimePeriod {
public:
double Hours() { return seconds / 3600; }
void Hours(double value) { seconds =3D value * 3600; }
private:
double seconds;
};
Ville Voutilainen skrev 2013-08-28 10:12:
>
>
>
> On 28 August 2013 10:47, Bengt Gustafsson=20
> <bengt.gustafsson@beamways.com <mailto:bengt.gustafsson@beamways.com>>=20
> 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 =3D 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 =3D 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).
>
>
>
> This would nicely take care of using properties, but the usual lure of=20
> properties in other languages is that
> they are very easy to define, too.
>
> --=20
>
> ---
> You received this message because you are subscribed to the Google=20
> Groups "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send=20
> an email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at=20
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Link=F6ping, Sweden
+46 13 465 10 85
www.beamways.com
--=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/.
--------------050104070808090006030005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta content=3D"text/html; charset=3DISO-8859-1"
http-equiv=3D"Content-Type">
</head>
<body text=3D"#000000" bgcolor=3D"#FFFFFF">
Do they really have syntax which is significiantly simpler than the
classic setter/getter pair of C++?<br>
<br>
Here is Microsoft's example for C#:<br>
<br>
<pre style=3D"padding: 5px; margin: 0px; font-family: Consolas, Courier=
, monospace; font-style: normal; font-weight: normal; overflow: auto; word-=
wrap: normal; color: rgb(0, 0, 0); font-size: 13px; font-variant: normal; l=
etter-spacing: normal; line-height: 17px; orphans: auto; text-align: start;=
text-indent: 0px; text-transform: none; widows: auto; word-spacing: 0px; -=
webkit-text-stroke-width: 0px;"><span style=3D"color: blue;">class</span> T=
imePeriod
{
<span style=3D"color: blue;">private</span> <span style=3D"color: =
blue;">double</span> seconds;
<span style=3D"color: blue;">public</span> <span style=3D"color: b=
lue;">double</span> Hours
{
<span style=3D"color: blue;">get</span> { <span style=3D"color: blu=
e;">return</span> seconds / 3600; }
<span style=3D"color: blue;">set</span> { seconds =3D value * 3600;=
}
}
}
</pre>
The only advantage would be that you only have to mention the name
Hours once. Instead you get an extra brace level and the keywords
get and set. To me that's about even, and I think the C++ class head
would look much cleaner:<br>
<br>
class TimePeriod {<br>
public:<br>
double Hours() { return seconds / 3600; }<br>
void Hours(double value) { seconds =3D value * 3600;=
}<br>
<br>
private:<br>
double seconds;<br>
};<br>
<br>
<br class=3D"Apple-interchange-newline">
<br>
<div class=3D"moz-cite-prefix">Ville Voutilainen skrev 2013-08-28
10:12:<br>
</div>
<blockquote
cite=3D"mid:CAFk2RUaqD5GJXhf54=3DT_ioc_JxLfRbPjaiV1QPVOKgV2gFk4MA@mail.gmai=
l.com"
type=3D"cite">
<div dir=3D"ltr"><br>
<div class=3D"gmail_extra"><br>
<br>
<div class=3D"gmail_quote">On 28 August 2013 10:47, Bengt
Gustafsson <span dir=3D"ltr"><<a moz-do-not-send=3D"true"
href=3D"mailto:bengt.gustafsson@beamways.com"
target=3D"_blank">bengt.gustafsson@beamways.com</a>></sp=
an>
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">How
about doing the change in the other end:<br>
<br>
Don't change anything in the class head, but allow an
implicit transformation:<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 can interfer with an assignment that is
allowed today. Also this is 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 be 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 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).<br>
<br>
<br>
</blockquote>
<div><br>
</div>
<div>This would nicely take care of using properties, but
the usual lure of properties in other languages is that<br>
they are very easy to define, too. <br>
</div>
</div>
<br>
</div>
</div>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google
Groups "ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it,
send an email to <a class=3D"moz-txt-link-abbreviated" href=3D"mailto=
:std-proposals+unsubscribe@isocpp.org">std-proposals+unsubscribe@isocpp.org=
</a>.<br>
To post to this group, send email to <a class=3D"moz-txt-link-abbrevi=
ated" href=3D"mailto:std-proposals@isocpp.org">std-proposals@isocpp.org</a>=
..<br>
Visit this group at <a moz-do-not-send=3D"true"
href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
>http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br>
</blockquote>
<br>
<pre class=3D"moz-signature" cols=3D"72">--=20
Bengt Gustafsson
CEO, Beamways AB
Westmansgatan 37A
582 16 Linköping, Sweden
+46 13 465 10 85
<a class=3D"moz-txt-link-abbreviated" href=3D"http://www.beamways.com">www.=
beamways.com</a>
</pre>
</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--------------050104070808090006030005--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Aug 2013 15:00:32 +0300
Raw View
--001a11c3d73c82a1d304e500bcd3
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 14:50, Bengt Gustafsson <bengt.gustafsson@beamways.com>wrote:
> Do they really have syntax which is significiantly simpler than the
> classic setter/getter pair of C++?
>
> Here is Microsoft's example for C#:
>
> class TimePeriod
> {
> private double seconds;
>
> public double Hours
> {
> get { return seconds / 3600; }
> set { seconds = value * 3600; }
> }
> }
>
>
Take a look at http://msdn.microsoft.com/en-us/library/bb384054.aspx for
"auto-implemented properties". Those
are rather shorter when there's no need to customize the get/set operations.
--
---
You received this message because you are 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/.
--001a11c3d73c82a1d304e500bcd3
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 August 2013 14:50, Bengt Gustafsson <span dir=3D"ltr"><<a =
href=3D"mailto:bengt.gustafsson@beamways.com" target=3D"_blank">bengt.gusta=
fsson@beamways.com</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
Do they really have syntax which is significiantly simpler than the
classic setter/getter pair of C++?<br>
<br>
Here is Microsoft's example for C#:<br>
<br>
<pre style=3D"text-indent:0px;letter-spacing:normal;font-variant:normal=
;text-align:start;font-style:normal;font-weight:normal;padding:5px;line-hei=
ght:17px;text-transform:none;overflow:auto;font-size:13px;margin:0px;font-f=
amily:Consolas,Courier,monospace;word-wrap:normal;word-spacing:0px">
<span style=3D"color:blue">class</span> TimePeriod
{
<span style=3D"color:blue">private</span>=A0<span style=3D"color:blue">=
double</span> seconds;
<span style=3D"color:blue">public</span>=A0<span style=3D"color:blue">d=
ouble</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></blockquote><div><br></div><div>Take a look at <a href=3D"htt=
p://msdn.microsoft.com/en-us/library/bb384054.aspx">http://msdn.microsoft.c=
om/en-us/library/bb384054.aspx</a> for "auto-implemented properties&qu=
ot;. Those<br>
are rather shorter when there's no need to customize the get/set operat=
ions.<br><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c3d73c82a1d304e500bcd3--
.
Author: cornedbee@google.com
Date: Wed, 28 Aug 2013 05:32:21 -0700 (PDT)
Raw View
------=_Part_240_22012991.1377693141542
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, August 28, 2013 1:50:04 PM UTC+2, Bengt Gustafsson wrote:
>
> Do they really have syntax which is significiantly simpler than the
> classic setter/getter pair of C++?
>
>
Properties are about the usage syntax, not the declaration 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.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
------=_Part_240_22012991.1377693141542
Content-Type: text/html; charset=ISO-8859-1
<div dir="ltr"><br><br>On Wednesday, August 28, 2013 1:50:04 PM UTC+2, Bengt Gustafsson wrote:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">
<div text="#000000" bgcolor="#FFFFFF">
Do they really have syntax which is significiantly simpler than the
classic setter/getter pair of C++?<br><pre cols="72"></pre></div></blockquote><div><br></div><div>Properties are about the usage syntax, not the declaration syntax. </div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_240_22012991.1377693141542--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Aug 2013 16:42:25 +0300
Raw View
--089e0139ff76e2d72d04e50228a4
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 15:32, <cornedbee@google.com> wrote:
>
>
> On Wednesday, August 28, 2013 1:50:04 PM UTC+2, Bengt Gustafsson wrote:
>>
>> Do they really have syntax which is significiantly simpler than the
>> classic setter/getter pair of C++?
>>
>>
> Properties are about the usage syntax, not the declaration syntax.
>
>
>
>
If that's the case (with which I disagree), we certainly don't need any
language changes for
properties, since public non-static data members of reference or proxy
class type achieve
the usage syntax just fine.
--
---
You received this message because you are 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/.
--089e0139ff76e2d72d04e50228a4
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 August 2013 15:32, <span dir=3D"ltr"><<a href=3D"mailto:c=
ornedbee@google.com" target=3D"_blank">cornedbee@google.com</a>></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"im"><br><br>O=
n Wednesday, August 28, 2013 1:50:04 PM UTC+2, Bengt Gustafsson wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
=20
=20
=20
<div text=3D"#000000" bgcolor=3D"#FFFFFF">
Do they really have syntax which is significiantly simpler than the
classic setter/getter pair of C++?<br><pre cols=3D"72"></pre></div></bl=
ockquote><div><br></div></div><div>Properties are about the usage syntax, n=
ot the declaration syntax.=A0</div></div><div class=3D"HOEnZb"><div class=
=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>If that's the case=
(with which I disagree), we certainly don't need any language changes =
for<br>properties, since public non-static data members of reference or pro=
xy class type achieve<br>
the usage syntax just fine.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0139ff76e2d72d04e50228a4--
.
Author: Sean Middleditch <sean@middleditch.us>
Date: Wed, 28 Aug 2013 10:00:20 -0700
Raw View
On Tue, Aug 27, 2013 at 5:23 PM, Nick <nicolas.jinchereau@gmail.com> wrote:
> Sean,
>
> I don't see a problem with a property behaving exactly as a regular
> getter/setter function with respect to hiding, overriding, overloading, etc.
> They are basically declared as functions, but with an extra keyword
> modifying them, and I think it would be counter-intuitive to implement their
> declaration in any other way.
>
> The difference with properties, would be how they behaved in code. They
> would behave mostly like a variable, but with one restriction. At each
> instance where a variable would be retrieved or stored, the respective
> overload of the getter or setter would be called instead. If the address of
> a property was taken, it would be equivalent to taking the address of a
> function. Unless the return type was a reference, the behavior exhibited
> would be that of taking the address of a temporary returned from a function.
No, you need _way_ more than one modification.
They break usage of things that look like member variables everywhere.
Many simple templates, macros, and other libraries that make a simple
logical assumption like "std::addressof(x.y)" gives you the address of
x.y, which with properties could be the address of a temporary
returned by x.y(). Yuck.
Again, the problems could be solved with some additional work, but
that work needs to be thought through. Given an `x.y` kind of
expression, how can you tell if it's a property? Do we need a whole
new set of traits like is_field_assignable, is_field_readable, etc.?
What do mutating assignment operators like += do with a property; not
work at all, or expand out into separate get/set, or intelligently
determine if the property getter returns a reference or a type with an
overloaded +=? How do properties interact with N3617 (Lifting
Overload Sets into Function Objects) ? Do properties work in method
bodies and how to they interact with two-phase name lookup if at all?
What about properties and setters with more than one parameter and
initializer lists? Member initializers? etc.
>
> If the time came for me to write a proposal, I am confident I could describe
> the semantics of properties in full.
Go ahead and do it then. :) This forum is not some kind of gateway
to being allowed to write a paper. A good number of the people who
post here (myself included) are not part of the committee and have
_zero_ say on what goes into the standard.
There still has been zero cases made for why anyone thinks C++ needs
these besides "C# does it" or the like. What problems do properties
solve that are unsolved (or poorly/awkwardly solved) right now in
C++11/14? It's not satisfying my worries that are important (I have
zero say on what goes into the standard), but the committee is going
to ask these questions, demand answers, and are usually
_significantly_ more conservative than I am being 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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Aug 2013 20:17:52 +0300
Raw View
--001a11c2c6bc6b68de04e5052b0e
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 20:00, Sean Middleditch <sean@middleditch.us> wrote:
>
> There still has been zero cases made for why anyone thinks C++ needs
> these besides "C# does it" or the like. What problems do properties
> solve that are unsolved (or poorly/awkwardly solved) right now in
> C++11/14? It's not satisfying my worries that are important (I have
> zero say on what goes into the standard), but the committee is going
> to ask these questions, demand answers, and are usually
> _significantly_ more conservative than I am being here. :)
>
>
>
There is one thing I am going to ask before anything else:
What on earth do we need besides a library solution pretty much like what
Richard outlined, and why would we need anything other than that?
--
---
You received this message because you are 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/.
--001a11c2c6bc6b68de04e5052b0e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 August 2013 20:00, Sean Middleditch <span dir=3D"ltr"><<a =
href=3D"mailto:sean@middleditch.us" target=3D"_blank">sean@middleditch.us</=
a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
There still has been zero cases made for why anyone thinks C++ needs<br>
these besides "C# does it" or the like. =A0What problems do prope=
rties<br>
solve that are unsolved (or poorly/awkwardly solved) right now in<br>
C++11/14? =A0It's not satisfying my worries that are important (I have<=
br>
zero say on what goes into the standard), but the committee is going<br>
to ask these questions, demand answers, and are usually<br>
_significantly_ more conservative than I am being here. :)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br><br></div></div></blockquote><d=
iv><br></div><div>There is one thing I am going to ask before anything else=
:<br></div><div>What on earth do we need besides a library solution pretty =
much like what<br>
</div><div>Richard outlined, and why would we need anything other than that=
?<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c2c6bc6b68de04e5052b0e--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 28 Aug 2013 21:13:26 +0200
Raw View
On Wed, 2013-08-28 at 20:17 +0300, Ville Voutilainen wrote:
>
>
>
> On 28 August 2013 20:00, Sean Middleditch <sean@middleditch.us> wrote:
> There is one thing I am going to ask before anything else:
>
> What on earth do we need besides a library solution pretty much like
> what
>
> Richard outlined, and why would we need anything other than that?
>
One thing an explicit property buys over library solutions is that the
reference to the containing instance becomes implicit.
No, I do not think that is enough of an advantage to add properties to
the language.
/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/.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Wed, 28 Aug 2013 23:22:04 +0300
Raw View
--001a11c3d73c20a3cf04e507be28
Content-Type: text/plain; charset=ISO-8859-1
On 28 August 2013 22:52, Nick <nicolas.jinchereau@gmail.com> wrote:
> I have to disagree with this.
>
> With Richard's implementation, taking sizeof(property<int>) yields 48
> bytes.
>
Very likely, it's using std::function which is not the lightest or fastest
thing on the planet.
>
>
> The function pointers can be done away with using some very convoluted
> template syntax, but the reference to the container must still exist,
> making the minimum possible size of a library based property 4 bytes, which
> is still not negligible.
>
>
>
Well... I have no trouble making the functions smaller, just by avoiding
std::function. The trouble with such
solutions is that I would need a combination of an auto member and a maker
function (the call to which would be
a non-static data member initializer) to make it really palatable.
I can store data inside a property, avoiding the "reference to the
container".
The library approach is not without downsides, but some of them are
fixable. At any rate, fixing those downsides
would be worth trying before we run head-over-heels towards standardizing
property keywords.
--
---
You received this message because you are 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/.
--001a11c3d73c20a3cf04e507be28
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 28 August 2013 22:52, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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><span style=3D"font-si=
ze:13px">I have to disagree with this.</span></div><div><span style=3D"font=
-size:13px"><br>
</span></div><div>With Richard's implementation, taking sizeof(property=
<int>) yields 48 bytes.</div></div></blockquote><div><br></div><div>V=
ery likely, it's using std::function which is not the lightest or faste=
st thing on the planet.<br>
=A0<br></div><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"><br><div><br><=
/div><div>The function pointers can be done away with using some very convo=
luted template syntax,=A0<span style=3D"font-size:13px">but the reference t=
o the container must still exist, making the minimum possible size of a lib=
rary based property 4 bytes, which is still not negligible.</span></div>
<div class=3D"im"><div><span style=3D"font-size:13px"><br><br></span></div>=
</div></div></blockquote><div><br></div><div>Well... I have no trouble maki=
ng the functions smaller, just by avoiding std::function. The trouble with =
such<br>
solutions is that I would need a combination of an auto member and a maker =
function (the call to which would be<br>a non-static data member initialize=
r) to make it really palatable.<br><br></div><div>I can store data inside a=
property, avoiding the "reference to the container".<br>
</div></div><br></div><div class=3D"gmail_extra">The library approach is no=
t without downsides, but some of them are fixable. At any rate, fixing thos=
e downsides<br>would be worth trying before we run head-over-heels towards =
standardizing property keywords.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c3d73c20a3cf04e507be28--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Wed, 28 Aug 2013 14:24:44 -0700
Raw View
--001a11c1dd02489c5504e5089edc
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Aug 28, 2013 at 12:52 PM, Nick <nicolas.jinchereau@gmail.com> wrote:
> I have to disagree with this.
>
> With Richard's implementation, taking sizeof(property<int>) yields 48
> bytes.
>
> So if you had an object with 10 properties, you would have a half a
> kilobyte of extra data per instance.
>
> The function pointers can be done away with using some very convoluted
> template syntax, but the reference to the container must still exist,
> making the minimum possible size of a library based property 4 bytes, which
> is still not negligible.
>
Yes, the code I presented is not ideal, in a number of ways. The storage
overhead is one. Another is that "a.number = b.number" does not compile,
and classes containing such properties become non-copyable ("a.number =
b.number;" would need to do different things depending on whether it
happens in the surrounding class's copy-assignment operator).
But... if we can find a set of language changes that suffice to make a
library implementation of properties work better, we are likely to improve
the language as a whole rather than adding a single point feature.
> On Wednesday, 28 August 2013 15:13:26 UTC-4, Magnus Fromreide wrote:
>
>> On Wed, 2013-08-28 at 20:17 +0300, Ville Voutilainen wrote:
>> >
>> >
>> >
>> > On 28 August 2013 20:00, Sean Middleditch <se...@middleditch.us>
>> wrote:
>>
>> > There is one thing I am going to ask before anything else:
>> >
>> > What on earth do we need besides a library solution pretty much like
>> > what
>> >
>> > Richard outlined, and why would we need anything other than that?
>> >
>>
>> One thing an explicit property buys over library solutions is that the
>> reference to the containing instance becomes implicit.
>>
>> No, I do not think that is enough of an advantage to add properties to
>> the language.
>>
>> /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/.
>
--
---
You received this message because you are 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/.
--001a11c1dd02489c5504e5089edc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wed, Aug 28, 2013 at 12:52 PM, Nick <span dir=3D"ltr">&=
lt;<a href=3D"mailto:nicolas.jinchereau@gmail.com" target=3D"_blank">nicola=
s.jinchereau@gmail.com</a>></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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><span style=3D"font-si=
ze:13px">I have to disagree with this.</span></div><div><span style=3D"font=
-size:13px"><br>
</span></div><div>With Richard's implementation, taking sizeof(property=
<int>) yields 48 bytes.</div><div><br></div><div>So if you had an obj=
ect with 10 properties, you would have a half a kilobyte of extra data per =
instance.</div>
<div><br></div><div>The function pointers can be done away with using some =
very convoluted template syntax,=A0<span style=3D"font-size:13px">but the r=
eference to the container must still exist, making the minimum possible siz=
e of a library based property 4 bytes, which is still not negligible.</span=
></div>
</div></blockquote><div><br></div><div>Yes, the code I presented is not ide=
al, in a number of ways. The storage overhead is one. Another is that "=
;a.number =3D b.number" does not compile, and classes containing such =
properties become non-copyable ("a.number =3D b.number;" would ne=
ed to do different things depending on whether it happens in the surroundin=
g class's copy-assignment operator).</div>
<div><br></div><div>But... if we can find a set of language changes that su=
ffice to make a library implementation of properties work better, we are li=
kely to improve the language as a whole rather than adding a single point f=
eature.</div>
<div>=A0</div><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 class=3D=
"im"><span style=3D"font-size:13px">On Wednesday, 28 August 2013 15:13:26 U=
TC-4, Magnus Fromreide wrote:</span><br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im">On Wed, 201=
3-08-28 at 20:17 +0300, Ville Voutilainen wrote:
<br>>=20
<br>>=20
<br>>=20
<br></div><div class=3D"im">> On 28 August 2013 20:00, Sean Middleditch =
<<a>se...@middleditch.us</a>> wrote:
<br>
<br>> There is one thing I am going to ask before anything else:
<br>>=20
<br>> What on earth do we need besides a library solution pretty much li=
ke
<br>> what
<br>>=20
<br>> Richard outlined, and why would we need anything other than that?
<br>>=20
<br>
<br>One thing an explicit property buys over library solutions is that the
<br>reference to the containing instance becomes implicit.
<br>
<br>No, I do not think that is enough of an advantage to add properties to
<br>the language.
<br>
<br>/MF
<br>
<br>
<br></div></blockquote></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
=A0<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" 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/" 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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c1dd02489c5504e5089edc--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Wed, 28 Aug 2013 15:30:18 -0700 (PDT)
Raw View
------=_Part_819_7158214.1377729018440
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, 28 August 2013 17:24:44 UTC-4, Richard Smith wrote:
> On Wed, Aug 28, 2013 at 12:52 PM, Nick <nicolas.j...@gmail.com<javascript:>
> > wrote:
>
>> I have to disagree with this.
>>
>> With Richard's implementation, taking sizeof(property<int>) yields 48
>> bytes.
>>
>> So if you had an object with 10 properties, you would have a half a
>> kilobyte of extra data per instance.
>>
>> The function pointers can be done away with using some very convoluted
>> template syntax, but the reference to the container must still exist,
>> making the minimum possible size of a library based property 4 bytes, which
>> is still not negligible.
>>
>
> Yes, the code I presented is not ideal, in a number of ways. The storage
> overhead is one. Another is that "a.number = b.number" does not compile,
> and classes containing such properties become non-copyable ("a.number =
> b.number;" would need to do different things depending on whether it
> happens in the surrounding class's copy-assignment operator).
>
> But... if we can find a set of language changes that suffice to make a
> library implementation of properties work better, we are likely to improve
> the language as a whole rather than adding a single point feature.
>
There are several more problems with library properties beside the storage
overhead.
Let's consider that we used the following template implementation, which
still takes 4 bytes per property:
template<typename T, class C, T(C::*get)(), void(C::*set)(T)>
struct property {
C *object;
property(C *object) : object(object){}
operator T() { return (object->*get)(); }
template<typename U> property &operator=(U &&u) { (object->*set)(std::
forward<U>(u)); return *this; }
}
1) But consider using it on a Point:
struct Point
{
float x, y;
Point(float x = 0, float y = 0) : x(x), y(y){}
};
How would you provide access to the members of Point with library
properties?
struct Test {
property<Point, ...> point;
};
Test test;
cout << test.point.x << endl;
Currently, the only option available is to override T* operator->()
const T* property::operator->() { return &(object->*get)(); }
but unless C::get() returns a reference, which it very likely won't, then
this code will be returning a reference to a temporary. This may not cause
problems, since that temporary is read only, but may will fail to compile
or generate warnings on some compilers.
2) No function overloading could be done for the setter.
3) specific functionality of the property's type would be hidden:
Consider if Point had operator+=()
Point& operator+=(const Point &p) { x += p.x; y += p.y; return *this; }
The following code would not compile:
test.point += Point(5, 6);
Whereas, with a real property, the get and set methods of the property
could be called to retrieve and store the value.
Now, a partial solution may be to include commonly used operators inside
the property class:
template<typename U>
property &operator+=(U &&u) {
T tmp = (object->*get)();
tmp += u;
(object->*set)(std::forward<U>(tmp));
return *this;
}
And since this is a template, I'm pretty sure(vs2012 and mingw tested) it
should be ignored for classes that don't have an operator+= unless you
actually try to use it, but that doesn't fix the problem that you still
have to include every operator manually into your property class.
If you started to use a class that had a ToString() method, now you would
need to incorporate that into your property too, and the list would go on
endlessly.
4) Finally if something like offsetof() was standardized to work on non-POD
types, there would be a way to get rid of that last 4 bytes per property,
but currently, it is not. And I say "something like" because assuming that
offsetof() did work, it would still require macros to get the job done. A
real piece of builtin compiler magic would still be needed to get a pointer
to the enclosing instance of an object.
Now, this is just the begining, but I'm sure I could go on for a few more
hours at least.
--
---
You received this message because you are 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_819_7158214.1377729018440
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Wednesday, 28 August 2=
013 17:24:44 UTC-4, Richard Smith wrote:</span><br><blockquote class=3D"gm=
ail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc soli=
d;padding-left: 1ex;"><div dir=3D"ltr">On Wed, Aug 28, 2013 at 12:52 PM, Ni=
ck <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfu=
scated-mailto=3D"4QacqHzBpXUJ">nicolas.j...@gmail.com</a>></span> wrote:=
<br><div><div class=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"><div><span style=3D"font-si=
ze:13px">I have to disagree with this.</span></div><div><span style=3D"font=
-size:13px"><br>
</span></div><div>With Richard's implementation, taking sizeof(property<=
int>) yields 48 bytes.</div><div><br></div><div>So if you had an object =
with 10 properties, you would have a half a kilobyte of extra data per inst=
ance.</div>
<div><br></div><div>The function pointers can be done away with using some =
very convoluted template syntax, <span style=3D"font-size:13px">but th=
e reference to the container must still exist, making the minimum possible =
size of a library based property 4 bytes, which is still not negligible.</s=
pan></div>
</div></blockquote><div><br></div><div>Yes, the code I presented is not ide=
al, in a number of ways. The storage overhead is one. Another is that "a.nu=
mber =3D b.number" does not compile, and classes containing such properties=
become non-copyable ("a.number =3D b.number;" would need to do different t=
hings depending on whether it happens in the surrounding class's copy-assig=
nment operator).</div>
<div><br></div><div>But... if we can find a set of language changes that su=
ffice to make a library implementation of properties work better, we are li=
kely to improve the language as a whole rather than adding a single point f=
eature.</div></div></div></div></blockquote><div> </div><div><br></div=
><div><br></div><div>There are several more problems with library propertie=
s beside the storage overhead.</div><div><br></div><div>Let's consider that=
we used the following template implementation, which still takes 4 bytes p=
er property:</div><div><br></div><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border: 1px solid 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">template</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span =
style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> T</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: #008;" class=
=3D"styled-by-prettify">class</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> C</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">C</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">::*</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">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">void</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify">C</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
::*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">set</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">)(</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"colo=
r: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">struct</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> C </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">*</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">object</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"><br> property</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">C </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ob=
ject</span><span style=3D"color: #660;" class=3D"styled-by-prettify">)</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: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">object</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">object</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">){}</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br><br> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">operator</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> T</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">{</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </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: #008;" =
class=3D"styled-by-prettify">object</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">->*</span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">)();</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </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"styled-by-prettify">te=
mplate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><=
</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">></span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> property </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">operator</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D(</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify">U </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&&</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify">u</span><span style=3D"color: #660;" class=3D"s=
tyled-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 sty=
le=3D"color: #008;" class=3D"styled-by-prettify">object</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">->*</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">set</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)(</span><span style=3D"color: #000;" c=
lass=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">forward</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">u</span><s=
pan 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"> </span><span style=3D"color: #660;" cl=
ass=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">;</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">}</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></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></div></code></di=
v><div><br></div><div>1) <span style=3D"font-size: 13px;">But consider=
using it on a Point:</span></div><div><br></div><div><div class=3D"prettyp=
rint" style=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(=
187, 187, 187); word-wrap: break-word;"><code class=3D"prettyprint"><div cl=
ass=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">struct</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Point</=
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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">,</span><font color=3D"#000000">=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> y</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">;</span></font><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><font color=3D"#=
000000"><span style=3D"color: #000;" class=3D"styled-by-prettify"> &n=
bsp; </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Point=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><s=
pan style=3D"color: #008;" class=3D"styled-by-prettify">float</span><span s=
tyle=3D"color: #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"> </span><span style=3D"color: #066;" c=
lass=3D"styled-by-prettify">0</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>float</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"> </span><span styl=
e=3D"color: #066;" class=3D"styled-by-prettify">0</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"> x</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x</sp=
an><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 style=3D"color: #660;" =
class=3D"styled-by-prettify">){}</span></font><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></div><div><br></div><d=
iv>How would you provide access to the members of Point with library proper=
ties?</div><div><br></div><div class=3D"prettyprint" style=3D"background-co=
lor: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); 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"> </span><span style=3D"col=
or: #606;" class=3D"styled-by-prettify">Test</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </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> property</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify"><</span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Point</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">=
point</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">};</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Test</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> test</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>cout </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> test</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify">point</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">x </=
span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> endl</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div></cod=
e></div><div><br></div><div>Currently, the only option available is to over=
ride T* operator->()</div><div><br></div><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"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">const</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> property</span><sp=
an style=3D"color: #660;" 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">->()</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"> </span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">return</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: #008;" class=3D"styled-by-prettify">=
object</span><span style=3D"color: #660;" class=3D"styled-by-prettify">->=
;*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">get</spa=
n><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></div></code></div><=
br>but unless C::get() returns a reference, which it very likely won't, the=
n this code will be returning a reference to a temporary. This may not caus=
e problems, since that temporary is read only, but may will fail to compile=
or generate warnings on some compilers.</div><div><br></div><div>2) <=
span style=3D"font-size: 13px;">No function overloading could be done for t=
he setter.</span></div><div><span style=3D"font-size: 13px;"><br></span></d=
iv><div><span style=3D"font-size: 13px;">3) specific functionality of the p=
roperty's type would be hidden:</span></div><div><span style=3D"font-size: =
13px;"><br></span></div><div><span style=3D"font-size: 13px;">Consider if P=
oint had operator+=3D()</span></div><div><span style=3D"font-size: 13px;"><=
br></span></div><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"><font colo=
r=3D"#660066"><span style=3D"color: #606;" class=3D"styled-by-prettify">Poi=
nt</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">operator</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">+=3D(</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: #60=
6;" class=3D"styled-by-prettify">Point</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">&</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">p</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><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;" class=3D"styled-by-prettify">+=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> p</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">x</span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> y </span><span style=3D"color: #660;" class=3D"styled-by-prettify">+=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> p</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span s=
tyle=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"> </span><span style=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: #008;" class=3D"styled-by-prettify=
">this</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></font><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code>=
</div><div style=3D"font-size: 13px;"><br></div><div style=3D"font-size: 13=
px;">The following code would not compile:</div><div style=3D"font-size: 13=
px;"><br></div><div><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-w=
ord;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">test</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify">point </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">+=3D</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Point</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">(</span><span style=3D"color: #066;" class=3D"styled-by-prettify"=
>5</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span sty=
le=3D"color: #066;" class=3D"styled-by-prettify">6</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>Whe=
reas, with a real property, the get and set methods of the property could b=
e called to retrieve and store the value.</div></div><div><br></div><div>No=
w, a partial solution may be to include commonly used operators inside the =
property class:</div><div><br></div><div><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 1=
87); word-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subp=
rettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettify">templ=
ate</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">typename</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>property </span><span st=
yle=3D"color: #660;" 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"c=
olor: #000;" class=3D"styled-by-prettify">U </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">&&</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">u</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r> T tmp </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">object</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">->*</span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">)();</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br> tmp </span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> u</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span><font color=3D"#000000"><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span></font=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">object</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">->*</span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">set</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">)(</span><span style=3D"color: #000;" c=
lass=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">forward</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify"><</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy">U</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify">tmp</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">));</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><font color=
=3D"#000000"><span style=3D"color: #000;" class=3D"styled-by-prettify">&nbs=
p; </span></font><span style=3D"color: #008;" class=3D"styled-by-pre=
ttify">return</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">*</spa=
n><span style=3D"color: #008;" class=3D"styled-by-prettify">this</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"c=
olor: #660;" class=3D"styled-by-prettify">}</span></div></code></div><div><=
br></div></div><div>And since this is a template, I'm pretty sure(vs2012 an=
d mingw tested) it should be ignored for classes that don't have an operato=
r+=3D unless you actually try to use it, but that doesn't fix the problem t=
hat you still have to include every operator manually into your property cl=
ass.</div><div><br></div><div>If you started to use a class that had a ToSt=
ring() method, now you would need to incorporate that into your property to=
o, and the list would go on endlessly.</div><div><br></div><div>4) <sp=
an style=3D"font-size: 13px;">Finally if something like offsetof() was stan=
dardized to work on non-POD types, there would be a way to get rid of that =
last 4 bytes per property, but currently, it is not. And I say "something l=
ike" because assuming that offsetof() did work, it would still require macr=
os to get the job done. A real piece of builtin compiler magic would still =
be needed to get a pointer to the enclosing instance of an object.</span></=
div><div><br></div><div><br></div><div>Now, this is just the begining, but =
I'm sure I could go on for a few more hours at least.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_819_7158214.1377729018440--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Aug 2013 16:04:06 -0700 (PDT)
Raw View
------=_Part_1623_13288046.1377731046984
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, August 28, 2013 10:17:52 AM UTC-7, Ville Voutilainen wrote:
>
> On 28 August 2013 20:00, Sean Middleditch <se...@middleditch.us<javascript:>
> > wrote:
>
>>
>> There still has been zero cases made for why anyone thinks C++ needs
>> these besides "C# does it" or the like. What problems do properties
>> solve that are unsolved (or poorly/awkwardly solved) right now in
>> C++11/14? It's not satisfying my worries that are important (I have
>> zero say on what goes into the standard), but the committee is going
>> to ask these questions, demand answers, and are usually
>> _significantly_ more conservative than I am being here. :)
>>
>>
>>
> There is one thing I am going to ask before anything else:
> What on earth do we need besides a library solution pretty much like what
> Richard outlined, and why would we need anything other than that?
>
I dislike properties in general. I don't like the idea of hiding function
calls in such a non-obviously-calling-a-function way.
*However*, I feel that if we decide that properties are important enough to
support, then they're important enough to support *at the language level*.
This notion of hacking a "solution" via the standard library is just awful.
I mean, look at this:
property<int> number = {
[&]() { return _number; },
[&](int number) { _number = number; }
};
This is a massive hack and everyone who reads that knows it. The use of
lambdas for what ought to be a simple function declaration, the use of a
variable for what is clearly a pair of functions, etc.
Just look at this conceptually. You're initializing the `number` property.
But you're not initializing it with its *value*; you're initializing it
with some lambda functions. That's conceptual nonsense that reveals the
hack for what it is. Rather than initializing the property with a value,
you're just initializing a class with some functions. This makes no
intuitive sense to anyone who doesn't understand how `property` works, thus
forcing people to use it via cargo-cult copy-and-paste programming. Because
that's always good.
Properties are supposed to make the language simpler easier to use, right?
So why would anyone use this library feature that is difficult to work
with, fidgety, bloats your class with pointless variables, confusing to
read without someone explaining how it works, instantly turns any trivial
type into a non-trivial type (since the property must be initialized by a
constructor), instantly turns any standard-layout type with private members
into a non-standard-layout type (since the property will be public), and is
all-around a bad idea? Just to make talking to instances of the class *
slightly* more convenient?
And this entire concept falls apart completely when a user tries to do any
of the following very simple things:
decltype(test.number);
auto num = test.number;
std::find(..., test.number);
//etc
And there's no way to work around that without some generalized way for a
type to say "deduce me in all cases as some other type." And while I would
be in favor of such a language feature (though not as a fix for this),
there will be *many* such places where the abstraction breaks down and the
kludge will make itself known.
If properties are syntactically a good and wanted thing, then they deserve
the dignity of being a proper language feature. And if they aren't worth
having as a first-class language feature, if they're not worth the
standards committee's time and effort, they're *definitely* not worth
having as a naked and transparent library kludge.
Half of a cat is not half as good as a whole cat. Having a library hack is *
worse* than not having properties at all.
--
---
You received this message because you are 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_1623_13288046.1377731046984
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 28, 2013 10:17:52 AM UTC-7, Ville Vou=
tilainen 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">On 28 August 2013 20:00, Sean Middleditch=
<span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfusc=
ated-mailto=3D"UZW0Uo-uznsJ">se...@middleditch.us</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><br>
There still has been zero cases made for why anyone thinks C++ needs<br>
these besides "C# does it" or the like. What problems do properties<b=
r>
solve that are unsolved (or poorly/awkwardly solved) right now in<br>
C++11/14? It's not satisfying my worries that are important (I have<b=
r>
zero say on what goes into the standard), but the committee is going<br>
to ask these questions, demand answers, and are usually<br>
_significantly_ more conservative than I am being here. :)<br>
<div><div><br><br></div></div></blockquote><div><br></div><div>There is one=
thing I am going to ask before anything else:<br></div><div>What on earth =
do we need besides a library solution pretty much like what<br>
</div><div>Richard outlined, and why would we need anything other than that=
?<br></div></div></div></div></blockquote><div><br>I dislike properties in =
general. I don't like the idea of hiding function calls in such a non-obvio=
usly-calling-a-function way.<br><br><i>However</i>, I feel that if we decid=
e that properties are important enough to support, then they're important e=
nough to support <i>at the language level</i>. This notion of hacking a "so=
lution" via the standard library is just awful. I mean, look at this:<br><b=
r><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"subpretty=
print"><span style=3D"color: #000;" class=3D"styled-by-prettify"> pro=
perty</span><span style=3D"color: #080;" class=3D"styled-by-prettify"><i=
nt></span><span style=3D"color: #000;" class=3D"styled-by-prettify"> num=
ber </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</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: #000;" class=3D"styled-by-prettify"><br> </span><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: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color: #00=
0;" 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"> _number</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
},</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>&nbs=
p; </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
[&](</span><span style=3D"color: #008;" class=3D"styled-by-prettify">in=
t</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> number</=
span><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"> _number </span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> number</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">=
<br> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>};</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></s=
pan></div></code></div><br>This is a massive hack and everyone who reads th=
at knows it. The use of lambdas for what ought to be a simple function decl=
aration, the use of a variable for what is clearly a pair of functions, etc=
..<br><br>Just look at this conceptually. You're initializing the `number` p=
roperty. But you're not initializing it with its <i>value</i>; you're initi=
alizing it with some lambda functions. That's conceptual nonsense that reve=
als the hack for what it is. Rather than initializing the property with a v=
alue, you're just initializing a class with some functions. This makes no i=
ntuitive sense to anyone who doesn't understand how `property` works, thus =
forcing people to use it via cargo-cult copy-and-paste programming. Because=
that's always good.<br><br>Properties are supposed to make the language si=
mpler easier to use, right? So why would anyone use this library feature th=
at is difficult to work with, fidgety, bloats your class with pointless var=
iables, confusing to read without someone explaining how it works, instantl=
y turns any trivial type into a non-trivial type (since the property must b=
e initialized by a constructor), instantly turns any standard-layout type w=
ith private members into a non-standard-layout type (since the property wil=
l be public), and is all-around a bad idea? Just to make talking to instanc=
es of the class <i>slightly</i> more convenient?<br><br>And this entire con=
cept falls apart completely when a user tries to do any of the following ve=
ry simple things:<br><br><div class=3D"prettyprint" style=3D"background-col=
or: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: sol=
id; 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">decltype</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">test</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">number</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">);</span><span st=
yle=3D"color: #000;" class=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"styled-by-prettify"> num </span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> test</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">number</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">find</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">(...,</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> test</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">number</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">);</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"><br></span><span style=3D"color: #800;" class=3D"=
styled-by-prettify">//etc</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br></span></div></code></div><br>And there's no way to work=
around that without some generalized way for a type to say "deduce me in a=
ll cases as some other type." And while I would be in favor of such a langu=
age feature (though not as a fix for this), there will be <i>many</i> such =
places where the abstraction breaks down and the kludge will make itself kn=
own.<br><br>If properties are syntactically a good and wanted thing, then t=
hey deserve the dignity of being a proper language feature. And if they are=
n't worth having as a first-class language feature, if they're not worth th=
e standards committee's time and effort, they're <i>definitely</i> not wort=
h having as a naked and transparent library kludge.<br><br>Half of a cat is=
not half as good as a whole cat. Having a library hack is <i>worse</i> tha=
n not having properties at all.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1623_13288046.1377731046984--
.
Author: =?ISO-8859-1?Q?Lo=EFc_Joly?= <loic.actarus.joly@numericable.fr>
Date: Thu, 29 Aug 2013 01:41:36 +0200
Raw View
Le 28/08/2013 15:42, Ville Voutilainen a =C3=A9crit :
>
>
> If that's the case (with which I disagree), we certainly don't need=20
> any language changes for
> properties, since public non-static data members of reference or proxy=20
> class type achieve
> the usage syntax just fine.
>
The main problem I have with public data members implementing auto=20
properties is that they don't provide a migration path if later, we=20
decide to use a non-auto property.
---
Lo=C4=8Fc
--=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/.
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Wed, 28 Aug 2013 16:49:45 -0700 (PDT)
Raw View
------=_Part_4546_8935731.1377733785956
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
could you clarify what you mean by non-auto property?
On Wednesday, 28 August 2013 19:41:36 UTC-4, Lo=EFc Joly wrote:
>
> Le 28/08/2013 15:42, Ville Voutilainen a =EF=BF=BDcrit :=20
> >=20
> >=20
> > If that's the case (with which I disagree), we certainly don't need=20
> > any language changes for=20
> > properties, since public non-static data members of reference or proxy=
=20
> > class type achieve=20
> > the usage syntax just fine.=20
> >=20
>
> The main problem I have with public data members implementing auto=20
> properties is that they don't provide a migration path if later, we=20
> decide to use a non-auto property.=20
>
> ---=20
> Lo=EF=BF=BDc=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_4546_8935731.1377733785956
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">could you clarify what you mean by non-auto property?<div>=
<br><br>On Wednesday, 28 August 2013 19:41:36 UTC-4, Lo=EFc Joly wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;">Le 28/08/2013 15:42, Ville Voutil=
ainen a =EF=BF=BDcrit :
<br>>
<br>>
<br>> If that's the case (with which I disagree), we certainly don't nee=
d=20
<br>> any language changes for
<br>> properties, since public non-static data members of reference or p=
roxy=20
<br>> class type achieve
<br>> the usage syntax just fine.
<br>>
<br>
<br>The main problem I have with public data members implementing auto=20
<br>properties is that they don't provide a migration path if later, we=20
<br>decide to use a non-auto property.
<br>
<br>---
<br>Lo=EF=BF=BDc
<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_4546_8935731.1377733785956--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Thu, 29 Aug 2013 02:06:34 +0200
Raw View
--089e014946400e8ccd04e50ae155
Content-Type: text/plain; charset=ISO-8859-1
On Thu, Aug 29, 2013 at 1:49 AM, Nick <nicolas.jinchereau@gmail.com> wrote:
> could you clarify what you mean by non-auto property?
>
I believe Loic means that if I have a initial version of some code that
look like this:
struct K
{
int count;
};
int f( K& k )
{
return k.count;
}
Then (years) later I upgrade it with some checks using some property
syntax, but want to keep the retrocompatibility:
class K // another retrocompatible change
{
public:
property int count { //* */ }
}
Assuming the property works like a public variable, then this is useful.
However, if I started my code like this, as a lot of code does:
struct K
{
int count();
};
int f( K& k )
{
return k.count();
}
Then there is no benefit in upgrading to properties, because it will not be
retro-compatible.
I don't have an opinion on this point. However it might point that a
property feature without
a way to implicitely use member functions like if they were properties (as
some suggested) would not use useful for code
that is already written.
It feels a bit like allowing k.count() to be written count(k) : it might
help generalization, but only with new code.
Joel Lamotte
--
---
You received this message because you are 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/.
--089e014946400e8ccd04e50ae155
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Thu, Aug 29, 2013 at 1:49 AM, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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">could you clarify what you mean by non-au=
to property?<div>
</div></div></blockquote></div><br>I believe Loic means that if I have a in=
itial version of some code that look like this:<br><br>struct K<br>{</div><=
div class=3D"gmail_extra">=A0 =A0 int count;</div><div class=3D"gmail_extra=
">};</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int f( K&am=
p; k )</div><div class=3D"gmail_extra">{</div><div class=3D"gmail_extra">=
=A0 =A0return k.count; =A0</div><div class=3D"gmail_extra">}<br><br>Then (y=
ears) later I upgrade it with some checks using some property syntax, but w=
ant to keep the retrocompatibility:<br>
<br>class K // another retrocompatible change<br>{</div><div class=3D"gmail=
_extra">public:</div><div class=3D"gmail_extra">=A0 =A0=A0</div><div class=
=3D"gmail_extra">=A0 =A0 property int count { //* */ }</div><div class=3D"g=
mail_extra"><br>
</div><div class=3D"gmail_extra">}</div><div class=3D"gmail_extra"><br></di=
v><div class=3D"gmail_extra">Assuming the property works like a public vari=
able, then this is useful.<br><br></div><div class=3D"gmail_extra">However,=
if I started my code like this, as a lot of code does:<br>
<br><div class=3D"gmail_extra">struct K<br>{</div><div class=3D"gmail_extra=
">=A0 =A0 int count();</div><div class=3D"gmail_extra">};</div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra">int f( K& k )</di=
v><div class=3D"gmail_extra">
{</div><div class=3D"gmail_extra">=A0 =A0return k.count(); =A0</div><div cl=
ass=3D"gmail_extra">}<br><br>Then there is no benefit in upgrading to prope=
rties, because it will not be retro-compatible.<br><br>I don't have an =
opinion on this point. However it might point that a property feature witho=
ut<br>
a way to implicitely use member functions like if they were properties (as =
some suggested) would not use useful for code<br>that is already written.<b=
r><br>It feels a bit like allowing k.count() to be written count(k) : it mi=
ght help generalization, but only with new code.<br>
<br><br>Joel Lamotte<br><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e014946400e8ccd04e50ae155--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Wed, 28 Aug 2013 17:18:11 -0700 (PDT)
Raw View
------=_Part_870_21621027.1377735491507
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Wednesday, 28 August 2013 20:06:34 UTC-4, Klaim - Jo=EBl Lamotte wrote:
>
> On Thu, Aug 29, 2013 at 1:49 AM, Nick <nicolas.j...@gmail.com<javascript:=
>
> > wrote:
>
>> could you clarify what you mean by non-auto property?
>>
>
> I believe Loic means that if I have a initial version of some code that=
=20
> look like this:
>
> struct K
> {
> int count;
> };
>
> int f( K& k )
> {
> return k.count; =20
> }
>
> Then (years) later I upgrade it with some checks using some property=20
> syntax, but want to keep the retrocompatibility:
>
> class K // another retrocompatible change
> {
> public:
> =20
> property int count { //* */ }
>
> }
>
> Assuming the property works like a public variable, then this is useful.
>
> However, if I started my code like this, as a lot of code does:
>
> struct K
> {
> int count();
> };
>
> int f( K& k )
> {
> return k.count(); =20
> }
>
> Then there is no benefit in upgrading to properties, because it will not=
=20
> be retro-compatible.
>
> I don't have an opinion on this point. However it might point that a=20
> property feature without
> a way to implicitely use member functions like if they were properties (a=
s=20
> some suggested) would not use useful for code
> that is already written.
>
> It feels a bit like allowing k.count() to be written count(k) : it might=
=20
> help generalization, but only with new code.
>
>
> Joel Lamotte
>
>
If I understand correctly,
while std::vector is currently implemented like this:
vector<T> {
size_t size() const { return _last - _first; }
};
and the size can be taken like this:
vector<int> myVec;
size_t sz =3D myVec.size();
then you are saying that the implementation of vector should be able to be=
=20
upgraded to:
vector<T> {
auto_property size_t size() const { return _last - _first; }
};
and still allow for both usages?
vector<int> myVec;
size_t sz1 =3D myVec.size();
size_t sz2 =3D myVec.size;
If this is correct, then I agree completely, and I think that this is=20
feasible using the function based property syntax that I initially proposed=
..
=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_870_21621027.1377735491507
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Wednesday, 28 August 2=
013 20:06:34 UTC-4, Klaim - Jo=EBl Lamotte wrote:</span><br><div><blockquo=
te 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 Thu, Aug 29, 2013 at 1:49 AM, Nick <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"bfOXUe0d9=
-sJ">nicolas.j...@gmail.com</a>></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">could you clarify what you mean by non-au=
to property?<div>
</div></div></blockquote></div><br>I believe Loic means that if I have a in=
itial version of some code that look like this:<br><br>struct K<br>{</div><=
div> int count;</div><div>};</div>
<div><br></div><div>int f( K& k )</div><div>{</div><div> re=
turn k.count; </div><div>}<br><br>Then (years) later I upgrade it wit=
h some checks using some property syntax, but want to keep the retrocompati=
bility:<br>
<br>class K // another retrocompatible change<br>{</div><div>public:</div><=
div> </div><div> property int count { //* */=
}</div><div><br>
</div><div>}</div><div><br></div><div>Assuming the property works like a pu=
blic variable, then this is useful.<br><br></div><div>However, if I started=
my code like this, as a lot of code does:<br>
<br><div>struct K<br>{</div><div> int count();</div><div>};</d=
iv><div><br></div><div>int f( K& k )</div><div>
{</div><div> return k.count(); </div><div>}<br><br>Then t=
here is no benefit in upgrading to properties, because it will not be retro=
-compatible.<br><br>I don't have an opinion on this point. However it might=
point that a property feature without<br>
a way to implicitely use member functions like if they were properties (as =
some suggested) would not use useful for code<br>that is already written.<b=
r><br>It feels a bit like allowing k.count() to be written count(k) : it mi=
ght help generalization, but only with new code.<br>
<br><br>Joel Lamotte<br><br></div></div></div></blockquote><div><br></div><=
div><br></div>If I understand correctly,<div><br></div><div>while std::vect=
or is currently implemented like this:</div><div><br></div><div class=3D"pr=
ettyprint" style=3D"border: 1px solid rgb(187, 187, 187); background-color:=
rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"prettyprint"><d=
iv class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by=
-prettify">vector</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify"><</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">></sp=
an><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> size_t size</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"> _last </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">-</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
_first</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: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">};</span></div></code></div><div><br>=
</div><div>and the size can be taken like this:</div><div><br></div><div cl=
ass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); backgrou=
nd-color: rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"=
styled-by-prettify">vector</span><span style=3D"color: #080;" class=3D"styl=
ed-by-prettify"><int></span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> myVec</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>size_t sz </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> myVec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">();</span></div></=
code></div><div><br></div><div>then you are saying that the implementation =
of vector should be able to be upgraded to:</div><div><br></div><div><div c=
lass=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); backgro=
und-color: rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"prett=
yprint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D=
"styled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</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;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"><br> auto=
_property size_t size</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">const<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><sp=
an 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: #0=
00;" class=3D"styled-by-prettify"> _last </span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">-</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> _first</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></=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">};</span></d=
iv></code></div><span class=3D"styled-by-prettify" style=3D"font-family: mo=
nospace; background-color: rgb(250, 250, 250); color: rgb(102, 102, 0);"><b=
r></span>and still allow for both usages?</div><div><br></div><div><div cla=
ss=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); backgroun=
d-color: rgb(250, 250, 250); word-wrap: break-word;"><code class=3D"prettyp=
rint"><div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify">vector</span><span style=3D"color: #080;" class=3D"style=
d-by-prettify"><int></span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> myVec</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>size_t sz1 </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> myVec</span><span style=3D"color: #660;" class=3D"styled-by-prettify">.</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify">size</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br>size_t sz2 </span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> myVec</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify">size</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">;</span></div></code></div><span class=3D"styl=
ed-by-prettify" style=3D"font-family: monospace; background-color: rgb(250,=
250, 250); color: rgb(102, 102, 0);"><br></span></div><div><span style=3D"=
font-size: 13px;">If this is correct, then I agree completely, </span>=
<font style=3D"font-size: 13px;">and I think that this is </font><span=
style=3D"font-size: 13px;">feasible</span><font style=3D"font-size: 13px;"=
> using the function based property syntax that I initially =
proposed.</font></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_870_21621027.1377735491507--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 03:59:49 +0300
Raw View
--001a11c3d0e67c29fe04e50b9f81
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 02:04, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> If properties are syntactically a good and wanted thing, then they deserve
> the dignity of being a proper language feature. And if
>
>
Do people think properties should be a language feature, when they are
seemingly just one of the many
things compile-time reflection can provide?
--
---
You received this message because you are 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/.
--001a11c3d0e67c29fe04e50b9f81
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 02:04, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</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"><br><div>If properties are =
syntactically a good and wanted thing, then they deserve the dignity of bei=
ng a proper language feature. And if<br>
<br></div></div></blockquote><div><br></div><div>Do people think properties=
should be a language feature, when they are seemingly just one of the many=
<br>things compile-time reflection can provide?<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c3d0e67c29fe04e50b9f81--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Wed, 28 Aug 2013 18:42:52 -0700 (PDT)
Raw View
------=_Part_6261_22378323.1377740572516
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, 28 August 2013 20:59:49 UTC-4, Ville Voutilainen wrote:
>
>
>
> On 29 August 2013 02:04, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>> If properties are syntactically a good and wanted thing, then they
>> deserve the dignity of being a proper language feature. And if
>>
>>
> Do people think properties should be a language feature, when they are
> seemingly just one of the many
> things compile-time reflection can provide?
>
I keep hearing people try to relate reflection to properties. This doesn't
make any sense to me at all. Can you provide a pseudo code example of how a
property would be retrieved using a reflection interface?
--
---
You received this message because you are 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_6261_22378323.1377740572516
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Wednesday, 28 August 2=
013 20:59:49 UTC-4, Ville Voutilainen wrote:</span><br><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"><br><div><br><br><div class=3D=
"gmail_quote">On 29 August 2013 02:04, Nicol Bolas <span dir=3D"ltr"><<a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"Or9q6emUMK=
0J">jmck...@gmail.com</a>></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"><br><div>If properties are =
syntactically a good and wanted thing, then they deserve the dignity of bei=
ng a proper language feature. And if<br>
<br></div></div></blockquote><div><br></div><div>Do people think properties=
should be a language feature, when they are seemingly just one of the many=
<br>things compile-time reflection can provide?</div></div></div></div></bl=
ockquote><div><br></div><div>I keep hearing people try to relate reflection=
to properties. This doesn't make any sense to me at all. Can you provide a=
pseudo code example of how a property would be retrieved using a reflectio=
n interface?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_6261_22378323.1377740572516--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 08:25:50 +0300
Raw View
--001a11c2cbf2cd39a804e50f5613
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 04:42, Nick <nicolas.jinchereau@gmail.com> wrote:
> On Wednesday, 28 August 2013 20:59:49 UTC-4, Ville Voutilainen wrote:
>
>
>>
>>
>> On 29 August 2013 02:04, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>>>
>>> If properties are syntactically a good and wanted thing, then they
>>> deserve the dignity of being a proper language feature. And if
>>>
>>>
>> Do people think properties should be a language feature, when they are
>> seemingly just one of the many
>> things compile-time reflection can provide?
>>
>
> I keep hearing people try to relate reflection to properties. This doesn't
> make any sense to me at all. Can you provide a pseudo code example of how a
> property would be retrieved using a reflection interface?
>
>
>
>
Depends on how far people are willing to go with reflection. ;) One of the
expectations of people proposing
reflection facilities is that
1) you can query the member functions and member data of a type
2) you can customize how a type answers to such queries
The part 2 may effectively involve being able to more or less overload
operator. or its equivalent
so that when queried for a member f() or x, the type can return whatever it
pleases, a reference to an existing member
of the type itself, a reference to a subobject or a member thereof, or
something more dynamic.
Completely imaginary, with quite a bunch of potentially controversial
facilities:
struct X
{
private:
int y;
public:
template<compile_time_string s> decltype(auto) operator-><s>()
{
static if (s == "x") {
return y;
} else {
static_assert(false, "no such member");
}
}
};
The use is then
X x;
int foo = x.x;
or more verbosely,
X x;
int foo = std::reflection::member<compiletimestring("x")>(x);
--
---
You received this message because you are 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/.
--001a11c2cbf2cd39a804e50f5613
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 04:42, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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"><span style=3D"font-size:13=
px">On Wednesday, 28 August 2013 20:59:49 UTC-4, Ville Voutilainen wrote:<=
/span><div class=3D"im">
<br><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"><br><div><br><=
br><div class=3D"gmail_quote">On 29 August 2013 02:04, Nicol Bolas <span di=
r=3D"ltr"><<a>jmck...@gmail.com</a>></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"><br><div>If properties are =
syntactically a good and wanted thing, then they deserve the dignity of bei=
ng a proper language feature. And if<br>
<br></div></div></blockquote><div><br></div><div>Do people think properties=
should be a language feature, when they are seemingly just one of the many=
<br>things compile-time reflection can provide?</div></div></div></div>
</blockquote><div><br></div></div><div>I keep hearing people try to relate =
reflection to properties. This doesn't make any sense to me at all. Can=
you provide a pseudo code example of how a property would be retrieved usi=
ng a reflection interface?</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Depends on how far peo=
ple are willing to go with reflection. ;) One of the expectations of people=
proposing<br>reflection facilities is that<br></div><div>1) you can query =
the member functions and member data of a type<br>
</div><div>2) you can customize how a type answers to such queries<br><br><=
/div><div>The part 2 may effectively involve being able to more or less ove=
rload operator. or its equivalent<br>so that when queried for a member f() =
or x, the type can return whatever it pleases, a reference to an existing m=
ember<br>
</div><div>of the type itself, a reference to a subobject or a member there=
of, or something more dynamic.<br><br></div><div>Completely imaginary, with=
quite a bunch of potentially controversial facilities:<br></div><div>struc=
t X<br>
{<br></div><div>private:<br></div><div>=A0=A0=A0 int y;<br></div><div>publi=
c:<br></div><div>=A0=A0=A0 template<compile_time_string s> decltype(a=
uto) operator-><s>()<br>=A0=A0=A0 {<br></div><div>=A0=A0=A0=A0=A0=
=A0=A0 static if (s =3D=3D "x") {<br>
</div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return y;<br></div><div>=A0=A0=
=A0=A0=A0=A0=A0 } else {<br></div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 st=
atic_assert(false, "no such member");<br></div><div>=A0=A0=A0=A0=
=A0=A0=A0 }<br></div><div>=A0=A0=A0 }<br></div><div>}; <br></div></div><br>
</div><div class=3D"gmail_extra">The use is then<br><br></div><div class=3D=
"gmail_extra">X x;<br>int foo =3D x.x;<br><br></div><div class=3D"gmail_ext=
ra">or more verbosely, <br></div><div class=3D"gmail_extra">X x;<br></div><=
div class=3D"gmail_extra">
int foo =3D std::reflection::member<compiletimestring("x")>=
(x);<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c2cbf2cd39a804e50f5613--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 28 Aug 2013 23:54:53 -0700 (PDT)
Raw View
------=_Part_277_24915736.1377759293501
Content-Type: text/plain; charset=ISO-8859-1
On Wednesday, August 28, 2013 10:25:50 PM UTC-7, Ville Voutilainen wrote:
>
> On 29 August 2013 04:42, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>
>> On Wednesday, 28 August 2013 20:59:49 UTC-4, Ville Voutilainen wrote:
>>
>>> On 29 August 2013 02:04, Nicol Bolas <jmck...@gmail.com> wrote:
>>>
>>>>
>>>> If properties are syntactically a good and wanted thing, then they
>>>> deserve the dignity of being a proper language feature. And if
>>>>
>>>>
>>> Do people think properties should be a language feature, when they are
>>> seemingly just one of the many
>>> things compile-time reflection can provide?
>>>
>>
>> I keep hearing people try to relate reflection to properties. This
>> doesn't make any sense to me at all. Can you provide a pseudo code example
>> of how a property would be retrieved using a reflection interface?
>>
>>
>>
>>
> Depends on how far people are willing to go with reflection. ;) One of the
> expectations of people proposing
> reflection facilities is that
> 1) you can query the member functions and member data of a type
> 2) you can customize how a type answers to such queries
>
But there's no coherent proposal for reflection that includes these things
as of yet. Not unless I missed a paper somewhere. It seems silly to dismiss
a proposal because of something that *might* happen in the future.
If reflection were a sure thing, if there was a proposal with broad support
that had all of these necessary features in it, I could see that being a
legitimate argument. Depending on the details of course; if you have to do
what you did in your example, I'd still be against it (because that's
horrifically unmaintainable in any real class). But without any such thing,
I see no reason not to have this.
It's the whole `array_ref` problem all over again. Because of what *might*have happened (and notably did not), C++14 will ship without an important
and useful piece of functionality.
The part 2 may effectively involve being able to more or less overload
> operator. or its equivalent
> so that when queried for a member f() or x, the type can return whatever
> it pleases, a reference to an existing member
> of the type itself, a reference to a subobject or a member thereof, or
> something more dynamic.
>
> Completely imaginary, with quite a bunch of potentially controversial
> facilities:
> struct X
> {
> private:
> int y;
> public:
> template<compile_time_string s> decltype(auto) operator-><s>()
> {
> static if (s == "x") {
> return y;
> } else {
> static_assert(false, "no such member");
> }
> }
> };
>
> The use is then
>
> X x;
> int foo = x.x;
>
> or more verbosely,
> X x;
> int foo = std::reflection::member<compiletimestring("x")>(x);
>
OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k is a
type that is *not* implicitly convertible to x.x's type? Or the part that
lets you have multiple properties with different types (say, an int and a
float)? Or the part that makes this increasing mass of code in any way
palatable or maintainable?
Why are people so willing to settle for this kind of hackery? Have we
learned *nothing* from the `enable_if` horrors? If this is an important
feature, it needs to be done right. And if it's not, it shouldn't be done
at all. We should focus on settling whether it's important enough to go
into the standard; if it is, it needs to be 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/.
------=_Part_277_24915736.1377759293501
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 28, 2013 10:25:50 PM UTC-7, Ville Vou=
tilainen 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">On 29 August 2013 04:42, Nick <span dir=
=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"kYaM7CtbBIwJ">nicolas.j...@gmail.com</a>></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"><span style=3D"font-size:13=
px">On Wednesday, 28 August 2013 20:59:49 UTC-4, Ville Voutilainen wrote:<=
/span><div>
<blockquote 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"><div><div class=3D=
"gmail_quote">On 29 August 2013 02:04, Nicol Bolas <span dir=3D"ltr"><<a=
>jmck...@gmail.com</a>></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"><br><div>If properties are =
syntactically a good and wanted thing, then they deserve the dignity of bei=
ng a proper language feature. And if<br>
<br></div></div></blockquote><div><br></div><div>Do people think properties=
should be a language feature, when they are seemingly just one of the many=
<br>things compile-time reflection can provide?</div></div></div></div>
</blockquote><div><br></div></div><div>I keep hearing people try to relate =
reflection to properties. This doesn't make any sense to me at all. Can you=
provide a pseudo code example of how a property would be retrieved using a=
reflection interface?</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Depends on how far peo=
ple are willing to go with reflection. ;) One of the expectations of people=
proposing<br>reflection facilities is that<br></div><div>1) you can query =
the member functions and member data of a type<br>
</div><div>2) you can customize how a type answers to such queries<br></div=
></div></div></div></blockquote><div><br>But there's no coherent proposal f=
or reflection that includes these things as of yet. Not unless I missed a p=
aper somewhere. It seems silly to dismiss a proposal because of something t=
hat <i>might</i> happen in the future.<br><br>If reflection were a sure thi=
ng, if there was a proposal with broad support that had all of these necess=
ary features in it, I could see that being a legitimate argument. Depending=
on the details of course; if you have to do what you did in your example, =
I'd still be against it (because that's horrifically unmaintainable in any =
real class). But without any such thing, I see no reason not to have this.<=
br><br>It's the whole `array_ref` problem all over again. Because of what <=
i>might</i> have happened (and notably did not), C++14 will ship without an=
important and useful piece of functionality.<br><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quot=
e"><div></div><div>The part 2 may effectively involve being able to more or=
less overload operator. or its equivalent<br>so that when queried for a me=
mber f() or x, the type can return whatever it pleases, a reference to an e=
xisting member<br>
</div><div>of the type itself, a reference to a subobject or a member there=
of, or something more dynamic.<br><br></div><div>Completely imaginary, with=
quite a bunch of potentially controversial facilities:<br></div><div>struc=
t X<br>
{<br></div><div>private:<br></div><div> int y;<br></div><=
div>public:<br></div><div> template<compile_time_strin=
g s> decltype(auto) operator-><s>()<br> {<br>=
</div><div> static if (s =3D=3D "=
x") {<br>
</div><div> &nbs=
p; return y;<br></div><div> } els=
e {<br></div><div> &nb=
sp; static_assert(false, "no such member");<br></div><div>  =
; }<br></div><div> }<br></d=
iv><div>}; <br></div></div><br>
</div><div>The use is then<br><br></div><div>X x;<br>int foo =3D x.x;<br><b=
r></div><div>or more verbosely, <br></div><div>X x;<br></div><div>
int foo =3D std::reflection::member<<wbr>compiletimestring("x")>(x);<=
br></div></div></blockquote><div><br>OK, where's the part that lets you do =
`x.x =3D 4`? Or `x.x =3D k`, where k is a type that is *not* implicitly con=
vertible to x.x's type? Or the part that lets you have multiple properties =
with different types (say, an int and a float)? Or the part that makes this=
increasing mass of code in any way palatable or maintainable?<br><br>Why a=
re people so willing to settle for this kind of hackery? Have we learned <i=
>nothing</i> from the `enable_if` horrors? If this is an important feature,=
it needs to be done right. And if it's not, it shouldn't be done at all. W=
e should focus on settling whether it's important enough to go into the sta=
ndard; if it is, it needs to be a language feature.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_277_24915736.1377759293501--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 10:04:16 +0300
Raw View
--047d7bf16090d3dd5004e510b6d8
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 09:54, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
>>>> Do people think properties should be a language feature, when they are
>>>> seemingly just one of the many
>>>> things compile-time reflection can provide?
>>>>
>>>
>>> I keep hearing people try to relate reflection to properties. This
>>> doesn't make any sense to me at all. Can you provide a pseudo code example
>>> of how a property would be retrieved using a reflection interface?
>>>
>>>
>>>
>>>
>> Depends on how far people are willing to go with reflection. ;) One of
>> the expectations of people proposing
>> reflection facilities is that
>> 1) you can query the member functions and member data of a type
>> 2) you can customize how a type answers to such queries
>>
>
> But there's no coherent proposal for reflection that includes these things
> as of yet. Not unless I missed a paper somewhere. It
>
Correct. The reflection study group hasn't even properly kicked to gear yet.
> seems silly to dismiss a proposal because of something that *might*happen in the future.
>
Well, there has been no such dismissal, so I don't see what you're
complaining about.
> template<compile_time_string s> decltype(auto) operator-><s>()
>> {
>> static if (s == "x") {
>> return y;
>> } else {
>> static_assert(false, "no such member");
>> }
>> }
>> };
>>
>> The use is then
>>
>> X x;
>> int foo = x.x;
>>
>> or more verbosely,
>> X x;
>> int foo = std::reflection::member<**compiletimestring("x")>(x);
>>
>
> OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k is
> a type that is *not* implicitly convertible to x.x's type? Or the
>
In the part where I return a reference to y.
> part that lets you have multiple properties with different types (say, an
> int and a float)? Or the part that makes this increasing mass
>
There's no restriction against having multiple properties with different
types in that pseudocode.
>
>
> Why are people so willing to settle for this kind of hackery? Have we
> learned *nothing* from the `enable_if` horrors? If this is an
>
Because sometimes people are willing to strive for a general facility that
may not be optimal for one of the cases
it covers, like properties, when the general facility provides much more
than just a single feature.
> important feature, it needs to be done right. And if it's not, it
> shouldn't be done at all. We should focus on settling whether it's
> important enough to go into the standard; if it is, it needs to be a
> language feature.
>
>
>
>
I guess we can speculate until the cows come home, but what is necessary
for any property proposal to go
forward is for such a proposal to exist, first of all. And it should take a
look at the property proposals that
have been proposed before, lest it's just running in circles.
--
---
You received this message because you are 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/.
--047d7bf16090d3dd5004e510b6d8
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 09:54, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</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"><br><div class=3D"im"><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><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 dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Do peo=
ple think properties should be a language feature, when they are seemingly =
just one of the many<br>things compile-time reflection can provide?</div></=
div>
</div></div>
</blockquote><div><br></div></div><div>I keep hearing people try to relate =
reflection to properties. This doesn't make any sense to me at all. Can=
you provide a pseudo code example of how a property would be retrieved usi=
ng a reflection interface?</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Depends on how far peo=
ple are willing to go with reflection. ;) One of the expectations of people=
proposing<br>reflection facilities is that<br></div><div>1) you can query =
the member functions and member data of a type<br>
</div><div>2) you can customize how a type answers to such queries<br></div=
></div></div></div></blockquote></div><div><br>But there's no coherent =
proposal for reflection that includes these things as of yet. Not unless I =
missed a paper somewhere. It </div>
</div></blockquote><div><br></div><div>Correct. The reflection study group =
hasn't even properly kicked to gear yet.<br>=A0<br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">
<div dir=3D"ltr"><div>seems silly to dismiss a proposal because of somethin=
g that <i>might</i> happen in the future.<br></div></div></blockquote><div>=
<br></div><div>Well, there has been no such dismissal, so I don't see w=
hat you're complaining about.<br>
<br><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"=
><div class=3D"im"><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><div class=3D"gmail_quote"><div>=A0=A0=A0 template<=
;compile_time_string s> decltype(auto) operator-><s>()<br>=A0=
=A0=A0 {<br></div><div>=A0=A0=A0=A0=A0=A0=A0 static if (s =3D=3D "x&qu=
ot;) {<br>
</div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return y;<br></div><div>=A0=A0=
=A0=A0=A0=A0=A0 } else {<br></div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 st=
atic_assert(false, "no such member");<br></div><div>=A0=A0=A0=A0=
=A0=A0=A0 }<br></div><div>=A0=A0=A0 }<br></div><div>}; <br></div></div><br>
</div><div>The use is then<br><br></div><div>X x;<br>int foo =3D x.x;<br><b=
r></div><div>or more verbosely, <br></div><div>X x;<br></div><div>
int foo =3D std::reflection::member<<u></u>compiletimestring("x&quo=
t;)>(x);<br></div></div></blockquote></div><div><br>OK, where's the =
part that lets you do `x.x =3D 4`? Or `x.x =3D k`, where k is a type that i=
s *not* implicitly convertible to x.x's type? Or the </div>
</div></blockquote><div><br></div><div>In the part where I return a referen=
ce to y.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><d=
iv>part that lets you have multiple properties with different types (say, a=
n int and a float)? Or the part that makes this increasing mass </div>
</div></blockquote><div><br></div><div>There's no restriction against h=
aving multiple properties with different types in that pseudocode.<br><br>=
=A0<br></div><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><br><br>Why are people so willing to settle for this =
kind of hackery? Have we learned <i>nothing</i> from the `enable_if` horror=
s? If this is an </div></div></blockquote><div><br></div><div>Because somet=
imes people are willing to strive for a general facility that may not be op=
timal for one of the cases<br>
it covers, like properties, when the general facility provides much more th=
an just a single feature.<br>=A0<br></div><blockquote class=3D"gmail_quote"=
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><d=
iv dir=3D"ltr">
<div>important feature, it needs to be done right. And if it's not, it =
shouldn't be done at all. We should focus on settling whether it's =
important enough to go into the standard; if it is, it needs to be a langua=
ge feature.<br>
</div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I guess we can specula=
te until the cows come home, but what is necessary for any property proposa=
l to go<br>forward is for such a proposal to exist, first of all. And it sh=
ould take a look at the property proposals that<br>
</div><div>have been proposed before, lest it's just running in circles=
.. <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7bf16090d3dd5004e510b6d8--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 29 Aug 2013 04:54:18 -0700 (PDT)
Raw View
------=_Part_2265_6158243.1377777258852
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 29, 2013 12:04:16 AM UTC-7, Ville Voutilainen wrote:
>
> On 29 August 2013 09:54, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>>
>>>>> Do people think properties should be a language feature, when they are
>>>>> seemingly just one of the many
>>>>> things compile-time reflection can provide?
>>>>>
>>>>
>>>> I keep hearing people try to relate reflection to properties. This
>>>> doesn't make any sense to me at all. Can you provide a pseudo code example
>>>> of how a property would be retrieved using a reflection interface?
>>>>
>>>>
>>>>
>>>>
>>> Depends on how far people are willing to go with reflection. ;) One of
>>> the expectations of people proposing
>>> reflection facilities is that
>>> 1) you can query the member functions and member data of a type
>>> 2) you can customize how a type answers to such queries
>>>
>>
>> But there's no coherent proposal for reflection that includes these
>> things as of yet. Not unless I missed a paper somewhere. It
>>
>
> Correct. The reflection study group hasn't even properly kicked to gear
> yet.
>
>
>> seems silly to dismiss a proposal because of something that *might*happen in the future.
>>
>
> Well, there has been no such dismissal, so I don't see what you're
> complaining about.
>
*ahem*: "Do people think properties should be a language feature, when they
are seemingly just one of the many
things compile-time reflection can provide?"
That sounds dismissive. Since you're dismissing properties as "one of the
many things compile-time reflection can provide". That sounds very much
like, "wait for reflection". Which is dismissive.
Or, let me put it this way:
There is no way to make properties as a hack, either via some library type
or via reflection, and still have it fulfill all of these requirements,
such that making a property:
1: Is easy for new C++ users to learn to use.
2: Is easy for new C++ users to read in other people's code.
3: Is reasonably compact in syntax.
4: Doesn't change the nature of the type on which it is placed.
5: Doesn't break the abstraction.
6: Has all of the features of properties in other languages that are
appropriate to C++.
You may be able to make it *function* with reflection. But it won't ever be
a *good* feature that people will want to use and teach others to use. With
reflection, it'll merely be a curiosity that maybe some advanced C++
programmers will provide.
template<compile_time_string s> decltype(auto) operator-><s>()
>>> {
>>> static if (s == "x") {
>>> return y;
>>> } else {
>>> static_assert(false, "no such member");
>>> }
>>> }
>>> };
>>>
>>> The use is then
>>>
>>> X x;
>>> int foo = x.x;
>>>
>>> or more verbosely,
>>> X x;
>>> int foo = std::reflection::member<**compiletimestring("x")>(x);
>>>
>>
>> OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k is
>> a type that is *not* implicitly convertible to x.x's type? Or the
>>
>
> In the part where I return a reference to y.
>
Except that the reference to `y` returns a `Type&` (where `Type` is `y`'s
type). And as I stated, if `k` is not *implicitly* convertible to `Type`,
then doing `x.x = k` will not work. The actual properties feature would
allow the user to specify multiple `set` methods, each of which could take *
any* type.
Also, what of the possibility where there is no actual `y` at all? That's a
very common use of properties: to create getters/setters for a "variable"
that doesn't exist. Or that you don't want to expose `Type&`? Do you have
to create some proxy type to do the actual getting/setting? Because that's
not sounding like a good feature anymore.
part that lets you have multiple properties with different types (say, an
>> int and a float)? Or the part that makes this increasing mass
>>
>
> There's no restriction against having multiple properties with different
> types in that pseudocode.
>
I can't imagine how that could possibly work, since your `operator-><s>`
can only return a single type. Not unless "multiple properties" means
"multiple properties that all happen to use the same type". And you can't
declare two of these `operator-><s>` things unless they take different
parameters. Which they don't.
Not unless you mean to use a concept or something to conditionally activate
or deactivate different instantiations based on `<s>`. Because that's not
helping the case for this being a good idea; that just makes the complex
feature even moreso.
Why are people so willing to settle for this kind of hackery? Have we
>> learned *nothing* from the `enable_if` horrors? If this is an
>>
>
> Because sometimes people are willing to strive for a general facility that
> may not be optimal for one of the cases
> it covers, like properties, when the general facility provides much more
> than just a single feature.
>
So what if they are? That doesn't explain why a hack is better than a real
feature. Or should we abandon concepts since `enable_if` and such hackery
can get us there anyway?
That presupposes the idea that if we had such reflection, we necessarily *
shouldn't* have real properties, because you could get maybe most of
properties working in a much less easily understood, hacky, and less
readable way. That no IDE would ever be able to understand without having a
full-fledged compiler built into it.
That the general facility might allow 80% of some idea to be implemented
doesn't mean that the 20% it doesn't work for stops being important. Or
that the pain of using the facility in that way should be ignored.
I'm not saying that we shouldn't have reflection. I'm saying that
reflection is no substitute for properties if that's a feature we want. Nor
should we try to twist reflection into something that would make properties
work. If it naturally evolves that way, fine. But we shouldn't try to make
it do that.
--
---
You received this message because you are 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_2265_6158243.1377777258852
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 29, 2013 12:04:16 AM UTC-7, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On 29 August 2013 09:54, Nicol Bolas <span=
dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-m=
ailto=3D"3n5IEdCyNAgJ">jmck...@gmail.com</a>></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"><br><div><blockquote class=
=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc s=
olid;padding-left:1ex">
<div dir=3D"ltr"><div><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 dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margi=
n:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div><br></div><div>Do peo=
ple think properties should be a language feature, when they are seemingly =
just one of the many<br>things compile-time reflection can provide?</div></=
div>
</div></div>
</blockquote><div><br></div></div><div>I keep hearing people try to relate =
reflection to properties. This doesn't make any sense to me at all. Can you=
provide a pseudo code example of how a property would be retrieved using a=
reflection interface?</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div><div>Depends on how far peo=
ple are willing to go with reflection. ;) One of the expectations of people=
proposing<br>reflection facilities is that<br></div><div>1) you can query =
the member functions and member data of a type<br>
</div><div>2) you can customize how a type answers to such queries<br></div=
></div></div></div></blockquote></div><div><br>But there's no coherent prop=
osal for reflection that includes these things as of yet. Not unless I miss=
ed a paper somewhere. It </div>
</div></blockquote><div><br></div><div>Correct. The reflection study group =
hasn't even properly kicked to gear yet.<br> <br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">
<div dir=3D"ltr"><div>seems silly to dismiss a proposal because of somethin=
g that <i>might</i> happen in the future.<br></div></div></blockquote><div>=
<br></div><div>Well, there has been no such dismissal, so I don't see what =
you're complaining about.<br></div></div></div></div></blockquote><div><br>=
*ahem*: "Do people think properties should be a language feature, when they=
are seemingly just one of the many<br>things compile-time reflection can p=
rovide?"<br><br>That sounds dismissive. Since you're dismissing properties =
as "one of the many things compile-time reflection can provide". That sound=
s very much like, "wait for reflection". Which is dismissive.<br><br>Or, le=
t me put it this way:<br><br>There is no way to make properties as a hack, =
either via some library type or via reflection, and still have it fulfill a=
ll of these requirements, such that making a property:<br><br>1: Is easy fo=
r new C++ users to learn to use.<br><br>2: Is easy for new C++ users to rea=
d in other people's code.<br><br>3: Is reasonably compact in syntax.<br><br=
>4: Doesn't change the nature of the type on which it is placed.<br><br>5: =
Doesn't break the abstraction.<br><br>6: Has all of the features of propert=
ies in other languages that are appropriate to C++.<br><br>You may be able =
to make it <i>function</i> with reflection. But it won't ever be a <i>good<=
/i> feature that people will want to use and teach others to use. With refl=
ection, it'll merely be a curiosity that maybe some advanced C++ programmer=
s will provide.<br><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin: 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1=
ex"><div dir=3D"ltr"><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"><div> te=
mplate<compile_time_string s> decltype(auto) operator-><s>()=
<br> {<br></div><div> =
static if (s =3D=3D "x") {<br>
</div><div> &nbs=
p; return y;<br></div><div> } els=
e {<br></div><div> &nb=
sp; static_assert(false, "no such member");<br></div><div>  =
; }<br></div><div> }<br></d=
iv><div>}; <br></div></div><br>
</div><div>The use is then<br><br></div><div>X x;<br>int foo =3D x.x;<br><b=
r></div><div>or more verbosely, <br></div><div>X x;<br></div><div>
int foo =3D std::reflection::member<<u></u>compil<wbr>etimestring("x")&g=
t;(x);<br></div></div></blockquote></div><div><br>OK, where's the part that=
lets you do `x.x =3D 4`? Or `x.x =3D k`, where k is a type that is *not* i=
mplicitly convertible to x.x's type? Or the </div>
</div></blockquote><div><br></div><div>In the part where I return a referen=
ce to y.<br></div></div></div></div></blockquote><div><br>Except that the r=
eference to `y` returns a `Type&` (where `Type` is `y`'s type). And as =
I stated, if `k` is not <i>implicitly</i> convertible to `Type`, then doing=
`x.x =3D k` will not work. The actual properties feature would allow the u=
ser to specify multiple `set` methods, each of which could take <i>any</i> =
type.<br><br>Also, what of the possibility where there is no actual `y` at =
all? That's a very common use of properties: to create getters/setters for =
a "variable" that doesn't exist. Or that you don't want to expose `Type&=
;`? Do you have to create some proxy type to do the actual getting/setting?=
Because that's not sounding like a good feature anymore.<br><br></div><blo=
ckquote 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:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>part =
that lets you have multiple properties with different types (say, an int an=
d a float)? Or the part that makes this increasing mass </div>
</div></blockquote><div><br></div><div>There's no restriction against havin=
g multiple properties with different types in that pseudocode.<br></div></d=
iv></div></div></blockquote><div><br>I can't imagine how that could possibl=
y work, since your `operator-><s>` can only return a single type. =
Not unless "multiple properties" means "multiple properties that all happen=
to use the same type". And you can't declare two of these `operator->&l=
t;s>` things unless they take different parameters. Which they don't.<br=
><br>Not unless you mean to use a concept or something to conditionally act=
ivate or deactivate different instantiations based on `<s>`. Because =
that's not helping the case for this being a good idea; that just makes the=
complex feature even moreso.<br><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"><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">
<div dir=3D"ltr"><div>Why are people so willing to settle for this kind of =
hackery? Have we learned <i>nothing</i> from the `enable_if` horrors? If th=
is is an </div></div></blockquote><div><br></div><div>Because sometimes peo=
ple are willing to strive for a general facility that may not be optimal fo=
r one of the cases<br>
it covers, like properties, when the general facility provides much more th=
an just a single feature.</div></div></div></div></blockquote><div><br>So w=
hat if they are? That doesn't explain why a hack is better than a real feat=
ure. Or should we abandon concepts since `enable_if` and such hackery can g=
et us there anyway?<br><br>That presupposes the idea that if we had such re=
flection, we necessarily <i>shouldn't</i> have real properties, because you=
could get maybe most of properties working in a much less easily understoo=
d, hacky, and less readable way. That no IDE would ever be able to understa=
nd without having a full-fledged compiler built into it.<br><br>That the ge=
neral facility might allow 80% of some idea to be implemented doesn't mean =
that the 20% it doesn't work for stops being important. Or that the pain of=
using the facility in that way should be ignored.<br><br>I'm not saying th=
at we shouldn't have reflection. I'm saying that reflection is no substitut=
e for properties if that's a feature we want. Nor should we try to twist re=
flection into something that would make properties work. If it naturally ev=
olves that way, fine. But we shouldn't try to make it do that.<br></div></d=
iv>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_2265_6158243.1377777258852--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 15:06:31 +0300
Raw View
--001a11c359c4c62c1b04e514ef9e
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 14:54, Nicol Bolas <jmckesson@gmail.com> wrote:
>
>
>> seems silly to dismiss a proposal because of something that *might*happen in the future.
>>>
>>
>> Well, there has been no such dismissal, so I don't see what you're
>> complaining about.
>>
>
> *ahem*: "Do people think properties should be a language feature, when
> they are seemingly just one of the many
>
> things compile-time reflection can provide?"
>
> That sounds dismissive. Since you're dismissing properties as "one of the
> many things compile-time reflection can provide". That sounds very much
> like, "wait for reflection". Which is dismissive.
>
Feel free to continue putting words into other people's mouths. That's a
question, not a dismissal. Anything
else you read into it is your own paranoia.
>
> Or, let me put it this way:
>
> There is no way to make properties as a hack, either via some library type
> or via reflection, and still have it fulfill all of these requirements,
> such that making a property:
>
> 1: Is easy for new C++ users to learn to use.
>
> 2: Is easy for new C++ users to read in other people's code.
>
> 3: Is reasonably compact in syntax.
>
> 4: Doesn't change the nature of the type on which it is placed.
>
> 5: Doesn't break the abstraction.
>
> 6: Has all of the features of properties in other languages that are
> appropriate to C++.
>
There's no way? Based on what evidence? Has this been explored by some
proposal I'm unaware of?
You may be right, which to me would indicate that properties aren't worth
their cost, especially
if it's common that the get/set functions need to be written anyway to
cover cases where they aren't
just trivial operations.
>
> You may be able to make it *function* with reflection. But it won't ever
> be a *good* feature that people will want to use and teach others to use.
> With reflection, it'll merely be a curiosity that maybe some advanced C++
> programmers will provide.
>
> template<compile_time_string s> decltype(auto) operator-><s>()
>>>> {
>>>> static if (s == "x") {
>>>> return y;
>>>> } else {
>>>> static_assert(false, "no such member");
>>>> }
>>>> }
>>>> };
>>>>
>>>> The use is then
>>>>
>>>> X x;
>>>> int foo = x.x;
>>>>
>>>> or more verbosely,
>>>> X x;
>>>> int foo = std::reflection::member<**compil**etimestring("x")>(x);
>>>>
>>>
>>> OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k
>>> is a type that is *not* implicitly convertible to x.x's type? Or the
>>>
>>
>> In the part where I return a reference to y.
>>
>
> Except that the reference to `y` returns a `Type&` (where `Type` is `y`'s
> type). And as I stated, if `k` is not *implicitly* convertible to `Type`,
> then doing `x.x = k` will not work. The actual properties feature would
> allow the user to specify multiple `set` methods, each of which could take
> *any* type.
>
Oh. I must admit I'm unaware of an existing property system that allows
multiple setters.
>
> Also, what of the possibility where there is no actual `y` at all? That's
> a very common use of properties: to create getters/setters for a "variable"
> that doesn't exist. Or that you don't want to expose `Type&`? Do you have
> to create some proxy type to do the actual getting/setting? Because that's
> not sounding like a good feature anymore.
>
No. You can set thin air if you want, or return temporaries.
> part that lets you have multiple properties with different types (say, an
>>> int and a float)? Or the part that makes this increasing mass
>>>
>>
>> There's no restriction against having multiple properties with different
>> types in that pseudocode.
>>
>
> I can't imagine how that could possibly work, since your `operator-><s>`
> can only return a single type. Not unless "multiple properties" means
> "multiple properties that all happen to use the same type". And you can't
> declare two of these `operator-><s>` things unless they take different
> parameters. Which they don't.
>
I can declare multiple specializations for it, since it's a template. I
also expect eventually to have a run-time counterpart
for it that will be called if none of the templates match. That would be
the way to plug run-time reflection on top of it.
>
> Not unless you mean to use a concept or something to conditionally
> activate or deactivate different instantiations based on `<s>`. Because
> that's not helping the case for this being a good idea; that just makes the
> complex feature even moreso.
>
If people choose to do that, it's up to them. It's not the fundamental
technique.
>
> Why are people so willing to settle for this kind of hackery? Have we
>>> learned *nothing* from the `enable_if` horrors? If this is an
>>>
>>
>> Because sometimes people are willing to strive for a general facility
>> that may not be optimal for one of the cases
>> it covers, like properties, when the general facility provides much more
>> than just a single feature.
>>
>
> So what if they are? That doesn't explain why a hack is better than a real
> feature. Or should we abandon concepts since `enable_if` and such hackery
> can get us there anyway?
>
You keep speaking of "hacks". The reason behind such a "hack" that is the
programmable dispatch is the case
where you have N properties/members in a subobject, and you want your
containing wrapper to mirror those.
With your properties, you'll write N properties. With reflection, you write
a single dispatching function that forwards
the member query to the subobject.
>
> That presupposes the idea that if we had such reflection, we necessarily *
> shouldn't* have real properties, because you could get maybe most of
> properties working in a much less easily understood, hacky, and less
> readable way. That no IDE would ever be able to understand without having a
> full-fledged compiler built into it.
>
> That the general facility might allow 80% of some idea to be implemented
> doesn't mean that the 20% it doesn't work for stops being important. Or
> that the pain of using the facility in that way should be ignored.
>
The real question is whether this 20% is important enough that a more
general facility can't cover it sufficiently
well. And do read what Richard said, perhaps it would be better to make
language changes that make properties
as library features more feasible, rather than just putting in a core
language property feature.
> I'm not saying that we shouldn't have reflection. I'm saying that
> reflection is no substitute for properties if that's a feature we want.
>
Again, based on what evidence/exploration? I'd like to see some actual
analysis rather than sweeping statements.
--
---
You received this message because you are 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/.
--001a11c359c4c62c1b04e514ef9e
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 14:54, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</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">=A0<br><div class=3D"im"><b=
lockquote 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:=
1ex">
<div dir=3D"ltr"><div>seems silly to dismiss a proposal because of somethin=
g that <i>might</i> happen in the future.<br></div></div></blockquote><div>=
<br></div><div>Well, there has been no such dismissal, so I don't see w=
hat you're complaining about.<br>
</div></div></div></div></blockquote></div><div><br>*ahem*: "Do people=
think properties should be a language feature, when they are seemingly jus=
t one of the many<div class=3D"im"><br>things compile-time reflection can p=
rovide?"<br>
<br></div>That sounds dismissive. Since you're dismissing properties as=
"one of the many things compile-time reflection can provide". Th=
at sounds very much like, "wait for reflection". Which is dismiss=
ive.<br>
</div></div></blockquote><div><br></div><div>Feel free to continue putting =
words into other people's mouths. That's a question, not a dismissa=
l. Anything<br></div><div>else you read into it is your own paranoia.<br>
=A0<br></div><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><br>Or, l=
et me put it this way:<br><br>There is no way to make properties as a hack,=
either via some library type or via reflection, and still have it fulfill =
all of these requirements, such that making a property:<br>
<br>1: Is easy for new C++ users to learn to use.<br><br>2: Is easy for new=
C++ users to read in other people's code.<br><br>3: Is reasonably comp=
act in syntax.<br><br>4: Doesn't change the nature of the type on which=
it is placed.<br>
<br>5: Doesn't break the abstraction.<br><br>6: Has all of the features=
of properties in other languages that are appropriate to C++.<br></div></d=
iv></blockquote><div><br></div><div>There's no way? Based on what evide=
nce? Has this been explored by some proposal I'm unaware of?<br>
</div><div>You may be right, which to me would indicate that properties are=
n't worth their cost, especially<br>if it's common that the get/set=
functions need to be written anyway to cover cases where they aren't<b=
r>
just trivial operations.<br></div><div><br>=A0<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div dir=3D"ltr"><div><br>You may be able to make it <i>funct=
ion</i> with reflection. But it won't ever be a <i>good</i> feature tha=
t people will want to use and teach others to use. With reflection, it'=
ll merely be a curiosity that maybe some advanced C++ programmers will prov=
ide.<br>
<br></div><div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"marg=
in:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div di=
r=3D"ltr"><div><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 dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div>=A0=A0=A0 template<=
;compile_time_string s> decltype(auto) operator-><s>()<br>=A0=
=A0=A0 {<br></div><div>=A0=A0=A0=A0=A0=A0=A0 static if (s =3D=3D "x&qu=
ot;) {<br>
</div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 return y;<br></div><div>=A0=A0=
=A0=A0=A0=A0=A0 } else {<br></div><div>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 st=
atic_assert(false, "no such member");<br></div><div>=A0=A0=A0=A0=
=A0=A0=A0 }<br></div><div>=A0=A0=A0 }<br></div><div>}; <br></div></div><br>
</div><div>The use is then<br><br></div><div>X x;<br>int foo =3D x.x;<br><b=
r></div><div>or more verbosely, <br></div><div>X x;<br></div><div>
int foo =3D std::reflection::member<<u></u>compil<u></u>etimestring(&quo=
t;x")>(x);<br></div></div></blockquote></div><div><br>OK, where'=
;s the part that lets you do `x.x =3D 4`? Or `x.x =3D k`, where k is a type=
that is *not* implicitly convertible to x.x's type? Or the </div>
</div></blockquote><div><br></div><div>In the part where I return a referen=
ce to y.<br></div></div></div></div></blockquote></div><div><br>Except that=
the reference to `y` returns a `Type&` (where `Type` is `y`'s type=
). And as I stated, if `k` is not <i>implicitly</i> convertible to `Type`, =
then doing `x.x =3D k` will not work. The actual properties feature would a=
llow the user to specify multiple `set` methods, each of which could take <=
i>any</i> type.<br>
</div></div></blockquote><div><br></div><div>Oh. I must admit I'm unawa=
re of an existing property system that allows multiple setters.<br>=A0<br><=
/div><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><br>Also, what of the possibility where there is no a=
ctual `y` at all? That's a very common use of properties: to create get=
ters/setters for a "variable" that doesn't exist. Or that you=
don't want to expose `Type&`? Do you have to create some proxy typ=
e to do the actual getting/setting? Because that's not sounding like a =
good feature anymore.<br>
</div></div></blockquote><div><br></div><div>No. You can set thin air if yo=
u want, or return temporaries. <br><br></div><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"><div><br></div><div class=3D"im"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div>part that lets you have multiple properties with diff=
erent types (say, an int and a float)? Or the part that makes this increasi=
ng mass </div>
</div></blockquote><div><br></div><div>There's no restriction against h=
aving multiple properties with different types in that pseudocode.<br></div=
></div></div></div></blockquote></div><div><br>I can't imagine how that=
could possibly work, since your `operator-><s>` can only return a=
single type. Not unless "multiple properties" means "multip=
le properties that all happen to use the same type". And you can't=
declare two of these `operator-><s>` things unless they take diff=
erent parameters. Which they don't.<br>
</div></div></blockquote><div><br></div><div>I can declare multiple special=
izations for it, since it's a template. I also expect eventually to hav=
e a run-time counterpart<br>for it that will be called if none of the templ=
ates match. That would be the way to plug run-time reflection on top of it.=
<br>
=A0<br></div><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><br>Not u=
nless you mean to use a concept or something to conditionally activate or d=
eactivate different instantiations based on `<s>`. Because that's=
not helping the case for this being a good idea; that just makes the compl=
ex feature even moreso.<br>
</div></div></blockquote><div><br></div><div>If people choose to do that, i=
t's up to them. It's not the fundamental technique.<br>=A0<br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br></div><div class=3D"im"><blockquote class=3D"gmai=
l_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><blockquote=
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli=
d;padding-left:1ex">
<div dir=3D"ltr"><div>Why are people so willing to settle for this kind of =
hackery? Have we learned <i>nothing</i> from the `enable_if` horrors? If th=
is is an </div></div></blockquote><div><br></div><div>Because sometimes peo=
ple are willing to strive for a general facility that may not be optimal fo=
r one of the cases<br>
it covers, like properties, when the general facility provides much more th=
an just a single feature.</div></div></div></div></blockquote></div><div><b=
r>So what if they are? That doesn't explain why a hack is better than a=
real feature. Or should we abandon concepts since `enable_if` and such hac=
kery can get us there anyway?<br>
</div></div></blockquote><div><br></div><div>You keep speaking of "hac=
ks". The reason behind such a "hack" that is the programmabl=
e dispatch is the case<br>where you have N properties/members in a subobjec=
t, and you want your containing wrapper to mirror those.<br>
</div><div>With your properties, you'll write N properties. With reflec=
tion, you write a single dispatching function that forwards<br>the member q=
uery to the subobject.<br><br>=A0<br></div><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><br>That presupposes the idea that if we had such ref=
lection, we necessarily <i>shouldn't</i> have real properties, because =
you could get maybe most of properties working in a much less easily unders=
tood, hacky, and less readable way. That no IDE would ever be able to under=
stand without having a full-fledged compiler built into it.<br>
<br>That the general facility might allow 80% of some idea to be implemente=
d doesn't mean that the 20% it doesn't work for stops being importa=
nt. Or that the pain of using the facility in that way should be ignored.<b=
r>
</div></div></blockquote><div><br></div><div>The real question is whether t=
his 20% is important enough that a more general facility can't cover it=
sufficiently<br>well. And do read what Richard said, perhaps it would be b=
etter to make language changes that make properties<br>
as library features more feasible, rather than just putting in a core langu=
age property feature.<br><br></div><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><br>I'm not saying that we shouldn't have reflection. I'm =
saying that reflection is no substitute for properties if that's a feat=
ure we want. </div></div></blockquote><div><br></div><div>Again, based on w=
hat evidence/exploration? I'd like to see some actual analysis rather t=
han sweeping statements.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c359c4c62c1b04e514ef9e--
.
Author: MJanes <max.jns@gmail.com>
Date: Thu, 29 Aug 2013 06:41:46 -0700 (PDT)
Raw View
------=_Part_82_17243539.1377783706927
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
FWIW, I share the view that "auto" properties hijack code by hiding=20
function calls behind usual "variable" access ( and things like output=20
parameters show that c++ variables and properties would not share the same=
=20
store/access semantics at all ). If one really wants a way to think get/set=
=20
pairs as "properties", why not just having operators giving an alternative=
=20
function invocation syntax ? ( as all user definable operators do BTW ),=20
eg. something like ( pretending the parser wouldn't complain ):
x:y:z --parsed as--> x.y().z(), that is making : a member zero-ary=
=20
invocation operator
x :=3D y :=3D z --parsed as--> x( y( z ) ), that is making :=3D a one-ary=
=20
invocation operator
this would also allow generalizations going beyond properties, while=20
retaining usual c++ variable semantics ...
Il giorno marted=EC 27 agosto 2013 17:04:42 UTC+2, Nick ha scritto:
>
> Has anyone considered using "auto" as a qualifier to specify that a=20
> function is a property?
>
--=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_82_17243539.1377783706927
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">FWIW, I share the view that "auto" properties hijack code =
by hiding function calls behind usual "variable" access ( and things like o=
utput parameters show that c++ variables and properties would not share the=
same store/access semantics at all ). If one really wants a way to think g=
et/set pairs as "properties", why not just having operators giving an alter=
native function invocation syntax ? ( as all user definable operators do BT=
W ), eg. something like ( pretending the parser wouldn't complain ):<br><br=
>x:y:z --parsed as--> x.=
y().z(), that is making : a member zero-ary invocation operator<br>x :=3D y=
:=3D z --parsed as--> x( y( z ) ), that is making :=3D a on=
e-ary invocation operator<br><br>this would also allow generalizations goin=
g beyond properties, while retaining usual c++ variable semantics ...<br><b=
r>Il giorno marted=EC 27 agosto 2013 17:04:42 UTC+2, Nick ha scritto:<block=
quote 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>Has anyone con=
sidered using "auto" as a qualifier to specify that a function is a propert=
y?<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_82_17243539.1377783706927--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 08:06:05 -0700 (PDT)
Raw View
------=_Part_13_16005785.1377788765423
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, 29 August 2013 08:06:31 UTC-4, Ville Voutilainen wrote:
>
>
>
> On 29 August 2013 14:54, Nicol Bolas <jmck...@gmail.com <javascript:>>wrote:
>
>>
>>
>>> seems silly to dismiss a proposal because of something that *might*happen in the future.
>>>>
>>>
>>> Well, there has been no such dismissal, so I don't see what you're
>>> complaining about.
>>>
>>
>> *ahem*: "Do people think properties should be a language feature, when
>> they are seemingly just one of the many
>>
>> things compile-time reflection can provide?"
>>
>> That sounds dismissive. Since you're dismissing properties as "one of the
>> many things compile-time reflection can provide". That sounds very much
>> like, "wait for reflection". Which is dismissive.
>>
>
> Feel free to continue putting words into other people's mouths. That's a
> question, not a dismissal. Anything
> else you read into it is your own paranoia.
>
>
>>
>> Or, let me put it this way:
>>
>> There is no way to make properties as a hack, either via some library
>> type or via reflection, and still have it fulfill all of these
>> requirements, such that making a property:
>>
>> 1: Is easy for new C++ users to learn to use.
>>
>> 2: Is easy for new C++ users to read in other people's code.
>>
>> 3: Is reasonably compact in syntax.
>>
>> 4: Doesn't change the nature of the type on which it is placed.
>>
>> 5: Doesn't break the abstraction.
>>
>> 6: Has all of the features of properties in other languages that are
>> appropriate to C++.
>>
>
> There's no way? Based on what evidence? Has this been explored by some
> proposal I'm unaware of?
> You may be right, which to me would indicate that properties aren't worth
> their cost, especially
> if it's common that the get/set functions need to be written anyway to
> cover cases where they aren't
> just trivial operations.
>
>
>
>>
>> You may be able to make it *function* with reflection. But it won't ever
>> be a *good* feature that people will want to use and teach others to
>> use. With reflection, it'll merely be a curiosity that maybe some advanced
>> C++ programmers will provide.
>>
>> template<compile_time_string s> decltype(auto) operator-><s>()
>>>>> {
>>>>> static if (s == "x") {
>>>>> return y;
>>>>> } else {
>>>>> static_assert(false, "no such member");
>>>>> }
>>>>> }
>>>>> };
>>>>>
>>>>> The use is then
>>>>>
>>>>> X x;
>>>>> int foo = x.x;
>>>>>
>>>>> or more verbosely,
>>>>> X x;
>>>>> int foo = std::reflection::member<**compil**etimestring("x")>(x);
>>>>>
>>>>
>>>> OK, where's the part that lets you do `x.x = 4`? Or `x.x = k`, where k
>>>> is a type that is *not* implicitly convertible to x.x's type? Or the
>>>>
>>>
>>> In the part where I return a reference to y.
>>>
>>
>> Except that the reference to `y` returns a `Type&` (where `Type` is `y`'s
>> type). And as I stated, if `k` is not *implicitly* convertible to
>> `Type`, then doing `x.x = k` will not work. The actual properties feature
>> would allow the user to specify multiple `set` methods, each of which could
>> take *any* type.
>>
>
> Oh. I must admit I'm unaware of an existing property system that allows
> multiple setters.
>
>
>>
>> Also, what of the possibility where there is no actual `y` at all? That's
>> a very common use of properties: to create getters/setters for a "variable"
>> that doesn't exist. Or that you don't want to expose `Type&`? Do you have
>> to create some proxy type to do the actual getting/setting? Because that's
>> not sounding like a good feature anymore.
>>
>
> No. You can set thin air if you want, or return temporaries.
>
>
>> part that lets you have multiple properties with different types (say, an
>>>> int and a float)? Or the part that makes this increasing mass
>>>>
>>>
>>> There's no restriction against having multiple properties with different
>>> types in that pseudocode.
>>>
>>
>> I can't imagine how that could possibly work, since your `operator-><s>`
>> can only return a single type. Not unless "multiple properties" means
>> "multiple properties that all happen to use the same type". And you can't
>> declare two of these `operator-><s>` things unless they take different
>> parameters. Which they don't.
>>
>
> I can declare multiple specializations for it, since it's a template. I
> also expect eventually to have a run-time counterpart
> for it that will be called if none of the templates match. That would be
> the way to plug run-time reflection on top of it.
>
>
>>
>> Not unless you mean to use a concept or something to conditionally
>> activate or deactivate different instantiations based on `<s>`. Because
>> that's not helping the case for this being a good idea; that just makes the
>> complex feature even moreso.
>>
>
> If people choose to do that, it's up to them. It's not the fundamental
> technique.
>
>
>>
>> Why are people so willing to settle for this kind of hackery? Have we
>>>> learned *nothing* from the `enable_if` horrors? If this is an
>>>>
>>>
>>> Because sometimes people are willing to strive for a general facility
>>> that may not be optimal for one of the cases
>>> it covers, like properties, when the general facility provides much more
>>> than just a single feature.
>>>
>>
>> So what if they are? That doesn't explain why a hack is better than a
>> real feature. Or should we abandon concepts since `enable_if` and such
>> hackery can get us there anyway?
>>
>
> You keep speaking of "hacks". The reason behind such a "hack" that is the
> programmable dispatch is the case
> where you have N properties/members in a subobject, and you want your
> containing wrapper to mirror those.
> With your properties, you'll write N properties. With reflection, you
> write a single dispatching function that forwards
> the member query to the subobject.
>
>
>
>>
>> That presupposes the idea that if we had such reflection, we necessarily
>> *shouldn't* have real properties, because you could get maybe most of
>> properties working in a much less easily understood, hacky, and less
>> readable way. That no IDE would ever be able to understand without having a
>> full-fledged compiler built into it.
>>
>> That the general facility might allow 80% of some idea to be implemented
>> doesn't mean that the 20% it doesn't work for stops being important. Or
>> that the pain of using the facility in that way should be ignored.
>>
>
> The real question is whether this 20% is important enough that a more
> general facility can't cover it sufficiently
> well. And do read what Richard said, perhaps it would be better to make
> language changes that make properties
> as library features more feasible, rather than just putting in a core
> language property feature.
>
>
>> I'm not saying that we shouldn't have reflection. I'm saying that
>> reflection is no substitute for properties if that's a feature we want.
>>
>
> Again, based on what evidence/exploration? I'd like to see some actual
> analysis rather than sweeping statements.
>
*"Oh. I must admit I'm unaware of an existing property system that allows
multiple setters."*
The D language property system(which I made reference to in my first post)
does:
import std.stdio;
struct Foo
{
@property int data() {
return m_data;
}
@property int data(int value) {
writeln("set int");
return m_data = value;
}
@property int data(float value) {
writeln("set float");
return m_data = cast(int)value;
}
private: int m_data;
}
void main()
{
Foo foo;
foo.data = 1;
foo.data = 2.0f;
writef("Result %s\n", foo.data);
}
output:
set int
set float
2
As far as this function goes, which I agree is quite imaginary, I don't see
how it would provide a better, if any, solution to the problems that
properties solve.
*"template<compile_time_string s> decltype(auto) operator-><s>()"*
--
---
You received this message because you are 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_13_16005785.1377788765423
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Thursday, 29 August 20=
13 08:06:31 UTC-4, Ville Voutilainen wrote:</span><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><br><div class=3D"gm=
ail_quote">On 29 August 2013 14:54, Nicol Bolas <span dir=3D"ltr"><<a hr=
ef=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"BNfv3yZdAZsJ"=
>jmck...@gmail.com</a>></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"> <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"><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>seems silly to dismiss a proposal because of somethin=
g that <i>might</i> happen in the future.<br></div></div></blockquote><div>=
<br></div><div>Well, there has been no such dismissal, so I don't see what =
you're complaining about.<br>
</div></div></div></div></blockquote></div><div><br>*ahem*: "Do people thin=
k properties should be a language feature, when they are seemingly just one=
of the many<div><br>things compile-time reflection can provide?"<br>
<br></div>That sounds dismissive. Since you're dismissing properties as "on=
e of the many things compile-time reflection can provide". That sounds very=
much like, "wait for reflection". Which is dismissive.<br>
</div></div></blockquote><div><br></div><div>Feel free to continue putting =
words into other people's mouths. That's a question, not a dismissal. Anyth=
ing<br></div><div>else you read into it is your own paranoia.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>Or=
, let me put it this way:<br><br>There is no way to make properties as a ha=
ck, either via some library type or via reflection, and still have it fulfi=
ll all of these requirements, such that making a property:<br>
<br>1: Is easy for new C++ users to learn to use.<br><br>2: Is easy for new=
C++ users to read in other people's code.<br><br>3: Is reasonably compact =
in syntax.<br><br>4: Doesn't change the nature of the type on which it is p=
laced.<br>
<br>5: Doesn't break the abstraction.<br><br>6: Has all of the features of =
properties in other languages that are appropriate to C++.<br></div></div><=
/blockquote><div><br></div><div>There's no way? Based on what evidence? Has=
this been explored by some proposal I'm unaware of?<br>
</div><div>You may be right, which to me would indicate that properties are=
n't worth their cost, especially<br>if it's common that the get/set functio=
ns need to be written anyway to cover cases where they aren't<br>
just trivial operations.<br></div><div><br> <br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pad=
ding-left:1ex"><div dir=3D"ltr"><div><br>You may be able to make it <i>func=
tion</i> with reflection. But it won't ever be a <i>good</i> feature that p=
eople will want to use and teach others to use. With reflection, it'll mere=
ly be a curiosity that maybe some advanced C++ programmers will provide.<br=
>
<br></div><div><blockquote class=3D"gmail_quote" style=3D"margin:0;margin-l=
eft:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><di=
v><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">
<div dir=3D"ltr"><div><blockquote class=3D"gmail_quote" style=3D"margin:0;m=
argin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div class=3D"gmail_quote"><div> te=
mplate<compile_time_string s> decltype(auto) operator-><s>()=
<br> {<br></div><div> =
static if (s =3D=3D "x") {<br>
</div><div> &nbs=
p; return y;<br></div><div> } els=
e {<br></div><div> &nb=
sp; static_assert(false, "no such member");<br></div><div>  =
; }<br></div><div> }<br></d=
iv><div>}; <br></div></div><br>
</div><div>The use is then<br><br></div><div>X x;<br>int foo =3D x.x;<br><b=
r></div><div>or more verbosely, <br></div><div>X x;<br></div><div>
int foo =3D std::reflection::member<<u></u>compil<u></u><wbr>etimestring=
("x")>(x);<br></div></div></blockquote></div><div><br>OK, where's the pa=
rt that lets you do `x.x =3D 4`? Or `x.x =3D k`, where k is a type that is =
*not* implicitly convertible to x.x's type? Or the </div>
</div></blockquote><div><br></div><div>In the part where I return a referen=
ce to y.<br></div></div></div></div></blockquote></div><div><br>Except that=
the reference to `y` returns a `Type&` (where `Type` is `y`'s type). A=
nd as I stated, if `k` is not <i>implicitly</i> convertible to `Type`, then=
doing `x.x =3D k` will not work. The actual properties feature would allow=
the user to specify multiple `set` methods, each of which could take <i>an=
y</i> type.<br>
</div></div></blockquote><div><br></div><div>Oh. I must admit I'm unaware o=
f an existing property system that allows multiple setters.<br> <br></=
div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-lef=
t:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br>Also, what of the possibility where there is no a=
ctual `y` at all? That's a very common use of properties: to create getters=
/setters for a "variable" that doesn't exist. Or that you don't want to exp=
ose `Type&`? Do you have to create some proxy type to do the actual get=
ting/setting? Because that's not sounding like a good feature anymore.<br>
</div></div></blockquote><div><br></div><div>No. You can set thin air if yo=
u want, or return temporaries. <br><br></div><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"><div><br></div><div><blockquote class=3D"gmail_quote" styl=
e=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"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div dir=3D"ltr"><div>part that lets you have multiple properties with diff=
erent types (say, an int and a float)? Or the part that makes this increasi=
ng mass </div>
</div></blockquote><div><br></div><div>There's no restriction against havin=
g multiple properties with different types in that pseudocode.<br></div></d=
iv></div></div></blockquote></div><div><br>I can't imagine how that could p=
ossibly work, since your `operator-><s>` can only return a single =
type. Not unless "multiple properties" means "multiple properties that all =
happen to use the same type". And you can't declare two of these `operator-=
><s>` things unless they take different parameters. Which they don=
't.<br>
</div></div></blockquote><div><br></div><div>I can declare multiple special=
izations for it, since it's a template. I also expect eventually to have a =
run-time counterpart<br>for it that will be called if none of the templates=
match. That would be the way to plug run-time reflection on top of it.<br>
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8e=
x;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><br>No=
t unless you mean to use a concept or something to conditionally activate o=
r deactivate different instantiations based on `<s>`. Because that's =
not helping the case for this being a good idea; that just makes the comple=
x feature even moreso.<br>
</div></div></blockquote><div><br></div><div>If people choose to do that, i=
t's up to them. It's not the fundamental technique.<br> <br></div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br></div><div><blockquote class=3D"gmail_quote" styl=
e=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"gma=
il_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-lef=
t:1ex">
<div dir=3D"ltr"><div>Why are people so willing to settle for this kind of =
hackery? Have we learned <i>nothing</i> from the `enable_if` horrors? If th=
is is an </div></div></blockquote><div><br></div><div>Because sometimes peo=
ple are willing to strive for a general facility that may not be optimal fo=
r one of the cases<br>
it covers, like properties, when the general facility provides much more th=
an just a single feature.</div></div></div></div></blockquote></div><div><b=
r>So what if they are? That doesn't explain why a hack is better than a rea=
l feature. Or should we abandon concepts since `enable_if` and such hackery=
can get us there anyway?<br>
</div></div></blockquote><div><br></div><div>You keep speaking of "hacks". =
The reason behind such a "hack" that is the programmable dispatch is the ca=
se<br>where you have N properties/members in a subobject, and you want your=
containing wrapper to mirror those.<br>
</div><div>With your properties, you'll write N properties. With reflection=
, you write a single dispatching function that forwards<br>the member query=
to the subobject.<br><br> <br></div><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><br>That presupposes the idea that if we had such ref=
lection, we necessarily <i>shouldn't</i> have real properties, because you =
could get maybe most of properties working in a much less easily understood=
, hacky, and less readable way. That no IDE would ever be able to understan=
d without having a full-fledged compiler built into it.<br>
<br>That the general facility might allow 80% of some idea to be implemente=
d doesn't mean that the 20% it doesn't work for stops being important. Or t=
hat the pain of using the facility in that way should be ignored.<br>
</div></div></blockquote><div><br></div><div>The real question is whether t=
his 20% is important enough that a more general facility can't cover it suf=
ficiently<br>well. And do read what Richard said, perhaps it would be bette=
r to make language changes that make properties<br>
as library features more feasible, rather than just putting in a core langu=
age property feature.<br><br></div><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><br>I'm not saying that we shouldn't have reflection. I'm saying that =
reflection is no substitute for properties if that's a feature we want. </d=
iv></div></blockquote><div><br></div><div>Again, based on what evidence/exp=
loration? I'd like to see some actual analysis rather than sweeping stateme=
nts.</div></div></div></div></blockquote><div><br></div><div><br></div><div=
><i>"Oh. I must admit I'm unaware of an existing property system that allow=
s multiple setters."</i><br></div><div><br></div><div>The D language proper=
ty system<span style=3D"font-size: 13px;">(which I made reference to in my =
first post)</span><span style=3D"font-size: 13px;"> does:</span></div>=
<div><br></div><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;"=
><code class=3D"prettyprint"><div class=3D"subprettyprint"><span class=3D"s=
tyled-by-prettify"><font color=3D"#000000"><div class=3D"subprettyprint">im=
port std.stdio;</div><div class=3D"subprettyprint"><br></div><div class=3D"=
subprettyprint">struct Foo</div><div class=3D"subprettyprint">{</div><div c=
lass=3D"subprettyprint"> @property int data() {</div><div clas=
s=3D"subprettyprint"> return m_data;</div><div c=
lass=3D"subprettyprint"> }</div><div class=3D"subprettyprint">=
@property int data(int value) {</div><div class=3D"subprettyp=
rint"> writeln("set int");</div><div class=3D"su=
bprettyprint"> return m_data =3D value;</div><di=
v class=3D"subprettyprint"> }</div><div class=3D"subprettyprin=
t"> @property int data(float value) {</div><div class=3D"subpr=
ettyprint"> writeln("set float");</div><div clas=
s=3D"subprettyprint"> return m_data =3D cast(int=
)value;</div><div class=3D"subprettyprint"> }</div><div class=
=3D"subprettyprint"> private: int m_data;</div><div class=3D"s=
ubprettyprint">}</div><div class=3D"subprettyprint"><br></div><div class=3D=
"subprettyprint">void main()</div><div class=3D"subprettyprint">{</div><div=
class=3D"subprettyprint"> Foo foo;</div><div class=3D"subpret=
typrint"> foo.data =3D 1;</div><div class=3D"subprettyprint">&=
nbsp; foo.data =3D 2.0f;</div><div class=3D"subprettyprint"> &=
nbsp; writef("Result %s\n", foo.data);</div><div class=3D"subprettyprint">}=
</div></font></span></div></code></div><div><br></div><div>output:</div><di=
v>set int</div><div>set float</div><div>2</div><div><br></div><div>As far a=
s this function goes, which I agree is quite imaginary, I don't see how it =
would provide a better, if any, solution to the problems that properties so=
lve.</div><div><br></div><div><span style=3D"color: rgb(80, 0, 80);"><i>"te=
mplate<compile_time_string s> decltype(auto) operator-><s>()=
"</i></span><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_13_16005785.1377788765423--
.
Author: max.jns@gmail.com
Date: Thu, 29 Aug 2013 00:32:47 -0700 (PDT)
Raw View
------=_Part_3428_27884085.1377761567784
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
FWIW, I share the view that "auto" properties hijack code by hiding=20
function calls behind usual "variable" access ( and things like output=20
parameters show that c+++ variables and properties do not share the same=20
store/access semantics ). If one really wants a way to think get/set pairs=
=20
as "properties", why not just having operators giving an alternative=20
function invocation syntax ? ( as all user definable operators essentially=
=20
do BTW ), eg. something like ( pretending the parser wouldn't complain ):
x:y:z --parsed as--> x.y().z()
x :=3D y :=3D z --parsed as--> x( y( z ) )
Il giorno marted=EC 27 agosto 2013 17:04:42 UTC+2, Nick ha scritto:
>
> Has anyone considered using "auto" as a qualifier to specify that a=20
> function is a property?
>
--=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_3428_27884085.1377761567784
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">FWIW, I share the view that "auto" properties hijack code =
by hiding function calls behind usual "variable" access ( and things like o=
utput parameters show that c+++ variables and properties do not share the s=
ame store/access semantics ). If one really wants a way to think get/set pa=
irs as "properties", why not just having operators giving an alternative fu=
nction invocation syntax ? ( as all user definable operators essentially do=
BTW ), eg. something like ( pretending the parser wouldn't complain ):<br>=
<br>x:y:z --parsed as--> =
x.y().z()<br>x :=3D y :=3D z --parsed as--> x( y( z ) )<br>=
<br>Il giorno marted=EC 27 agosto 2013 17:04:42 UTC+2, Nick ha scritto:<blo=
ckquote 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>Has anyone c=
onsidered using "auto" as a qualifier to specify that a function is a prope=
rty?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3428_27884085.1377761567784--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 18:55:48 +0300
Raw View
--089e013cbae8bf8e4e04e51823c0
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 18:06, Nick <nicolas.jinchereau@gmail.com> wrote:
> *"Oh. I must admit I'm unaware of an existing property system that allows
> multiple setters."*
>
> The D language property system(which I made reference to in my first post)
> does:
>
> import std.stdio;
>
> struct Foo
> {
> @property int data() {
> return m_data;
> }
> @property int data(int value) {
> writeln("set int");
> return m_data = value;
> }
> @property int data(float value) {
> writeln("set float");
> return m_data = cast(int)value;
> }
> private: int m_data;
> }
>
> void main()
> {
> Foo foo;
> foo.data = 1;
> foo.data = 2.0f;
> writef("Result %s\n", foo.data);
> }
>
> output:
> set int
> set float
> 2
>
Thanks.
>
> As far as this function goes, which I agree is quite imaginary, I don't
> see how it would provide a better, if any, solution to the problems that
> properties solve.
>
> *"template<compile_time_string s> decltype(auto) operator-><s>()"*
>
>
>
>
I never claimed it provides a better solution that a simple property
syntax. The idea is more geared towards
forwarding and avoiding boilerplate when doing so. If the same facility can
be used for properties, that's
just fine and dandy.
Do note that I am unaware of any reflection idea that would support
differentiating getters/setters like
properties do, so making (or, if you want, twisting) reflection facilities
support the functionality
that properties provide requires some amounts of work.
--
---
You received this message because you are 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/.
--089e013cbae8bf8e4e04e51823c0
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 18:06, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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"><span style=3D"font-size:13=
px"></span><div><div class=3D"h5"><div><i>"Oh. I must admit I'm un=
aware of an existing property system that allows multiple setters."</i=
><br>
</div><div><br></div></div></div><div>The D language property system<span s=
tyle=3D"font-size:13px">(which I made reference to in my first post)</span>=
<span style=3D"font-size:13px">=A0does:</span></div><div><br></div><div sty=
le=3D"background-color:rgb(250,250,250);border:1px solid rgb(187,187,187);w=
ord-wrap:break-word">
<code><div><span><font color=3D"#000000"><div>import std.stdio;</div><div><=
br></div><div>struct Foo</div><div>{</div><div>=A0 =A0 @property int data()=
{</div><div>=A0 =A0 =A0 =A0 return m_data;</div><div>=A0 =A0 }</div><div>=
=A0 =A0 @property int data(int value) {</div>
<div>=A0 =A0 =A0 =A0 writeln("set int");</div><div>=A0 =A0 =A0 =
=A0 return m_data =3D value;</div><div>=A0 =A0 }</div><div>=A0 =A0 @propert=
y int data(float value) {</div><div>=A0 =A0 =A0 =A0 writeln("set float=
");</div><div>=A0 =A0 =A0 =A0 return m_data =3D cast(int)value;</div>
<div>=A0 =A0 }</div><div>=A0 =A0 private: int m_data;</div><div>}</div><div=
><br></div><div>void main()</div><div>{</div><div>=A0 =A0 Foo foo;</div><di=
v>=A0 =A0 foo.data =3D 1;</div><div>=A0 =A0 foo.data =3D 2.0f;</div><div>=
=A0 =A0 writef("Result %s\n", foo.data);</div>
<div>}</div></font></span></div></code></div><div><br></div><div>output:</d=
iv><div>set int</div><div>set float</div><div>2</div></div></blockquote><di=
v><br></div><div>Thanks.<br>=A0<br></div><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><br></div><div>As far as this function goes, which I =
agree is quite imaginary, I don't see how it would provide a better, if=
any, solution to the problems that properties solve.</div><div class=3D"im=
">
<div><br></div><div><span style=3D"color:rgb(80,0,80)"><i>"template<=
;compile_time_string s> decltype(auto) operator-><s>()"</i=
></span><br></div></div></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I never claimed it pro=
vides a better solution that a simple property syntax. The idea is more gea=
red towards<br></div><div>forwarding and avoiding boilerplate when doing so=
.. If the same facility can be used for properties, that's<br>
just fine and dandy.<br><br></div><div>Do note that I am unaware of any ref=
lection idea that would support differentiating getters/setters like<br>pro=
perties do, so making (or, if you want, twisting) reflection facilities sup=
port the functionality<br>
that properties provide requires some amounts of work. <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e013cbae8bf8e4e04e51823c0--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 09:26:20 -0700 (PDT)
Raw View
------=_Part_3908_11123694.1377793580158
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, 29 August 2013 11:55:48 UTC-4, Ville Voutilainen wrote:
>
>
>
> On 29 August 2013 18:06, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>
>> *"Oh. I must admit I'm unaware of an existing property system that
>> allows multiple setters."*
>>
>> The D language property system(which I made reference to in my first
>> post) does:
>>
>> import std.stdio;
>>
>> struct Foo
>> {
>> @property int data() {
>> return m_data;
>> }
>> @property int data(int value) {
>> writeln("set int");
>> return m_data = value;
>> }
>> @property int data(float value) {
>> writeln("set float");
>> return m_data = cast(int)value;
>> }
>> private: int m_data;
>> }
>>
>> void main()
>> {
>> Foo foo;
>> foo.data = 1;
>> foo.data = 2.0f;
>> writef("Result %s\n", foo.data);
>> }
>>
>> output:
>> set int
>> set float
>> 2
>>
>
> Thanks.
>
>
>>
>> As far as this function goes, which I agree is quite imaginary, I don't
>> see how it would provide a better, if any, solution to the problems that
>> properties solve.
>>
>> *"template<compile_time_string s> decltype(auto) operator-><s>()"*
>>
>>
>>
>>
> I never claimed it provides a better solution that a simple property
> syntax. The idea is more geared towards
> forwarding and avoiding boilerplate when doing so. If the same facility
> can be used for properties, that's
> just fine and dandy.
>
> Do note that I am unaware of any reflection idea that would support
> differentiating getters/setters like
> properties do, so making (or, if you want, twisting) reflection facilities
> support the functionality
> that properties provide requires some amounts of work.
>
>
*"If the same facility can be used for properties, that's just fine and
dandy."*
I don't see how it ever could.
Reflection is about being able to examine code at run-time.
If a class has a function Foo() then one should be able to do this:
Object *object;
Class->GetType()->GetMethod("Foo")->Invoke(object);
Likewise, with a variable called 'number', one should be able to do:
Object *object;
Class->GetType()->GetField("number")->SetInt(object, 5);
So I don't understand how the above could ever be better than a regular old
setter/getter function.
object->set(5);
and in terms of anything happening at compile time, that pretty much falls
under the category of a library implementation, which IMO has been
thoroughly discussed already, and ruled out as far as standardization goes.
--
---
You received this message because you are 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_3908_11123694.1377793580158
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Thursday, 29 August 20=
13 11:55:48 UTC-4, Ville Voutilainen wrote:</span><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><br><br><div class=3D"gm=
ail_quote">On 29 August 2013 18:06, Nick <span dir=3D"ltr"><<a href=3D"j=
avascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"S3lIJL2lsmgJ">nicola=
s.j...@gmail.com</a>></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"><span style=3D"font-size:13=
px"></span><div><div><div><i>"Oh. I must admit I'm unaware of an existing p=
roperty system that allows multiple setters."</i><br>
</div><div><br></div></div></div><div>The D language property system<span s=
tyle=3D"font-size:13px">(which I made reference to in my first post)</span>=
<span style=3D"font-size:13px"> does:</span></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><font color=3D"#000000"><div>import std.stdio;</div><div><=
br></div><div>struct Foo</div><div>{</div><div> @property int =
data() {</div><div> return m_data;</div><div>&nb=
sp; }</div><div> @property int data(int value) {</div>
<div> writeln("set int");</div><div>  =
; return m_data =3D value;</div><div> }</div><di=
v> @property int data(float value) {</div><div> &=
nbsp; writeln("set float");</div><div> re=
turn m_data =3D cast(int)value;</div>
<div> }</div><div> private: int m_data;</div><div=
>}</div><div><br></div><div>void main()</div><div>{</div><div> =
Foo foo;</div><div> foo.data =3D 1;</div><div> f=
oo.data =3D 2.0f;</div><div> writef("Result %s\n", foo.data);<=
/div>
<div>}</div></font></span></div></code></div><div><br></div><div>output:</d=
iv><div>set int</div><div>set float</div><div>2</div></div></blockquote><di=
v><br></div><div>Thanks.<br> <br></div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><br></div><div>As far as this function goes, which I =
agree is quite imaginary, I don't see how it would provide a better, if any=
, solution to the problems that properties solve.</div><div>
<div><br></div><div><span style=3D"color:rgb(80,0,80)"><i>"template<comp=
ile_time_string s> decltype(auto) operator-><s>()"</i></span><b=
r></div></div></div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I never claimed it pro=
vides a better solution that a simple property syntax. The idea is more gea=
red towards<br></div><div>forwarding and avoiding boilerplate when doing so=
.. If the same facility can be used for properties, that's<br>
just fine and dandy.<br><br></div><div>Do note that I am unaware of any ref=
lection idea that would support differentiating getters/setters like<br>pro=
perties do, so making (or, if you want, twisting) reflection facilities sup=
port the functionality<br>
that properties provide requires some amounts of work. <br></div></div><br>=
</div></div></blockquote><div><br></div><div><br></div><div><i>"<span style=
=3D"font-size: 13px;">If the same facility can be used for properties, that=
's </span><span style=3D"font-size: 13px;">just fine and dandy."</span=
></i></div><div><br></div><div>I don't see how it ever could.</div><div><br=
></div><div>Reflection is about being able to examine code at run-time.</di=
v><div><br></div><div>If a class has a function Foo(<span style=3D"font-siz=
e: 13px;">) </span><span style=3D"font-size: 13px;">then one should be=
able to do this:</span></div><div><span style=3D"font-size: 13px;"><div cl=
ass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border: =
1px solid rgb(187, 187, 187); word-wrap: break-word;"><code class=3D"pretty=
print"><div class=3D"subprettyprint"><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Object</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">*</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ob=
ject</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><spa=
n style=3D"color: #606;" class=3D"styled-by-prettify">Class</span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">-></span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">GetType</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">()-></span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">GetMethod</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #080;" c=
lass=3D"styled-by-prettify">"</span><span style=3D"color: rgb(34, 34, 34); =
font-family: Arial, Helvetica, sans-serif; background-color: rgb(255, 255, =
255);"><span style=3D"color: #080;" class=3D"styled-by-prettify">Foo</span>=
</span><span style=3D"color: #080;" class=3D"styled-by-prettify">"</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)-></span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Invoke</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">object</span><span style=3D"color: r=
gb(102, 102, 0); font-size: 13px; font-family: Arial, Helvetica, sans-serif=
;"><span style=3D"color: #660;" class=3D"styled-by-prettify">);</span></spa=
n></div></code></div></span></div><div><span style=3D"font-size: 13px;"><br=
></span></div><div><span style=3D"font-size: 13px;">Likewise, with a variab=
le called 'number', one should be able to do:</span></div><div><span style=
=3D"font-size: 13px;"><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"><span sty=
le=3D"color: #606;" class=3D"styled-by-prettify">Object</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-by-prettify">object</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></span><span style=3D"color: #606;" class=3D"styled-by-=
prettify">Class</span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">-></span><span style=3D"color: #606;" class=3D"styled-by-prettify">=
GetType</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()-=
></span><span style=3D"color: #606;" class=3D"styled-by-prettify">GetFie=
ld</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span>=
<span style=3D"color: #080;" class=3D"styled-by-prettify">"number"</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)-></span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">SetInt</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"colo=
r: #008;" class=3D"styled-by-prettify">object</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: #066;" class=3D"sty=
led-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">);</span></div></code></div><br></span></div><div><span style=3D"fo=
nt-size: 13px;">So I don't understand how the above could ever be better th=
an a regular old setter/getter function.</span></div><div><span style=3D"fo=
nt-size: 13px;"><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border: 1px solid 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">object</span><span style=3D"colo=
r: #660;" class=3D"styled-by-prettify">-></span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">set</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">(</span><span style=3D"color: #066;" class=3D"st=
yled-by-prettify">5</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">);</span></div></code></div><br></span></div><div><font size=3D"2"=
>and in terms of anything happening at compile time, that pretty much falls=
under the category of a library implementation, which IMO has been </=
font>thoroughly<font size=3D"2"> discussed already, and ruled out as f=
ar as standardization goes.</font></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3908_11123694.1377793580158--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 20:03:38 +0300
Raw View
--001a11339b6a5e99fe04e51916de
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 19:26, Nick <nicolas.jinchereau@gmail.com> wrote:
>
> and in terms of anything happening at compile time, that pretty much falls
> under the category of a library implementation, which IMO has been
> thoroughly discussed already, and ruled out as far as standardization
> goes.
>
>
>
>
I have seen zero evidence of any "ruling out". What we have is vocal
opinions from people
who aren't trying to explore the library possibilities, or any other
possibilities for that matter,
very hard. If someone wants to propose properties, such alternatives need
to be explored
by a proposal paper, otherwise I see little reason to say anything but
"thanks for sharing"
about such a 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/.
--001a11339b6a5e99fe04e51916de
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 19:26, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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"><br><div><font>and in terms=
of anything happening at compile time, that pretty much falls under the ca=
tegory of a library implementation, which IMO has been=A0</font>thoroughly<=
font>=A0discussed already, and ruled out as far as standardization goes.</f=
ont></div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I have seen zero evide=
nce of any "ruling out". What we have is vocal opinions from peop=
le<br>who aren't trying to explore the library possibilities, or any ot=
her possibilities for that matter,<br>
very hard. If someone wants to propose properties, such alternatives need t=
o be explored<br>by a proposal paper, otherwise I see little reason to say =
anything but "thanks for sharing"<br></div><div>about such a prop=
osal.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11339b6a5e99fe04e51916de--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 10:21:07 -0700 (PDT)
Raw View
------=_Part_7247_14870186.1377796868001
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, 29 August 2013 13:03:38 UTC-4, Ville Voutilainen wrote:
>
> On 29 August 2013 19:26, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>
>>
>> and in terms of anything happening at compile time, that pretty much
>> falls under the category of a library implementation, which IMO has been
>> thoroughly discussed already, and ruled out as far as standardization
>> goes.
>>
>>
>>
>>
> I have seen zero evidence of any "ruling out". What we have is vocal
> opinions from people
> who aren't trying to explore the library possibilities, or any other
> possibilities for that matter,
> very hard. If someone wants to propose properties, such alternatives need
> to be explored
> by a proposal paper, otherwise I see little reason to say anything but
> "thanks for sharing"
> about such a proposal.
>
I mean no disrespect here, but it's starting to seem a little like you
haven't even read half the posts in this thread.
*"What we have is vocal opinions from people who aren't trying to explore
the library possibilities"*
I am really lost as to how you can claim that the idea of a library
implementation of properties hasn't been explored. A rather naive search on
Google will easily produce at least 3-4 attempted implementations within
the first couple of pages.
more specifically, you can read this:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf
--
---
You received this message because you are 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_7247_14870186.1377796868001
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size: 13px;">On Thursday, 29 August 20=
13 13:03:38 UTC-4, Ville Voutilainen wrote:</span><br><blockquote class=3D=
"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc s=
olid;padding-left: 1ex;"><div dir=3D"ltr"><br><div><div class=3D"gmail_quot=
e">On 29 August 2013 19:26, Nick <span dir=3D"ltr"><<a href=3D"javascrip=
t:" target=3D"_blank" gdf-obfuscated-mailto=3D"rqsSjCA_i3MJ">nicolas.j...@g=
mail.com</a>></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"><br><div><font>and in terms=
of anything happening at compile time, that pretty much falls under the ca=
tegory of a library implementation, which IMO has been </font>thorough=
ly<font> discussed already, and ruled out as far as standardization go=
es.</font></div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div><div>I have seen zero evide=
nce of any "ruling out". What we have is vocal opinions from people<br>who =
aren't trying to explore the library possibilities, or any other possibilit=
ies for that matter,<br>
very hard. If someone wants to propose properties, such alternatives need t=
o be explored<br>by a proposal paper, otherwise I see little reason to say =
anything but "thanks for sharing"<br></div><div>about such a proposal.</div=
></div></div></div></blockquote><div><br></div><div><br></div><div>I mean n=
o disrespect here, but it's starting to seem a little like you haven't even=
read half the posts in this thread.</div><div><br></div><div><i>"<span sty=
le=3D"font-size: 13px;">What we have is vocal opinions from people </s=
pan><span style=3D"font-size: 13px;">who aren't trying to explore the libra=
ry possibilities"</span></i></div><div><br></div><div>I am really lost as t=
o how you can claim that the idea of a library implementation of properties=
hasn't been explored. A rather naive search on Google will easily produce =
at least 3-4 attempted implementations within the first couple of pages.</d=
iv><div><br></div><div>more specifically, you can read this:</div><div><a h=
ref=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf">h=
ttp://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1615.pdf</a><br></d=
iv><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_7247_14870186.1377796868001--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 20:50:09 +0300
Raw View
--047d7b6d7adab5aa2804e519bccc
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 20:21, Nick <nicolas.jinchereau@gmail.com> wrote:
>
> I mean no disrespect here, but it's starting to seem a little like you
> haven't even read half the posts in this thread.
>
I have read each and every post in this thread. We may draw different
conclusions from those posts,
and that's fine.
>
> *"What we have is vocal opinions from people who aren't trying to explore
> the library possibilities"*
>
> I am really lost as to how you can claim that the idea of a library
> implementation of properties hasn't been explored. A rather naive search on
> Google will easily produce at least 3-4 attempted implementations within
> the first couple of pages.
>
>
>
And those take into use the c++11 features at hand? Richard has a pretty
good starting point for a library
solution for properties. Has that been explored further, or has it just
been dismissed off-hand?
--
---
You received this message because you are 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/.
--047d7b6d7adab5aa2804e519bccc
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 20:21, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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"><br><div>I mean no disrespe=
ct here, but it's starting to seem a little like you haven't even r=
ead half the posts in this thread.</div>
</div></blockquote><div><br></div><div>I have read each and every post in t=
his thread. We may draw different conclusions from those posts,<br>and that=
's fine.<br>=A0<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"im"><div><br></div><div><i>"<span style=
=3D"font-size:13px">What we have is vocal opinions from people=A0</span><sp=
an style=3D"font-size:13px">who aren't trying to explore the library po=
ssibilities"</span></i></div>
<div><br></div></div><div>I am really lost as to how you can claim that the=
idea of a library implementation of properties hasn't been explored. A=
rather naive search on Google will easily produce at least 3-4 attempted i=
mplementations within the first couple of pages.</div>
<div><br><br></div></div></blockquote><div><br></div><div>And those take in=
to use the c++11 features at hand? Richard has a pretty good starting point=
for a library<br>solution for properties. Has that been explored further, =
or has it just been dismissed off-hand? <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b6d7adab5aa2804e519bccc--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 12:01:42 -0700 (PDT)
Raw View
------=_Part_29_18326648.1377802902765
Content-Type: text/plain; charset=ISO-8859-1
This paper, suggests the idea of implicitly callable functions:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
What I am suggesting is overloadable, implicitly callable functions, with
one parameter, that can be paired with the ones that are described in the
above paper.
There was a post about properties on these boards about 6-7 months ago,
where someone mentioned this paper, but no one commented on it. Beside
that, I have not been able to find any reference to discussion or a formal
proposal on this topic. Does anyone have anymore information about this?
--
---
You received this message because you are 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_29_18326648.1377802902765
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">This paper, suggests the idea of implicitly callable funct=
ions:<div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/200=
4/n1611.pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.=
pdf</a><br></div><div><br></div><div>What I am suggesting is overloadable, =
implicitly callable functions, with one parameter, that can be paired with =
the ones that are described in the above paper.</div><div><br></div><div>Th=
ere was a post about properties on these boards about 6-7 months ago, where=
someone mentioned this paper, but no one commented on it. Beside that, I h=
ave not been able to find any reference to discussion or a formal proposal =
on this topic. Does anyone have anymore information about this?</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_29_18326648.1377802902765--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 22:06:12 +0300
Raw View
--047d7b6d8938aa3c5504e51acc0f
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 22:01, Nick <nicolas.jinchereau@gmail.com> wrote:
> This paper, suggests the idea of implicitly callable functions:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
>
> What I am suggesting is overloadable, implicitly callable functions, with
> one parameter, that can be paired with the ones that are described in the
> above paper.
>
> There was a post about properties on these boards about 6-7 months ago,
> where someone mentioned this paper, but no one commented on it. Beside
> that, I have not been able to find any reference to discussion or a formal
> proposal on this topic. Does anyone have anymore information about this?
>
>
>
>
The paper seems to be from an era during which the committee didn't
necessarily take/publish technical discussion
minutes. At least I didn't find such technical minutes in the following
mailing or the one in which that paper
was published. I can ask the Evolution Working Group for whether anyone
recollects what happened and why.
--
---
You received this message because you are 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/.
--047d7b6d8938aa3c5504e51acc0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 22:01, Nick <span dir=3D"ltr"><<a href=3D"mail=
to:nicolas.jinchereau@gmail.com" target=3D"_blank">nicolas.jinchereau@gmail=
..com</a>></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">This paper, suggests the id=
ea of implicitly callable functions:<div><a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf" target=3D"_blank">http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf</a><br>
</div><div><br></div><div>What I am suggesting is overloadable, implicitly =
callable functions, with one parameter, that can be paired with the ones th=
at are described in the above paper.</div><div><br></div><div>There was a p=
ost about properties on these boards about 6-7 months ago, where someone me=
ntioned this paper, but no one commented on it. Beside that, I have not bee=
n able to find any reference to discussion or a formal proposal on this top=
ic. Does anyone have anymore information about this?</div>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
<br><br></div></div></blockquote><div><br></div><div>The paper seems to be =
from an era during which the committee didn't necessarily take/publish =
technical discussion<br>minutes. At least I didn't find such technical =
minutes in the following mailing or the one in which that paper<br>
was published. I can ask the Evolution Working Group for whether anyone rec=
ollects what happened and why.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b6d8938aa3c5504e51acc0f--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 29 Aug 2013 22:08:07 +0300
Raw View
--089e0139ff768e017204e51ad3cb
Content-Type: text/plain; charset=ISO-8859-1
On 29 August 2013 22:06, Ville Voutilainen <ville.voutilainen@gmail.com>wrote:
>
>
>
> On 29 August 2013 22:01, Nick <nicolas.jinchereau@gmail.com> wrote:
>
>> This paper, suggests the idea of implicitly callable functions:
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
>>
>> What I am suggesting is overloadable, implicitly callable functions, with
>> one parameter, that can be paired with the ones that are described in the
>> above paper.
>>
>> There was a post about properties on these boards about 6-7 months ago,
>> where someone mentioned this paper, but no one commented on it. Beside
>> that, I have not been able to find any reference to discussion or a formal
>> proposal on this topic. Does anyone have anymore information about this?
>>
>>
>>
>>
> The paper seems to be from an era during which the committee didn't
> necessarily take/publish technical discussion
> minutes. At least I didn't find such technical minutes in the following
> mailing or the one in which that paper
> was published. I can ask the Evolution Working Group for whether anyone
> recollects what happened and why.
>
>
Oh, do note that while that implicit-function paper has some similarities
to properties, the problem it
presents has afaik been solved by variable templates in c++14.
--
---
You received this message because you are 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/.
--089e0139ff768e017204e51ad3cb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 29 August 2013 22:06, Ville Voutilainen <span dir=3D"ltr"><<a=
href=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutil=
ainen@gmail.com</a>></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"><br><div class=3D"gmail_ext=
ra"><br><br><div class=3D"gmail_quote"><div class=3D"im">On 29 August 2013 =
22:01, Nick <span dir=3D"ltr"><<a href=3D"mailto:nicolas.jinchereau@gmai=
l.com" target=3D"_blank">nicolas.jinchereau@gmail.com</a>></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">This paper, suggests the id=
ea of implicitly callable functions:<div><a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf" target=3D"_blank">http://www.op=
en-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf</a><br>
</div><div><br></div><div>What I am suggesting is overloadable, implicitly =
callable functions, with one parameter, that can be paired with the ones th=
at are described in the above paper.</div><div><br></div><div>There was a p=
ost about properties on these boards about 6-7 months ago, where someone me=
ntioned this paper, but no one commented on it. Beside that, I have not bee=
n able to find any reference to discussion or a formal proposal on this top=
ic. Does anyone have anymore information about this?</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div></div><div>The paper seems =
to be from an era during which the committee didn't necessarily take/pu=
blish technical discussion<br>minutes. At least I didn't find such tech=
nical minutes in the following mailing or the one in which that paper<br>
was published. I can ask the Evolution Working Group for whether anyone rec=
ollects what happened and why.<br></div></div><br></div></div>
</blockquote></div><br><br></div><div class=3D"gmail_extra">Oh, do note tha=
t while that implicit-function paper has some similarities to properties, t=
he problem it<br></div><div class=3D"gmail_extra">presents has afaik been s=
olved by variable templates in c++14.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0139ff768e017204e51ad3cb--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 13:55:53 -0700 (PDT)
Raw View
------=_Part_124_13058511.1377809753540
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, 29 August 2013 15:08:07 UTC-4, Ville Voutilainen wrote:
>
>
>
>
> On 29 August 2013 22:06, Ville Voutilainen <ville.vo...@gmail.com<javascript:>
> > wrote:
>
>>
>>
>>
>> On 29 August 2013 22:01, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>>
>>> This paper, suggests the idea of implicitly callable functions:
>>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
>>>
>>> What I am suggesting is overloadable, implicitly callable functions,
>>> with one parameter, that can be paired with the ones that are described in
>>> the above paper.
>>>
>>> There was a post about properties on these boards about 6-7 months ago,
>>> where someone mentioned this paper, but no one commented on it. Beside
>>> that, I have not been able to find any reference to discussion or a formal
>>> proposal on this topic. Does anyone have anymore information about this?
>>>
>>>
>>>
>>>
>> The paper seems to be from an era during which the committee didn't
>> necessarily take/publish technical discussion
>> minutes. At least I didn't find such technical minutes in the following
>> mailing or the one in which that paper
>> was published. I can ask the Evolution Working Group for whether anyone
>> recollects what happened and why.
>>
>>
>
> Oh, do note that while that implicit-function paper has some similarities
> to properties, the problem it
> presents has afaik been solved by variable templates in c++14.
>
True that *part* of the *first* problem has been solved with variable
templates =) The paper still uses an ICF to calculate and return the area
of circle based on it's radius, which cannot be solved with variable
templates, so I still believe the feature deserves serious consideration.
I can't say I agree with the paper's solution to the second problem though.
The paper provides a method of creating a setter by returning a filter
class instead of the actual value. While this does create the desired
functionality of a setter, and does so with out the memory overhead of a
library based property implementation, it still presents some of the same
problems.
Firstly, the declaration of the filter class does decrease the readability
of the class declaration. I imagine it would be quite painful to deal with
a class declaration containing 10+ of these filter classes.
Second, and probably most importantly, the return type of the property will
be hidden from the caller. Intellisense would report the return type as the
name of the filter class, rather than the actual type, and any
documentation would have to explicitly state the return type, and hope that
the caller knows what's going on with the filter class.
A solution could be to name the filters things like float_AreaFilter, but
it would be impossible to enforce this, and would be only a marginal
improvement. Alternatively, the caller would be stuck having to go and look
through the implementation of the filter to find out what it actually
returns.
Also, any hopes of compile time type deduction of the property would be
lost.
Finally, as I described above, for the library property implementation, any
operator overloads or implicit conversions would have to be explicitly
defined inside each filter class. Of course, a solution would be to inherit
a bunch of mixins with operator overloads, but this would only serve to
decrease readability even more.
So I think that the accessors as described in the paper are a good start,
but that the solution for mutators would be much improved by using
overloadable, single parameter, implicitly callable functions.
--
---
You received this message because you are 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_124_13058511.1377809753540
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, 29 August 2013 15:08:07 UTC-4, Ville =
Voutilainen 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"><br><div><br><br><div class=3D"gmail_quote">On 29 August 2013 22:06, =
Ville Voutilainen <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_=
blank" gdf-obfuscated-mailto=3D"ijOfpWFT0KYJ">ville.vo...@gmail.com</a>>=
</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"><br><div><br><br><div class=
=3D"gmail_quote"><div>On 29 August 2013 22:01, Nick <span dir=3D"ltr"><<=
a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"ijOfpWFT0=
KYJ">nicolas.j...@gmail.com</a>></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">This paper, suggests the id=
ea of implicitly callable functions:<div><a href=3D"http://www.open-std.org=
/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf" target=3D"_blank">http://www.op=
en-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2004/<wbr>n1611.pdf</a><br>
</div><div><br></div><div>What I am suggesting is overloadable, implicitly =
callable functions, with one parameter, that can be paired with the ones th=
at are described in the above paper.</div><div><br></div><div>There was a p=
ost about properties on these boards about 6-7 months ago, where someone me=
ntioned this paper, but no one commented on it. Beside that, I have not bee=
n able to find any reference to discussion or a formal proposal on this top=
ic. Does anyone have anymore information about this?</div>
</div><div><div>
<p></p>
<br><br></div></div></blockquote><div><br></div></div><div>The paper seems =
to be from an era during which the committee didn't necessarily take/publis=
h technical discussion<br>minutes. At least I didn't find such technical mi=
nutes in the following mailing or the one in which that paper<br>
was published. I can ask the Evolution Working Group for whether anyone rec=
ollects what happened and why.<br></div></div><br></div></div>
</blockquote></div><br><br></div><div>Oh, do note that while that implicit-=
function paper has some similarities to properties, the problem it<br></div=
><div>presents has afaik been solved by variable templates in c++14.<br></d=
iv></div></blockquote><div><br></div><div>True that <i><b>part</b></i> of t=
he <i><b>first</b></i> problem has been solved with variable templates =3D)=
<span style=3D"font-size: 13px;">The paper still uses an ICF to calcu=
late and return the area of circle based on it's radius, which cannot be so=
lved with variable templates, so</span><span style=3D"font-size: 13px;">&nb=
sp;I still believe the feature deserves serious consideration.</span></div>=
<div><br></div><div><br></div><div>I can't say I agree with the paper's sol=
ution to the second problem though.</div><div><br></div><div>The paper prov=
ides a method of creating a setter by returning a filter class instead of t=
he actual value. While this does create the desired functionality of a sett=
er, and does so with out the memory overhead of a library based property im=
plementation, it still presents some of the same problems.</div><div><br></=
div><div>Firstly, the declaration of the filter class does decrease the rea=
dability of the class declaration. I imagine it would be quite painful to d=
eal with a class declaration containing 10+ of these filter classes.</div><=
div><br></div><div>Second, and probably most importantly, the return type o=
f the property will be hidden from the caller. Intellisense would report th=
e return type <span style=3D"font-size: 13px;">as the name of the filt=
er class, rather than the actual type, and any documentation would have to =
explicitly state the return type, and hope that the caller knows what's goi=
ng on with the filter class.<br><br></span></div><div>A solution could be t=
o name the filters things like float_AreaFilter, but it would be impossible=
to enforce this, and would be only a marginal improvement. Alternatively, =
the caller would be stuck having to go and look through the implementation =
of the filter to find out what it actually returns.</div><div><br></div><di=
v>Also, any hopes of compile time type deduction of the property would be l=
ost.</div><div><br></div><div>Finally, as I described above, for the librar=
y property implementation, any operator overloads or implicit conversions w=
ould have to be explicitly defined inside each filter class. Of course, a s=
olution would be to inherit a bunch of mixins with operator overloads, but =
this would only serve to decrease readability even more.</div><div><br></di=
v><div><br></div><div>So I think that the accessors as described in the pap=
er are a good start, but that the solution for mutators would be much impro=
ved by using overloadable, single parameter, implicitly callable functions.=
</div><div><br></div><div><br></div><div><span style=3D"font-size: 13px;"><=
br></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_124_13058511.1377809753540--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Thu, 29 Aug 2013 18:34:32 -0700 (PDT)
Raw View
------=_Part_331_10522066.1377826472621
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, 29 August 2013 13:50:09 UTC-4, Ville Voutilainen wrote:
>
>
>
>
> On 29 August 2013 20:21, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>
>>
>> I mean no disrespect here, but it's starting to seem a little like you
>> haven't even read half the posts in this thread.
>>
>
> I have read each and every post in this thread. We may draw different
> conclusions from those posts,
> and that's fine.
>
>
>>
>> *"What we have is vocal opinions from people who aren't trying to
>> explore the library possibilities"*
>>
>> I am really lost as to how you can claim that the idea of a library
>> implementation of properties hasn't been explored. A rather naive search on
>> Google will easily produce at least 3-4 attempted implementations within
>> the first couple of pages.
>>
>>
>>
> And those take into use the c++11 features at hand? Richard has a pretty
> good starting point for a library
> solution for properties. Has that been explored further, or has it just
> been dismissed off-hand?
>
I have stated the main problems with library implementations several times
in this thread, and if you can't already see how they apply to Richard's
implementation, or any library implementation, and why they can't be solved
with the current set of language features(even c++11/14), then I'm not sure
where to start explaining. If I were writing an actual proposal, I would
describe the issue in detail, but I don't see any reason to keep repeating
myself here.
Plus, I agree with Nicol Bolas. If anything in the realm of properties is
going to be standardized, it should be done right. There is no point
standardizing some expensive, messy, partially functional, hack you can
just find on google.
If anyone could provide any information on what became of N1611, It would
be greatly appreciated.
--
---
You received this message because you are 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_331_10522066.1377826472621
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Thursday, 29 August 2013 13:50:09 UTC-4, Ville =
Voutilainen 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"><br><div><br><br><div class=3D"gmail_quote">On 29 August 2013 20:21, =
Nick <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-ob=
fuscated-mailto=3D"cDTpkHSF-PMJ">nicolas.j...@gmail.com</a>></span> wrot=
e:<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"><br><div>I mean no disrespe=
ct here, but it's starting to seem a little like you haven't even read half=
the posts in this thread.</div>
</div></blockquote><div><br></div><div>I have read each and every post in t=
his thread. We may draw different conclusions from those posts,<br>and that=
's fine.<br> <br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div><div><br></div><div><i>"<span style=3D"font-size:13px=
">What we have is vocal opinions from people </span><span style=3D"fon=
t-size:13px">who aren't trying to explore the library possibilities"</span>=
</i></div>
<div><br></div></div><div>I am really lost as to how you can claim that the=
idea of a library implementation of properties hasn't been explored. A rat=
her naive search on Google will easily produce at least 3-4 attempted imple=
mentations within the first couple of pages.</div>
<div><br><br></div></div></blockquote><div><br></div><div>And those take in=
to use the c++11 features at hand? Richard has a pretty good starting point=
for a library<br>solution for properties. Has that been explored further, =
or has it just been dismissed off-hand? <br>
</div></div></div></div></blockquote><div><br></div><div>I have stated the =
main problems with library implementations several times in this thread, an=
d if you can't already see how they apply to Richard's implementation, or a=
ny library implementation, and why they can't be solved with the current se=
t of language features(even c++11/14), then I'm not sure where to start exp=
laining. If I were writing an actual proposal, I would describe the issue i=
n detail, but I don't see any reason to keep repeating myself here.</div><d=
iv><br></div><div><span style=3D"font-size: 13px;">Plus, I agree with Nicol=
Bolas. If anything in the realm of properties is going to be standardized,=
it should be done right. There is no point standardizing some expensive, m=
essy, partially functional, hack you can just find on google.</span><br></d=
iv><div><br></div><div>If anyone could provide any information on what beca=
me of N1611, It would be greatly appreciated.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_331_10522066.1377826472621--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Fri, 30 Aug 2013 02:35:49 -0700 (PDT)
Raw View
------=_Part_494_33053281.1377855350005
Content-Type: text/plain; charset=ISO-8859-1
On Thursday, August 29, 2013 10:03:38 AM UTC-7, Ville Voutilainen wrote:
>
> On 29 August 2013 19:26, Nick <nicolas.j...@gmail.com <javascript:>>wrote:
>
>> and in terms of anything happening at compile time, that pretty much
>> falls under the category of a library implementation, which IMO has been
>> thoroughly discussed already, and ruled out as far as standardization
>> goes.
>>
>
> I have seen zero evidence of any "ruling out". What we have is vocal
> opinions from people
> who aren't trying to explore the library possibilities, or any other
> possibilities for that matter,
> very hard.
>
We aren't trying to "explore the library possibilities" because it's a
waste of time. They fundamentally cannot work; not without significant
cruft and limiting the utility of the functionality. I have no idea what
"other possibilities" refers to. If you're talking about the reflection
stuff, save it; that's not an actual feature of any standard, nor is it a
proposed feature *for* any standard. It's the twinkle in some people's
eyes; it doesn't count as a "possibility" since a non-existent proposal
cannot be adequately evaluated.
The essential essence of properties, as a construct, is the effective
transformation of these expressions (given `Type variableName`):
auto data = variableName.field;
variableName.field = data2;
Into these:
auto data = variableName.SomeGetterFunction();
variableName.SomeSetterFunction(data2);
This is what the feature is; if a properties implementation cannot do this,
it is non-functional.
C++14, as a language, *cannot do this*. Not *correctly*. Not in all cases.
`variableName.field` is a variable name. It *must* be a variable name.
Therefore, any C++11/14-based library solution, *no matter how it is
implemented*, must ultimately put a member variable named `field` in
`Type`. It won't be the type that `SomeGetterFunction` returns, but it must
be *some type*.
Here is a short list of the holes that this creates in the abstraction:
* Since `field` is a non-static data member, it takes up space. Even if
it's just one `char` in size, it has already broken the layout of your
class. You therefore cannot use these properties on any class that has
strict layout needs. Let alone strict *memory* needs.
* Since `field` is a public non-static data member, it is not private.
Therefore, your class cannot be standard layout if you want private
variables too. Admittedly, this is not very important since you just broke
whatever layout compatibility you might have had by putting a member
variable there. But it's still there.
* Since `field` is a variable, it has a type. A type that is notably
separate from the return type of the hypothetical `SomeGetterFunction`. The
simple `auto data = variableName.field` completely breaks the abstraction
by deducing the field's actual type, rather than the hypothetical return
type.
There may be more, but this is enough. It doesn't matter *how* these are
implemented; the mere fact that it's a *variable* is the problem. These
failures of the abstraction *cannot be fixed*. Every library implementation
will have these failures.
Not being able to be used on standard layout types is a *complete
deal-breaker* as far as users are concerned. One of the most obvious uses
for properties is on simple vector and point classes:
class vec3
{
public:
float GetX() {return _x;}
float GetY() {return _y;}
float GetZ() {return _z;}
void SetX(float val) {_x = val;}
void SetY(float val) {_y = val;}
void SetZ(float val) {_z = val;}
private:
float _x, _y, _z;
};
Properties need to be able to work on this class. It needs to be able to
take those getters and setters and make it look like this to the user:
vec3 vec(...);
vec.x = 4;
auto data = vec.z;
Ignoring the question of whether such a class should even have accessors, *every
library solution* will change the layout of this class. Every library
solution will make the class no longer standard layout.
And that's not acceptable, because it is very important to the utility of
this class that it remain layout-compatible with various interfaces. If
it's not layout-compatible with a simple struct of 3 floats, then it simply
cannot do its job. That's a fundamental part of its interface.
*That* is what makes this a hack, a kludge. The abstraction has many points
of failure, and they're all very easy to hit. They confine the library
"solution" to a far more limited range of utility.
If the user of a feature, *especially* one that exists to make coding more
convenient, has to be constantly thinking about niggling issues like this,
or to avoid their use in common circumstances, then this is clearly not an
acceptable method of implementation. This is much like Boost.Lambda, where
you frequently have to do things like use `boost::ref` and such to create
reference wrappers for things.
And note that this analysis does not need to look at an implementation.
Every pure-library implementation will have these faults. There are more
that I could look at, but I hope I've made my point: there's nothing to be
gained by looking at "solutions" that *a priori* cannot succeed in any
meaningful way.
If someone wants to propose properties, such alternatives need to be
> explored
>
by a proposal paper, otherwise I see little reason to say anything but
> "thanks for sharing"
>
about such a proposal.
>
Why?
It's a simple question. Why?
No other proposals had to go through that. I don't recall Bjarne Stroustrup
having to explore Boost.ConceptCheck before talking about innumerable
versions of concepts. I don't recall the people proposaing static_if having
to explore various Macro methods and such before making their proposal. I
don't recall the r-value reference guys having to try to implement
Boost.Move before being able to get people to look seriously at in-language
move support. Are you saying that the the reflection group should have to
investigate all possible library solutions for compile-time reflection
before talking about their wanted language features?
Sure, they may have made reference to attempts to implement them. But none
of them dwelled on them at any real length. Why? Because they knew a priori
that there was no way to do the feature any justice without real,
language-level support.
And if they could do that, then why is *required* that properties
proponents explore alternative "solutions" in order for them to get a
reasonable hearing on the idea of a language feature? What is so special
about properties as a construct that it needs to have someone explore all
of the myriad of ways that it *cannot possibly work* as a library feature?
If you don't like properties as a feature *just say so*. If you don't want
properties as a langauge feature, *just say so*. You don't have to hide
behind "make it work as a library, then we'll see". Just say, "it's
pointless and I don't want to see it in C++;" it's that simple.
I think the reason you want this "exploration" of library implementations
is that you don't want properties. *Ever*. What you want is to find all of
the places where the kludge-implementation of properties fails. Then, like
adding spackling paste to a crumbling wall, you will add random features to
C++ so that the kludge won't fail there. And you'll keep adding "standard
spackle" until the kludge-implementation of properties gets to some "well
enough" point, by a completely and wholely arbitrary metric.
And then you'll use that as a justification for why we shouldn't have it as
a real language feature.
No other C++ feature was built this way. I didn't see uniform
initialization doing that. They didn't have to go through Boost.Assign and
build up a random list of features that would make Boost.Assign work more
cleanly. They came up with a completely separate syntax. They said that
they could do it better and more reasonably by ignoring the library kludge
and *doing it right*.
I didn't see lambdas proposal going through Boost.Lambda and Boost.Phoenix,
picking and choosing places where they could maybe add a few low-impact
language features that would improve various aspects of the implementation
and some such. No, they ignored the library kludge and *did it right*.
So why do you single *this* idea out?
--
---
You received this message because you are 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_494_33053281.1377855350005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 29, 2013 10:03:38 AM UTC-7, Ville Vout=
ilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
><div><div class=3D"gmail_quote">On 29 August 2013 19:26, Nick <span dir=3D=
"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"rqsSjCA_i3MJ">nicolas.j...@gmail.com</a>></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><font>and in terms of =
anything happening at compile time, that pretty much falls under the catego=
ry of a library implementation, which IMO has been </font>thoroughly<f=
ont> discussed already, and ruled out as far as standardization goes.<=
/font></div>
</div></blockquote><div><br></div><div>I have seen zero evidence of any "ru=
ling out". What we have is vocal opinions from people<br>who aren't trying =
to explore the library possibilities, or any other possibilities for that m=
atter,<br>
very hard.</div></div></div></div></blockquote><div><br>We aren't trying to=
"explore the library possibilities" because it's a waste of time. They fun=
damentally cannot work; not without significant cruft and limiting the util=
ity of the functionality. I have no idea what "other possibilities" refers =
to. If you're talking about the reflection stuff, save it; that's not an ac=
tual feature of any standard, nor is it a proposed feature <i>for</i> any s=
tandard. It's the twinkle in some people's eyes; it doesn't count as a "pos=
sibility" since a non-existent proposal cannot be adequately evaluated.<br>=
<br>The essential essence of properties, as a construct, is the effective t=
ransformation of these expressions (given `Type variableName`):<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: #008;" class=3D"styled-by-prettify">auto</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> data </span><span sty=
le=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> variableName</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify">field</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br>variableName</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify">field </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> data2</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span></div></code></div><br>Into these:<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;"><co=
de class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color=
: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> data </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> variableName</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">SomeGetterFunction</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">();</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"><br>variableName</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">.</span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">SomeSetterFunction</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">data2</span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"><br></span></div></code></div><br>This is what the feature is; if a prope=
rties implementation cannot do this, it is non-functional.<br><br>C++14, as=
a language, <b>cannot do this</b>. Not <i>correctly</i>. Not in all cases.=
<br><br>`variableName.field` is a variable name. It <i>must</i> be a variab=
le name. Therefore, any C++11/14-based library solution, <i>no matter how i=
t is implemented</i>, must ultimately put a member variable named `field` i=
n `Type`. It won't be the type that `SomeGetterFunction` returns, but it mu=
st be <i>some type</i>.<br><br>Here is a short list of the holes that this =
creates in the abstraction:<br><br>* Since `field` is a non-static data mem=
ber, it takes up space. Even if it's just one `char` in size, it has alread=
y broken the layout of your class. You therefore cannot use these propertie=
s on any class that has strict layout needs. Let alone strict <i>memory</i>=
needs.<br>* Since `field` is a public non-static data member, it is not pr=
ivate. Therefore, your class cannot be standard layout if you want private =
variables too. Admittedly, this is not very important since you just broke =
whatever layout compatibility you might have had by putting a member variab=
le there. But it's still there.<br>* Since `field` is a variable, it has a =
type. A type that is notably separate from the return type of the hypotheti=
cal `SomeGetterFunction`. The simple `auto data =3D variableName.field` com=
pletely breaks the abstraction by deducing the field's actual type, rather =
than the hypothetical return type.<br><br>There may be more, but this is en=
ough. It doesn't matter <i>how</i> these are implemented; the mere fact tha=
t it's a <i>variable</i> is the problem. These failures of the abstraction =
<i>cannot be fixed</i>. Every library implementation will have these failur=
es.<br><br>Not being able to be used on standard layout types is a <i>compl=
ete deal-breaker</i> as far as users are concerned. One of the most obvious=
uses for properties is on simple vector and point classes:<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">class</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> vec3<br></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: #0=
08;" class=3D"styled-by-prettify">public</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;" c=
lass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">GetX</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: #008;" class=3D"styled-by-prettify">return</span><spa=
n 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"colo=
r: #000;" class=3D"styled-by-prettify"><br> </span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">float</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">GetY</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"s=
tyled-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: #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"><br> <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">float</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #606;" class=3D"styled-by-prettify">GetZ</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;" cl=
ass=3D"styled-by-prettify">{</span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> _z</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br><br> </span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">void</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">SetX<=
/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"> val</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">_x </span><span style=3D"color: #660;" class=3D"styled-by-=
prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y"> val</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"styled-by-prettify">void=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">SetY</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">float</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> val</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-b=
y-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettif=
y">_y </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"> val</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"><br> </span><=
span style=3D"color: #008;" class=3D"styled-by-prettify">void</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">SetZ</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">float</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> val</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">)</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
{</span><span style=3D"color: #000;" class=3D"styled-by-prettify">_z </span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> val</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;}</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">private</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"><br> </span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">float</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 style=3D"color: #000;" class=3D"styled-by-prett=
ify"> _y</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,<=
/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 styl=
e=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">};</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br></span></div></code></div><br>Propert=
ies need to be able to work on this class. It needs to be able to take thos=
e getters and setters and make it look like this to the user:<br><br><div c=
lass=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); border-=
color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-wra=
p: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><=
span style=3D"color: #000;" class=3D"styled-by-prettify">vec3 vec</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br>vec</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">4</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> data </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"> vec</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify">z</span><span style=3D"color: #660;" clas=
s=3D"styled-by-prettify">;</span></div></code></div><br>Ignoring the questi=
on of whether such a class should even have accessors, <i>every library sol=
ution</i> will change the layout of this class. Every library solution will=
make the class no longer standard layout.<br><br>And that's not acceptable=
, because it is very important to the utility of this class that it remain =
layout-compatible with various interfaces. If it's not layout-compatible wi=
th a simple struct of 3 floats, then it simply cannot do its job. That's a =
fundamental part of its interface.<br><br><i>That</i> is what makes this a =
hack, a kludge. The abstraction has many points of failure, and they're all=
very easy to hit. They confine the library "solution" to a far more limite=
d range of utility.<br><br>If the user of a feature, <i>especially</i> one =
that exists to make coding more convenient, has to be constantly thinking a=
bout niggling issues like this, or to avoid their use in common circumstanc=
es, then this is clearly not an acceptable method of implementation. This i=
s much like Boost.Lambda, where you frequently have to do things like use `=
boost::ref` and such to create reference wrappers for things.<br><br>And no=
te that this analysis does not need to look at an implementation. Every pur=
e-library implementation will have these faults. There are more that I coul=
d look at, but I hope I've made my point: there's nothing to be gained by l=
ooking at "solutions" that <b>a priori</b> cannot succeed in any meaningful=
way.<br><br><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1=
px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">If s=
omeone wants to propose properties, such alternatives need to be explored<b=
r></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left:=
1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">by=
a proposal paper, otherwise I see little reason to say anything but "thank=
s for sharing"<br></blockquote></div><blockquote class=3D"gmail_quote" styl=
e=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"><div>about such a p=
roposal.</div></div></div></div></blockquote><div><br>Why?<br><br>It's a si=
mple question. Why?<br><br>No other proposals had to go through that. I don=
't recall Bjarne Stroustrup having to explore Boost.ConceptCheck before tal=
king about innumerable versions of concepts. I don't recall the people prop=
osaing static_if having to explore various Macro methods and such before ma=
king their proposal. I don't recall the r-value reference guys having to tr=
y to implement Boost.Move before being able to get people to look seriously=
at in-language move support. Are you saying that the the reflection group =
should have to investigate all possible library solutions for compile-time =
reflection before talking about their wanted language features?<br><br>Sure=
, they may have made reference to attempts to implement them. But none of t=
hem dwelled on them at any real length. Why? Because they knew a priori tha=
t there was no way to do the feature any justice without real, language-lev=
el support.<br><br>And if they could do that, then why is <i>required</i> t=
hat properties proponents explore alternative "solutions" in order for them=
to get a reasonable hearing on the idea of a language feature? What is so =
special about properties as a construct that it needs to have someone explo=
re all of the myriad of ways that it <i>cannot possibly work</i> as a libra=
ry feature?<br><br>If you don't like properties as a feature <i>just say so=
</i>. If you don't want properties as a langauge feature, <i>just say so</i=
>. You don't have to hide behind "make it work as a library, then we'll see=
". Just say, "it's pointless and I don't want to see it in C++;" it's that =
simple.<br><br>I think the reason you want this "exploration" of library im=
plementations is
that you don't want properties. <i>Ever</i>. What you want is to find all o=
f the places where the kludge-implementation of properties fails. Then, lik=
e adding spackling paste to a crumbling wall, you will add random features =
to C++ so that the kludge won't fail there. And you'll keep adding "standar=
d spackle" until the kludge-implementation of properties gets to some "well=
enough" point, by a completely and wholely arbitrary metric.<br><br>And th=
en you'll use that as a justification for why we shouldn't have it as a rea=
l language feature.<br><br>No other C++ feature was built this way. I didn'=
t see uniform initialization doing that. They didn't have to go through Boo=
st.Assign and build up a random list of features that would make Boost.Assi=
gn work more cleanly. They came up with a completely separate syntax. They =
said that they could do it better and more reasonably by ignoring the libra=
ry kludge and <i>doing it right</i>.<br><br>I didn't see lambdas proposal g=
oing through Boost.Lambda and Boost.Phoenix, picking and choosing places wh=
ere they could maybe add a few low-impact language features that would impr=
ove various aspects of the implementation and some such. No, they ignored t=
he library kludge and <i>did it right</i>.<br><br>So why do you single <i>t=
his</i> idea out?<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_494_33053281.1377855350005--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Fri, 30 Aug 2013 13:08:17 +0300
Raw View
--047d7b6d7adacdcfda04e5276628
Content-Type: text/plain; charset=ISO-8859-1
On 30 August 2013 12:35, Nicol Bolas <jmckesson@gmail.com> wrote:
>
> * Since `field` is a non-static data member, it takes up space. Even if
> it's just one `char` in size, it has already broken the layout of your
> class. You therefore cannot use these properties on any class that has
> strict layout needs. Let alone strict *memory* needs.
>
Thanks, that's a good reason.
If someone wants to propose properties, such alternatives need to be
> explored
>
by a proposal paper, otherwise I see little reason to say anything but
> "thanks for sharing"
>
about such a proposal.
>>
>
> Why?
>
> It's a simple question. Why?
>
Because the proposal says "this is how properties must be, and alternatives
don't work". It has to explain why
the alternatives don't work.
>
> No other proposals had to go through that. I don't recall Bjarne
> Stroustrup having to explore Boost.ConceptCheck before talking
>
Every one of them did. You're mistaking the level to which they went
through that.
> about innumerable versions of concepts. I don't recall the people
> proposaing static_if having to explore various Macro methods and such
> before making their proposal. I don't recall the r-value reference guys
> having to try to implement Boost.Move before
>
The static if proposal did sufficient exploration, and explains the
motivation of static if as opposed to using #define
to do the same things. The "exploration" has never been suggested as a
requirement to implement a library solution
as a prerequisite for proposing a language feature, although it wouldn't
hurt.
> being able to get people to look seriously at in-language move support.
> Are you saying that the the reflection group should have to investigate all
> possible library solutions for compile-time reflection before talking about
> their wanted language features?
>
Before talking? No. I expect they should most certainly investigate the
library solutions before proposing language
changes.
> And if they could do that, then why is *required* that properties
> proponents explore alternative "solutions" in order for them to get a
> reasonable hearing on the idea of a language feature? What is so special
> about properties as a construct that it needs to have someone explore all
> of the myriad of ways that it *cannot possibly work* as a library feature?
>
There's nothing special about properties. The bar for them is the same as
for other proposals. I don't think I have
requested anything that other proposals didn't do.
>
> I think the reason you want this "exploration" of library implementations
> is that you don't want properties. *Ever*. What you want is to
>
I think the reason I want it is because I want the people who write a
proposal for properties to provide evidence
for their assertions, and write up the reasons why they are proposing
language changes instead of library
additions.
>
> No other C++ feature was built this way. I didn't see uniform
> initialization doing that. They didn't have to go through Boost.Assign and
> build up a random list of features that would make Boost.Assign work more
> cleanly. They came up with a completely separate syntax. They said that
> they could do it better and more reasonably by ignoring the library kludge
> and *doing it right*.
>
They certainly didn't ignore the "library kludge". They considered how far
a library solution can go and made an educated
decision. Furthermore, they wrote a proposal that explains the results of
that consideration.
>
> I didn't see lambdas proposal going through Boost.Lambda and
> Boost.Phoenix, picking and choosing places where they could maybe add a few
> low-impact language features that would improve various aspects of the
> implementation and some such. No, they ignored the library kludge and *did
> it right*.
>
>
That's just utter rubbish. The lambda proposal authors are the very same
people who have written
boost lambda. They most certainly did go through boost lambda in the way
you describe, and, again,
presented a proposal based on that analysis, after finding out that
language changes are necessary.
--
---
You received this message because you are 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/.
--047d7b6d7adacdcfda04e5276628
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 30 August 2013 12:35, Nicol Bolas <span dir=3D"ltr"><<a href=
=3D"mailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&g=
t;</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"><br><div>* Since `field` is=
a non-static data member, it takes up space. Even if it's just one `ch=
ar` in size, it has already broken the layout of your class. You therefore =
cannot use these properties on any class that has strict layout needs. Let =
alone strict <i>memory</i> needs.<br>
</div></div></blockquote><div><br></div><div>Thanks, that's a good reas=
on.<br><br><div class=3D"im"><br><blockquote style=3D"margin:0px 0px 0px 0.=
8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail=
_quote">
If someone wants to propose properties, such alternatives need to be explor=
ed<br></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-lef=
t:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote">by a p=
roposal paper, otherwise I see little reason to say anything but "than=
ks for sharing"<br>
</blockquote></div></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><b=
lockquote 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"><div>about such a proposal=
..</div></div></div></div></blockquote><div><br>Why?<br><br>It's a simpl=
e question. Why?<br></div></div></blockquote><div><br></div><div>Because th=
e proposal says "this is how properties must be, and alternatives don&=
#39;t work". It has to explain why<br>
the alternatives don't work.<br>=A0<br></div><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><br>No other proposals had to go through that. I=
don't recall Bjarne Stroustrup having to explore Boost.ConceptCheck be=
fore talking </div>
</div></blockquote><div><br></div><div>Every one of them did. You're mi=
staking the level to which they went through that.<br>=A0<br></div><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>about innumerable versions of concepts. I don't r=
ecall the people proposaing static_if having to explore various Macro metho=
ds and such before making their proposal. I don't recall the r-value re=
ference guys having to try to implement Boost.Move before </div>
</div></blockquote><div><br></div><div>The static if proposal did sufficien=
t exploration, and explains the motivation of static if as opposed to using=
#define<br></div><div>to do the same things. The "exploration" h=
as never been suggested as a requirement to implement a library solution<br=
>
</div><div>as a prerequisite for proposing a language feature, although it =
wouldn't hurt.<br></div><div>=A0<br></div><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>being able to get people to look seriously at in-lang=
uage move support. Are you saying that the the reflection group should have=
to investigate all possible library solutions for compile-time reflection =
before talking about their wanted language features?<br>
</div></div></blockquote><div><br></div><div>Before talking? No. I expect t=
hey should most certainly investigate the library solutions before proposin=
g language<br>changes.<br>=A0<br></div><div>=A0</div><blockquote class=3D"g=
mail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-l=
eft:1ex">
<div dir=3D"ltr"><div>And if they could do that, then why is <i>required</i=
> that properties proponents explore alternative "solutions" in o=
rder for them to get a reasonable hearing on the idea of a language feature=
? What is so special about properties as a construct that it needs to have =
someone explore all of the myriad of ways that it <i>cannot possibly work</=
i> as a library feature?<br>
</div></div></blockquote><div><br></div><div>There's nothing special ab=
out properties. The bar for them is the same as for other proposals. I don&=
#39;t think I have<br></div><div>requested anything that other proposals di=
dn't do. <br>
=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"></blockquote><div>=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div>I think the reason you want this "exploration&qu=
ot; of library implementations is
that you don't want properties. <i>Ever</i>. What you want is to </div>=
</div></blockquote><div><br></div><div>I think the reason I want it is beca=
use I want the people who write a proposal for properties to provide eviden=
ce<br>
for their assertions, and write up the reasons why they are proposing langu=
age changes instead of library<br>additions.<br><br>=A0<br></div><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"><div><br>No other C++ feature was built this way. I didn&#=
39;t see uniform initialization doing that. They didn't have to go thro=
ugh Boost.Assign and build up a random list of features that would make Boo=
st.Assign work more cleanly. They came up with a completely separate syntax=
.. They said that they could do it better and more reasonably by ignoring th=
e library kludge and <i>doing it right</i>.<br>
</div></div></blockquote><div><br></div><div>They certainly didn't igno=
re the "library kludge". They considered how far a library soluti=
on can go and made an educated<br>decision. Furthermore, they wrote a propo=
sal that explains the results of that consideration.<br>
=A0<br></div><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><br>I did=
n't see lambdas proposal going through Boost.Lambda and Boost.Phoenix, =
picking and choosing places where they could maybe add a few low-impact lan=
guage features that would improve various aspects of the implementation and=
some such. No, they ignored the library kludge and <i>did it right</i>.<br=
>
<br></div></div></blockquote><div><br></div><div>That's just utter rubb=
ish. The lambda proposal authors are the very same people who have written<=
br>boost lambda. They most certainly did go through boost lambda in the way=
you describe, and, again,<br>
</div><div>presented a proposal based on that analysis, after finding out t=
hat language changes are necessary. <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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b6d7adacdcfda04e5276628--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Fri, 30 Aug 2013 13:34:28 +0200
Raw View
On Thu, Aug 29, 2013 at 2:06 AM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
>
> On Thu, Aug 29, 2013 at 1:49 AM, Nick <nicolas.jinchereau@gmail.com> wrot=
e:
>>
>> could you clarify what you mean by non-auto property?
>
>
> I believe Loic means that if I have a initial version of some code that l=
ook
> like this:
>
> struct K
> {
> int count;
> };
>
> int f( K& k )
> {
> return k.count;
> }
>
> Then (years) later I upgrade it with some checks using some property synt=
ax,
> but want to keep the retrocompatibility:
In my opinion this is quite stupid. Putting in some checks is a
breaking change and you want all code affected to continue compiling
silently? Or, in other words, what kind of checks can you put in that
are not a breaking change from what is effectively just a normal data
member?
Mit freundlichen Gr=FC=DFen,
Martinho
--=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/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Aug 2013 16:33:04 +0200
Raw View
--047d7b471e6ab2a9bd04e52b19eb
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 30, 2013 at 1:34 PM, Martinho Fernandes <
martinho.fernandes@gmail.com> wrote:
> In my opinion this is quite stupid. Putting in some checks is a
> breaking change and you want all code affected to continue compiling
> silently? Or, in other words, what kind of checks can you put in that
> are not a breaking change from what is effectively just a normal data
> member?
>
First, that's a very simplistic example to show the evolution.
Second, no, that's not stupid (please stay polite), it's the kind of change
you do each time you modify the implementation of a function without
changing it's interface.
There is no difference: if you do a breaking change in your implementation,
yes it will break the whole, but at least it's isolated in a specific scope.
It's totally different than changing an interface (why do I even have to
explain this?) which will force the user to change a lot of code, and each
change is an opportunity
to add new bugs, without the initial change being the source of the bugs.
One simple real-world example:
let's say there is an internal mutable mutex and the count have to lock it
in the new version of the code to add thread safety (in a poor but correct
way).
From:
struct K
{
int count;
};
To:
struct K
{
// ... additional thread-safe manipulation functions
int count() const { std::lock_guard<std::mutex> _(m_mutex); return
m_count; }
private:
mutable std::mutex m_mutex;
int m_count;
};
That's the kind of change that happen regularly in big code bases, in
particular when thread-safety becomes important.
Here, either there is some kind of property feature that makes this code
not impact the usable code, even if the type
itself becomes more complex, or you have to go to all the user code and
modify it.
It DOES have an impact that might break the application, like ANY change to
any implementation of an interface.
But here the problem pointed is the interface, the implementation is not
the problem that properties is trying to solve.
Joel Lamotte
--
---
You received this message because you are 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/.
--047d7b471e6ab2a9bd04e52b19eb
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Aug 30, 2013 at 1:34 PM, Martinho Fernandes <span dir=3D"ltr"><<=
a href=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">martinho.f=
ernandes@gmail.com</a>></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 id=3D":2bq" style=3D"overflow:hidden">In my opinion t=
his is quite stupid. Putting in some checks is a<br>
breaking change and you want all code affected to continue compiling<br>
silently? Or, in other words, what kind of checks can you put in that<br>
are not a breaking change from what is effectively just a normal data<br>
member?</div></blockquote></div><br>First, that's a very simplistic exa=
mple to show the evolution.</div><div class=3D"gmail_extra"><br>Second, no,=
that's not stupid (please stay polite), it's the kind of change yo=
u do each time you modify the implementation of a function without changing=
it's interface.<br>
There is no difference: if you do a breaking change in your implementation,=
yes it will break the whole, but at least it's isolated in a specific =
scope.<br>It's totally different than changing an interface (why do I e=
ven have to explain this?) which will force the user to change a lot of cod=
e, and each change is an opportunity<br>
to add new bugs, without the initial change being the source of the bugs.<b=
r><br>One simple real-world example: <br>let's say there is an internal=
mutable mutex and the count have to lock it in the new version of the code=
to add thread safety (in a poor but correct way).<br>
<br>From:</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_ext=
ra">struct K<br>{<br>=A0 =A0 int count;<br>};<br><br>To:<br><br>struct K<br=
>{<br>=A0 =A0 // ... additional thread-safe manipulation functions<br>=A0<b=
r>=A0 =A0 int count() const { std::lock_guard<std::mutex> _(m_mutex);=
return m_count; }<br>
<br>private:<br>=A0 =A0 mutable std::mutex m_mutex;<br>=A0 =A0 int m_count;=
<br>};<br><br>That's the kind of change that happen regularly in big co=
de bases, in particular when thread-safety becomes important.<br>Here, eith=
er there is some kind of property feature that makes this code not impact t=
he usable code, even if the type<br>
itself becomes more complex, or you have to go to all the user code and mod=
ify it.<br>It DOES have an impact that might break the application, like AN=
Y change to any implementation of an interface.<br>But here the problem poi=
nted is the interface, the implementation is not the problem that propertie=
s is trying to solve.<br>
<br>Joel Lamotte</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--047d7b471e6ab2a9bd04e52b19eb--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Fri, 30 Aug 2013 17:50:21 +0200
Raw View
I think I was misunderstood :( And maybe I misunderstood you as well.
On Fri, Aug 30, 2013 at 4:33 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
> Second, no, that's not stupid (please stay polite),
Let me get this out of the way first. Even though people tell me I
have a high level of fluency in English, it isn't my native language
so I apologise if I inadvertently crossed a line somewhere.
When I think an idea is stupid, I say that the idea is stupid to mean
that the idea is stupid. Is that impolite? What should I say to
express that a certain idea is stupid while keeping it polite enough
for this context? I understand that saying someone is stupid is not
polite but, at least in my native language/culture, saying the same
about abstract entities is fine.
On Fri, Aug 30, 2013 at 4:33 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
> it's the kind of change
> you do each time you modify the implementation of a function without
> changing it's interface.
> There is no difference: if you do a breaking change in your implementatio=
n,
> yes it will break the whole, but at least it's isolated in a specific sco=
pe.
> It's totally different than changing an interface (why do I even have to
> explain this?) which will force the user to change a lot of code, and eac=
h
> change is an opportunity
> to add new bugs, without the initial change being the source of the bugs.
Ok, even though, as you said, the example provided is a poor one, it
was enough for me to conjecture some hypothetical better ones.
However, I disagree with "there is no difference". There are changes
that don't change the manifest interface (i.e. the interface you
expose for the compiler, the function signature) but that do change
the actual interface. An example of that would be adding a check for
negative or otherwise out-of-range numbers in an integral property and
behaving differently for those (be it setting it to zero, or throwing,
or whatever). The actual interface becomes more than the signature,
because C++ does not have the capabilities to express richer
interfaces easily.
If you look at it in standards terms, the interface of a function is
not only the signature but also its Requires clause (and all the other
stuff but Requires is enough for this discussion). The signature for
`std::sort` says it takes two iterators and a comparison (well, not
even that, but let's pretend it does), but that's not all. It takes
two iterators *that define a valid range* and a comparison *that
defines a strict weak ordering*. If, for example, you change "that
defines a strict weak ordering" to "that defines a total preorder" by
changing only the implementation, you will break your clients, even
though the manifest interface didn't change. Your clients will likely
still compile with such a change, but they will no wonder work
correctly.
Basically, I prefer when a change to the actual interface reflects
itself on the manifest interface, so that the compiler can help me
out. I am aware that this isn't so feasible, but that doesn't mean we
should add more ways to give up on that ability (I don't want to claim
it means we should not add them, though).
The use of the word "check" led me to think of changes similar to the
example I gave of checking for out-of-range values (locking a mutex is
not a check, is it?). Changing normal data to properties with
additional "checks" in it is not something one wants to encourage.
Thanks for clarifying what you meant and I hope you will be more
precise about what kind of changes you want to enable with this
feature in the future, especially because I see a lot of programmers
thinking of this ability to add precondition checks silently as a
benefit of property syntax (that was all over the place when I was
using C#).
Mit freundlichen Gr=FC=DFen,
Martinho
--=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/.
.
Author: Nevin Liber <nevin@eviloverlord.com>
Date: Fri, 30 Aug 2013 11:05:07 -0500
Raw View
--001a11c2cfbe502ad504e52c6500
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On 30 August 2013 09:33, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com> wrote:
>
>
> One simple real-world example:
> let's say there is an internal mutable mutex and the count have to lock i=
t
> in the new version of the code to add thread safety (in a poor but correc=
t
> way).
>
> From:
>
> struct K
> {
> int count;
> };
>
> To:
>
> struct K
> {
> // ... additional thread-safe manipulation functions
>
> int count() const { std::lock_guard<std::mutex> _(m_mutex); return
> m_count; }
>
> private:
> mutable std::mutex m_mutex;
> int m_count;
> };
>
> That's the kind of change that happen regularly in big code bases, in
> particular when thread-safety becomes important.
>
I find this uncompelling, because such transformations can easily break
correctness. If someone expects the call to count() to return the same
value in two successive calls (which might not even be in the same
function), this transformation breaks them.
In practical terms, I've found it incredibly rare to make these kind of
wholesale changes to implementations (those that change preconditions or
postconditions) without having to revisit the entire program.
What problem is trying to be solved with properties? Is it just the
syntactical notation of not having to use parentheses?
--=20
Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
--=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/.
--001a11c2cfbe502ad504e52c6500
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On 30 August 2013 09:33, Klaim - Jo=EBl Lamotte <span dir=
=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim=
@gmail.com</a>></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:1p=
x #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra">=
<div class=3D"gmail_extra"><br><br>One simple real-world example: <br>let&#=
39;s say there is an internal mutable mutex and the count have to lock it i=
n the new version of the code to add thread safety (in a poor but correct w=
ay).<br>
<br>From:</div></div><div class=3D"gmail_extra"><br></div><div class=3D"gma=
il_extra">struct K<br>{<br>=A0 =A0 int count;<br>};<br><br>To:<br><br>struc=
t K<br>{<br>=A0 =A0 // ... additional thread-safe manipulation functions<br=
>=A0<br>=A0 =A0 int count() const { std::lock_guard<std::mutex> _(m_m=
utex); return m_count; }<br>
<br>private:<br>=A0 =A0 mutable std::mutex m_mutex;<br>=A0 =A0 int m_count;=
<br>};<br><br>That's the kind of change that happen regularly in big co=
de bases, in particular when thread-safety becomes important.<br></div></di=
v></blockquote>
<div><br></div><div>I find this uncompelling, because such transformations =
can easily break correctness.=A0 If someone expects the call to count() to =
return the same value in two successive calls (which might not even be in t=
he same function), this transformation breaks them.<br>
<br></div><div>In practical terms, I've found it incredibly rare to mak=
e these kind of wholesale changes to implementations (those that change pre=
conditions or postconditions) without having to revisit the entire program.=
<br>
<br><br></div><div>What problem is trying to be solved with properties?=A0 =
Is it just the syntactical notation of not having to use parentheses?<br></=
div></div>-- <br>=A0Nevin ":-)" Liber=A0 <mailto:<a href=3D"ma=
ilto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com</a>&g=
t;=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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--001a11c2cfbe502ad504e52c6500--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Aug 2013 18:06:30 +0200
Raw View
--089e01493832e3f5a604e52c673f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 30, 2013 at 5:50 PM, Martinho Fernandes <
martinho.fernandes@gmail.com> wrote:
> On Fri, Aug 30, 2013 at 4:33 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.co=
m>
> wrote:
> > Second, no, that's not stupid (please stay polite),
>
> Let me get this out of the way first. Even though people tell me I
> have a high level of fluency in English, it isn't my native language
> so I apologise if I inadvertently crossed a line somewhere.
>
>
Not much, and I'm not a native english speaker either, but the "stupid"
word is both hiding what you mean
and not respectful.
> When I think an idea is stupid, I say that the idea is stupid to mean
> that the idea is stupid. Is that impolite? What should I say to
> express that a certain idea is stupid while keeping it polite enough
> for this context? I understand that saying someone is stupid is not
> polite but, at least in my native language/culture, saying the same
> about abstract entities is fine.
>
>
Saying something is stupid is not polite either.
Just state exactly what you find hard to accept and why, so that we can
argue about it politely.
I must precise: I'm not offended, don't worry.
> However, I disagree with "there is no difference". There are changes
> that don't change the manifest interface (i.e. the interface you
> expose for the compiler, the function signature) but that do change
> the actual interface. An example of that would be adding a check for
> negative or otherwise out-of-range numbers in an integral property and
> behaving differently for those (be it setting it to zero, or throwing,
> or whatever). The actual interface becomes more than the signature,
> because C++ does not have the capabilities to express richer
> interfaces easily.
>
> If you look at it in standards terms, the interface of a function is
> not only the signature but also its Requires clause (and all the other
> stuff but Requires is enough for this discussion).
Indeed.
Yes changing the implementation the way I suggest change the requirements,
but it don't change the interface itself.
I don't know if we can consider the requirements parts of the whole
interface,
I think that in C++, until we have a standard way to check these
requirements
other than by using strong typing, it's hard to consider an interface and
it's
requirements as the same thing.
> Basically, I prefer when a change to the actual interface reflects
> itself on the manifest interface, so that the compiler can help me
> out. I am aware that this isn't so feasible, but that doesn't mean we
> should add more ways to give up on that ability (I don't want to claim
> it means we should not add them, though).
>
>
As I was saying, I don't see how changing a requirement of a library
interface can be
reflected on the compilation of user code.
The only way is to have something like contracts and assertions, but
it's a totally different proposition (which someone is working on by the
way).
> The use of the word "check" led me to think of changes similar to the
> example I gave of checking for out-of-range values (locking a mutex is
> not a check, is it?).
The mutex example is not a check indeed.
The initial statement is similar to what you expected, so yes I was talking
for example
checking if the returned value make sense or if the call itself is valid.
I could find another simple such example, like returning a normalized
direction from such a property
but you get the idea.
> Changing normal data to properties with
> additional "checks" in it is not something one wants to encourage.
> Thanks for clarifying what you meant and I hope you will be more
> precise about what kind of changes you want to enable with this
> feature in the future, especially because I see a lot of programmers
> thinking of this ability to add precondition checks silently as a
> benefit of property syntax (that was all over the place when I was
> using C#).
>
>
I meant any change that don't break the interface.
Unfortunately, as stated already, there is no way to, at compile time,
to enforce requirements at compile time or runtime other than what
can be checked through strong typing, assertions and soon concepts.
What you suggests, if I understood correctly, is that the point of having
properties
so that evolution of an interface is easy don't makes a lot of sense if
there is no way
to enforce the requirements of the interface.
Tell me if I misunderstood.
If I'm correct, then I both agree and disagree: in a perfect world you
would be right.
In the current C++ version, we change implementations all the time without
changing interfaces,
sometime with changing the requirements too. I agree that a way to enforce
requirements would
make both properties and all function interfaces better.
Joel Lamotte
--=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/.
--089e01493832e3f5a604e52c673f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Aug 30, 2013 at 5:50 PM, Martinho Fernandes <span dir=3D"lt=
r"><<a href=3D"mailto:martinho.fernandes@gmail.com" target=3D"_blank">ma=
rtinho.fernandes@gmail.com</a>></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 class=3D"im">On Fri, Aug 30, 2013 at 4:33 PM, Klaim -=
Jo=EBl Lamotte <<a href=3D"mailto:mjklaim@gmail.com">mjklaim@gmail.com<=
/a>> wrote:<br>
> Second, no, that's not stupid (please stay polite),<br>
<br>
</div>Let me get this out of the way first. Even though people tell me I<br=
>
have a high level of fluency in English, it isn't my native language<br=
>
so I apologise if I inadvertently crossed a line somewhere.<br>
<br></blockquote><div><br>Not much, and I'm not a native english speake=
r either, but the "stupid" word is both hiding what you mean=A0<b=
r>and not respectful.<br>=A0</div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(20=
4,204,204);border-left-style:solid;padding-left:1ex">
When I think an idea is stupid, I say that the idea is stupid to mean<br>
that the idea is stupid. Is that impolite? What should I say to<br>
express that a certain idea is stupid while keeping it polite enough<br>
for this context? I understand that saying someone is stupid is not<br>
polite but, at least in my native language/culture, saying the same<br>
about abstract entities is fine.<br>
<div class=3D"im"><br></div></blockquote><div><br><br>Saying something is s=
tupid is not polite either.<br>Just state exactly what you find hard to acc=
ept and why, so that we can argue about it politely.<br><br>I must precise:=
I'm not offended, don't worry.<br>
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex">
However, I disagree with "there is no difference". There are chan=
ges<br>
that don't change the manifest interface (i.e. the interface you<br>
expose for the compiler, the function signature) but that do change<br>
the actual interface. An example of that would be adding a check for<br>
negative or otherwise out-of-range numbers in an integral property and<br>
behaving differently for those (be it setting it to zero, or throwing,<br>
or whatever). The actual interface becomes more than the signature,<br>
because C++ does not have the capabilities to express richer<br>
interfaces easily.<br>
<br></blockquote><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">If you look at it in standards terms, the=
interface of a function is<br>
not only the signature but also its Requires clause (and all the other<br>
stuff but Requires is enough for this discussion). </blockquote><div><br></=
div><div>Indeed.</div><div><br></div><div><div>Yes changing the implementat=
ion the way I suggest change the requirements,<br>but it don't change t=
he interface itself.<br>
I don't know if we can consider the requirements parts of the whole int=
erface,<br>I think that in C++, until we have a standard way to check these=
requirements<br>other than by using strong typing, it's hard to consid=
er an interface and it's<br>
requirements as the same thing.</div></div><div>=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Basically, I prefer when a change to the actual interface reflects<br>
itself on the manifest interface, so that the compiler can help me<br>
out. I am aware that this isn't so feasible, but that doesn't mean =
we<br>
should add more ways to give up on that ability (I don't want to claim<=
br>
it means we should not add them, though).<br>
<br></blockquote><div><br></div><div>As I was saying, I don't see how c=
hanging a requirement of a library interface can be<br>reflected on the com=
pilation of user code.<br>The only way is to have something like contracts =
and assertions, but=A0<br>
it's a totally different proposition (which someone is working on by th=
e way).<br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204=
,204);border-left-style:solid;padding-left:1ex">
The use of the word "check" led me to think of changes similar to=
the<br>
example I gave of checking for out-of-range values (locking a mutex is<br>
not a check, is it?). </blockquote><div><br></div><div>The mutex example is=
not a check indeed.<br>The initial statement is similar to what you expect=
ed, so yes I was talking for example<br>checking if the returned value make=
sense or if the call itself is valid.<br>
I could find another simple such example, like returning a normalized direc=
tion from such a property<br>but you get the idea.<br></div><div>=A0</div><=
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">
Changing normal data to properties with<br>
additional "checks" in it is not something one wants to encourage=
..<br>
Thanks for clarifying what you meant and I hope you will be more<br>
precise about what kind of changes you want to enable with this<br>
feature in the future, especially because I see a lot of programmers<br>
thinking of this ability to add precondition checks silently as a<br>
benefit of property syntax (that was all over the place when I was<br>
using C#).<br>
<div class=3D""><div class=3D"h5"><br></div></div></blockquote><div><br></d=
iv><div>I meant any change that don't break the interface.<br>Unfortuna=
tely, as stated already, there is no way to, at compile time,<br>to enforce=
requirements at compile time or runtime other than what=A0<br>
can be checked through strong typing, assertions and soon concepts.<br><br>=
What you suggests, if I understood correctly, is that the point of having p=
roperties<br>so that evolution of an interface is easy don't makes a lo=
t of sense if there is no way<br>
to enforce the requirements of the interface.<br>Tell me if I misunderstood=
..<br><br>If I'm correct, then I both agree and disagree: in a perfect w=
orld you would be right.<br>In the current C++ version, we change implement=
ations all the time without changing interfaces, <br>
sometime with changing the requirements too. I agree that a way to enforce =
requirements would=A0<br>make both properties and all function interfaces b=
etter.<br><br>Joel Lamotte</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e01493832e3f5a604e52c673f--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Aug 2013 09:06:56 -0700
Raw View
On sexta-feira, 30 de agosto de 2013 02:35:49, Nicol Bolas wrote:
> What you want is to find all of the places where the kludge-implementation
> of properties fails. Then, like adding spackling paste to a crumbling wall,
> you will add random features to C++ so that the kludge won't fail there.
> And you'll keep adding "standard spackle" until the kludge-implementation
> of properties gets to some "well enough" point, by a completely and wholely
> arbitrary metric.
And what's the harm in that? No, really, let's think this through.
If a solution can be achieved with just minor language changes supported by a
larger library change, should we not consider it against a major language
change? There are benefits to doing it with a minor language change, most
notably the fact that compilers will implement them more quickly and that
there's a smaller chance of incompatibilities. There may be cons too, like a
more clumsy syntax.
Also, "arbitrary metric" is exactly what you proposed on this email. You
listed a few requirements that any solution must meet. If a minor language
change + library change solution meets those requirements, why should it not
be considered?
Note that I'm not at all passing judgement on the properties language or
properties library proposals.
--
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/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Aug 2013 18:12:33 +0200
Raw View
--089e012953ba840c3904e52c7d09
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 30, 2013 at 6:05 PM, Nevin Liber <nevin@eviloverlord.com> wrote:
> I find this uncompelling, because such transformations can easily break
> correctness. If someone expects the call to count() to return the same
> value in two successive calls (which might not even be in the same
> function), this transformation breaks them.
>
>
I believe you are making the same point than Martinho Fernandes so I should
have answered in my last email.
> In practical terms, I've found it incredibly rare to make these kind of
> wholesale changes to implementations (those that change preconditions or
> postconditions) without having to revisit the entire program.
>
>
It depends on the requirements but I also find rare a change of
requirements by changing implementation of a function.
However, I don't always have checks that make sure I didn't change these
requirements.
To me all these points are about the requirements part of any kind of
function (properties included) which indeed are hard to prove not being
changed by a change of the implementation.
But again, fixing that requires another set of language feature and is not
directly related to properties, in my opinion.
>
> What problem is trying to be solved with properties? Is it just the
> syntactical notation of not having to use parentheses?
>
More or less. I belive the point of properties to be about allowing both
member object and member functions to be used in the same way
so that one could be upgraded to the other when the need come, without
having to modify the whole code base.
--
---
You received this message because you are 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/.
--089e012953ba840c3904e52c7d09
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Aug 30, 2013 at 6:05 PM, Nevin Liber <span dir=3D"ltr"><<a href=
=3D"mailto:nevin@eviloverlord.com" target=3D"_blank">nevin@eviloverlord.com=
</a>></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>I find this uncompelling, because such transformation=
s can easily break correctness.=A0 If someone expects the call to count() t=
o return the same value in two successive calls (which might not even be in=
the same function), this transformation breaks them.<br>
<br></div></blockquote><div><br></div><div>I believe you are making the sam=
e point than=A0Martinho Fernandes so I should have answered in my last emai=
l.</div><div>=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);bor=
der-left-style:solid;padding-left:1ex">
<div></div><div>In practical terms, I've found it incredibly rare to ma=
ke these kind of wholesale changes to implementations (those that change pr=
econditions or postconditions) without having to revisit the entire program=
..<br>
<br></div></blockquote><div><br></div><div>It depends on the requirements b=
ut I also find rare a change of requirements by changing implementation of =
a function.<br>However, I don't always have checks that make sure I did=
n't change these requirements.<br>
To me all these points are about the requirements part of any kind of funct=
ion (properties included) which indeed are hard to prove not being changed =
by a change of the implementation.<br>But again, fixing that requires anoth=
er set of language feature and is not directly related to properties, in my=
opinion.</div>
<div>=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=
-style:solid;padding-left:1ex"><div><br></div><div>What problem is trying t=
o be solved with properties?=A0 Is it just the syntactical notation of not =
having to use parentheses?</div>
</blockquote></div><br>More or less. I belive the point of properties to be=
about allowing both member object and member functions to be used in the s=
ame way<br>so that one could be upgraded to the other when the need come, w=
ithout having to modify the whole code base.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e012953ba840c3904e52c7d09--
.
Author: loic.actarus.joly@numericable.fr
Date: Fri, 30 Aug 2013 18:14:02 +0200 (CEST)
Raw View
<!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><br>---- Message d'origine ----<br>>De : "Martinho Fernandes" <=
martinho.fernandes@gmail.com><br><br><br>> The use of the word "check=
" led me to think of changes similar to the<br>> example I gave of check=
ing for out-of-range values (locking a mutex is<br>> not a check, is it?=
). Changing normal data to properties with<br>> additional "checks" in i=
t is not something one wants to encourage.<br>> Thanks for clarifying wh=
at you meant and I hope you will be more<br>> precise about what kind of=
changes you want to enable with this<br>> feature in the future, especi=
ally because I see a lot of programmers<br>> thinking of this ability to=
add precondition checks silently as a<br>> benefit of property syntax (=
that was all over the place when I was<br>> using C#).<br><br>There are =
two kinds of checks that may be added: <div>- You might add a new prec=
ondition</div><div>- You might add a new check for an existing precondition=
that was previously only mandated in documentation, and for which you prov=
ided no help to the user if it was violated.</div><div><br></div><div>I bel=
ieve the second use case is fine.</div><div><br></div><div>And even in the =
first situation, not having properties would force an interface change the =
first time a precondition is added, but all further changes to precondition=
s will be non interface breaking, unless you purposefully do it, which may =
be done by renaming the interface too.</div><div><br></div><div>Breaking th=
e interface when the implementation evolves may be very beneficial in some =
cases, but I believe the benefits of it depends on the specific situation. =
It should be an explicit decision of the class designer to break the interf=
ace or not. Currently, changing the implementation may force the class impl=
ementer to break the interface(*). With properties, he would have the freed=
om to do what is best in his case.</div><div><br></div><div>I have several =
similar other use cases where I would probably not want to break the interf=
ace:</div><div>- Adding some instrumentation to the code, for instance logg=
ing all accesses to a data</div><div>- Switching between a data that is dir=
ectly stored and a data computed on demand.</div><div><br></div><div><br></=
div><div>(*) In fact, in order to avoid the possibility of this forced inte=
rface breakage, many coding standards discourage the use of public data mem=
bers, mandating code that is longer to write and less pleasant to use.</div=
><div><br></div><div>--- </div><div>Lo=EFc</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Aug 2013 18:16:47 +0200
Raw View
--089e0112cf10a73d9604e52c8ca7
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
On Fri, Aug 30, 2013 at 6:12 PM, Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>=
wrote:
>
>
>> What problem is trying to be solved with properties? Is it just the
>> syntactical notation of not having to use parentheses?
>>
>
> More or less. I belive the point of properties to be about allowing both
> member object and member functions to be used in the same way
> so that one could be upgraded to the other when the need come, without
> having to modify the whole code base.
>
I should add that, as pointed previously, one coudld have the same feature
by just always using functions in public interfaces,
in which case indeed parentheses might become noise.
That's basically why I think properties are interesting but I'm not really
pressed to have them in C++ (if there was a competition in order of
inclusion in the standard).
I can still use member functions only as public interfaces and ignore the
noise of the parentheses.
Still, if there was a simple and cheap way to remove that noise, it would
be "nice".
--=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/.
--089e0112cf10a73d9604e52c8ca7
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Fri, Aug 30, 2013 at 6:12 PM, Klaim - Jo=EBl Lamotte <span dir=
=3D"ltr"><<a href=3D"mailto:mjklaim@gmail.com" target=3D"_blank">mjklaim=
@gmail.com</a>></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">=
<div class=3D"gmail_quote"><div class=3D"im"><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><br></div><div>What problem is trying to be solved with properties?=A0=
Is it just the syntactical notation of not having to use parentheses?</div=
>
</blockquote></div></div><br>More or less. I belive the point of properties=
to be about allowing both member object and member functions to be used in=
the same way<br>so that one could be upgraded to the other when the need c=
ome, without having to modify the whole code base.</div>
</div>
</blockquote></div><br></div><div class=3D"gmail_extra">I should add that, =
as pointed previously, one coudld have the same feature by just always usin=
g functions in public interfaces,<br>in which case indeed parentheses might=
become noise.<br>
<br>That's basically why I think properties are interesting but I'm=
not really pressed to have them in C++ (if there was a competition in orde=
r of inclusion in the standard).<br>I can still use member functions only a=
s public interfaces and ignore the noise of the parentheses.<br>
Still, if there was a simple and cheap way to remove that noise, it would b=
e "nice".<br><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0112cf10a73d9604e52c8ca7--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 30 Aug 2013 18:47:04 +0200
Raw View
On Fri, 2013-08-30 at 18:14 +0200, loic.actarus.joly@numericable.fr
wrote:
>
> ---- Message d'origine ----
> >De : "Martinho Fernandes" <martinho.fernandes@gmail.com>
>
>
> > The use of the word "check" led me to think of changes similar to
> the
> > example I gave of checking for out-of-range values (locking a mutex
> is
> > not a check, is it?). Changing normal data to properties with
> > additional "checks" in it is not something one wants to encourage.
> > Thanks for clarifying what you meant and I hope you will be more
> > precise about what kind of changes you want to enable with this
> > feature in the future, especially because I see a lot of programmers
> > thinking of this ability to add precondition checks silently as a
> > benefit of property syntax (that was all over the place when I was
> > using C#).
>
> There are two kinds of checks that may be added:
> - You might add a new precondition
> - You might add a new check for an existing precondition that was
> previously only mandated in documentation, and for which you provided
> no help to the user if it was violated.
>
>
> I believe the second use case is fine.
>
>
> And even in the first situation, not having properties would force an
> interface change the first time a precondition is added, but all
> further changes to preconditions will be non interface breaking,
> unless you purposefully do it, which may be done by renaming the
> interface too.
>
>
> Breaking the interface when the implementation evolves may be very
> beneficial in some cases, but I believe the benefits of it depends on
> the specific situation. It should be an explicit decision of the class
> designer to break the interface or not. Currently, changing the
> implementation may force the class implementer to break the
> interface(*). With properties, he would have the freedom to do what is
> best in his case.
>
> I have several similar other use cases where I would probably not want
> to break the interface:
> - Adding some instrumentation to the code, for instance logging all
> accesses to a data
> - Switching between a data that is directly stored and a data computed
> on demand.
>
I have a pile of such code myself, and sometimes properties feels like
an easy fix.
I then realize the the problem is that the code is written to an
interface that is at to low a level and the real fix is to abstract the
code further so that clients won't have to muck about with the internal
details of the classes.
>
> (*) In fact, in order to avoid the possibility of this forced
> interface breakage, many coding standards discourage the use of public
> data members, mandating code that is longer to write and less pleasant
> to use.
>
I think this is very much in the eye of the beholder - from my point of
view non-private data members are a wart on a class and papering over
them is not helpful. Furthermore, properties used in this way makes it
harder to reason about the code.
Can this throw?
instance.variable;
Today, the answer is no but with properties it might. Now, that might be
beneficiary in some odd cases but it is still surprising.
I also think that the function call
instance.variable;
is a lot less clear about being a function call than
instance.variable();
/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/.
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 30 Aug 2013 09:52:54 -0700 (PDT)
Raw View
------=_Part_312_1444001.1377881574198
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
To me the latest motivation for properties is the most resonating: creating=
=20
the ability to change a plain data member to a pair of methods in a later=
=20
edition of a library component without breaking code. And I agree that a=20
good effect of this would be that you don't have to do setters and getters=
=20
for all members just in case that you may want to add checks or=20
transformations or whatever later.
I previously posted the suggestion of introducing syntactical sugar at the=
=20
place of use where assignment gets transformed to a setter call in=20
basically the same way as a =3D in a declaration is transformed to at ctor=
=20
call, and where mentioning a method pointer without the leading & is=20
sugered to implicitly add a trailing().
The main drawback with this idea is probably that you have to use the=20
pattern that the two methods have the same name with 0 and 1 parameter. To=
=20
allow a =3D b =3D c syntax the setter would have to return the value set,=
=20
otherwise you would end up with the rather strange:
int a =3D object.getTheProp;
object.setTheProp =3D 3;
The main advantage is that it does not add any burden to the writing of the=
=20
class head, and (I think) that it is easy to implement for compiler vendors=
=20
and safe as it only allows code that was previously erroneous.
When it comes to Ville's earlier (well, a lot earlier by now) comment about=
=20
auto-implementing set and get methods, that's the other way around, isn't=
=20
it? You declare a data member but access it as if it was a pair of setters=
=20
in the code that uses the class. To me this seems like a way to reduce the=
=20
typing burden which stems from the programming guideline rule that all=20
member access is to be via setters and getters. Of course the two can be=20
combined, which causes what looks like an assignment into a setter call=20
which does the exact same assignment (with automatic implementation there's=
=20
not much else it can do), all awaiting a possible future time when the=20
setter may be replaced with an explicitly written function. Rather=20
contrived (unless we are aiming at binary backwards compatibility - no=20
recompilation required, but it doesn't seem so from recent posts).
The implications of using the value of a member variable and then the=20
member variable gets replaced by a getter of the same name is normally that=
=20
it just continues to work. But other uses like taking the address of the=20
member no longer works. But how could it? There is no member to take the=20
address of anymore. And thus the code should break. When you do a=20
reimplementation for instance to calculate the value on the fly instead of=
=20
storing it as a data member you must of course accept that you can't take=
=20
its address anymore. decltype() is also a problem as it would change from=
=20
the member type to the method type, or do you have to add the leading & to=
=20
use decltype with a method?
There is of course the case when the getter you replaced the member with=20
returns a reference to another member, which you then should be able to=20
take the address of, but won't be as taking the address would get you the=
=20
address of the method (a possibility we must of course preserve). This=20
means that the code looks broken, so you have to add your trailing ()=20
again, but it doesn't get worse than that.
My conclusion is that this approach would solve a majority of the problem,=
=20
be noisy about almost all remaining cases, but admittedly cause a few=20
member->method changes to cause hard to track errors, such as getters that=
=20
actually return method pointers or return values captured by auto followed=
=20
by code that is indifferent to type. But given that a method pointer is=20
about the weirdest type available in C++ (i.e. works with least amount of=
=20
operators and function signatures) I think the actual cases of "silent=20
breaking of code" will be very few. Note that I'm not talking about this=20
language change breaking code (if someone can show that the language=20
feature itself breaks ANY code I don't think it should be introduced).=20
Den fredagen den 30:e augusti 2013 kl. 18:16:47 UTC+2 skrev Klaim - Jo=EBl=
=20
Lamotte:
>
>
>
>
> On Fri, Aug 30, 2013 at 6:12 PM, Klaim - Jo=EBl Lamotte <mjk...@gmail.com=
<javascript:>
> > wrote:
>
>>
>>
>>> What problem is trying to be solved with properties? Is it just the=20
>>> syntactical notation of not having to use parentheses?
>>>
>>
>> More or less. I belive the point of properties to be about allowing both=
=20
>> member object and member functions to be used in the same way
>> so that one could be upgraded to the other when the need come, without=
=20
>> having to modify the whole code base.
>> =20
>
> I should add that, as pointed previously, one coudld have the same featur=
e=20
> by just always using functions in public interfaces,
> in which case indeed parentheses might become noise.
>
> That's basically why I think properties are interesting but I'm not reall=
y=20
> pressed to have them in C++ (if there was a competition in order of=20
> inclusion in the standard).
> I can still use member functions only as public interfaces and ignore the=
=20
> noise of the parentheses.
> Still, if there was a simple and cheap way to remove that noise, it would=
=20
> be "nice".
>
>
--=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_312_1444001.1377881574198
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>To me the latest motivation for properties is the mos=
t resonating: creating the ability to change a plain data member to a pair =
of methods in a later edition of a library component without breaking code.=
And I agree that a good effect of this would be that you don't have to do =
setters and getters for all members just in case that you may want to add c=
hecks or transformations or whatever later.</div><div><br></div>I previousl=
y posted the suggestion of introducing syntactical sugar at the place of us=
e where assignment gets transformed to a setter call in basically the same =
way as a =3D in a declaration is transformed to at ctor call, and where men=
tioning a method pointer without the leading & is sugered to implicitly=
add a trailing().<div><br></div><div>The main drawback with this idea is p=
robably that you have to use the pattern that the two methods have the same=
name with 0 and 1 parameter. To allow a =3D b =3D c syntax the setter woul=
d have to return the value set, otherwise you would end up with the rather =
strange:</div><div><br></div><div>int a =3D object.getTheProp;</div><div>ob=
ject.setTheProp =3D 3;</div><div><br></div><div><span style=3D"font-size: 1=
3px;">The main advantage is that it does not add any burden to the writing =
of the class head, and (I think) that it is easy to implement for compiler =
vendors and safe as it only allows code that was previously erroneous.</spa=
n><br></div><div><span style=3D"font-size: 13px;"><br></span></div><div><sp=
an style=3D"font-size: 13px;">When it comes to Ville's earlier (well, a lot=
earlier by now) comment about auto-implementing set and get methods, that'=
s the other way around, isn't it? You declare a data member but access it a=
s if it was a pair of setters in the code that uses the class. To me this s=
eems like a way to reduce the typing burden which stems from the programmin=
g guideline rule that all member access is to be via setters and getters. O=
f course the two can be combined, which causes what looks like an assignmen=
t into a setter call which does the exact same assignment (with automatic i=
mplementation there's not much else it can do), all awaiting a possible fut=
ure time when the setter may be replaced with an explicitly written functio=
n. Rather contrived (unless we are aiming at binary backwards compatibility=
- no recompilation required, but it doesn't seem so from recent posts).</s=
pan></div><div><span style=3D"font-size: 13px;"><br></span></div><div><span=
style=3D"font-size: 13px;">The implications of using the value of a member=
variable and then the member variable gets replaced by a getter of the sam=
e name is normally that it just continues to work. But other uses like taki=
ng the address of the member no longer works. But how could it? There is no=
member to take the address of anymore. And thus the code should break. Whe=
n you do a reimplementation for instance to calculate the value on the fly =
instead of storing it as a data member you must of course accept that you c=
an't take its address anymore. decltype() is also a problem as it would cha=
nge from the member type to the method type, or do you have to add the lead=
ing & to use decltype with a method?</span></div><div><span style=3D"fo=
nt-size: 13px;"><br></span></div><div><span style=3D"font-size: 13px;">Ther=
e is of course the case when the getter you replaced the member with return=
s a reference to another member, which you then should be able to take the =
address of, but won't be as taking the address would get you the address of=
the method (a possibility we must of course preserve). This means that the=
code looks broken, so you have to add your trailing () again, but it doesn=
't get worse than that.</span></div><div><span style=3D"font-size: 13px;"><=
br></span></div><div><span style=3D"font-size: 13px;">My conclusion is that=
this approach would solve a majority of the problem, be noisy about almost=
all remaining cases, but admittedly cause a few member->method changes =
to cause hard to track errors, such as getters that actually return method =
pointers or return values captured by auto followed by code that is indiffe=
rent to type. But given that a method pointer is about the weirdest type av=
ailable in C++ (i.e. works with least amount of operators and function sign=
atures) I think the actual cases of "silent breaking of code" will be very =
few. Note that I'm not talking about this language change breaking code (if=
someone can show that the language feature itself breaks ANY code I don't =
think it should be introduced). </span></div><div><br>Den fredagen den=
30:e augusti 2013 kl. 18:16:47 UTC+2 skrev Klaim - Jo=EBl Lamotte:<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"><br><div><br><br><div=
class=3D"gmail_quote">On Fri, Aug 30, 2013 at 6:12 PM, Klaim - Jo=EBl Lamo=
tte <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" gdf-obf=
uscated-mailto=3D"84W1UduuBUYJ">mjk...@gmail.com</a>></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><div class=3D"gmail_qu=
ote"><div><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><br></div><div>What problem is trying to be solved with properties?&nb=
sp; Is it just the syntactical notation of not having to use parentheses?</=
div>
</blockquote></div></div><br>More or less. I belive the point of properties=
to be about allowing both member object and member functions to be used in=
the same way<br>so that one could be upgraded to the other when the need c=
ome, without having to modify the whole code base.</div>
</div>
</blockquote></div><br></div><div>I should add that, as pointed previously,=
one coudld have the same feature by just always using functions in public =
interfaces,<br>in which case indeed parentheses might become noise.<br>
<br>That's basically why I think properties are interesting but I'm not rea=
lly pressed to have them in C++ (if there was a competition in order of inc=
lusion in the standard).<br>I can still use member functions only as public=
interfaces and ignore the noise of the parentheses.<br>
Still, if there was a simple and cheap way to remove that noise, it would b=
e "nice".<br><br></div></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_312_1444001.1377881574198--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 30 Aug 2013 10:01:55 -0700 (PDT)
Raw View
------=_Part_517_13589907.1377882115873
Content-Type: text/plain; charset=ISO-8859-1
Magnus:
You are of course right that from a clearness standpoint a function call
should look like one and a member access look like that.
So the question is whether this is more important than being able to
migrate from variable to method without breaking existing usages.
I know that many think that global data members are a no-no, but isn't that
a consequence of considering the possibility that checking of the value or
action on its change may be needed in the future, and thus actually the
only solution to the migration problem being promoted to a self-sufficient
rule. Apart from the scare of future code breaking changes, why would
setting a member by calling setters be better than setting it directly? At
least this is the usual motivation for setters/getters I have seen in text
books.
Den fredagen den 30:e augusti 2013 kl. 18:47:04 UTC+2 skrev Magnus
Fromreide:
>
> On Fri, 2013-08-30 at 18:14 +0200, loic.act...@numericable.fr<javascript:>
> wrote:
> >
> > ---- Message d'origine ----
> > >De : "Martinho Fernandes" <martinho....@gmail.com <javascript:>>
> >
> >
> > > The use of the word "check" led me to think of changes similar to
> > the
> > > example I gave of checking for out-of-range values (locking a mutex
> > is
> > > not a check, is it?). Changing normal data to properties with
> > > additional "checks" in it is not something one wants to encourage.
> > > Thanks for clarifying what you meant and I hope you will be more
> > > precise about what kind of changes you want to enable with this
> > > feature in the future, especially because I see a lot of programmers
> > > thinking of this ability to add precondition checks silently as a
> > > benefit of property syntax (that was all over the place when I was
> > > using C#).
> >
> > There are two kinds of checks that may be added:
> > - You might add a new precondition
> > - You might add a new check for an existing precondition that was
> > previously only mandated in documentation, and for which you provided
> > no help to the user if it was violated.
> >
> >
> > I believe the second use case is fine.
> >
> >
> > And even in the first situation, not having properties would force an
> > interface change the first time a precondition is added, but all
> > further changes to preconditions will be non interface breaking,
> > unless you purposefully do it, which may be done by renaming the
> > interface too.
> >
> >
> > Breaking the interface when the implementation evolves may be very
> > beneficial in some cases, but I believe the benefits of it depends on
> > the specific situation. It should be an explicit decision of the class
> > designer to break the interface or not. Currently, changing the
> > implementation may force the class implementer to break the
> > interface(*). With properties, he would have the freedom to do what is
> > best in his case.
>
> >
> > I have several similar other use cases where I would probably not want
> > to break the interface:
> > - Adding some instrumentation to the code, for instance logging all
> > accesses to a data
> > - Switching between a data that is directly stored and a data computed
> > on demand.
> >
> I have a pile of such code myself, and sometimes properties feels like
> an easy fix.
>
> I then realize the the problem is that the code is written to an
> interface that is at to low a level and the real fix is to abstract the
> code further so that clients won't have to muck about with the internal
> details of the classes.
> >
> > (*) In fact, in order to avoid the possibility of this forced
> > interface breakage, many coding standards discourage the use of public
> > data members, mandating code that is longer to write and less pleasant
> > to use.
> >
> I think this is very much in the eye of the beholder - from my point of
> view non-private data members are a wart on a class and papering over
> them is not helpful. Furthermore, properties used in this way makes it
> harder to reason about the code.
>
> Can this throw?
>
> instance.variable;
>
> Today, the answer is no but with properties it might. Now, that might be
> beneficiary in some odd cases but it is still surprising.
>
> I also think that the function call
>
> instance.variable;
>
> is a lot less clear about being a function call than
>
> instance.variable();
>
> /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_517_13589907.1377882115873
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Magnus:<div><br></div><div>You are of course right that fr=
om a clearness standpoint a function call should look like one and a member=
access look like that.</div><div><br></div><div>So the question is whether=
this is more important than being able to migrate from variable to method =
without breaking existing usages.</div><div><br></div><div>I know that many=
think that global data members are a no-no, but isn't that a consequence o=
f considering the possibility that checking of the value or action on its c=
hange may be needed in the future, and thus actually the only solution to t=
he migration problem being promoted to a self-sufficient rule. Apart from t=
he scare of future code breaking changes, why would setting a member by cal=
ling setters be better than setting it directly? At least this is the usual=
motivation for setters/getters I have seen in text books.<br><br>Den freda=
gen den 30:e augusti 2013 kl. 18:47:04 UTC+2 skrev Magnus Fromreide:<blockq=
uote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-lef=
t: 1px #ccc solid;padding-left: 1ex;">On Fri, 2013-08-30 at 18:14 +0200, <a=
href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"RmrIWVLR7l=
cJ">loic.act...@numericable.<wbr>fr</a>
<br>wrote:
<br>>=20
<br>> ---- Message d'origine ----
<br>> >De : "Martinho Fernandes" <<a href=3D"javascript:" target=
=3D"_blank" gdf-obfuscated-mailto=3D"RmrIWVLR7lcJ">martinho....@gmail.com</=
a>>
<br>>=20
<br>>=20
<br>> > The use of the word "check" led me to think of changes simila=
r to
<br>> the
<br>> > example I gave of checking for out-of-range values (locking a=
mutex
<br>> is
<br>> > not a check, is it?). Changing normal data to properties with
<br>> > additional "checks" in it is not something one wants to encou=
rage.
<br>> > Thanks for clarifying what you meant and I hope you will be m=
ore
<br>> > precise about what kind of changes you want to enable with th=
is
<br>> > feature in the future, especially because I see a lot of prog=
rammers
<br>> > thinking of this ability to add precondition checks silently =
as a
<br>> > benefit of property syntax (that was all over the place when =
I was
<br>> > using C#).
<br>>=20
<br>> There are two kinds of checks that may be added:=20
<br>> - You might add a new precondition
<br>> - You might add a new check for an existing precondition that was
<br>> previously only mandated in documentation, and for which you provi=
ded
<br>> no help to the user if it was violated.
<br>>=20
<br>>=20
<br>> I believe the second use case is fine.
<br>>=20
<br>>=20
<br>> And even in the first situation, not having properties would force=
an
<br>> interface change the first time a precondition is added, but all
<br>> further changes to preconditions will be non interface breaking,
<br>> unless you purposefully do it, which may be done by renaming the
<br>> interface too.
<br>>=20
<br>>=20
<br>> Breaking the interface when the implementation evolves may be very
<br>> beneficial in some cases, but I believe the benefits of it depends=
on
<br>> the specific situation. It should be an explicit decision of the c=
lass
<br>> designer to break the interface or not. Currently, changing the
<br>> implementation may force the class implementer to break the
<br>> interface(*). With properties, he would have the freedom to do wha=
t is
<br>> best in his case.
<br>
<br>>=20
<br>> I have several similar other use cases where I would probably not =
want
<br>> to break the interface:
<br>> - Adding some instrumentation to the code, for instance logging al=
l
<br>> accesses to a data
<br>> - Switching between a data that is directly stored and a data comp=
uted
<br>> on demand.
<br>>=20
<br>I have a pile of such code myself, and sometimes properties feels like
<br>an easy fix.
<br>
<br>I then realize the the problem is that the code is written to an
<br>interface that is at to low a level and the real fix is to abstract the
<br>code further so that clients won't have to muck about with the internal
<br>details of the classes.
<br>>=20
<br>> (*) In fact, in order to avoid the possibility of this forced
<br>> interface breakage, many coding standards discourage the use of pu=
blic
<br>> data members, mandating code that is longer to write and less plea=
sant
<br>> to use.
<br>>=20
<br>I think this is very much in the eye of the beholder - from my point of
<br>view non-private data members are a wart on a class and papering over
<br>them is not helpful. Furthermore, properties used in this way mak=
es it
<br>harder to reason about the code.
<br>
<br>Can this throw?
<br>
<br>instance.variable;
<br>
<br>Today, the answer is no but with properties it might. Now, that might b=
e
<br>beneficiary in some odd cases but it is still surprising.
<br>
<br>I also think that the function call
<br>
<br>instance.variable;
<br>
<br>is a lot less clear about being a function call than
<br>
<br>instance.variable();
<br>
<br>/MF
<br>
<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_517_13589907.1377882115873--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Fri, 30 Aug 2013 19:46:26 +0200
Raw View
On Fri, 2013-08-30 at 10:01 -0700, Bengt Gustafsson wrote:
> Magnus:
>
>
> You are of course right that from a clearness standpoint a function
> call should look like one and a member access look like that.
>
>
> So the question is whether this is more important than being able to
> migrate from variable to method without breaking existing usages.
>
I think that is one of the big questions here.
> I know that many think that global data members are a no-no, but isn't
> that a consequence of considering the possibility that checking of the
> value or action on its change may be needed in the future, and thus
> actually the only solution to the migration problem being promoted to
> a self-sufficient rule. Apart from the scare of future code breaking
> changes, why would setting a member by calling setters be better than
> setting it directly? At least this is the usual motivation for
> setters/getters I have seen in text books.
>
I do not think setters/getters are a good thing either, just that they
are better than public members but I admit that the reason they are
better is as outlined above.
The reason they are bad is that they expose internal parts of the
object, just like public members do.
I prefer if the code is at a higher level so I have a Square with two
constructors, one taking a distance and the other taking an area. When I
want to change my Square instance using either property i construct a
new Square and assign it to the original one.
Yes - sometimes this won't work but that is a problem for those times.
/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/.
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Fri, 30 Aug 2013 11:26:58 -0700 (PDT)
Raw View
------=_Part_412_32094860.1377887218640
Content-Type: text/plain; charset=ISO-8859-1
Bengt:
Taking the address of a property should not create any new problems. Since
properties would inherently be functions, taking their address would
exhibit the same behavior as taking the address of any function, and that
behavior is already described in the standard. That behavior shouldn't have
to be changed to add properties.
My intention *is* that getter/setter pairs should be implemented as two
methods which have the same name, with 0 and 1 parameter, but I don't see
this as a drawback. It actually provides several advantages, one of which
being the ability to overload the setter, and another being that the
getters and setters are clearly declared as functions in the header,
signifying the possibility of side effects to the caller.
I image the effect of 'a = prop = c' to be as follows:
prop.set(c);
a = prop.get();
Likewise, I would expect 'prop += a' to work as follows:
auto tmp = prop.get();
tmp += a
prop.set(tmp);
I do agree there is the 'possibility' for confusion, but this exists with
any feature, and I believe the above usage should be straight forward
enough.
*"here is of course the case when the getter you replaced the member with
returns a reference to another member, which you then should be able to
take the address of, but won't be as taking the address would get you the
address of the method"*
I don't see any reason that this should work differently than a regular
function, and taking the address of an implicitly callable function that
returns a reference should yield the same result as if the function was not
implicitly callable.
*"if someone can show that the language feature itself breaks ANY code I
don't think it should be introduced"*
I do agree, but as properties would inherently be "functions with perks" I
don't believe they should introduce any major new problems.
Magnus:
*"The reason they are bad is that they expose internal parts of the *
*object, just like public members do."*
I don't understand how this is the case, considering that an implementer
could omit the setter function, only implementing the getter, thus making
the property read only.
On Tuesday, 27 August 2013 11:04:42 UTC-4, Nick wrote:
>
> Has anyone considered using "auto" as a qualifier to specify that a
> function is a property?
>
> The D programming language uses a similar approach, except that
> "@property" is used in front of the function. The "property" keyword is
> already in use in Objective-C++ and CLI, so instead, the auto keyword could
> be used as a qualifier.
>
> I remember reading a paper somewhere that suggested something similar to
> this, but it used a new keyword "implicit" in place of auto. I believe this
> still clear enough, and avoids the need for another keyword.
>
> class Test
> {
> int _number;
> std::pair<int, int> _twoNumbers;
> public:
> // getter
> int number() auto {
> return _number;
> }
>
> // setter
> int number(int number) auto {
> return _number = number;
> }
>
> // getter by reference
> const pair<int, int> &twoNumbers() const auto {
> return _twoNumbers;
> }
>
> // setter
> const pair<int, int> &twoNumbers(const pair<int, int> &tn) auto {
> return (_twoNumbers = tn);
> }
> };
>
>
> /////////////////////////
> Test test;
>
>
> test.number = 5;
> //same as: test.number(5);
>
>
> int a = test.number;
> // same as: int a = test.number();
>
>
> test.number += 5;
> // same as: test.number( test.number() + 5 );
>
>
> int a = 1 + test.number + 3;
> // same as: int a = 1 + test.number() + 3;
>
>
> cout << number.twoNumbers.first << endl;
> // same as: cout << number.twoNumbers().first << endl;
>
>
--
---
You received this message because you are 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_412_32094860.1377887218640
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Bengt:</div><div><br></div><div>Taking the address of=
a property should not create any new problems. Since properties would inhe=
rently be functions, taking their address would exhibit the same behavior a=
s taking the address of any function, and that behavior is already describe=
d in the standard. That behavior shouldn't have to be changed to add proper=
ties.</div><div><br></div><div>My intention <i>is</i> that getter/setter pa=
irs should be implemented as two methods which have the same name, with 0 a=
nd 1 parameter, but I don't see this as a drawback. It actually provides se=
veral advantages, one of which being the ability to overload the setter, an=
d another being that the getters and setters are clearly declared as functi=
ons in the header, signifying the possibility of side effects to the caller=
..</div><div><br></div><div>I image the effect of 'a =3D prop =3D c' to be a=
s follows:</div><div class=3D"prettyprint" style=3D"background-color: rgb(2=
50, 250, 250); border: 1px solid rgb(187, 187, 187); word-wrap: break-word;=
"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"=
color: #000;" class=3D"styled-by-prettify">prop</span><span style=3D"color:=
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">set</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">c</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>a=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> prop</span><spa=
n style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">get</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">();</span></div></code></div><div><=
br></div><div>Likewise, I would expect 'prop +=3D a' to work as follows:</d=
iv><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"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> tmp </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> prop</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #008;" class=3D"styled-by-prettify">ge=
t</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>tmp </span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">+=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> a<br>prop</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">.</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">set</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">(</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify">tmp</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">);</span></div></code></div><div><br></div><div><span st=
yle=3D"font-size: 13px;">I do agree there is the 'possibility' for confusio=
n, but this exists with any feature, and I believe the above usage should b=
e straight forward enough.</span><br></div><div><br></div><div><i>"here is =
of course the case when the getter you replaced the member with returns a r=
eference to another member, which you then should be able to take the addre=
ss of, but won't be as taking the address would get you the address of the =
method"</i></div><div><br></div><div>I don't see any reason that this shoul=
d work differently than a regular function, and taking the address of an im=
plicitly callable function that returns a reference should yield the same r=
esult as if the function was not implicitly callable.</div><div><br></div><=
div><br></div><div><i>"if someone can show that the language feature itself=
breaks ANY code I don't think it should be introduced"</i></div><div><br><=
/div><div>I do agree, but as properties would inherently be "functions with=
perks" I don't believe they should introduce any major new problems.</div>=
<div><br></div><div><br></div><div>Magnus:</div><div><br></div><div><i>"The=
reason they are bad is that they expose internal parts of the </i></d=
iv><div><i>object, just like public members do."</i></div><div><br></div><d=
iv>I don't understand how this is the case, considering that an implementer=
could omit the setter function, only implementing the getter, thus making =
the property read only.</div><br>On Tuesday, 27 August 2013 11:04:42 UTC-4,=
Nick wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>Has anyone considered using "auto" as a qualifier to specify that a fu=
nction is a property?<br></div><div><br></div><div>The D programming langua=
ge uses a similar approach, except that "@property" is used in front of the=
function. The "property" keyword is already in use in Objective-C++ =
and CLI, so instead, the auto keyword could be used as a qualifier.<div><br=
></div><div>I remember reading a paper somewhere that suggested something s=
imilar to this, but it used a new keyword "implicit" in place of auto. I be=
lieve this still clear enough, and avoids the need for another keyword.</di=
v><div><br></div><div><div style=3D"background-color:rgb(250,250,250);borde=
r:1px solid rgb(187,187,187);word-wrap:break-word"><code><div><span style=
=3D"color:#008">class</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">Test</span><span style=3D"color:#000"><br></span><span styl=
e=3D"color:#660">{</span><span style=3D"color:#000"><br> </spa=
n><span style=3D"color:#008">int</span><span style=3D"color:#000"> _number<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br>&nb=
sp; std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#000">pair</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#008">int</span><span style=3D"color:#660">,</span><span style=3D"color=
:#000"> </span><span style=3D"color:#008">int</span><span style=3D"color:#6=
60">></span><span style=3D"color:#000"> _twoNumbers</span><span style=3D=
"color:#660">;</span><span style=3D"color:#000"><br></span><span style=3D"c=
olor:#008">public</span><span style=3D"color:#660">:</span><span style=3D"c=
olor:#000"><br> </span><span style=3D"color:#800">// getter</s=
pan><span style=3D"color:#000"><br> </span><span style=3D"colo=
r:#008">int</span><span style=3D"color:#000"> number</span><span style=3D"c=
olor:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color=
:#008">auto</span><span style=3D"color:#000"> </span><span style=3D"color:#=
660">{</span><span style=3D"color:#000"><br> </s=
pan><span style=3D"color:#008">return</span><span style=3D"color:#000"> _nu=
mber</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><b=
r> </span><span style=3D"color:#660">}</span><span style=3D"co=
lor:#000"><br> <br> </span><span style=3D"color:#=
800">// setter</span><span style=3D"color:#000"><br> </span><s=
pan style=3D"color:#008">int</span><span style=3D"color:#000"> number</span=
><span style=3D"color:#660">(</span><span style=3D"color:#008">int</span><s=
pan style=3D"color:#000"> number</span><span style=3D"color:#660">)</span><=
span style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><sp=
an style=3D"color:#000"> </span><span style=3D"color:#660">{</span><span st=
yle=3D"color:#000"><br> </span><span style=3D"co=
lor:#008">return</span><span style=3D"color:#000"> _number </span><span sty=
le=3D"color:#660">=3D</span><span style=3D"color:#000"> number</span><span =
style=3D"color:#660">;</span><span style=3D"color:#000"><br> <=
/span><span style=3D"color:#660">}</span><span style=3D"color:#000"><br>&nb=
sp; <br> </span><span style=3D"color:#800">// getter by=
reference</span><span style=3D"color:#000"><br> </span><span =
style=3D"color:#008">const</span><span style=3D"color:#000"> pair</span><sp=
an style=3D"color:#660"><</span><span style=3D"color:#008">int</span><sp=
an style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span st=
yle=3D"color:#008">int</span><span style=3D"color:#660">></span><span st=
yle=3D"color:#000"> </span><span style=3D"color:#660">&</span><span sty=
le=3D"color:#000">twoNumbers</span><span style=3D"color:#660">()</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#008">const</span><span=
style=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span s=
tyle=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=
=3D"color:#000"><br> </span><span style=3D"color=
:#008">return</span><span style=3D"color:#000"> _twoNumbers</span><span sty=
le=3D"color:#660">;</span><span style=3D"color:#000"><br> </sp=
an><span style=3D"color:#660">}</span><span style=3D"color:#000"><br> =
<br> </span><span style=3D"color:#800">// setter</span=
><span style=3D"color:#000"><br> </span><span style=3D"color:#=
008">const</span><span style=3D"color:#000"> pair</span><span style=3D"colo=
r:#660"><</span><span style=3D"color:#008">int</span><span style=3D"colo=
r:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">int</span><span style=3D"color:#660">></span><span style=3D"color:#00=
0"> </span><span style=3D"color:#660">&</span><span style=3D"color:#000=
">twoNumbers</span><span style=3D"color:#660">(</span><span style=3D"color:=
#008">const</span><span style=3D"color:#000"> pair</span><span style=3D"col=
or:#660"><</span><span style=3D"color:#008">int</span><span style=3D"col=
or:#660">,</span><span style=3D"color:#000"> </span><span style=3D"color:#0=
08">int</span><span style=3D"color:#660">></span><span style=3D"color:#0=
00"> </span><span style=3D"color:#660">&</span><span style=3D"color:#00=
0">tn</span><span style=3D"color:#660">)</span><span style=3D"color:#000"> =
</span><span style=3D"color:#008">auto</span><span style=3D"color:#000"> </=
span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br>&nbs=
p; </span><span style=3D"color:#008">return</span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">(</span><span sty=
le=3D"color:#000">_twoNumbers </span><span style=3D"color:#660">=3D</span><=
span style=3D"color:#000"> tn</span><span style=3D"color:#660">);</span><sp=
an style=3D"color:#000"><br> </span><span style=3D"color:#660"=
>}</span><span style=3D"color:#000"><br></span><span style=3D"color:#660">}=
;</span><span style=3D"color:#000"><br><br><br></span><span style=3D"color:=
#800">/////////////////////////</span><span style=3D"color:#000"><br></span=
><span style=3D"color:#606">Test</span><span style=3D"color:#000"> test</sp=
an><span style=3D"color:#660">;</span><span style=3D"color:#000"><br><br><b=
r>test</span><span style=3D"color:#660">.</span><span style=3D"color:#000">=
number </span><span style=3D"color:#660">=3D</span><span style=3D"color:#00=
0"> </span><span style=3D"color:#066">5</span><span style=3D"color:#660">;<=
/span><span style=3D"color:#000"><br></span><span style=3D"color:#800">//sa=
me as: test.number(5);</span><span style=3D"color:#000"><br><br><br><=
/span><span style=3D"color:#008">int</span><span style=3D"color:#000"> a </=
span><span style=3D"color:#660">=3D</span><span style=3D"color:#000"> test<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">number<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#800">// same as: int a =3D test.number();</=
span><span style=3D"color:#000"><br><br><br>test</span><span style=3D"color=
:#660">.</span><span style=3D"color:#000">number </span><span style=3D"colo=
r:#660">+=3D</span><span style=3D"color:#000"> </span><span style=3D"color:=
#066">5</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#800">// same as: test.number( test.=
number() + 5 );</span><span style=3D"color:#000"><br><br><br></span><span s=
tyle=3D"color:#008">int</span><span style=3D"color:#000"> a </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#066">1</span><span style=3D"color:#000"> </span><span style=3D"c=
olor:#660">+</span><span style=3D"color:#000"> test</span><span style=3D"co=
lor:#660">.</span><span style=3D"color:#000">number </span><span style=3D"c=
olor:#660">+</span><span style=3D"color:#000"> </span><span style=3D"color:=
#066">3</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br></span><span style=3D"color:#800">// same as: int a =3D 1 + test=
..number() + 3;</span><span style=3D"color:#000"><br><br><br>cout </span><sp=
an style=3D"color:#660"><<</span><span style=3D"color:#000"> number</=
span><span style=3D"color:#660">.</span><span style=3D"color:#000">twoNumbe=
rs</span><span style=3D"color:#660">.</span><span style=3D"color:#000">firs=
t </span><span style=3D"color:#660"><<</span><span style=3D"color:#00=
0"> endl</span><span style=3D"color:#660">;</span><span style=3D"color:#000=
"><br></span><span style=3D"color:#800">// same as: cout << num=
ber.twoNumbers().first << endl;</span></div></code></div><div><br></d=
iv></div></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_412_32094860.1377887218640--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Fri, 30 Aug 2013 11:28:05 -0700 (PDT)
Raw View
------=_Part_1077_6570322.1377887285135
Content-Type: text/plain; charset=ISO-8859-1
Bengt:
Taking the address of a property should not create any new problems. Since
properties would inherently be functions, taking their address would
exhibit the same behavior as taking the address of any function, and that
behavior is already described in the standard. That behavior shouldn't have
to be changed to add properties.
My intention *is* that getter/setter pairs should be implemented as two
methods which have the same name, with 0 and 1 parameter, but I don't see
this as a drawback. It actually provides several advantages, one of which
being the ability to overload the setter, and another being that the
getters and setters are clearly declared as functions in the header,
signifying the possibility of side effects to the caller.
I image the effect of 'a = prop = c' to be as follows:
prop.set(c);
a = prop.get();
Likewise, I would expect 'prop += a' to work as follows:
auto tmp = prop.get();
tmp += a
prop.set(tmp);
I do agree there is the 'possibility' for confusion, but this exists with
any feature, and I believe the above usage should be straight forward
enough.
*"here is of course the case when the getter you replaced the member with
returns a reference to another member, which you then should be able to
take the address of, but won't be as taking the address would get you the
address of the method"*
I don't see any reason that this should work differently than a regular
function, and taking the address of an implicitly callable function that
returns a reference should yield the same result as if the function was not
implicitly callable.
*"if someone can show that the language feature itself breaks ANY code I
don't think it should be introduced"*
I do agree, but as properties would inherently be "functions with perks" I
don't believe they should introduce any major new problems.
Magnus:
*"The reason they are bad is that they expose internal parts of the *
*object, just like public members do."*
I don't understand how this is the case, considering that an implementer
could omit the setter function, only implementing the getter, thus making
the property read only.
--
---
You received this message because you are 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_1077_6570322.1377887285135
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Bengt:</div><div><br></div><div>Taking the address of=
a property should not create any new problems. Since properties would inhe=
rently be functions, taking their address would exhibit the same behavior a=
s taking the address of any function, and that behavior is already describe=
d in the standard. That behavior shouldn't have to be changed to add proper=
ties.</div><div><br></div><div>My intention <i>is</i> that getter=
/setter pairs should be implemented as two methods which have the same name=
, with 0 and 1 parameter, but I don't see this as a drawback. It actually p=
rovides several advantages, one of which being the ability to overload the =
setter, and another being that the getters and setters are clearly declared=
as functions in the header, signifying the possibility of side effects to =
the caller.</div><div><br></div><div>I image the effect of 'a =3D prop =3D =
c' to be as follows:</div><div style=3D"border: 1px solid rgb(187, 187, 187=
); background-color: rgb(250, 250, 250); word-wrap: break-word;"><code><spa=
n style=3D"color: rgb(0, 0, 0);">prop</span><span style=3D"color: rgb(102, =
102, 0);">.</span><span style=3D"color: rgb(0, 0, 136);">set</span><span st=
yle=3D"color: rgb(102, 102, 0);">(</span><span style=3D"color: rgb(0, 0, 0)=
;">c</span><span style=3D"color: rgb(102, 102, 0);">);</span><span style=3D=
"color: rgb(0, 0, 0);"><br>a </span><span style=3D"color: rgb(102, 102=
, 0);">=3D</span><span style=3D"color: rgb(0, 0, 0);"> prop</span><spa=
n style=3D"color: rgb(102, 102, 0);">.</span><span style=3D"color: rgb(0, 0=
, 136);">get</span><span style=3D"color: rgb(102, 102, 0);">();</span></cod=
e></div><div><br></div><div>Likewise, I would expect 'prop +=3D a' to work =
as follows:</div><div style=3D"border: 1px solid rgb(187, 187, 187); backgr=
ound-color: rgb(250, 250, 250); word-wrap: break-word;"><code><span style=
=3D"color: rgb(0, 0, 136);">auto</span><span style=3D"color: rgb(0, 0, 0);"=
> tmp </span><span style=3D"color: rgb(102, 102, 0);">=3D</span><=
span style=3D"color: rgb(0, 0, 0);"> prop</span><span style=3D"color: =
rgb(102, 102, 0);">.</span><span style=3D"color: rgb(0, 0, 136);">get</span=
><span style=3D"color: rgb(102, 102, 0);">();</span><span style=3D"color: r=
gb(0, 0, 0);"><br>tmp </span><span style=3D"color: rgb(102, 102, 0);">=
+=3D</span><span style=3D"color: rgb(0, 0, 0);"> a<br>prop</span><span=
style=3D"color: rgb(102, 102, 0);">.</span><span style=3D"color: rgb(0, 0,=
136);">set</span><span style=3D"color: rgb(102, 102, 0);">(</span><span st=
yle=3D"color: rgb(0, 0, 0);">tmp</span><span style=3D"color: rgb(102, 102, =
0);">);</span></code></div><div><br></div><div><span style=3D"font-size: 13=
px;">I do agree there is the 'possibility' for confusion, but this exists w=
ith any feature, and I believe the above usage should be straight forward e=
nough.</span><br></div><div class=3D"GC2AS1XDAEB"><div><br></div><div><i>"h=
ere is of course the case when the getter you replaced the member with retu=
rns a reference to another member, which you then should be able to take th=
e address of, but won't be as taking the address would get you the address =
of the method"</i></div><div><br></div></div><div>I don't see any reason th=
at this should work differently than a regular function, and taking the add=
ress of an implicitly callable function that returns a reference should yie=
ld the same result as if the function was not implicitly callable.</div><di=
v class=3D"GC2AS1XDAEB"><div><br></div><div><br></div><div><i>"if someone c=
an show that the language feature itself breaks ANY code I don't think it s=
hould be introduced"</i></div><div><br></div></div><div>I do agree, but as =
properties would inherently be "functions with perks" I don't believe they =
should introduce any major new problems.</div><div><br></div><div><br></div=
><div>Magnus:</div><div class=3D"GC2AS1XDAEB"><div><br></div><div><i>"The r=
eason they are bad is that they expose internal parts of the </i></div=
><div><i>object, just like public members do."</i></div><div><br></div></di=
v><div>I don't understand how this is the case, considering that an impleme=
nter could omit the setter function, only implementing the getter, thus mak=
ing the property read only.</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_1077_6570322.1377887285135--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Aug 2013 13:16:36 -0700
Raw View
On sexta-feira, 30 de agosto de 2013 09:52:54, Bengt Gustafsson wrote:
> To me the latest motivation for properties is the most resonating: creating
> the ability to change a plain data member to a pair of methods in a later
> edition of a library component without breaking code.
That's assuming the rest of the code isn't doing anything like taking pointers
or references to the property itself.
For example, the following would break if Klass::theprop becomes a property
instead of a plain int:
void f(int &);
void f(Klass k)
{
f(k.theprop);
}
In some situations, it might be a good thing that it breaks. But it's still a
breakage.
In that light, I have to ask: has anyone given any thought to a "pointer-to-
member-property?" We have PMFs and PMDs, so what would be the syntax and the
requirements for a PMP?
Also, what happens to setter overloads in a PMP?
--
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/.
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Fri, 30 Aug 2013 22:30:06 +0200
Raw View
--089e0112cf109020b104e530161b
Content-Type: text/plain; charset=ISO-8859-1
On Fri, Aug 30, 2013 at 10:16 PM, Thiago Macieira <thiago@macieira.org>wrote:
> For example, the following would break if Klass::theprop becomes a property
> instead of a plain int:
>
> void f(int &);
> void f(Klass k)
> {
> f(k.theprop);
> }
>
Could you clarify how that would break?
--
---
You received this message because you are 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/.
--089e0112cf109020b104e530161b
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">=
On Fri, Aug 30, 2013 at 10:16 PM, Thiago Macieira <span dir=3D"ltr"><<a =
href=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</=
a>></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 id=3D":2rs" style=3D"overflow:hidden">F=
or example, the following would break if Klass::theprop becomes a property<=
br>
instead of a plain int:<br>
<br>
void f(int &);<br>
void f(Klass k)<br>
{<br>
=A0 =A0 f(k.theprop);<br>
}</div></blockquote></div><br>Could you clarify how that would break?<br><b=
r><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0112cf109020b104e530161b--
.
Author: Bengt Gustafsson <bengt.gustafsson@beamways.com>
Date: Fri, 30 Aug 2013 14:46:57 -0700 (PDT)
Raw View
------=_Part_367_31957030.1377899217063
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
The discussion lately has revolved around classes evolving from having data=
=20
members to in later editions having equally named setters and getters, and=
=20
in which cases this transition in one user defined library breaks other=20
user defined code. If theprop in Thiago's example changes from a data=20
member to a getter returning by value calling f for this value breaks.
Thiago: Under which condition would it NOT be good that your code example=
=20
breaks. Well, maybe if f() really uses the parameter as a const&... do you=
=20
see other cases?
Thiago(2): As per my suggestion properties are just syntactic sugar at the=
=20
place of use there is no special PMP thingy. With other suggestions with=20
special provisions in the class head this would be an important=20
consideration, what you may have use for is to get the address of the=20
setter and getter, but what you think you have is a data member... I would=
=20
not even want to think about having a PMP which packetizes the getter and=
=20
all setters into an "overloaded member function pointer" which can then be=
=20
called in so many different ways...
Nick: In the same situation, what happens when the code evolves is that the=
=20
address of the member goes from being a T* to a T (CLASS::*)(), which is=20
rather a big difference.
Nick(2): The other assignment operators and serial assignment would be=20
problematic, I think. Mainly as the result of copy construction followed by=
=20
the operator followed by assignment may not render the same result as=20
applying the operator on the "real" data, but also for performance reasons.=
=20
Nevertheless, not having these operators automagically generated as you=20
indicate will surely be the largest source of code breakages when evolving=
=20
from a plain data member to setter/getter... anyone with better ideas?
Den fredagen den 30:e augusti 2013 kl. 22:30:06 UTC+2 skrev Klaim - Jo=EBl=
=20
Lamotte:
>
>
> On Fri, Aug 30, 2013 at 10:16 PM, Thiago Macieira <thi...@macieira.org<ja=
vascript:>
> > wrote:
>
>> For example, the following would break if Klass::theprop becomes a=20
>> property
>> instead of a plain int:
>>
>> void f(int &);
>> void f(Klass k)
>> {
>> f(k.theprop);
>> }
>>
>
> Could you clarify how that would break?
>
>
>
--=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_367_31957030.1377899217063
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The discussion lately has revolved around classes evolving=
from having data members to in later editions having equally named setters=
and getters, and in which cases this transition in one user defined librar=
y breaks other user defined code. If theprop in Thiago's example changes fr=
om a data member to a getter returning by value calling f for this value br=
eaks.<div><br></div><div>Thiago: Under which condition would it NOT be good=
that your code example breaks. Well, maybe if f() really uses the paramete=
r as a const&... do you see other cases?</div><div><br></div><div>Thiag=
o(2): As per my suggestion properties are just syntactic sugar at the place=
of use there is no special PMP thingy. With other suggestions with special=
provisions in the class head this would be an important consideration, wha=
t you may have use for is to get the address of the setter and getter, but =
what you think you have is a data member... I would not even want to think =
about having a PMP which packetizes the getter and all setters into an "ove=
rloaded member function pointer" which can then be called in so many differ=
ent ways...</div><div><br></div><div>Nick: In the same situation, what happ=
ens when the code evolves is that the address of the member goes from being=
a T* to a T (CLASS::*)(), which is rather a big difference.</div><div><br>=
</div><div>Nick(2): The other assignment operators and serial assignment wo=
uld be problematic, I think. Mainly as the result of copy construction foll=
owed by the operator followed by assignment may not render the same result =
as applying the operator on the "real" data, but also for performance reaso=
ns. Nevertheless, not having these operators automagically generated as you=
indicate will surely be the largest source of code breakages when evolving=
from a plain data member to setter/getter... anyone with better ideas?<br>=
<br>Den fredagen den 30:e augusti 2013 kl. 22:30:06 UTC+2 skrev Klaim - Jo=
=EBl Lamotte:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div><br><div class=3D"gmail_quote">On Fri, Aug 30, 2013 at 10:16 PM, Thiag=
o Macieira <span dir=3D"ltr"><<a href=3D"javascript:" target=3D"_blank" =
gdf-obfuscated-mailto=3D"fVNwwzp4R88J">thi...@macieira.org</a>></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 style=3D"overflow:hidden">For example, =
the following would break if Klass::theprop becomes a property<br>
instead of a plain int:<br>
<br>
void f(int &);<br>
void f(Klass k)<br>
{<br>
f(k.theprop);<br>
}</div></blockquote></div><br>Could you clarify how that would break?<br><b=
r><br></div></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_367_31957030.1377899217063--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Fri, 30 Aug 2013 15:18:14 -0700
Raw View
--nextPart1546117.VHxgSJMkbY
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
On sexta-feira, 30 de agosto de 2013 14:46:57, Bengt Gustafsson wrote:
> Thiago: Under which condition would it NOT be good that your code example
> breaks. Well, maybe if f() really uses the parameter as a const&... do you
> see other cases?
If it's const ref, it's not a problem. The getter member will either return
(at minimum) a prvalue or a const-ref, both of which bind to a const-ref.
A very simple example is if that f(int &) overload did:
void f(int &i) { i = 2; }
Whereas before you could call this indirect setter, with properties you can't.
By the same token, the pointer to the data member will no longer compile:
int Klass:: *ptr = &Klass::theprop;
auto ptr2 = &Klass::theprop;
I'm sure we can find a few more if we think really hard.
The only reason I brought this up is that one of the stated benefits for having
a language extension to support properties was that it would allow updates
without source-incompatibility. That is not the case: some incompatibilities
might happen.
> Thiago(2): As per my suggestion properties are just syntactic sugar at the
> place of use there is no special PMP thingy. With other suggestions with
> special provisions in the class head this would be an important
> consideration, what you may have use for is to get the address of the
> setter and getter, but what you think you have is a data member... I would
> not even want to think about having a PMP which packetizes the getter and
> all setters into an "overloaded member function pointer" which can then be
> called in so many different ways...
Fair enough, I was just asking.
--
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
--nextPart1546117.VHxgSJMkbY
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
Content-Transfer-Encoding: 7Bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBSIRosM/XwBW70U1gRAoFKAKCxtWFGoCngdp28F82rdQ9OfWgNBACeOhoS
9oq6r6BK5WbOCKiz1wQFkqI=
=pO69
-----END PGP SIGNATURE-----
--nextPart1546117.VHxgSJMkbY--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Fri, 30 Aug 2013 15:44:07 -0700 (PDT)
Raw View
------=_Part_319_30777569.1377902648005
Content-Type: text/plain; charset=ISO-8859-1
*I would not even want to think about having a PMP which packetizes the
getter and all setters into an "overloaded member function pointer"*
This would not have to be the case, but I understand how it may seem that
way. For that reason, *I should revise my original premise.*
At this point, I don't even believe this concept should be referred to as
properties. I believe the wording from N1611 is much more appropriate. I do
not believe the word "Property" should be associated with this concept at
all, because questions like the one I have quoted above will just keep
coming up. I believe this issue should be labelled both in terminology, and
in the C++ language as "implicitly callable functions". It should be
clearly labelled as a language construct specific to C++, which has no
explicit or implicit relationship to "properties" in any other language.
And the contextual keyword "implicit" should be used to denote that a class
member function can be implicitly called. These functions could be
described as functions that are called implicitly as needed to facilitate
the usage of an appropriately qualified identifier, where the get and set
methods may be called one or more times in a single expression.
With the above revision in mind, the response to the original concern about
function pointers becomes obvious:
T(Class::*)() != void(Class::*)(T)
*"Nick: In the same situation, what happens when the code evolves is that
the address of the member goes from being a T* to a T (CLASS::*)(), which
is rather a big difference."*
That is true, and yet another reason why I feel it's necessary to revise my
original premise. I believe making it known that these are functions would
allow the caller to make better judgement concerning their use.
*"void f(int &i) { i = 2; } *
*Whereas before you could call this indirect setter, with properties you
can't."*
This is also true, along with many similar cases, and it may make sense to
create a list of attributes of regular functions that would be prohibited
in the case of implicitly callable functions. I don't believe that placing
a few restrictions on unnecessary use cases would hurt the overall
usefulness 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_319_30777569.1377902648005
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><i>I would not even want to think about having a PMP =
which packetizes the getter and all setters into an "overloaded member func=
tion pointer"</i></div><div><br></div><div>This would not have to be the ca=
se, but I understand how it may seem that way. For that reason, <b>I should=
revise my original premise.</b></div><div><br></div><div>At this point, I =
don't even believe this concept should be referred to as properties. I beli=
eve the wording from N1611 is much more appropriate. I do not believe the w=
ord "Property" should be associated with this concept at all, because quest=
ions like the one I have quoted above will just keep coming up. I believe t=
his issue should be labelled both in terminology, and in the C++ language a=
s "implicitly callable functions". It should be clearly labelled as a langu=
age construct specific to C++, which has no explicit or implicit relationsh=
ip to "properties" in any other language. And the contextual keyword "impli=
cit" should be used to denote that a class member function can be implicitl=
y called. These functions could be described as functions that are called i=
mplicitly as needed to facilitate the usage of an appropriately qualified i=
dentifier, where the get and set methods may be called one or more times in=
a single expression.</div><div><br></div><div>With the above revision in m=
ind, the response to the original concern about function pointers becomes o=
bvious:</div><div><br></div><div><div class=3D"prettyprint" style=3D"backgr=
ound-color: rgb(250, 250, 250); border: 1px solid rgb(187, 187, 187); word-=
wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint=
"><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"c=
olor: #606;" class=3D"styled-by-prettify">Class</span><span style=3D"color:=
#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">!=3D</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-p=
rettify">void</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">(</span><span style=3D"color: #606;" class=3D"styled-by-prettify">Class<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">::*)(</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">)</span></div></code></di=
v></div><div><br></div><div><br></div><div><i>"Nick: In the same situation,=
what happens when the code evolves is that the address of the member goes =
from being a T* to a T (CLASS::*)(), which is rather a big difference."</i>=
</div><div><br></div><div>That is true, and yet another reason why I feel i=
t's necessary to revise my original premise. I believe making it known that=
these are functions would allow the caller to make better judgement concer=
ning their use.</div><div><br></div><div><i>"void f(int &i) { i =3D 2; =
} </i></div><div><i>Whereas before you could call this indirect setter=
, with properties you can't."</i></div><div><br></div><div>This is also tru=
e, along with many similar cases, and it may make sense to create a list of=
attributes of regular functions that would be prohibited in the case of im=
plicitly callable functions. I don't believe that placing a few restriction=
s on unnecessary use cases would hurt the overall usefulness of properties.=
</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_319_30777569.1377902648005--
.
Author: Nick <nicolas.jinchereau@gmail.com>
Date: Tue, 3 Sep 2013 19:00:05 -0700 (PDT)
Raw View
------=_Part_5027_33094179.1378260005680
Content-Type: text/plain; charset=ISO-8859-1
I have to say, I am surprised at the overall lack of enthusiasm for this
idea.
I think implicitly callable functions have great potential as a language
feature, especially considering that they can be implemented in a
completely backward, non-breaking way. I think that the argument about the
"hidden complexity" of properties would turn out to be completely unfounded
if their real use cases were examined objectively, and that any concerns
about their negative impact on code coherency could easily be put to rest,
given a sufficiently detailed specification of their behavior.
I plan to write a draft specifying the details of implicitly callable
functions, their semantics, their alternatives, and an analysis of some
common use cases. I wouldn't feel like I had given this idea a fair shake
without removing the complication that can arise when discussing such a
complex issue piece by piece.
I would like to thank everyone again for their contributions.
On Tuesday, 27 August 2013 11:04:42 UTC-4, Nick wrote:
>
> Has anyone considered using "auto" as a qualifier to specify that a
> function is a property?
>
> The D programming language uses a similar approach, except that
> "@property" is used in front of the function. The "property" keyword is
> already in use in Objective-C++ and CLI, so instead, the auto keyword could
> be used as a qualifier.
>
> I remember reading a paper somewhere that suggested something similar to
> this, but it used a new keyword "implicit" in place of auto. I believe this
> still clear enough, and avoids the need for another keyword.
>
> class Test
> {
> int _number;
> std::pair<int, int> _twoNumbers;
> public:
> // getter
> int number() auto {
> return _number;
> }
>
> // setter
> int number(int number) auto {
> return _number = number;
> }
>
> // getter by reference
> const pair<int, int> &twoNumbers() const auto {
> return _twoNumbers;
> }
>
> // setter
> const pair<int, int> &twoNumbers(const pair<int, int> &tn) auto {
> return (_twoNumbers = tn);
> }
> };
>
>
> /////////////////////////
> Test test;
>
>
> test.number = 5;
> //same as: test.number(5);
>
>
> int a = test.number;
> // same as: int a = test.number();
>
>
> test.number += 5;
> // same as: test.number( test.number() + 5 );
>
>
> int a = 1 + test.number + 3;
> // same as: int a = 1 + test.number() + 3;
>
>
> cout << number.twoNumbers.first << endl;
> // same as: cout << number.twoNumbers().first << endl;
>
>
--
---
You received this message because you are 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_5027_33094179.1378260005680
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"> I have to say, I am surprised at the overall lack o=
f enthusiasm for this idea.<div><br></div><div> I think implicitly ca=
llable functions have great potential as a language feature, especially con=
sidering that they can be implemented in a completely backward, non-breakin=
g way. I think that the argument about the "hidden complexity" of propertie=
s would turn out to be completely unfounded if their real use cases were ex=
amined objectively, and that any concerns about their negative impact on co=
de coherency could easily be put to rest, given a sufficiently detailed spe=
cification of their behavior.<div><br></div><div> I plan to write a d=
raft specifying the details of implicitly callable functions, their semanti=
cs, their alternatives, and an analysis of some common use cases. I wouldn'=
t feel like I had given this idea a fair shake without removing the complic=
ation that can arise when discussing such a complex issue piece by piece.<b=
r><div><div><br></div><div> I would like to thank everyone again for =
their contributions.</div><div><br></div><div><br><br>On Tuesday, 27 August=
2013 11:04:42 UTC-4, Nick 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>Has anyone considered using "auto" as a qualifi=
er to specify that a function is a property?<br></div><div><br></div><div>T=
he D programming language uses a similar approach, except that "@property" =
is used in front of the function. The "property" keyword is already i=
n use in Objective-C++ and CLI, so instead, the auto keyword could be used =
as a qualifier.<div><br></div><div>I remember reading a paper somewhere tha=
t suggested something similar to this, but it used a new keyword "implicit"=
in place of auto. I believe this still clear enough, and avoids the need f=
or another keyword.</div><div><br></div><div><div style=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">class</span><span style=3D"color:#000"=
> </span><span style=3D"color:#606">Test</span><span style=3D"color:#000"><=
br></span><span style=3D"color:#660">{</span><span style=3D"color:#000"><br=
> </span><span style=3D"color:#008">int</span><span style=3D"c=
olor:#000"> _number</span><span style=3D"color:#660">;</span><span style=3D=
"color:#000"><br> std</span><span style=3D"color:#660">::</spa=
n><span style=3D"color:#000">pair</span><span style=3D"color:#660"><</sp=
an><span style=3D"color:#008">int</span><span style=3D"color:#660">,</span>=
<span style=3D"color:#000"> </span><span style=3D"color:#008">int</span><sp=
an style=3D"color:#660">></span><span style=3D"color:#000"> _twoNumbers<=
/span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br></s=
pan><span style=3D"color:#008">public</span><span style=3D"color:#660">:</s=
pan><span style=3D"color:#000"><br> </span><span style=3D"colo=
r:#800">// getter</span><span style=3D"color:#000"><br> </span=
><span style=3D"color:#008">int</span><span style=3D"color:#000"> number</s=
pan><span style=3D"color:#660">()</span><span style=3D"color:#000"> </span>=
<span style=3D"color:#008">auto</span><span style=3D"color:#000"> </span><s=
pan style=3D"color:#660">{</span><span style=3D"color:#000"><br> &nbs=
p; </span><span style=3D"color:#008">return</span><span style=
=3D"color:#000"> _number</span><span style=3D"color:#660">;</span><span sty=
le=3D"color:#000"><br> </span><span style=3D"color:#660">}</sp=
an><span style=3D"color:#000"><br> <br> </span><s=
pan style=3D"color:#800">// setter</span><span style=3D"color:#000"><br>&nb=
sp; </span><span style=3D"color:#008">int</span><span style=3D"color=
:#000"> number</span><span style=3D"color:#660">(</span><span style=3D"colo=
r:#008">int</span><span style=3D"color:#000"> number</span><span style=3D"c=
olor:#660">)</span><span style=3D"color:#000"> </span><span style=3D"color:=
#008">auto</span><span style=3D"color:#000"> </span><span style=3D"color:#6=
60">{</span><span style=3D"color:#000"><br> </sp=
an><span style=3D"color:#008">return</span><span style=3D"color:#000"> _num=
ber </span><span style=3D"color:#660">=3D</span><span style=3D"color:#000">=
number</span><span style=3D"color:#660">;</span><span style=3D"color:#000"=
><br> </span><span style=3D"color:#660">}</span><span style=3D=
"color:#000"><br> <br> </span><span style=3D"colo=
r:#800">// getter by reference</span><span style=3D"color:#000"><br> =
</span><span style=3D"color:#008">const</span><span style=3D"color:#=
000"> pair</span><span style=3D"color:#660"><</span><span style=3D"color=
:#008">int</span><span style=3D"color:#660">,</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#008">int</span><span style=3D"color:#660"=
>></span><span style=3D"color:#000"> </span><span style=3D"color:#660">&=
amp;</span><span style=3D"color:#000">twoNumbers</span><span style=3D"color=
:#660">()</span><span style=3D"color:#000"> </span><span style=3D"color:#00=
8">const</span><span style=3D"color:#000"> </span><span style=3D"color:#008=
">auto</span><span style=3D"color:#000"> </span><span style=3D"color:#660">=
{</span><span style=3D"color:#000"><br> </span><=
span style=3D"color:#008">return</span><span style=3D"color:#000"> _twoNumb=
ers</span><span style=3D"color:#660">;</span><span style=3D"color:#000"><br=
> </span><span style=3D"color:#660">}</span><span style=3D"col=
or:#000"><br> <br> </span><span style=3D"color:#8=
00">// setter</span><span style=3D"color:#000"><br> </span><sp=
an style=3D"color:#008">const</span><span style=3D"color:#000"> pair</span>=
<span style=3D"color:#660"><</span><span style=3D"color:#008">int</span>=
<span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><span=
style=3D"color:#008">int</span><span style=3D"color:#660">></span><span=
style=3D"color:#000"> </span><span style=3D"color:#660">&</span><span =
style=3D"color:#000">twoNumbers</span><span style=3D"color:#660">(</span><s=
pan style=3D"color:#008">const</span><span style=3D"color:#000"> pair</span=
><span style=3D"color:#660"><</span><span style=3D"color:#008">int</span=
><span style=3D"color:#660">,</span><span style=3D"color:#000"> </span><spa=
n style=3D"color:#008">int</span><span style=3D"color:#660">></span><spa=
n style=3D"color:#000"> </span><span style=3D"color:#660">&</span><span=
style=3D"color:#000">tn</span><span style=3D"color:#660">)</span><span sty=
le=3D"color:#000"> </span><span style=3D"color:#008">auto</span><span style=
=3D"color:#000"> </span><span style=3D"color:#660">{</span><span style=3D"c=
olor:#000"><br> </span><span style=3D"color:#008=
">return</span><span style=3D"color:#000"> </span><span style=3D"color:#660=
">(</span><span style=3D"color:#000">_twoNumbers </span><span style=3D"colo=
r:#660">=3D</span><span style=3D"color:#000"> tn</span><span style=3D"color=
:#660">);</span><span style=3D"color:#000"><br> </span><span s=
tyle=3D"color:#660">}</span><span style=3D"color:#000"><br></span><span sty=
le=3D"color:#660">};</span><span style=3D"color:#000"><br><br><br></span><s=
pan style=3D"color:#800">/////////////////////////</span><span style=3D"col=
or:#000"><br></span><span style=3D"color:#606">Test</span><span style=3D"co=
lor:#000"> test</span><span style=3D"color:#660">;</span><span style=3D"col=
or:#000"><br><br><br>test</span><span style=3D"color:#660">.</span><span st=
yle=3D"color:#000">number </span><span style=3D"color:#660">=3D</span><span=
style=3D"color:#000"> </span><span style=3D"color:#066">5</span><span styl=
e=3D"color:#660">;</span><span style=3D"color:#000"><br></span><span style=
=3D"color:#800">//same as: test.number(5);</span><span style=3D"color=
:#000"><br><br><br></span><span style=3D"color:#008">int</span><span style=
=3D"color:#000"> a </span><span style=3D"color:#660">=3D</span><span style=
=3D"color:#000"> test</span><span style=3D"color:#660">.</span><span style=
=3D"color:#000">number</span><span style=3D"color:#660">;</span><span style=
=3D"color:#000"><br></span><span style=3D"color:#800">// same as: int=
a =3D test.number();</span><span style=3D"color:#000"><br><br><br>test</sp=
an><span style=3D"color:#660">.</span><span style=3D"color:#000">number </s=
pan><span style=3D"color:#660">+=3D</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#066">5</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#800">// same as: &=
nbsp;test.number( test.number() + 5 );</span><span style=3D"color:#000"><br=
><br><br></span><span style=3D"color:#008">int</span><span style=3D"color:#=
000"> a </span><span style=3D"color:#660">=3D</span><span style=3D"color:#0=
00"> </span><span style=3D"color:#066">1</span><span style=3D"color:#000"> =
</span><span style=3D"color:#660">+</span><span style=3D"color:#000"> test<=
/span><span style=3D"color:#660">.</span><span style=3D"color:#000">number =
</span><span style=3D"color:#660">+</span><span style=3D"color:#000"> </spa=
n><span style=3D"color:#066">3</span><span style=3D"color:#660">;</span><sp=
an style=3D"color:#000"><br></span><span style=3D"color:#800">// same as: &=
nbsp;int a =3D 1 + test.number() + 3;</span><span style=3D"color:#000"><br>=
<br><br>cout </span><span style=3D"color:#660"><<</span><span style=
=3D"color:#000"> number</span><span style=3D"color:#660">.</span><span styl=
e=3D"color:#000">twoNumbers</span><span style=3D"color:#660">.</span><span =
style=3D"color:#000">first </span><span style=3D"color:#660"><<</span=
><span style=3D"color:#000"> endl</span><span style=3D"color:#660">;</span>=
<span style=3D"color:#000"><br></span><span style=3D"color:#800">// same as=
: cout << number.twoNumbers().first << endl;</span></div>=
</code></div><div><br></div></div></div></div></blockquote></div></div></di=
v></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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_5027_33094179.1378260005680--
.
Author: stackmachine@hotmail.com
Date: Wed, 4 Sep 2013 00:06:10 -0700 (PDT)
Raw View
------=_Part_3119_32344481.1378278370889
Content-Type: text/plain; charset=ISO-8859-1
Can we please name a property what it is - a *property*? I honestly don't
care about other languages, C++ is not Objective-anything or CLI. I do not
see any reason to use auto or any other new keyword.Those languages aren't
compatible with C++ - neither should 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/.
------=_Part_3119_32344481.1378278370889
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Can we please name a property what it is - a *property*? I=
honestly don't care about other languages, C++ is not Objective-anything o=
r CLI. I do not see any reason to use auto or any other new keyword.Those l=
anguages aren't compatible with C++ - neither should C++.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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_3119_32344481.1378278370889--
.
Author: =?UTF-8?Q?Klaim_=2D_Jo=C3=ABl_Lamotte?= <mjklaim@gmail.com>
Date: Wed, 4 Sep 2013 10:40:53 +0200
Raw View
--089e0122aa246ef99804e58ac3fd
Content-Type: text/plain; charset=ISO-8859-1
On Wed, Sep 4, 2013 at 9:06 AM, <stackmachine@hotmail.com> wrote:
> Can we please name a property what it is - a *property*? I honestly don't
> care about other languages, C++ is not Objective-anything or CLI. I do not
> see any reason to use auto or any other new keyword.Those languages aren't
> compatible with C++ - neither should C++.
>
> --
>
"Properties" often use a specific syntax, here Nick is talking really
about only allowing functions to be implicitely callable, nothing more.
"properties" suggests more.
Joel Lamotte
--
---
You received this message because you are 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/.
--089e0122aa246ef99804e58ac3fd
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On Wed, Sep 4, 2013 at 9:06 AM, <span dir=3D"ltr"><<a href=3D"m=
ailto:stackmachine@hotmail.com" target=3D"_blank">stackmachine@hotmail.com<=
/a>></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">Can we please name a proper=
ty what it is - a *property*? I honestly don't care about other languag=
es, C++ is not Objective-anything or CLI. I do not see any reason to use au=
to or any other new keyword.Those languages aren't compatible with C++ =
- neither should C++.<br>
</div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
--=A0</div></div></blockquote><div><br></div><div><br></div><div>"Prop=
erties" =A0often use a specific syntax, here Nick is talking really ab=
out only allowing functions to be implicitely callable, nothing more.</div>
<div>"properties" suggests more.<br><br>Joel Lamotte</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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
--089e0122aa246ef99804e58ac3fd--
.