Topic: properties?
Author: Evan Teran <evan.teran@gmail.com>
Date: Wed, 9 Aug 2017 10:32:28 -0700 (PDT)
Raw View
------=_Part_5635_1439829336.1502299948753
Content-Type: multipart/alternative;
boundary="----=_Part_5636_195812855.1502299948754"
------=_Part_5636_195812855.1502299948754
Content-Type: text/plain; charset="UTF-8"
I never brought it up before because I assumed that it MUST have been
discussed in the past... but a search turns up nothing. Is there any
thoughts about introducing properties to classes/structs/unions? Like
lambdas, I kinda envision them as syntactic sugar for public member
variables which overload cast operators and operator=. I can imagine
something like this (forgive adhoc syntax I'm making up on the spot..., I
think that the specific syntax is less important than whether or not the
feature is desirable)
class T {
public:
[[property]] int data = [ read_data, write_data ];
public:
int read_data() const { return data_; }
void write_data(int n) { data_ = n; }
private:
int data_;
};
Not pretty, but I suspect that we can come up with something better. The
idea is that this would be roughly equivalent to the following code:
class T {
public:
struct data_impl {
T& operator=(int n) {
self->write_data(n);
return *self;
}
operator int() const {
return self->read_data();
}
T *self;
} data = { this };
public:
int read_data() const { return data_; }
void write_data(int n) { data_ = n; }
private:
int data_;
};
The idea being of course that this makes code such as the following valid:
T value;
value.data = 10;
std::cout << value.data << "\n"
I can imagine a few benefits for properties:
1. If we encourage the use of properties over named getters and setters,
then it makes long term maintenance of code simpler with better API
stability. We can write code initially just using public member syntax if
there is no need for special handling on reading or writing of the member.
If the need ever arises to have special handling during read or write, then
it the code only needs to change in the class itself. The code which uses
it need not change at all (obvious exceptions involving taking the address
of a member, but taking the address of a property could just be a hard
error since it doesn't make much sense in the typical case).
2. Can replace a lot of uses of bifields which often result in undefined
or platform specific behaviors. A user could create properties which
represent each bit and can do the masking themselves to ensure in a
reliable way that the bits they intend to work with are the ones which
actually get used regardless of endian issues.
Like I said, I'm less interesting in the bikeshedding of syntax concerns,
but more interested in the relative merits and concerns with this type of
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.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/6ed2bd55-5538-418f-8f1a-263a9958babd%40isocpp.org.
------=_Part_5636_195812855.1502299948754
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I never brought it up before because I assumed that it MUS=
T have been discussed in the past... but a search turns up nothing. Is ther=
e any thoughts about introducing properties to classes/structs/unions? Like=
lambdas, I kinda envision them as syntactic sugar for public member variab=
les which overload cast operators and operator=3D. I can imagine something =
like this (forgive adhoc syntax I'm making up on the spot..., I think t=
hat the specific syntax is less important than whether or not the feature i=
s desirable)<div><br><div class=3D"prettyprint" style=3D"background-color: =
rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; =
border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div=
class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">class</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"><br></span><span s=
tyle=3D"color: #008;" 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>=C2=A0 =C2=A0 </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">[[</span><span style=3D"colo=
r: #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"> </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">int</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> data </span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">[</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> read_data</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span st=
yle=3D"color: #000;" class=3D"styled-by-prettify"> write_data </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">public</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>=C2=A0 =C2=A0 </span><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">int</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> read_data</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">()</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </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"> </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: #008;" class=3D"styled-by-prettify">return</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> data_</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"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">void</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> write_data</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">int</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> n</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"> data_ </span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">private=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">int</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> data_</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>=
<br>Not pretty, but I suspect that we can come up with something better. Th=
e idea is that this would be roughly equivalent to the following code:<br><=
br></div></div><div><br><div class=3D"prettyprint" style=3D"background-colo=
r: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: soli=
d; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><=
div class=3D"subprettyprint"><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">class</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"><br></span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">public</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">:</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">struct</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> data_impl </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">{</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 T</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">&</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">operator</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">=3D(</span><span style=3D"co=
lor: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">)</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><=
br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #=
008;" class=3D"styled-by-prettify">self</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">write_data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">n</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" 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-b=
y-prettify">self</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"><br>=C2=A0 =C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">operator</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D=
"styled-by-prettify">int</span><span style=3D"color: #660;" class=3D"styled=
-by-prettify">()</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">con=
st</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">{</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">return</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">se=
lf</span><span style=3D"color: #660;" class=3D"styled-by-prettify">-></s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify">read_data</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify">();</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=
=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 T </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">*</span><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">self</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>}</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> data </=
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: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">this</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br></span><span style=3D"color: #008;" 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>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> read_data=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">()</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">const</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">{</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"styl=
ed-by-prettify">return</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> data_</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: #660;" class=3D"styled-by-prettify">}</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 <=
/span><span style=3D"color: #008;" class=3D"styled-by-prettify">void</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> write_data</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">int</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> n</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">)</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> data_ </span><span style=3D"color: #660;" class=3D"styled-by-prett=
ify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> n=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</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></span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">private</span><span style=3D"color: #660;" =
class=3D"styled-by-prettify">:</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">int</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> data_</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></span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">};</span></div></code></div><br><div>The idea being of course that this m=
akes code such as the following valid:<br><br></div></div><div class=3D"pre=
ttyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(=
187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-wo=
rd;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #000;" class=3D"styled-by-prettify">=C2=A0 =C2=A0 T value</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 value</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">.</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">data </span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">10</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"><br>=C2=A0 =C2=A0 std</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify">cout </span><span style=3D"color: #660;" class=3D"styled-=
by-prettify"><<</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> value</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">da=
ta </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: #080;" class=3D"styled-by-prettify">"\n"</sp=
an></div></code></div><div><br></div><div>I can imagine a few benefits for =
properties:<br><br><ol><li>If we encourage the use of properties over named=
getters and setters, then it makes long term maintenance of code simpler w=
ith better API stability. We can write code initially just using public mem=
ber syntax if there is no need for special handling on reading or writing o=
f the member. If the need ever arises to have special handling during read =
or write, then it the code only needs to change in the class itself. The co=
de which uses it need not change at all (obvious exceptions involving takin=
g the address of a member, but taking the address of a property could just =
be a hard error since it doesn't make much sense in the typical case).<=
/li><li>Can replace a lot of uses of bifields which often result in undefin=
ed or platform specific behaviors. A user could create properties which rep=
resent each bit and can do the masking themselves to ensure in a reliable w=
ay that the bits they intend to work with are the ones which actually get u=
sed regardless of endian issues.</li></ol><div>Like I said, I'm less in=
teresting in the bikeshedding of syntax concerns, but more interested in th=
e relative merits and concerns with this type of feature.</div></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/6ed2bd55-5538-418f-8f1a-263a9958babd%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/6ed2bd55-5538-418f-8f1a-263a9958babd=
%40isocpp.org</a>.<br />
------=_Part_5636_195812855.1502299948754--
------=_Part_5635_1439829336.1502299948753--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Wed, 9 Aug 2017 13:59:20 -0400
Raw View
On 2017-08-09 13:32, Evan Teran wrote:
> I never brought it up before because I assumed that it MUST have been
> discussed in the past...
It has. To death. Properties are contentious.
(Nicol and I came up with something maybe a year ago that seemed
plausible and had additional benefits, but I don't know if it ever got
written up...)
> but a search turns up nothing.
Um...
https://groups.google.com/a/isocpp.org/forum/#!searchin/std-proposals/properties%7Csort:relevance
> I think that the specific syntax is less important than whether or
> not the feature is desirable)
A number of folks seem to be interested, but the implementation seems to
be contentious, from what I recall.
> [[property]] int data = [ read_data, write_data ];
FWIW, I'm pretty sure this syntax won't fly. Also, while there are
significant advantages to this simplistic approach, I'm sure some folks
will complain (loudly) that it requires the get/set functions are still
direct members of the class, and there may be difficulties knowing which
one to call when.
Do please also read the inline class threads...
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/10557c71-2b0f-6675-305e-1267eeda1ed6%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 9 Aug 2017 13:20:11 -0700 (PDT)
Raw View
------=_Part_155_2040492007.1502310011167
Content-Type: multipart/alternative;
boundary="----=_Part_156_1543909948.1502310011167"
------=_Part_156_1543909948.1502310011167
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 9, 2017 at 1:59:24 PM UTC-4, Matthew Woehlke wrote:
>
> On 2017-08-09 13:32, Evan Teran wrote:
> > I never brought it up before because I assumed that it MUST have been
> > discussed in the past...
>
> It has. To death. Properties are contentious.
>
> (Nicol and I came up with something maybe a year ago that seemed
> plausible and had additional benefits, but I don't know if it ever got
> written up...)
>
I poked around with the ideas for a while. The basic idea was to provide 3
independently-useful features that, when combined, would allow you to
develop a zero-overhead, low-boilerplate library implementation of
properties. Those features being stateless member subobjects
<https://github.com/NicolBolas/Proposal-Ideas/blob/master/Stateless%20Subobjects.md>(so
that the property would just be a member), inner classes (so that the
property could just be an inner class, which would have access to its
owning subobject, no matter where it was), and language-support for
CRTP-base class (so that you could write the implementation of the inner
class outside of the inner class itself, and thus reuse boilerplate).
My biggest stumbling block was the latter. I realized that I was basically
creating "mixins," but though inheritance. The problem there is that the
derived class is incomplete until the template instantiation of the base
class, so the CRTP-base class can only access features of the derived class
within functions. That made doing simple things like iterator traits
impossible without some external class (like `iterator_traits`).
So if I wanted to do mixins without a bunch of arbitrary limitations,
they'd need to not just be some base class using template trickery, but a
true, first-class feature that was separate from template instantiation.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/cd0988be-8dc0-43be-96b1-94ec6f8e5e91%40isocpp.org.
------=_Part_156_1543909948.1502310011167
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>On Wednesday, August 9, 2017 at 1:59:24 PM UTC-4, =
Matthew Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-=
08-09 13:32, Evan Teran wrote:
<br>> I never brought it up before because I assumed that it MUST have b=
een=20
<br>> discussed in the past...
<br>
<br>It has. To death. Properties are contentious.
<br>
<br>(Nicol and I came up with something maybe a year ago that seemed
<br>plausible and had additional benefits, but I don't know if it ever =
got
<br>written up...)
<br></blockquote><div><br>I poked around with the ideas for a while. The ba=
sic idea was to provide 3 independently-useful features that, when combined=
, would allow you to develop a zero-overhead, low-boilerplate library imple=
mentation of properties. Those features being <a href=3D"https://github.com=
/NicolBolas/Proposal-Ideas/blob/master/Stateless%20Subobjects.md">stateless=
member subobjects </a>(so that the property would just be a member), inner=
classes (so that the property could just be an inner class, which would ha=
ve access to its owning subobject, no matter where it was), and language-su=
pport for CRTP-base class (so that you could write the implementation of th=
e inner class outside of the inner class itself, and thus reuse boilerplate=
).<br><br>My biggest stumbling block was the latter. I realized that I was =
basically creating "mixins," but though inheritance. The problem =
there is that the derived class is incomplete until the template instantiat=
ion of the base class, so the CRTP-base class can only access features of t=
he derived class within functions. That made doing simple things like itera=
tor traits impossible without some external class (like `iterator_traits`).=
<br><br>So if I wanted to do mixins without a bunch of arbitrary limitation=
s, they'd need to not just be some base class using template trickery, =
but a true, first-class feature that was separate from template instantiati=
on.<br></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/cd0988be-8dc0-43be-96b1-94ec6f8e5e91%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/cd0988be-8dc0-43be-96b1-94ec6f8e5e91=
%40isocpp.org</a>.<br />
------=_Part_156_1543909948.1502310011167--
------=_Part_155_2040492007.1502310011167--
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Wed, 9 Aug 2017 16:33:09 -0700 (PDT)
Raw View
------=_Part_282_1985881465.1502321590044
Content-Type: multipart/alternative;
boundary="----=_Part_283_1648129789.1502321590044"
------=_Part_283_1648129789.1502321590044
Content-Type: text/plain; charset="UTF-8"
Just read Metaclasses
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r1.pdf> ;)
than see if you get some ideas...
BR
Cleiton
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/335aacaa-9c3e-4d77-9495-97ffa7cb0307%40isocpp.org.
------=_Part_283_1648129789.1502321590044
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><br></div><div>Just read=C2=A0<a href=3D"http://www.o=
pen-std.org/jtc1/sc22/wg21/docs/papers/2017/p0707r1.pdf">Metaclasses</a>=C2=
=A0;) than see if you get some ideas...</div><div><br></div><div><br></div>=
<div>BR</div><div>Cleiton</div><div><br></div><br></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/335aacaa-9c3e-4d77-9495-97ffa7cb0307%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/335aacaa-9c3e-4d77-9495-97ffa7cb0307=
%40isocpp.org</a>.<br />
------=_Part_283_1648129789.1502321590044--
------=_Part_282_1985881465.1502321590044--
.
Author: Bo Persson <bop@gmb.dk>
Date: Thu, 10 Aug 2017 04:12:12 +0200
Raw View
On 2017-08-09 19:32, Evan Teran wrote:
> I never brought it up before because I assumed that it MUST have been
> discussed in the past...
Oh, yeah...
>
> The idea being of course that this makes code such as the following valid:
>
> |
> T value;
> value.data =10;
> std::cout <<value.data <<"\n"
> |
>
This could already work if you just add () to each use of data. :-)
> I can imagine a few benefits for properties:
>
> 1. If we encourage the use of properties over named getters and
> setters, then it makes long term maintenance of code simpler with
> better API stability. We can write code initially just using public
> member syntax if there is no need for special handling on reading or
> writing of the member. If the need ever arises to have special
> handling during read or write, then it the code only needs to change
> in the class itself. The code which uses it need not change at all
> (obvious exceptions involving taking the address of a member, but
> taking the address of a property could just be a hard error since it
> doesn't make much sense in the typical case).
A counter argument here is that adding "special handling", like
validating the assigned value, IS an API change.
Adding LOTS of processing changes the runtime characteristics of the
code, which could also be considered an API change.
> 2. Can replace a lot of uses of bifields which often result in
> undefined or platform specific behaviors. A user could create
> properties which represent each bit and can do the masking
> themselves to ensure in a reliable way that the bits they intend to
> work with are the ones which actually get used regardless of endian
> issues.
>
This offers a solution to a problem I have never had.
Bo Persson
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/omgfdk%24pkv%241%40blaine.gmane.org.
.
Author: Evan Teran <evan.teran@gmail.com>
Date: Wed, 9 Aug 2017 22:02:15 -0700 (PDT)
Raw View
------=_Part_506_1756726524.1502341335571
Content-Type: multipart/alternative;
boundary="----=_Part_507_1391265353.1502341335571"
------=_Part_507_1391265353.1502341335571
Content-Type: text/plain; charset="UTF-8"
Hmm, I don't know why when i typed "properties" into the search it came up
empty, maybe an unlucky network quirk :-/. Regardless, I see them now, and
yes, it does seem that they have been discussed numerous times in many
different ways.
@Matthew, yea, I was fairly certain that the syntax was not viable, only
used it for illustrative purposes. I am certain that better syntax could be
developed that would be more robust. I will certainly take a look at
discussing involving inline classes. That's for the pointer on that one.
@Nicol, sounds interesting. If inner classes allow a library solution, that
sounds great. I've toyed with some library solutions, but at the moment, it
takes a bunch of macro usage to make them remotely "pretty".
@Bo, Yes, Of course I could just add the () and they'll "just work". it is
true that this is just syntax. But I think better syntax is sometimes a
worthy goal if it makes the code better. I see what you are saying about
changing the performance characteristics of "reading a member" would be
viewed as an API change. I do however think it's a matter of perspective.
Any function or method can become arbitrarily more complex between
versions; if the way to use it remains the same, and the result is
effectively the same, then I would at least call it "compatible" with the
previous API. Sure, it's different, if it's more expensive but it is
conceptually compatible. I'd leave it to the library writers to inform
users if there is a catastrophic change in performance.
As for the bitfield replacements, I understand that it's not a problem that
you've encountered, but when dealing with (or emulating) hardware it can be
a concern. I need a specific bit to be set, and I'd love to give it a name,
so the code is nice and readable. But it's quite easy to fall into the land
of compiler specific or arch specific behaviors. It would be nice if I had
the ability to do this portable between compilers and compiler versions.
Anyway.
Bottom line is that I see that this has been discussed... a lot. And I have
a lot of reading to do if I am wanting to have a change of making an
informed contribution to the discussion.
Thanks for humoring my post.
Evan
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d4dae6fc-5a58-48be-a7a3-cd2496a470a1%40isocpp.org.
------=_Part_507_1391265353.1502341335571
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hmm, I don't know why when i typed "properties&qu=
ot; into the search it came up empty, maybe an unlucky network quirk :-/. R=
egardless, I see them now, and yes, it does seem that they have been discus=
sed numerous times in many different ways.<br><br>@Matthew, yea, I was fair=
ly certain that the syntax was not viable, only used it for illustrative pu=
rposes. I am certain that better syntax could be developed that would be mo=
re robust. I will certainly take a look at discussing involving inline clas=
ses. That's for the pointer on that one.<br><br>@Nicol, sounds interest=
ing. If inner classes allow a library solution, that sounds great. I've=
toyed with some library solutions, but at the moment, it takes a bunch of =
macro usage to make them remotely "pretty".<br><br>@Bo, Yes, Of c=
ourse I could just add the () and they'll "just work". it is =
true that this is just syntax. But I think better syntax is sometimes a wor=
thy goal if it makes the code better. I see what you are saying about chang=
ing the performance characteristics of "reading a member" would b=
e viewed as an API change. I do however think it's a matter of perspect=
ive. Any function or method can become arbitrarily more complex between ver=
sions; if the way to use it remains the same, and the result is effectively=
the same, then I would at least call it "compatible" with the pr=
evious API. Sure, it's different, if it's more expensive but it is =
conceptually compatible. I'd leave it to the library writers to inform =
users if there is a catastrophic change in performance.<br><br>As for the b=
itfield replacements, I understand that it's not a problem that you'=
;ve encountered, but when dealing with (or emulating) hardware it can be a =
concern. I need a specific bit to be set, and I'd love to give it a nam=
e, so the code is nice and readable. But it's quite easy to fall into t=
he land of compiler specific or arch specific behaviors. It would be nice i=
f I had the ability to do this portable between compilers and compiler vers=
ions.<br><br>Anyway.<br><br>Bottom line is that I see that this has been di=
scussed... a lot. And I have a lot of reading to do if I am wanting to have=
a change of making an informed contribution to the discussion.<div><br></d=
iv><div>Thanks for humoring my post.</div><div>Evan</div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d4dae6fc-5a58-48be-a7a3-cd2496a470a1%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d4dae6fc-5a58-48be-a7a3-cd2496a470a1=
%40isocpp.org</a>.<br />
------=_Part_507_1391265353.1502341335571--
------=_Part_506_1756726524.1502341335571--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Wed, 9 Aug 2017 23:19:00 -0700 (PDT)
Raw View
------=_Part_471_293108276.1502345940075
Content-Type: multipart/alternative;
boundary="----=_Part_472_752484452.1502345940076"
------=_Part_472_752484452.1502345940076
Content-Type: text/plain; charset="UTF-8"
On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Persson wrote:
>
> On 2017-08-09 19:32, Evan Teran wrote:
> > I never brought it up before because I assumed that it MUST have been
> > discussed in the past...
>
> Oh, yeah...
>
> >
> > The idea being of course that this makes code such as the following
> valid:
> >
> > |
> > T value;
> > value.data =10;
> > std::cout <<value.data <<"\n"
> > |
> >
>
> This could already work if you just add () to each use of data. :-)
>
Would it? Would this:
some_function(value.data());
Would that allow `some_function` to set `data`'s value? To do that, you
would need to make `data()` return a proxy object, which can be converted
into the appropriate type, but can also be assigned to the appropriate type
and otherwise treated exactly like a reference to the other type.
That's hardly "just" adding something.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/9979b017-fc21-445f-a1d1-0f55f8e7bf3d%40isocpp.org.
------=_Part_472_752484452.1502345940076
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Pers=
son wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-09 19:32,=
Evan Teran wrote:
<br>> I never brought it up before because I assumed that it MUST have b=
een=20
<br>> discussed in the past...=20
<br>
<br>Oh, yeah...
<br>
<br>>=20
<br>> The idea being of course that this makes code such as the followin=
g valid:
<br>>=20
<br>> |
<br>> =C2=A0 =C2=A0 =C2=A0T value;
<br>> =C2=A0 =C2=A0 =C2=A0value.data =3D10;
<br>> =C2=A0 =C2=A0 =C2=A0std::cout <<value.data <<"\n&=
quot;
<br>> |
<br>>
<br>
<br>This could already work if you just add () to each use of data. =C2=A0:=
-)<br></blockquote><div><br>Would it? Would this:<br><br><div style=3D"back=
ground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-=
style: solid; border-width: 1px; overflow-wrap: break-word;" class=3D"prett=
yprint"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify">some_function</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify">value</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify">data</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">());</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span></div></code></div><br>Would that allow `some_=
function` to set `data`'s value? To do that, you would need to make `da=
ta()` return a proxy object, which can be converted into the appropriate ty=
pe, but can also be assigned to the appropriate type and otherwise treated =
exactly like a reference to the other type.<br><br>That's hardly "=
just" adding something.</div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/9979b017-fc21-445f-a1d1-0f55f8e7bf3d%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9979b017-fc21-445f-a1d1-0f55f8e7bf3d=
%40isocpp.org</a>.<br />
------=_Part_472_752484452.1502345940076--
------=_Part_471_293108276.1502345940075--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 09:35:15 +0300
Raw View
On 10 August 2017 at 09:19, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Persson wrote:
>>
>> On 2017-08-09 19:32, Evan Teran wrote:
>> > I never brought it up before because I assumed that it MUST have been
>> > discussed in the past...
>>
>> Oh, yeah...
>>
>> >
>> > The idea being of course that this makes code such as the following
>> > valid:
>> >
>> > |
>> > T value;
>> > value.data =10;
>> > std::cout <<value.data <<"\n"
>> > |
>> >
>>
>> This could already work if you just add () to each use of data. :-)
>
>
> Would it? Would this:
>
> some_function(value.data());
>
> Would that allow `some_function` to set `data`'s value? To do that, you
> would need to make `data()` return a proxy object, which can be converted
> into the appropriate type, but can also be assigned to the appropriate type
> and otherwise treated exactly like a reference to the other type.
>
> That's hardly "just" adding something.
Gee, data() could just return a reference.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUadaK3Dz_EgKMCp%3DUP84-VgZHtjnPaRn4yZTnADgUqgnQ%40mail.gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 10 Aug 2017 10:05:12 -0400
Raw View
On 2017-08-10 02:35, Ville Voutilainen wrote:
> On 10 August 2017 at 09:19, Nicol Bolas <jmckesson@gmail.com> wrote:
>> On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Persson wrote:
>>> On 2017-08-09 19:32, Evan Teran wrote:
>>>> std::cout <<value.data <<"\n"
>>>
>>> This could already work if you just add () to each use of data. :-)
>>
>> Would it? Would this:
>>
>> some_function(value.data());
>>
>> Would that allow `some_function` to set `data`'s value? To do that, you
>> would need to make `data()` return a proxy object, which can be converted
>> into the appropriate type, but can also be assigned to the appropriate type
>> and otherwise treated exactly like a reference to the other type.
>>
>> That's hardly "just" adding something.
>
> Gee, data() could just return a reference.
....which is only possible if it is okay for the user to directly assign
to the underlying data member. If something non-trivial needs to happen
when the property is assigned, then no, you'd need to return a proxy
object. (And, alas, some_function would need to be a template.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/3784a92f-9045-e0e8-df9f-51a68f66ac99%40gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 10 Aug 2017 10:08:46 -0400
Raw View
On 2017-08-09 16:20, Nicol Bolas wrote:
> On Wednesday, August 9, 2017 at 1:59:24 PM UTC-4, Matthew Woehlke wrote:
>> On 2017-08-09 13:32, Evan Teran wrote:
> I poked around with the ideas for a while. The basic idea was to
> provide 3 independently-useful features [...] stateless member
> subobjects [...] inner classes [...] and language-support for
> CRTP-base class (so that you could write the implementation of the
> inner class outside of the inner class itself, and thus reuse
> boilerplate).>
> My biggest stumbling block was the latter. I realized that I was basically
> creating "mixins," but though inheritance. The problem there is that the
> derived class is incomplete until the template instantiation of the base
> class, so the CRTP-base class can only access features of the derived class
> within functions. That made doing simple things like iterator traits
> impossible without some external class (like `iterator_traits`).
>
> So if I wanted to do mixins without a bunch of arbitrary limitations,
> they'd need to not just be some base class using template trickery, but a
> true, first-class feature that was separate from template instantiation.
Ah. Of course, mixins are sufficiently wide-spread that figuring those
out is almost certainly worthwhile in its own right. (I've always
thought so, anyway.)
Maybe someone would be interested in taking up the torch on those?
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/05214462-9ca7-a5c8-018a-4a05faf02f7c%40gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 10 Aug 2017 07:18:13 -0700 (PDT)
Raw View
------=_Part_940_901225916.1502374693617
Content-Type: multipart/alternative;
boundary="----=_Part_941_1951000555.1502374693617"
------=_Part_941_1951000555.1502374693617
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 10, 2017 at 10:05:17 AM UTC-4, Matthew Woehlke wrote:
>
> On 2017-08-10 02:35, Ville Voutilainen wrote:
> > On 10 August 2017 at 09:19, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> >> On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Persson wrote:
> >>> On 2017-08-09 19:32, Evan Teran wrote:
> >>>> std::cout <<value.data <<"\n"
> >>>
> >>> This could already work if you just add () to each use of data. :-)
> >>
> >> Would it? Would this:
> >>
> >> some_function(value.data());
> >>
> >> Would that allow `some_function` to set `data`'s value? To do that, you
> >> would need to make `data()` return a proxy object, which can be
> converted
> >> into the appropriate type, but can also be assigned to the appropriate
> type
> >> and otherwise treated exactly like a reference to the other type.
> >>
> >> That's hardly "just" adding something.
> >
> > Gee, data() could just return a reference.
>
> ...which is only possible if it is okay for the user to directly assign
> to the underlying data member. If something non-trivial needs to happen
> when the property is assigned, then no, you'd need to return a proxy
> object. (And, alas, some_function would need to be a template.)
Not to mention that it assumes that there is actually an object behind
`data()` that could be returned as a reference. Many properties are
phantasmal; the actual data is not stored in the type it appears as.
Indeed, one could say that the whole point of properties as a feature are
that they *can be* phantasmal in such a way, without the user being aware
of their nature.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/ab000071-6881-487f-b507-bcd6d656bb52%40isocpp.org.
------=_Part_941_1951000555.1502374693617
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 10, 2017 at 10:05:17 AM UTC-4, Matthew=
Woehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2017-08-10 0=
2:35, Ville Voutilainen wrote:
<br>> On 10 August 2017 at 09:19, Nicol Bolas <<a href=3D"javascript:=
" target=3D"_blank" gdf-obfuscated-mailto=3D"bgI50Fh3BwAJ" rel=3D"nofollow"=
onmousedown=3D"this.href=3D'javascript:';return true;" onclick=3D"=
this.href=3D'javascript:';return true;">jmck...@gmail.com</a>> w=
rote:
<br>>> On Wednesday, August 9, 2017 at 10:12:36 PM UTC-4, Bo Persson =
wrote:
<br>>>> On 2017-08-09 19:32, Evan Teran wrote:
<br>>>>> =C2=A0 =C2=A0 =C2=A0std::cout <<value.data <&=
lt;"\n"
<br>>>>
<br>>>> This could already work if you just add () to each use of =
data. =C2=A0:-)
<br>>>
<br>>> Would it? Would this:
<br>>>
<br>>> some_function(value.data());
<br>>>
<br>>> Would that allow `some_function` to set `data`'s value? To=
do that, you
<br>>> would need to make `data()` return a proxy object, which can b=
e converted
<br>>> into the appropriate type, but can also be assigned to the app=
ropriate type
<br>>> and otherwise treated exactly like a reference to the other ty=
pe.
<br>>>
<br>>> That's hardly "just" adding something.
<br>>=20
<br>> Gee, data() could just return a reference.
<br>
<br>...which is only possible if it is okay for the user to directly assign
<br>to the underlying data member. If something non-trivial needs to happen
<br>when the property is assigned, then no, you'd need to return a prox=
y
<br>object. (And, alas, some_function would need to be a template.) </block=
quote><div><br>Not to mention that it assumes that there is actually an obj=
ect behind `data()` that could be returned as a reference. Many properties =
are phantasmal; the actual data is not stored in the type it appears as. In=
deed, one could say that the whole point of properties as a feature are tha=
t they <i>can be</i> phantasmal in such a way, without the user being aware=
of their nature.<br></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/ab000071-6881-487f-b507-bcd6d656bb52%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ab000071-6881-487f-b507-bcd6d656bb52=
%40isocpp.org</a>.<br />
------=_Part_941_1951000555.1502374693617--
------=_Part_940_901225916.1502374693617--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 10 Aug 2017 10:40:25 -0400
Raw View
On 2017-08-10 10:18, Nicol Bolas wrote:
> On Thursday, August 10, 2017 at 10:05:17 AM UTC-4, Matthew Woehlke wrote:
>> On 2017-08-10 02:35, Ville Voutilainen wrote:
>>> Gee, data() could just return a reference.
>>
>> ...which is only possible if it is okay for the user to directly assign
>> to the underlying data member. If something non-trivial needs to happen
>> when the property is assigned, then no, you'd need to return a proxy
>> object. (And, alas, some_function would need to be a template.)
>
> Not to mention that it assumes that there is actually an object behind
> `data()` that could be returned as a reference. Many properties are
> phantasmal; the actual data is not stored in the type it appears as.
> Indeed, one could say that the whole point of properties as a feature are
> that they *can be* phantasmal in such a way, without the user being aware
> of their nature.
....at least until someone tries to take/pass it as a reference to the
"apparent" type ;-). In a strongly-typed language like C++, that's just
insurmountable. (But I don't consider it a feature-killer.)
Applying this to bitfields was mentioned earlier in the thread...
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/994d795d-3c10-7201-8386-12f5ec7bbaae%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 17:40:55 +0300
Raw View
On 10 August 2017 at 17:08, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> Ah. Of course, mixins are sufficiently wide-spread that figuring those
> out is almost certainly worthwhile in its own right. (I've always
> thought so, anyway.)
>
> Maybe someone would be interested in taking up the torch on those?
I daresay we should see how much we can get via reflection, and then
figure out whether we want
to add specific facilities.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUb74DztdM5e6cjgEsJeNEqwmy5hWkcTBUa1zJbojb%3DtCQ%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 10 Aug 2017 09:21:22 -0700 (PDT)
Raw View
------=_Part_1030_1031566323.1502382083010
Content-Type: multipart/alternative;
boundary="----=_Part_1031_946003205.1502382083011"
------=_Part_1031_946003205.1502382083011
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 10, 2017 at 10:40:58 AM UTC-4, Ville Voutilainen wrote:
>
> On 10 August 2017 at 17:08, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> > Ah. Of course, mixins are sufficiently wide-spread that figuring those
> > out is almost certainly worthwhile in its own right. (I've always
> > thought so, anyway.)
> >
> > Maybe someone would be interested in taking up the torch on those?
>
>
> I daresay we should see how much we can get via reflection, and then
> figure out whether we want
> to add specific facilities.
>
This is not a problem reflection can solve. Or at least, not the problem I
was encountering with CRTP-based mixins. That problem being the fact that
the derived class (the class being mixed into) is *incomplete* at the point
where the mixin is being instantiated.
That's the catch-22: you need a way to augment a type with new stuff, but
you also need a way to access the stuff that was previously added to the
type. And as I understand, you cannot invoke reflection on an incomplete
type.
And even if you could reflect over a partially complete type, you wouldn't
be able to access members that haven't been declared yet. And since
CRTP-based mixins are used as base classes, then pretty much everything
about the derived class has not yet been declared.
A proper mixin facility needs the following three properties:
1: The ability for a type to add the mixin to itself, such that the mixin's
declarations are able to have access to any previously-declared members in
the type.
2: The ability for a type that gets mixed-into to access the mixin's
declarations as if they were its own.
3: The ability to convert a pointer/reference to a type into a
pointer/reference to the mixin it uses, providing access only to the
mixin's interface.
Note: I'm not sure that #3 is really needed. But at the same time, it seems
like an *exceedingly* useful thing to have, since it allows you to have
external operator overloading and the like.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/5d2c2db8-9774-4099-82d6-c97b909363ad%40isocpp.org.
------=_Part_1031_946003205.1502382083011
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 10, 2017 at 10:40:58 AM UTC-4, Ville V=
outilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 August =
2017 at 17:08, Matthew Woehlke <<a href=3D"javascript:" target=3D"_blank=
" gdf-obfuscated-mailto=3D"ZEhVQ0t5BwAJ" rel=3D"nofollow" onmousedown=3D"th=
is.href=3D'javascript:';return true;" onclick=3D"this.href=3D'j=
avascript:';return true;">mwoehlk...@gmail.com</a>> wrote:
<br>> Ah. Of course, mixins are sufficiently wide-spread that figuring t=
hose
<br>> out is almost certainly worthwhile in its own right. (I've alw=
ays
<br>> thought so, anyway.)
<br>>
<br>> Maybe someone would be interested in taking up the torch on those?
<br>
<br>
<br>I daresay we should see how much we can get via reflection, and then
<br>figure out whether we want
<br>to add specific facilities.<br></blockquote><div><br>This is not a prob=
lem reflection can solve. Or at least, not the problem I was encountering w=
ith CRTP-based mixins. That problem being the fact that the derived class (=
the class being mixed into) is <i>incomplete</i> at the point where the mix=
in is being instantiated.<br><br>That's the catch-22: you need a way to=
augment a type with new stuff, but you also need a way to access the stuff=
that was previously added to the type. And as I understand, you cannot inv=
oke reflection on an incomplete type.<br><br>And even if you could reflect =
over a partially complete type, you wouldn't be able to access members =
that haven't been declared yet. And since CRTP-based mixins are used as=
base classes, then pretty much everything about the derived class has not =
yet been declared.<br><br>A proper mixin facility needs the following three=
properties:<br><br>1: The ability for a type to add the mixin to itself, s=
uch that the mixin's declarations are able to have access to any previo=
usly-declared members in the type.<br><br>2: The ability for a type that ge=
ts mixed-into to access the mixin's declarations as if they were its ow=
n.<br><br>3: The ability to convert a pointer/reference to a type into a po=
inter/reference to the mixin it uses, providing access only to the mixin=
9;s interface.<br><br>Note: I'm not sure that #3 is really needed. But =
at the same time, it seems like an <i>exceedingly</i> useful thing to have,=
since it allows you to have external operator overloading and the like.<br=
></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/5d2c2db8-9774-4099-82d6-c97b909363ad%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/5d2c2db8-9774-4099-82d6-c97b909363ad=
%40isocpp.org</a>.<br />
------=_Part_1031_946003205.1502382083011--
------=_Part_1030_1031566323.1502382083010--
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 10 Aug 2017 12:35:54 -0400
Raw View
On 2017-08-10 10:40, Ville Voutilainen wrote:
> On 10 August 2017 at 17:08, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> Ah. Of course, mixins are sufficiently wide-spread that figuring those
>> out is almost certainly worthwhile in its own right. (I've always
>> thought so, anyway.)
>>
>> Maybe someone would be interested in taking up the torch on those?
>
>
> I daresay we should see how much we can get via reflection, and then
> figure out whether we want to add specific facilities.
I don't think *reflection* can help with CRTP... *metaclasses* on the
other hand...
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/b81cd136-20c1-bd12-3bb0-42ff322323ad%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 19:35:57 +0300
Raw View
On 10 August 2017 at 19:21, Nicol Bolas <jmckesson@gmail.com> wrote:
> On Thursday, August 10, 2017 at 10:40:58 AM UTC-4, Ville Voutilainen wrote:
>>
>> On 10 August 2017 at 17:08, Matthew Woehlke <mwoehlk...@gmail.com> wrote:
>> > Ah. Of course, mixins are sufficiently wide-spread that figuring those
>> > out is almost certainly worthwhile in its own right. (I've always
>> > thought so, anyway.)
>> >
>> > Maybe someone would be interested in taking up the torch on those?
>>
>>
>> I daresay we should see how much we can get via reflection, and then
>> figure out whether we want
>> to add specific facilities.
>
>
> This is not a problem reflection can solve. Or at least, not the problem I
> was encountering with CRTP-based mixins. That problem being the fact that
> the derived class (the class being mixed into) is incomplete at the point
> where the mixin is being instantiated.
>
> That's the catch-22: you need a way to augment a type with new stuff, but
> you also need a way to access the stuff that was previously added to the
> type. And as I understand, you cannot invoke reflection on an incomplete
> type.
You can run metaprograms on a type that is so-called almost-complete,
and the metaprogram completes it.
See http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0707r1.pdf.
> And even if you could reflect over a partially complete type, you wouldn't
> be able to access members that haven't been declared yet. And since
Except that you can, if you postpone instantiation of such code to a
time when the members
are available. You generate a template, and then instantiate the
template with the member. The member
does need to be a parameter, but that doesn't change the mixed-in code.
> A proper mixin facility needs the following three properties:
>
> 1: The ability for a type to add the mixin to itself, such that the mixin's
> declarations are able to have access to any previously-declared members in
> the type.
Right, none of the metaprogramming proposals I've seen thus far
support exactly this. The mixin
must accept the type it's going to be mixed in as a parameter of some
kind. We don't have
'inline templates' where we can just explode code into a context, and
have the exploded code
expect certain declarations to be valid.
> 2: The ability for a type that gets mixed-into to access the mixin's
> declarations as if they were its own.
This is another aspect which is not that direct in the proposals I've seen.
> 3: The ability to convert a pointer/reference to a type into a
> pointer/reference to the mixin it uses, providing access only to the mixin's
> interface.
This is easy to do, just generate a conversion function or an operator.
With the proposed metaprogramming facilities, we can fairly easily
express "make type X behave like
type Y, without requiring an inheritance relationship". We can
generate delegation code. What we
don't have is "make the code in type Y behave differently depending on
its surrounding context, without
having any readiness for that in type Y".
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUakgF_ZAt81uhcwn4KzLcbjC04LpqyREHWoKNFe6njDfQ%40mail.gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 19:36:54 +0300
Raw View
On 10 August 2017 at 19:35, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> I don't think *reflection* can help with CRTP... *metaclasses* on the
> other hand...
I consider code generation a part of reflection. Introspection is
different, and more limited. :P
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUZTE5dcQ8f-WaRJNVFGXebsDrWheUXjk70BOYScqb3L6w%40mail.gmail.com.
.
Author: Matthew Woehlke <mwoehlke.floss@gmail.com>
Date: Thu, 10 Aug 2017 12:53:54 -0400
Raw View
On 2017-08-10 12:36, Ville Voutilainen wrote:
> On 10 August 2017 at 19:35, Matthew Woehlke wrote:
>> I don't think *reflection* can help with CRTP... *metaclasses* on the
>> other hand...
>
> I consider code generation a part of reflection. Introspection is
> different, and more limited. :P
Ah, I see... language impedance ;-).
(I suspect Nicol and I have the same "understanding" of what
"reflection" means... i.e. to us, P0707 *builds on* reflection, but
isn't *part of* reflection.)
--
Matthew
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/17b1a3ed-1590-21ce-328d-053b86d6fc0b%40gmail.com.
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 19:59:58 +0300
Raw View
On 10 August 2017 at 19:53, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
> On 2017-08-10 12:36, Ville Voutilainen wrote:
>> On 10 August 2017 at 19:35, Matthew Woehlke wrote:
>>> I don't think *reflection* can help with CRTP... *metaclasses* on the
>>> other hand...
>>
>> I consider code generation a part of reflection. Introspection is
>> different, and more limited. :P
>
> Ah, I see... language impedance ;-).
>
> (I suspect Nicol and I have the same "understanding" of what
> "reflection" means... i.e. to us, P0707 *builds on* reflection, but
> isn't *part of* reflection.)
Well, what is part of reflection remains to be seen. We don't have
anything published yet, and
there's been some serious thought to go towards something that's less
template-y than the first reflection
proposals were. In addition to that, we are seriously looking into
what code generating compile-time
facilities should be like (and look like). It seems clear that we want
code transformation and generation
capabilities. Whether metaclasses will be part of that picture is
another matter.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUYys9RHq1y%2BVGor55HHz5XqPyixrexPKp5mOAnuSMW%2Bow%40mail.gmail.com.
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 10 Aug 2017 10:14:31 -0700 (PDT)
Raw View
------=_Part_1045_412153231.1502385272060
Content-Type: multipart/alternative;
boundary="----=_Part_1046_1859562261.1502385272060"
------=_Part_1046_1859562261.1502385272060
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 10, 2017 at 1:00:01 PM UTC-4, Ville Voutilainen wrote:
>
> On 10 August 2017 at 19:53, Matthew Woehlke <mwoehlk...@gmail.com
> <javascript:>> wrote:
> > On 2017-08-10 12:36, Ville Voutilainen wrote:
> >> On 10 August 2017 at 19:35, Matthew Woehlke wrote:
> >>> I don't think *reflection* can help with CRTP... *metaclasses* on the
> >>> other hand...
> >>
> >> I consider code generation a part of reflection. Introspection is
> >> different, and more limited. :P
> >
> > Ah, I see... language impedance ;-).
> >
> > (I suspect Nicol and I have the same "understanding" of what
> > "reflection" means... i.e. to us, P0707 *builds on* reflection, but
> > isn't *part of* reflection.)
>
> Well, what is part of reflection remains to be seen. We don't have
> anything published yet, and
> there's been some serious thought to go towards something that's less
> template-y than the first reflection
> proposals were. In addition to that, we are seriously looking into
> what code generating compile-time
> facilities should be like (and look like). It seems clear that we want
> code transformation and generation
> capabilities. Whether metaclasses will be part of that picture is
> another matter.
>
I guess it's more a matter of the fact that it's a *very* far future thing.
C++20 is highly unlikely to see purely introspective reflection. So the
chance of code generation reflection reaching even C++23 is pretty low.
If mixins are a good idea for C++, I just don't see a need for us to hold
off until C++23 (at the earliest), just because we think we *might* be able
to get them via code generation reflection. If it were right around the
corner, that'd be one thing. But when that sort of stuff is still in the
design/research project stage, then let's see if we can solve the problem
in a more direct way.
At least in the meantime.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/2fe78db2-1a96-4c22-9439-1c12dea4868e%40isocpp.org.
------=_Part_1046_1859562261.1502385272060
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 10, 2017 at 1:00:01 PM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 August 2=
017 at 19:53, Matthew Woehlke <<a href=3D"javascript:" target=3D"_blank"=
gdf-obfuscated-mailto=3D"T9Zv1OGABwAJ" rel=3D"nofollow" onmousedown=3D"thi=
s.href=3D'javascript:';return true;" onclick=3D"this.href=3D'ja=
vascript:';return true;">mwoehlk...@gmail.com</a>> wrote:
<br>> On 2017-08-10 12:36, Ville Voutilainen wrote:
<br>>> On 10 August 2017 at 19:35, Matthew Woehlke wrote:
<br>>>> I don't think *reflection* can help with CRTP... *meta=
classes* on the
<br>>>> other hand...
<br>>>
<br>>> I consider code generation a part of reflection. Introspection=
is
<br>>> different, and more limited. :P
<br>>
<br>> Ah, I see... language impedance ;-).
<br>>
<br>> (I suspect Nicol and I have the same "understanding" of =
what
<br>> "reflection" means... i.e. to us, P0707 *builds on* refl=
ection, but
<br>> isn't *part of* reflection.)
<br>
<br>Well, what is part of reflection remains to be seen. We don't have
<br>anything published yet, and
<br>there's been some serious thought to go towards something that'=
s less
<br>template-y than the first reflection
<br>proposals were. In addition to that, we are seriously looking into
<br>what code generating compile-time
<br>facilities should be like (and look like). It seems clear that we want
<br>code transformation and generation
<br>capabilities. Whether metaclasses will be part of that picture is
<br>another matter.
<br></blockquote><div><br>I guess it's more a matter of the fact that i=
t's a <i>very</i> far future thing. C++20 is highly unlikely to see pur=
ely introspective reflection. So the chance of code generation reflection r=
eaching even C++23 is pretty low.<br><br>If mixins are a good idea for C++,=
I just don't see a need for us to hold off until C++23 (at the earlies=
t), just because we think we <i>might</i> be able to get them via code gene=
ration reflection. If it were right around the corner, that'd be one th=
ing. But when that sort of stuff is still in the design/research project st=
age, then let's see if we can solve the problem in a more direct way.<b=
r><br>At least in the meantime.<br></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/2fe78db2-1a96-4c22-9439-1c12dea4868e%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/2fe78db2-1a96-4c22-9439-1c12dea4868e=
%40isocpp.org</a>.<br />
------=_Part_1046_1859562261.1502385272060--
------=_Part_1045_412153231.1502385272060--
.
Author: Ville Voutilainen <ville.voutilainen@gmail.com>
Date: Thu, 10 Aug 2017 20:38:22 +0300
Raw View
On 10 August 2017 at 20:14, Nicol Bolas <jmckesson@gmail.com> wrote:
> I guess it's more a matter of the fact that it's a very far future thing.
> C++20 is highly unlikely to see purely introspective reflection. So the
> chance of code generation reflection reaching even C++23 is pretty low.
Considering that there's already implementation experience on both
introspective reflection
and code generation, it's safe to say that that's far from a matter of fact.
> If mixins are a good idea for C++, I just don't see a need for us to hold
> off until C++23 (at the earliest), just because we think we might be able to
> get them via code generation reflection. If it were right around the corner,
> that'd be one thing. But when that sort of stuff is still in the
> design/research project stage, then let's see if we can solve the problem in
> a more direct way.
> At least in the meantime.
If we'd have a pressing need for mixins, or confidence that we can't
get close enough
to them via the reflection facilities, that might be plausible.
Neither being the case, there's
no need to rush into a specific mixin facility.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAFk2RUafz5KPRcAhvr7BNEdgxTAsiZidb_pPzgHOvoRXPc6uog%40mail.gmail.com.
.
Author: Cleiton Santoia <cleitonsantoia@gmail.com>
Date: Thu, 10 Aug 2017 11:09:39 -0700 (PDT)
Raw View
------=_Part_1128_1891303795.1502388579803
Content-Type: multipart/alternative;
boundary="----=_Part_1129_2006726584.1502388579803"
------=_Part_1129_2006726584.1502388579803
Content-Type: text/plain; charset="UTF-8"
> Ah, I see... language impedance ;-).
>
> (I suspect Nicol and I have the same "understanding" of what
> "reflection" means... i.e. to us, P0707 *builds on* reflection, but
> isn't *part of* reflection.)
>
Introspection + transform + injection = reflection
BR
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/d119b3dd-7fd5-4741-8ca4-142b82a1abee%40isocpp.org.
------=_Part_1129_2006726584.1502388579803
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<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;">Ah, I see... language impedance ;-).
<br>
<br>(I suspect Nicol and I have the same "understanding" of what
<br>"reflection" means... i.e. to us, P0707 *builds on* reflectio=
n, but
<br>isn't *part of* reflection.)
<br></blockquote><div><br></div><div><br></div>Introspection + transform + =
injection =3D reflection<div><br></div><div>BR<br><br></div><div>=C2=A0</di=
v></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/d119b3dd-7fd5-4741-8ca4-142b82a1abee%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d119b3dd-7fd5-4741-8ca4-142b82a1abee=
%40isocpp.org</a>.<br />
------=_Part_1129_2006726584.1502388579803--
------=_Part_1128_1891303795.1502388579803--
.
Author: Nicol Bolas <jmckesson@gmail.com>
Date: Thu, 10 Aug 2017 12:12:12 -0700 (PDT)
Raw View
------=_Part_1236_686147625.1502392333028
Content-Type: multipart/alternative;
boundary="----=_Part_1237_1511278969.1502392333029"
------=_Part_1237_1511278969.1502392333029
Content-Type: text/plain; charset="UTF-8"
On Thursday, August 10, 2017 at 1:38:25 PM UTC-4, Ville Voutilainen wrote:
>
> On 10 August 2017 at 20:14, Nicol Bolas <jmck...@gmail.com <javascript:>>
> wrote:
> > I guess it's more a matter of the fact that it's a very far future
> thing.
> > C++20 is highly unlikely to see purely introspective reflection. So the
> > chance of code generation reflection reaching even C++23 is pretty low.
>
> Considering that there's already implementation experience on both
> introspective reflection
> and code generation, it's safe to say that that's far from a matter of
> fact.
>
Sure, that's possible. But the statistical evidence from the committee's
behavior strongly suggests otherwise.
Concepts took about 4 years to go from initial design to a finished TS.
While there had been some talk about modules before N4047 in 2014, it still
took 3 years to take that proposal to the PDTS phase, putting it on
Concepts TS's pace. The Coroutines TS took even longer, finally landing as
a TS after 6 years work.
Introspective reflection? That started in 2014, and they're still arguing
about the interface. Don't get me wrong; that's a good argument to have.
I'm just saying that it's moving slowly much more slowly than other
proposals. It's looking more on pace to match Coroutines than Concepts.
And that's just measuring the time to becoming a TS. If you look at the TS
wave that entered C++17, we clearly see that the only things that made it
were things that reached their TS status by the end of 2014. Filesystem,
Parallelism v1, and LibFundamentals v1 all hit that timeframe, and they all
got voted in. Concepts, and Concurrency missed that timeframe and had to
wait for the next C++ version.
You could argue that there were technical reasons for waiting on those. But
this is what we've seen from the committee.
Concepts, Ranges, Networking, and Coroutines are probably going to hit
C++20. But Modules is on the same timeframe relative to C++20 that Concepts
were relative to C++17. And purely introspective reflection is even farther
behind than that.
So unless the intent is to have the various reflection proposals go
straight into the standard without a TS phase first, I don't see a reason
to expect reflection of any form to be standardized anytime soon.
So while I appreciate your optimism about the committee's ability to
quickly adopt features, until there is evidence of that optimism
translating into features actually being quickly adopted, I shall remain
skeptical ;)
> If mixins are a good idea for C++, I just don't see a need for us to hold
> > off until C++23 (at the earliest), just because we think we might be
> able to
> > get them via code generation reflection. If it were right around the
> corner,
> > that'd be one thing. But when that sort of stuff is still in the
> > design/research project stage, then let's see if we can solve the
> problem in
> > a more direct way.
> > At least in the meantime.
>
> If we'd have a pressing need for mixins, or confidence that we can't
> get close enough
> to them via the reflection facilities, that might be plausible.
> Neither being the case, there's
> no need to rush into a specific mixin facility.
>
Every time you use the CRTP, what you're really doing is using a mixin. So
the Range-v3 technique for creating range types easily? That's just a
mixin, done in a very unintuitive way.
The need for this feature has been there for quite some time. The need for
it as a language feature is to avoid all of the problems associated with it
as an idiom (teachability, fragile interface, no compiler checking, etc).
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/7fe1d0c9-79b0-4e18-919a-be56fd102892%40isocpp.org.
------=_Part_1237_1511278969.1502392333029
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, August 10, 2017 at 1:38:25 PM UTC-4, Ville Vo=
utilainen wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin=
-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 10 August 2=
017 at 20:14, Nicol Bolas <<a href=3D"javascript:" target=3D"_blank" gdf=
-obfuscated-mailto=3D"_S9qafqCBwAJ" rel=3D"nofollow" onmousedown=3D"this.hr=
ef=3D'javascript:';return true;" onclick=3D"this.href=3D'javasc=
ript:';return true;">jmck...@gmail.com</a>> wrote:
<br>> I guess it's more a matter of the fact that it's a very fa=
r future thing.
<br>> C++20 is highly unlikely to see purely introspective reflection. S=
o the
<br>> chance of code generation reflection reaching even C++23 is pretty=
low.
<br>
<br>Considering that there's already implementation experience on both
<br>introspective reflection
<br>and code generation, it's safe to say that that's far from a ma=
tter of fact.<br></blockquote><div><br>Sure, that's possible. But the s=
tatistical evidence from the committee's behavior strongly suggests oth=
erwise.<br><br>Concepts took about 4 years to go from initial design to a f=
inished TS.=20
While there had been some talk about modules before N4047 in 2014, it still=
took 3 years to take that proposal to the PDTS=20
phase, putting it on Concepts TS's pace. The Coroutines TS took even lo=
nger, finally landing as a TS after 6 years work.<br><br>Introspective refl=
ection? That started in 2014, and they're still arguing about the inter=
face. Don't get me wrong; that's a good argument to have. I'm j=
ust saying=20
that it's moving slowly much more slowly than other proposals. It's=
looking more on pace to match Coroutines than Concepts.<br><br>And that=
9;s just measuring the time to becoming a TS. If you look at the TS wave th=
at entered C++17, we clearly see that the only things that made it were thi=
ngs that reached their TS status by the end of 2014. Filesystem, Parallelis=
m v1, and LibFundamentals v1 all hit that timeframe, and they all got voted=
in. Concepts, and Concurrency missed that timeframe and had to wait for th=
e next C++ version.<br><br>You could argue that there were technical reason=
s for waiting on those. But this is what we've seen from the committee.=
<br><br>Concepts, Ranges, Networking, and Coroutines are probably going to =
hit C++20. But Modules is on the same timeframe relative to C++20 that Conc=
epts were relative to C++17. And purely introspective reflection is even fa=
rther behind than that.<br><br>So unless the intent is to have the various =
reflection proposals go straight into the standard without a TS phase first=
, I don't see a reason to expect reflection of any form to be standardi=
zed anytime soon.<br><br>So while I appreciate your optimism about the comm=
ittee's ability to quickly adopt features, until there is evidence of t=
hat optimism translating into features actually being quickly adopted, I sh=
all remain skeptical ;)<br><br></div><blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">
> If mixins are a good idea for C++, I just don't see a need for us =
to hold
<br>> off until C++23 (at the earliest), just because we think we might =
be able to
<br>> get them via code generation reflection. If it were right around t=
he corner,
<br>> that'd be one thing. But when that sort of stuff is still in t=
he
<br>> design/research project stage, then let's see if we can solve =
the problem in
<br>> a more direct way.
<br>> At least in the meantime.
<br>
<br>If we'd have a pressing need for mixins, or confidence that we can&=
#39;t
<br>get close enough
<br>to them via the reflection facilities, that might be plausible.
<br>Neither being the case, there's
<br>no need to rush into a specific mixin facility.
<br></blockquote><div><br>Every time you use the CRTP, what you're real=
ly doing is using a mixin. So the Range-v3 technique for creating range typ=
es easily? That's just a mixin, done in a very unintuitive way.<br><br>=
The need for this feature has been there for quite some time. The need for =
it as a language feature is to avoid all of the problems associated with it=
as an idiom (teachability, fragile interface, no compiler checking, etc).<=
br></div></div>
<p></p>
-- <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+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/7fe1d0c9-79b0-4e18-919a-be56fd102892%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/7fe1d0c9-79b0-4e18-919a-be56fd102892=
%40isocpp.org</a>.<br />
------=_Part_1237_1511278969.1502392333029--
------=_Part_1236_686147625.1502392333028--
.