Topic: Generalized "using" member aliases.
Author: Derek Ross <antiquarktv@gmail.com>
Date: Thu, 21 Jul 2016 19:23:07 -0700 (PDT)
Raw View
------=_Part_91_839745895.1469154187556
Content-Type: multipart/alternative;
boundary="----=_Part_92_2098299631.1469154187557"
------=_Part_92_2098299631.1469154187557
Content-Type: text/plain; charset=UTF-8
It would be useful if "using" aliases could be expanded beyond namespaces
and types. Why not provide aliases for class members? This would be useful
if you wanted to derive a class from a standard type such as pair or tuple,
but wanted more meaningful member names than the built-in .first, .second,
etc, names. In effect, a way to easily "rename" a member.
The member alias syntax would look like:
class X { ...
using NewName = ExistingName;
where ExistingName is an existing member variable or member function in a
class. The implemention would treat NewName like a macro, and substitute
ExistingName wherever NewName appears. ExistingName could also specify a
function, e.g., "ExistingName()", in which case NewName becomes a
property-like element.
*Examples:*
You could derive from a std::pair, then alias different names to the .first
and .second members of the pair.
struct Gps_Pos : pair<double,double> {
using latitude = first;
using longitude = second;
};
Gps_Pos gps;
gps.latitude = 12.34; //sets gps.first
Another possibility could be to alias names to certain elements of an
array. Thus, an N-dimensional array could provide names for each dimension.
struct Vec3d{
double data[3];
using x = data[0];
using y = data[1];
using z = data[2];
};
Vec3d v;
v.z = 123; // sets data[2]
Member aliases could also be used to shorten inconveniently long names:
struct My_Database{
int GetNumberOfCustomersCurrentlyActive(){
...
}
using custs = GetNumberOfCustomersCurrentlyActive;
};
My_Database db;
cout << db.custs() ; // calls db.GetNumberOfCustomersCurrentlyActive()
Finally, member aliases could be used to access elements of a tuple through
meaningful names. This brings tuples one step closer to being a struct
replacement, with all the extra features that a tuple provides.
struct Person : tuple<string,int>{
string& get0(){return std::get<0>(*this);}
int& get1(){return std::get<1>(*this);}
using name = get0();
using age = get1();
};
Person p;
p.name = "Bob"; //sets via get<0>(p)
----
Cheers,
Derek
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/d0eb7c1b-19b5-4ab4-97c3-e3f1a88a7fe3%40isocpp.org.
------=_Part_92_2098299631.1469154187557
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">It would be useful if "using" aliases could be e=
xpanded beyond namespaces and types. Why not provide aliases for class memb=
ers? This would be useful if you wanted to derive a class from a standard t=
ype such as pair or tuple, but wanted more meaningful member names than the=
built-in .first, .second, etc, names. In effect, a way to easily "ren=
ame" a member.<br><br>The member alias syntax would look like: <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; w=
ord-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyp=
rint"><span style=3D"color: #008;" class=3D"styled-by-prettify">class</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-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"><br>=C2=A0</span><span style=3D"color: #008;" cl=
ass=3D"styled-by-prettify">using</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">NewName</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </s=
pan><span style=3D"color: #606;" class=3D"styled-by-prettify">ExistingName<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></d=
iv></code></div><br>where ExistingName is an existing member variable or me=
mber function in a class. The implemention would treat NewName like a macro=
, and substitute ExistingName wherever NewName appears. ExistingName could =
also specify a function, e.g., "ExistingName()", in which case Ne=
wName becomes a property-like element. <br><br><b>Examples:</b><br><br>You =
could derive from a std::pair, then alias different names to the .first and=
.second members of the pair.<br><br><div class=3D"prettyprint" style=3D"ba=
ckground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); borde=
r-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"p=
rettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" clas=
s=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" class=3D=
"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-b=
y-prettify">Gps_Pos</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"> pair</sp=
an><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">double</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"c=
olor: #008;" class=3D"styled-by-prettify">double</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"style=
d-by-prettify"> =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 </span><span style=3D"color:=
#008;" class=3D"styled-by-prettify">using</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> latitude </span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" clas=
s=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"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"=
styled-by-prettify">using</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> longitude </span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> second</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: #660;" class=3D"styled-by-prettify">};</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br><br></span><s=
pan style=3D"color: #606;" class=3D"styled-by-prettify">Gps_Pos</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify"> gps</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> <br>gps</span><span style=3D"color: =
#660;" class=3D"styled-by-prettify">.</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">latitude </span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> </span><span style=3D"color: #066;" class=3D"styled-by-=
prettify">12.34</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: #800;" class=3D"styled-by-prettify">//sets gps.fi=
rst</span></div></code></div><br>Another possibility could be to alias name=
s to certain elements of an array. Thus, an N-dimensional array could provi=
de names for each dimension. <br>=C2=A0<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 clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Vec3d</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">{</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"><br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">double</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> data</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y">[</span><span style=3D"color: #066;" class=3D"styled-by-prettify">3</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">];</span><span =
style=3D"color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0<br>=C2=
=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify"=
>using</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"color: #000;" class=3D"styled-by-prettify"> data</span><span =
style=3D"color: #660;" class=3D"styled-by-prettify">[</span><span style=3D"=
color: #066;" class=3D"styled-by-prettify">0</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>=C2=A0 =C2=A0 </span><span style=3D"color: #0=
08;" class=3D"styled-by-prettify">using</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"sty=
led-by-prettify"> data</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">[</span><span style=3D"color: #066;" class=3D"styled-by-prettif=
y">1</span><span style=3D"color: #660;" class=3D"styled-by-prettify">];</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=
=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">using<=
/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 st=
yle=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=
: #066;" class=3D"styled-by-prettify">2</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"style=
d-by-prettify">};</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"><br><br></span><span style=3D"color: #606;" class=3D"styled-by-prett=
ify">Vec3d</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
v</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"><br>v</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"> </span><span style=3D"color: #066;" class=3D"=
styled-by-prettify">123</span><span style=3D"color: #660;" class=3D"styled-=
by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-by-pretti=
fy"> </span><span style=3D"color: #800;" class=3D"styled-by-prettify">// se=
ts data[2]</span></div></code></div>=C2=A0<br>Member aliases could also be =
used to shorten inconveniently long names:<br>=C2=A0<br><div class=3D"prett=
yprint" style=3D"background-color: rgb(250, 250, 250); border-color: rgb(18=
7, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-word=
;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D=
"color: #008;" class=3D"styled-by-prettify">struct</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;=
" class=3D"styled-by-prettify">My_Database</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;" clas=
s=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styl=
ed-by-prettify">GetNumberOfCustomersCurrentlyActive</span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">(){</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 =C2=A0</span><span styl=
e=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: #660;" class=3D"styled-by-prettify">}</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0<br>=C2=A0 =C2=A0 </s=
pan><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span><=
span style=3D"color: #000;" class=3D"styled-by-prettify"> custs </span><spa=
n 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=
: #606;" class=3D"styled-by-prettify">GetNumberOfCustomersCurrentlyActive</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">};</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"><br>=C2=A0<br></span><span style=3D=
"color: #606;" class=3D"styled-by-prettify">My_Database</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> db</span><span style=3D"col=
or: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"><br>cout </span><span style=3D"color: #660;"=
class=3D"styled-by-prettify"><<</span><span style=3D"color: #000;" c=
lass=3D"styled-by-prettify"> db</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">.</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify">custs</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">()</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #800;" class=3D"styled-by-prettify">// calls db.GetNumberOfCusto=
mersCurrentlyActive()</span></div></code></div><br>Finally, member aliases =
could be used to access elements of a tuple through meaningful names. This =
brings tuples one step closer to being a struct replacement, with all the e=
xtra features that a tuple provides. <br><br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #00=
8;" class=3D"styled-by-prettify">struct</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">Person</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"> t=
uple</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><</=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">string</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: #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">string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> get0</span><span style=3D"color: #66=
0;" class=3D"styled-by-prettify">(){</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">return</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> std</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">::</span><span style=3D"color: #008;" class=3D"styled-by-=
prettify">get</span><span style=3D"color: #660;" class=3D"styled-by-prettif=
y"><</span><span style=3D"color: #066;" class=3D"styled-by-prettify">0</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">>(*</span=
><span style=3D"color: #008;" class=3D"styled-by-prettify">this</span><span=
style=3D"color: #660;" class=3D"styled-by-prettify">);}</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =C2=A0 </span><sp=
an style=3D"color: #008;" class=3D"styled-by-prettify">int</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> =C2=A0 =C2=A0get1</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(){</span><span style=3D=
"color: #008;" class=3D"styled-by-prettify">return</span><span style=3D"col=
or: #000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" cla=
ss=3D"styled-by-prettify">get</span><span style=3D"color: #660;" class=3D"s=
tyled-by-prettify"><</span><span style=3D"color: #066;" class=3D"styled-=
by-prettify">1</span><span style=3D"color: #660;" class=3D"styled-by-pretti=
fy">>(*</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"><br>=C2=A0 =
=C2=A0 <br>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">using</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> name </span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> =
get0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">();</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"><br>=C2=A0 =
=C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prettify">usi=
ng</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> age =C2=
=A0</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> get1</span><s=
pan 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 style=3D"color: #=
000;" class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #60=
6;" class=3D"styled-by-prettify">Person</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> p</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br>p</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">.</span><span style=3D"color: #000;" class=3D"styled-by-prettify">na=
me </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span =
style=3D"color: #080;" class=3D"styled-by-prettify">"Bob"</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span styl=
e=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"colo=
r: #800;" class=3D"styled-by-prettify">//sets via get<0>(p)</span></d=
iv></code></div><br>----<br>Cheers,<br>Derek<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/d0eb7c1b-19b5-4ab4-97c3-e3f1a88a7fe3%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/d0eb7c1b-19b5-4ab4-97c3-e3f1a88a7fe3=
%40isocpp.org</a>.<br />
------=_Part_92_2098299631.1469154187557--
------=_Part_91_839745895.1469154187556--
.
Author: "D. B." <db0451@gmail.com>
Date: Fri, 22 Jul 2016 08:40:34 +0100
Raw View
--001a11468e08caf2890538348ce0
Content-Type: text/plain; charset=UTF-8
How would one disambiguate between 'aliased members' and typenames in the
outer scope, which might well overlap? Would the former now have to take
precedence? What would the syntax be for resolving ambiguous aliases? I
dunno, it seems like a lot of work for little benefit.
Or for negative benefit in some cases:
"ExistingName could also specify a function, e.g., "ExistingName()", in
which case NewName becomes a property-like element."
- But then we have horribly ambiguous syntax for whether something is a
member variable or method, requiring us to constantly consult the class to
unearth byzantine using declarations, which don't produce "property-like
elements" anyway if the function signature doesn't return a modifiable
reference.
"Member aliases could also be used to shorten inconveniently long names"
- thereby producing 2 names for the same object, cluttering the namespace
and introducing ambiguity, merely to remove the responsibility of users not
to choose stupidly long names?
"This brings tuples one step closer to being a struct replacement"
- sounds like ominous portent to me. structs aren't tuples, and tuples
aren't structs. Neither should replace the other. Do we really need to
introduce a bunch of problems such as the above just to make interface
design slightly easier for the lazy
....I dunno, just playing devil's advocate. I've never felt a need for this
and am not convinced that the cited rationales are good things, quite the
opposite in most cases.
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEwWaOWU9maQCXAsPMqDgeOyxMQBdVjXixfCYO_vBri9g%40mail.gmail.com.
--001a11468e08caf2890538348ce0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>How would one disambiguate between 'aliased membe=
rs' and typenames in the outer scope, which might well overlap? Would t=
he former now have to take precedence? What would the syntax be for resolvi=
ng ambiguous aliases? I dunno, it seems like a lot of work for little benef=
it.<br><br>Or for negative benefit in some cases:<br><br>"ExistingName=
could also specify a function, e.g., "ExistingName()", in which =
case NewName becomes a property-like element."<br>- But then we have h=
orribly ambiguous syntax for whether something is a member variable or meth=
od, requiring us to constantly consult the class to unearth byzantine using=
declarations, which don't produce "property-like elements" a=
nyway if the function signature doesn't return a modifiable reference.<=
br><br>"Member aliases could also be used to shorten inconveniently lo=
ng names"<br>- thereby producing 2 names for the same object, clutteri=
ng the namespace and introducing ambiguity, merely to remove the responsibi=
lity of users not to choose stupidly long names?<br><br>"This brings t=
uples one step closer to being a struct replacement"<br></div><div>- s=
ounds like ominous portent to me. structs aren't tuples, and tuples are=
n't structs. Neither should replace the other. Do we really need to int=
roduce a bunch of problems such as the above just to make interface design =
slightly easier for the lazy<br></div><div><br></div><div>...I dunno, just =
playing devil's advocate. I've never felt a need for this and am no=
t convinced that the cited rationales are good things, quite the opposite i=
n most cases.<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/CACGiwhEwWaOWU9maQCXAsPMqDgeOyxMQBdVj=
XixfCYO_vBri9g%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CACGiwhEwWaOWU9ma=
QCXAsPMqDgeOyxMQBdVjXixfCYO_vBri9g%40mail.gmail.com</a>.<br />
--001a11468e08caf2890538348ce0--
.
Author: Derek Ross <antiquarktv@gmail.com>
Date: Fri, 22 Jul 2016 07:58:52 -0700 (PDT)
Raw View
------=_Part_374_777315557.1469199532371
Content-Type: multipart/alternative;
boundary="----=_Part_375_521357246.1469199532372"
------=_Part_375_521357246.1469199532372
Content-Type: text/plain; charset=UTF-8
On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B. wrote:
>
> How would one disambiguate between 'aliased members' and typenames in the
> outer scope, which might well overlap?
>
It would be the same as a member variable having the same name as a type in
the outer scope. So, already a solved problem.
> "ExistingName could also specify a function, e.g., "ExistingName()", in
> which case NewName becomes a property-like element."
> - But then we have horribly ambiguous syntax for whether something is a
> member variable or method, requiring us to constantly consult the class to
> unearth byzantine using declarations, which don't produce "property-like
> elements" anyway if the function signature doesn't return a modifiable
> reference.
>
I am confident that C++ developers will be able to wrap their minds around
it.
> "Member aliases could also be used to shorten inconveniently long names"
> - thereby producing 2 names for the same object, cluttering the namespace
> and introducing ambiguity, merely to remove the responsibility of users not
> to choose stupidly long names?
>
This is inspired by the recommended way of shortening a long namespace
name, such as
namespace American_Telephone_and_Telegraph { ... }
using ATT = American_Telephone_and_Telegraph;
or shortening typenames like:
using vecvecstr = std::vector<std::vector<std::string>>;
> "This brings tuples one step closer to being a struct replacement"
> - sounds like ominous portent to me. structs aren't tuples, and tuples
> aren't structs. Neither should replace the other. Do we really need to
> introduce a bunch of problems such as the above just to make interface
> design slightly easier for the lazy
>
If there were an easy way to convert a struct to a tuple, then some current
topics such as reflection or default comparisons (see links), could be
implemented as a library rather than by changing the language.
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4452.pdf
----
Cheers,
Derek
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/bcee3692-87df-4f63-b8c6-dcba5601a105%40isocpp.org.
------=_Part_375_521357246.1469199532372
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B. wrote:=
<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bor=
der-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>How woul=
d one disambiguate between 'aliased members' and typenames in the o=
uter scope, which might well overlap?=C2=A0<br></div></div></blockquote><di=
v><br></div><div>It would be the same as a member variable having the same =
name as a type in the outer scope. So, already a solved problem.=C2=A0</div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;marg=
in-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"=
ltr"><div>"ExistingName could also specify a function, e.g., "Exi=
stingName()", in which case NewName becomes a property-like element.&q=
uot;<br>- But then we have horribly ambiguous syntax for whether something =
is a member variable or method, requiring us to constantly consult the clas=
s to unearth byzantine using declarations, which don't produce "pr=
operty-like elements" anyway if the function signature doesn't ret=
urn a modifiable reference.<br></div></div></blockquote><div><br></div><div=
>I am confident that C++ developers will be able to wrap their minds around=
it.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D=
"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex=
;"><div dir=3D"ltr"><div>"Member aliases could also be used to shorten=
inconveniently long names"<br>- thereby producing 2 names for the sam=
e object, cluttering the namespace and introducing ambiguity, merely to rem=
ove the responsibility of users not to choose stupidly long names?<br></div=
></div></blockquote><div><br></div><div>This is inspired by the recommended=
way of shortening a long namespace name, such as=C2=A0</div><div><br></div=
><div class=3D"prettyprint" style=3D"border: 1px solid rgb(187, 187, 187); =
word-wrap: break-word; background-color: rgb(250, 250, 250);"><code class=
=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;"=
class=3D"styled-by-prettify">namespace</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"=
styled-by-prettify">American_Telephone_and_Telegraph</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: #660;" class=3D"style=
d-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><br></=
span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</span>=
<span style=3D"color: #000;" class=3D"styled-by-prettify"> ATT </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=
: #606;" class=3D"styled-by-prettify">American_Telephone_and_Telegraph</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span></div><=
/code></div><div><br></div><div>or shortening typenames like:=C2=A0</div><d=
iv><br></div><div><div class=3D"prettyprint" style=3D"border: 1px solid rgb=
(187, 187, 187); word-wrap: break-word; background-color: rgb(250, 250, 250=
);"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span style=
=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify"> vecvecstr </span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: =
#000;" class=3D"styled-by-prettify"> std</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify">std</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">::</span><span style=3D"color: #000;" class=3D"styled-by-prettify">v=
ector</span><span style=3D"color: #660;" class=3D"styled-by-prettify"><<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify">std</span><=
span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span sty=
le=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">>>;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span></div></code></div><=
/div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>"This brings tuples one step closer to being a struct re=
placement"<br></div><div>- sounds like ominous portent to me. structs =
aren't tuples, and tuples aren't structs. Neither should replace th=
e other. Do we really need to introduce a bunch of problems such as the abo=
ve just to make interface design slightly easier for the lazy<br></div></di=
v></blockquote><div><br></div><div>If there were an easy way to convert a s=
truct to a tuple, then some current topics such as reflection or default co=
mparisons (see links), could be implemented as a library rather than by cha=
nging the language.=C2=A0</div><div><br></div><div>http://www.open-std.org/=
jtc1/sc22/wg21/docs/papers/2015/n4475.pdf<br></div><div>http://www.open-std=
..org/jtc1/sc22/wg21/docs/papers/2015/n4452.pdf<br></div><div>=C2=A0</div><d=
iv>----</div><div>Cheers,=C2=A0</div><div>Derek</div><div><br></div><div><b=
r></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/bcee3692-87df-4f63-b8c6-dcba5601a105%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/bcee3692-87df-4f63-b8c6-dcba5601a105=
%40isocpp.org</a>.<br />
------=_Part_375_521357246.1469199532372--
------=_Part_374_777315557.1469199532371--
.
Author: szollosi.lorand@gmail.com
Date: Fri, 22 Jul 2016 08:56:25 -0700 (PDT)
Raw View
------=_Part_904_1256354457.1469202985369
Content-Type: multipart/alternative;
boundary="----=_Part_905_1995812520.1469202985369"
------=_Part_905_1995812520.1469202985369
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi,
As for the *pair* example, I'd suggest just using references. Note that you=
=20
can have a ref to a member of a *tuple* as well. This might or might not=20
have a memory cost depending on your compiler. As for the *using a =3D b();=
*=20
syntax, I'm not sure we want to 'hide' function calls behind members, as we=
=20
never used to do that in C++ (that's like hidden costs). That said, I'm not=
=20
completely against this, as I had this need before as well...
-lorro
2016. j=C3=BAlius 22., p=C3=A9ntek 16:58:52 UTC+2 id=C5=91pontban Derek Ros=
s a k=C3=B6vetkez=C5=91t=20
=C3=ADrta:
>
> On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B. wrote:
>>
>> How would one disambiguate between 'aliased members' and typenames in th=
e=20
>> outer scope, which might well overlap?=20
>>
>
> It would be the same as a member variable having the same name as a type=
=20
> in the outer scope. So, already a solved problem.=20
> =20
>
>> "ExistingName could also specify a function, e.g., "ExistingName()", in=
=20
>> which case NewName becomes a property-like element."
>> - But then we have horribly ambiguous syntax for whether something is a=
=20
>> member variable or method, requiring us to constantly consult the class =
to=20
>> unearth byzantine using declarations, which don't produce "property-like=
=20
>> elements" anyway if the function signature doesn't return a modifiable=
=20
>> reference.
>>
>
> I am confident that C++ developers will be able to wrap their minds aroun=
d=20
> it.=20
> =20
>
>> "Member aliases could also be used to shorten inconveniently long names"
>> - thereby producing 2 names for the same object, cluttering the namespac=
e=20
>> and introducing ambiguity, merely to remove the responsibility of users =
not=20
>> to choose stupidly long names?
>>
>
> This is inspired by the recommended way of shortening a long namespace=20
> name, such as=20
>
> namespace American_Telephone_and_Telegraph { ... }
>
> using ATT =3D American_Telephone_and_Telegraph;
>
> or shortening typenames like:=20
>
> using vecvecstr =3D std::vector<std::vector<std::string>>;=20
> =20
>
>> "This brings tuples one step closer to being a struct replacement"
>> - sounds like ominous portent to me. structs aren't tuples, and tuples=
=20
>> aren't structs. Neither should replace the other. Do we really need to=
=20
>> introduce a bunch of problems such as the above just to make interface=
=20
>> design slightly easier for the lazy
>>
>
> If there were an easy way to convert a struct to a tuple, then some=20
> current topics such as reflection or default comparisons (see links), cou=
ld=20
> be implemented as a library rather than by changing the language.=20
>
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4475.pdf
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4452.pdf
> =20
> ----
> Cheers,=20
> Derek
>
>
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/361901c2-098a-47ea-ab1f-431b35389baa%40isocpp.or=
g.
------=_Part_905_1995812520.1469202985369
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hi,<br><br>As for the <i>pair</i> example, I'd suggest=
just using references. Note that you can have a ref to a member of a <i>tu=
ple</i> as well. This might or might not have a memory cost depending on yo=
ur compiler. As for the <i>using a =3D b();</i> syntax, I'm not sure we=
want to 'hide' function calls behind members, as we never used to =
do that in C++ (that's like hidden costs). That said, I'm not compl=
etely against this, as I had this need before as well...<br><br>-lorro<br><=
br>2016. j=C3=BAlius 22., p=C3=A9ntek 16:58:52 UTC+2 id=C5=91pontban Derek =
Ross a k=C3=B6vetkez=C5=91t =C3=ADrta:<blockquote class=3D"gmail_quote" sty=
le=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left=
: 1ex;"><div dir=3D"ltr">On Friday, July 22, 2016 at 2:40:38 AM UTC-5, D. B=
.. wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>How w=
ould one disambiguate between 'aliased members' and typenames in th=
e outer scope, which might well overlap?=C2=A0<br></div></div></blockquote>=
<div><br></div><div>It would be the same as a member variable having the sa=
me name as a type in the outer scope. So, already a solved problem.=C2=A0</=
div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;ma=
rgin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"lt=
r"><div>"ExistingName could also specify a function, e.g., "Exist=
ingName()", in which case NewName becomes a property-like element.&quo=
t;<br>- But then we have horribly ambiguous syntax for whether something is=
a member variable or method, requiring us to constantly consult the class =
to unearth byzantine using declarations, which don't produce "prop=
erty-like elements" anyway if the function signature doesn't retur=
n a modifiable reference.<br></div></div></blockquote><div><br></div><div>I=
am confident that C++ developers will be able to wrap their minds around i=
t.=C2=A0</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"m=
argin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div=
dir=3D"ltr"><div>"Member aliases could also be used to shorten inconv=
eniently long names"<br>- thereby producing 2 names for the same objec=
t, cluttering the namespace and introducing ambiguity, merely to remove the=
responsibility of users not to choose stupidly long names?<br></div></div>=
</blockquote><div><br></div><div>This is inspired by the recommended way of=
shortening a long namespace name, such as=C2=A0</div><div><br></div><div s=
tyle=3D"border:1px solid rgb(187,187,187);word-wrap:break-word;background-c=
olor:rgb(250,250,250)"><code><div><span style=3D"color:#008">namespace</spa=
n><span style=3D"color:#000"> </span><span style=3D"color:#606">American_Te=
lephone_and_<wbr>Telegraph</span><span style=3D"color:#000"> </span><span s=
tyle=3D"color:#660">{</span><span style=3D"color:#000"> </span><span style=
=3D"color:#660">...</span><span style=3D"color:#000"> </span><span style=3D=
"color:#660">}</span><span style=3D"color:#000"><br><br></span><span style=
=3D"color:#008">using</span><span style=3D"color:#000"> ATT </span><span st=
yle=3D"color:#660">=3D</span><span style=3D"color:#000"> </span><span style=
=3D"color:#606">American_Telephone_and_<wbr>Telegraph</span><span style=3D"=
color:#660">;</span></div></code></div><div><br></div><div>or shortening ty=
penames like:=C2=A0</div><div><br></div><div><div style=3D"border:1px solid=
rgb(187,187,187);word-wrap:break-word;background-color:rgb(250,250,250)"><=
code><div><span style=3D"color:#008">using</span><span style=3D"color:#000"=
> vecvecstr </span><span style=3D"color:#660">=3D</span><span style=3D"colo=
r:#000"> std</span><span style=3D"color:#660">::</span><span style=3D"color=
:#000">vector</span><span style=3D"color:#660"><</span><span style=3D"co=
lor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"colo=
r:#000">vector</span><span style=3D"color:#660"><</span><span style=3D"c=
olor:#000">std</span><span style=3D"color:#660">::</span><span style=3D"col=
or:#008">s<wbr>tring</span><span style=3D"color:#660">>>;</span><span=
style=3D"color:#000"> </span></div></code></div></div><div>=C2=A0</div><bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>"This bring=
s tuples one step closer to being a struct replacement"<br></div><div>=
- sounds like ominous portent to me. structs aren't tuples, and tuples =
aren't structs. Neither should replace the other. Do we really need to =
introduce a bunch of problems such as the above just to make interface desi=
gn slightly easier for the lazy<br></div></div></blockquote><div><br></div>=
<div>If there were an easy way to convert a struct to a tuple, then some cu=
rrent topics such as reflection or default comparisons (see links), could b=
e implemented as a library rather than by changing the language.=C2=A0</div=
><div><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs=
/papers/2015/n4475.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"t=
his.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.or=
g%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4475.pdf\x26sa\x3dD\x26snt=
z\x3d1\x26usg\x3dAFQjCNEN9hkR1Mx1bwyYCBd44bXPtlD6Aw';return true;" oncl=
ick=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.ope=
n-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4475.pdf\x26sa\x3d=
D\x26sntz\x3d1\x26usg\x3dAFQjCNEN9hkR1Mx1bwyYCBd44bXPtlD6Aw';return tru=
e;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n4475=
..pdf</a><br></div><div><a href=3D"http://www.open-std.org/jtc1/sc22/wg21/do=
cs/papers/2015/n4452.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=3D=
"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.open-std.=
org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4452.pdf\x26sa\x3dD\x26s=
ntz\x3d1\x26usg\x3dAFQjCNEWRKFYjHKFYueZdchjKkp0cfjhQQ';return true;" on=
click=3D"this.href=3D'http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.o=
pen-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2015%2Fn4452.pdf\x26sa\x=
3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEWRKFYjHKFYueZdchjKkp0cfjhQQ';return t=
rue;">http://www.open-std.org/jtc1/<wbr>sc22/wg21/docs/papers/2015/<wbr>n44=
52.pdf</a><br></div><div>=C2=A0</div><div>----</div><div>Cheers,=C2=A0</div=
><div>Derek</div><div><br></div><div><br></div></div></blockquote></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/361901c2-098a-47ea-ab1f-431b35389baa%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/361901c2-098a-47ea-ab1f-431b35389baa=
%40isocpp.org</a>.<br />
------=_Part_905_1995812520.1469202985369--
------=_Part_904_1256354457.1469202985369--
.
Author: Greg Marr <gregmmarr@gmail.com>
Date: Fri, 22 Jul 2016 10:58:54 -0700 (PDT)
Raw View
------=_Part_1023_1420183606.1469210334664
Content-Type: multipart/alternative;
boundary="----=_Part_1024_1083338041.1469210334668"
------=_Part_1024_1083338041.1469210334668
Content-Type: text/plain; charset=UTF-8
On Thursday, July 21, 2016 at 10:23:07 PM UTC-4, Derek Ross wrote:
>
> It would be useful if "using" aliases could be expanded beyond namespaces
> and types. Why not provide aliases for class members? This would be useful
> if you wanted to derive a class from a standard type such as pair or tuple,
> but wanted more meaningful member names than the built-in .first, .second,
> etc, names. In effect, a way to easily "rename" a member.
>
There was a discussion of this here back in December.
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4PR7LUngZFw
https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/KMI1F_0k55s
--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving 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/ea7b738a-ec82-46ba-8903-e1097b9d9e39%40isocpp.org.
------=_Part_1024_1083338041.1469210334668
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">On Thursday, July 21, 2016 at 10:23:07 PM UTC-4, Derek Ros=
s 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">It wo=
uld be useful if "using" aliases could be expanded beyond namespa=
ces and types. Why not provide aliases for class members? This would be use=
ful if you wanted to derive a class from a standard type such as pair or tu=
ple, but wanted more meaningful member names than the built-in .first, .sec=
ond, etc, names. In effect, a way to easily "rename" a member.<br=
></div></blockquote><div><br></div><div>There was a discussion of this here=
back in December.</div><div><br></div><div>https://groups.google.com/a/iso=
cpp.org/forum/#!topic/std-proposals/4PR7LUngZFw<br></div><div>https://group=
s.google.com/a/isocpp.org/forum/#!topic/std-proposals/KMI1F_0k55s<br></div>=
<div><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/ea7b738a-ec82-46ba-8903-e1097b9d9e39%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/ea7b738a-ec82-46ba-8903-e1097b9d9e39=
%40isocpp.org</a>.<br />
------=_Part_1024_1083338041.1469210334668--
------=_Part_1023_1420183606.1469210334664--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 26 Jul 2016 18:47:32 -0700 (PDT)
Raw View
------=_Part_1747_875311857.1469584052573
Content-Type: multipart/alternative;
boundary="----=_Part_1748_670317957.1469584052573"
------=_Part_1748_670317957.1469584052573
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UTC=
+8=E4=B8=8B=E5=8D=883:40:38=EF=BC=8CD. B.=E5=86=99=E9=81=93=EF=BC=9A
>
> How would one disambiguate between 'aliased members' and typenames in the=
=20
> outer scope, which might well overlap? Would the former now have to take=
=20
> precedence? What would the syntax be for resolving ambiguous aliases? I=
=20
> dunno, it seems like a lot of work for little benefit.
>
> Or for negative benefit in some cases:
>
> "ExistingName could also specify a function, e.g., "ExistingName()", in=
=20
> which case NewName becomes a property-like element."
> - But then we have horribly ambiguous syntax for whether something is a=
=20
> member variable or method, requiring us to constantly consult the class t=
o=20
> unearth byzantine using declarations, which don't produce "property-like=
=20
> elements" anyway if the function signature doesn't return a modifiable=20
> reference.
>
> I don't see the need when you have applied some workable naming=20
conventions.
=20
> "Member aliases could also be used to shorten inconveniently long names"
> - thereby producing 2 names for the same object, cluttering the namespace=
=20
> and introducing ambiguity, merely to remove the responsibility of users n=
ot=20
> to choose stupidly long names?
>
> Alias declarations are similar here.
=20
> "This brings tuples one step closer to being a struct replacement"
> - sounds like ominous portent to me. structs aren't tuples, and tuples=20
> aren't structs. Neither should replace the other. Do we really need to=20
> introduce a bunch of problems such as the above just to make interface=20
> design slightly easier for the lazy
>
> Both struct and tuple are instances of product type=20
<https://en.wikipedia.org/wiki/Product_type>s with possible some additional=
=20
metadata. Typically, tuples are purely product types, and struts can have=
=20
names in their fields, as so-called record type=20
<https://en.wikipedia.org/wiki/Record_(computer_science)>s. Thus, structs=
=20
can be viewed as tuples with (mostly) named members as its elements. The=20
names are additional to the elements of ordinary tuple. It would be quite=
=20
natural in a language with first class tuples and named member interface=20
based on them. Also note that record types are sometimes too restrictive=20
than necessary, e.g. specifying layout of these types should not require=20
names of members.
=20
> ...I dunno, just playing devil's advocate. I've never felt a need for thi=
s=20
> and am not convinced that the cited rationales are good things, quite the=
=20
> opposite in most cases.
>
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/9323492b-fd49-4819-8abe-c1c08252b617%40isocpp.or=
g.
------=_Part_1748_670317957.1469584052573
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8822=E6=97=A5=E6=98=
=9F=E6=9C=9F=E4=BA=94 UTC+8=E4=B8=8B=E5=8D=883:40:38=EF=BC=8CD. B.=E5=86=99=
=E9=81=93=EF=BC=9A<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>How would one disambiguate between 'aliased members' and =
typenames in the outer scope, which might well overlap? Would the former no=
w have to take precedence? What would the syntax be for resolving ambiguous=
aliases? I dunno, it seems like a lot of work for little benefit.<br><br>O=
r for negative benefit in some cases:<br><br>"ExistingName could also =
specify a function, e.g., "ExistingName()", in which case NewName=
becomes a property-like element."<br>- But then we have horribly ambi=
guous syntax for whether something is a member variable or method, requirin=
g us to constantly consult the class to unearth byzantine using declaration=
s, which don't produce "property-like elements" anyway if the=
function signature doesn't return a modifiable reference.<br><br></div=
></div></blockquote><div>I don't see the need when you have applied som=
e workable naming conventions.<br>=C2=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div>"Member aliases could also b=
e used to shorten inconveniently long names"<br>- thereby producing 2 =
names for the same object, cluttering the namespace and introducing ambigui=
ty, merely to remove the responsibility of users not to choose stupidly lon=
g names?<br><br></div></div></blockquote><div>Alias declarations are simila=
r here.<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"margi=
n: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><di=
v dir=3D"ltr"><div>"This brings tuples one step closer to being a stru=
ct replacement"<br></div><div>- sounds like ominous portent to me. str=
ucts aren't tuples, and tuples aren't structs. Neither should repla=
ce the other. Do we really need to introduce a bunch of problems such as th=
e above just to make interface design slightly easier for the lazy<br></div=
><div><br></div></div></blockquote><div>Both struct and tuple are instances=
of <a href=3D"https://en.wikipedia.org/wiki/Product_type">product type</a>=
s with possible some additional metadata. Typically, tuples are purely prod=
uct types, and struts can have names in their fields, as so-called <a href=
=3D"https://en.wikipedia.org/wiki/Record_(computer_science)">record type</a=
>s. Thus, structs can be viewed as tuples with (mostly) named members as it=
s elements. The names are additional to the elements of ordinary tuple. It =
would be quite natural in a language with first class tuples and named memb=
er interface based on them. Also note that record types are sometimes too r=
estrictive than necessary, e.g. specifying layout of these types should not=
require names of members.<br><br>=C2=A0<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;=
padding-left: 1ex;"><div dir=3D"ltr"><div></div><div>...I dunno, just playi=
ng devil's advocate. I've never felt a need for this and am not con=
vinced that the cited rationales are good things, quite the opposite in mos=
t cases.<br></div></div>
</blockquote></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/9323492b-fd49-4819-8abe-c1c08252b617%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/9323492b-fd49-4819-8abe-c1c08252b617=
%40isocpp.org</a>.<br />
------=_Part_1748_670317957.1469584052573--
------=_Part_1747_875311857.1469584052573--
.
Author: FrankHB1989 <frankhb1989@gmail.com>
Date: Tue, 26 Jul 2016 18:56:38 -0700 (PDT)
Raw View
------=_Part_1794_252960846.1469584598580
Content-Type: multipart/alternative;
boundary="----=_Part_1795_1915210899.1469584598580"
------=_Part_1795_1915210899.1469584598580
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
=E5=9C=A8 2016=E5=B9=B47=E6=9C=8823=E6=97=A5=E6=98=9F=E6=9C=9F=E5=85=AD UTC=
+8=E4=B8=8A=E5=8D=881:58:55=EF=BC=8CGreg Marr=E5=86=99=E9=81=93=EF=BC=9A
>
> On Thursday, July 21, 2016 at 10:23:07 PM UTC-4, Derek Ross wrote:
>>
>> It would be useful if "using" aliases could be expanded beyond namespace=
s=20
>> and types. Why not provide aliases for class members? This would be usef=
ul=20
>> if you wanted to derive a class from a standard type such as pair or tup=
le,=20
>> but wanted more meaningful member names than the built-in .first, .secon=
d,=20
>> etc, names. In effect, a way to easily "rename" a member.
>>
>
> There was a discussion of this here back in December.
>
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/4PR7LU=
ngZFw
>
> https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/KMI1F_=
0k55s
>
> The discussion seemed to be inactive for a long time.
I actually prefer the broader idea: to allow users specifying a name in *an=
y=20
*scope bounds to some entity, rather than only in some class scope. This=20
also eliminates some need of macros.
--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/0c6cb819-86d9-403f-8316-b303743b1814%40isocpp.or=
g.
------=_Part_1795_1915210899.1469584598580
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><br>=E5=9C=A8 2016=E5=B9=B47=E6=9C=8823=E6=97=A5=E6=98=
=9F=E6=9C=9F=E5=85=AD UTC+8=E4=B8=8A=E5=8D=881:58:55=EF=BC=8CGreg Marr=E5=
=86=99=E9=81=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: =
0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div d=
ir=3D"ltr">On Thursday, July 21, 2016 at 10:23:07 PM UTC-4, Derek Ross wrot=
e:<blockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">It would be usef=
ul if "using" aliases could be expanded beyond namespaces and typ=
es. Why not provide aliases for class members? This would be useful if you =
wanted to derive a class from a standard type such as pair or tuple, but wa=
nted more meaningful member names than the built-in .first, .second, etc, n=
ames. In effect, a way to easily "rename" a member.<br></div></bl=
ockquote><div><br></div><div>There was a discussion of this here back in De=
cember.</div><div><br></div><div><a href=3D"https://groups.google.com/a/iso=
cpp.org/forum/#!topic/std-proposals/4PR7LUngZFw" target=3D"_blank" rel=3D"n=
ofollow" onmousedown=3D"this.href=3D'https://groups.google.com/a/isocpp=
..org/forum/#!topic/std-proposals/4PR7LUngZFw';return true;" onclick=3D"=
this.href=3D'https://groups.google.com/a/isocpp.org/forum/#!topic/std-p=
roposals/4PR7LUngZFw';return true;">https://groups.google.com/a/<wbr>is=
ocpp.org/forum/#!topic/std-<wbr>proposals/4PR7LUngZFw</a><br></div><div><a =
href=3D"https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/=
KMI1F_0k55s" target=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D=
'https://groups.google.com/a/isocpp.org/forum/#!topic/std-proposals/KMI=
1F_0k55s';return true;" onclick=3D"this.href=3D'https://groups.goog=
le.com/a/isocpp.org/forum/#!topic/std-proposals/KMI1F_0k55s';return tru=
e;">https://groups.google.com/a/<wbr>isocpp.org/forum/#!topic/std-<wbr>prop=
osals/KMI1F_0k55s</a><br></div><div><br></div></div></blockquote><div>The d=
iscussion seemed to be inactive for a long time.<br><br>I actually prefer t=
he broader idea: to allow users specifying a name in <i>any </i>scope bound=
s to some entity, rather than only in some class scope. This also eliminate=
s some need of macros.<br><br><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/0c6cb819-86d9-403f-8316-b303743b1814%=
40isocpp.org?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/0c6cb819-86d9-403f-8316-b303743b1814=
%40isocpp.org</a>.<br />
------=_Part_1795_1915210899.1469584598580--
------=_Part_1794_252960846.1469584598580--
.