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

Consider the following:

namespace foo
{
    struct bar {};
    void baz() {}
    int qux;
}

namespace A = foo;
using B = foo::bar;
auto &C = foo::baz;
auto &D = foo::qux;

The question is, why do we have to use at least three different ways in
order to say use X as an alias of Y?

Is there any fundamental reason why using X = Y cannot (or should not) be
valid for all kinds of names?

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">Consider the following:<div><br></div><div>namespace foo</=
div><div>{</div><div>=C2=A0 =C2=A0 struct bar {};</div><div>=C2=A0 =C2=A0 v=
oid baz() {}</div><div>=C2=A0 =C2=A0 int qux;</div><div>}</div><div><br></d=
iv><div>namespace A =3D foo;</div><div>using B =3D foo::bar;</div><div>auto=
 &amp;C =3D foo::baz;</div><div>auto &amp;D =3D foo::qux;</div><div><br></d=
iv><div>The question is, why do we have to use at least three different way=
s in order to say use X as an alias of Y?</div><div><br></div><div>Is there=
 any fundamental reason why using X =3D Y cannot (or should not) be valid f=
or all kinds of names?</div><div><br></div><div>Cheers,</div><div>V.</div><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113ad434a823390527177d53--

.

------=_Part_120_1993872942.1450361862697
Content-Type: multipart/alternative;
 boundary="----=_Part_121_850506692.1450361862697"

------=_Part_121_850506692.1450361862697
Content-Type: text/plain; charset=UTF-8

On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote:
>
> Consider the following:
>
> namespace foo
> {
>     struct bar {};
>     void baz() {}
>     int qux;
> }
>
> namespace A = foo;
> using B = foo::bar;
> auto &C = foo::baz;
> auto &D = foo::qux;
>
> The question is, why do we have to use at least three different ways in
> order to say use X as an alias of Y?
>

Because they're not the same thing. However much you may want to think of
`C` and `D` as "aliases", they are not. They are *references to objects*.

Doing `B b{};` is legal. Doing `C c{};` is not. It makes perfect sense that
creating a typename alias and creating an object reference would require
different syntax. Just as creating a namespace alias uses different syntax
from a typename alias.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viache=
slav Usov 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"lt=
r">Consider the following:<div><br></div><div>namespace foo</div><div>{</di=
v><div>=C2=A0 =C2=A0 struct bar {};</div><div>=C2=A0 =C2=A0 void baz() {}</=
div><div>=C2=A0 =C2=A0 int qux;</div><div>}</div><div><br></div><div>namesp=
ace A =3D foo;</div><div>using B =3D foo::bar;</div><div>auto &amp;C =3D fo=
o::baz;</div><div>auto &amp;D =3D foo::qux;</div><div><br></div><div>The qu=
estion is, why do we have to use at least three different ways in order to =
say use X as an alias of Y?</div></div></blockquote><div><br>Because they&#=
39;re not the same thing. However much you may want to think of `C` and `D`=
 as &quot;aliases&quot;, they are not. They are <i>references to objects</i=
>.<br><br>Doing `B b{};` is legal. Doing `C c{};` is not. It makes perfect =
sense that creating a typename alias and creating an object reference would=
 require different syntax. Just as creating a namespace alias uses differen=
t syntax from a typename alias.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_121_850506692.1450361862697--
------=_Part_120_1993872942.1450361862697--

.

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

On Thu, Dec 17, 2015 at 3:17 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote:
>>
>> Consider the following:
>>
>> namespace foo
>> {
>>     struct bar {};
>>     void baz() {}
>>     int qux;
>> }
>>
>> namespace A = foo;
>> using B = foo::bar;
>> auto &C = foo::baz;
>> auto &D = foo::qux;
>>
>> The question is, why do we have to use at least three different ways in
>> order to say use X as an alias of Y?
>>
>
> Because they're not the same thing. However much you may want to think of
> `C` and `D` as "aliases", they are not. They are *references to objects*.
>

I did not mean to ask why different syntaxes had to be used per the current
standard. My question was a proposal, which I thought would be self-evident
in this forum; let me re-formulate it more explicitly.

Proposal: make syntax using X = Y a valid alternative to namespace X = Y
(when Y is a namespace name); or auto &X = Y (when Y is a function or an
object); this is similar to how using X = Y is a valid alternative to
typedef Y X (when Y is a type).

Motivation: the current means of creating alternative names for language
entities create leaky abstractions and have corresponding maintenance
costs. Consider this:

// unit 1
struct A {};

// unit 2
using X = A;
auto a = X();

At some later time, the code in unit 1 changes to:

B A();

The code in unit 2 is no longer valid.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 17, 2015 at 3:17 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex"><div dir=3D"ltr">On Thursday, December 17, =
2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote:<blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr">Consider the following:<div><br></div><div>namespace foo</div><div=
>{</div><div>=C2=A0 =C2=A0 struct bar {};</div><div>=C2=A0 =C2=A0 void baz(=
) {}</div><div>=C2=A0 =C2=A0 int qux;</div><div>}</div><div><br></div><div>=
namespace A =3D foo;</div><div>using B =3D foo::bar;</div><div>auto &amp;C =
=3D foo::baz;</div><div>auto &amp;D =3D foo::qux;</div><div><br></div><div>=
The question is, why do we have to use at least three different ways in ord=
er to say use X as an alias of Y?</div></div></blockquote><div><br>Because =
they&#39;re not the same thing. However much you may want to think of `C` a=
nd `D` as &quot;aliases&quot;, they are not. They are <i>references to obje=
cts</i>.<br></div></div></blockquote><div><br></div><div>I did not mean to =
ask why different syntaxes had to be used per the current standard. My ques=
tion was a proposal, which I thought would be self-evident in this forum; l=
et me re-formulate it more explicitly.</div><div><br></div><div>Proposal: m=
ake=C2=A0syntax using X =3D Y a valid alternative to namespace X =3D Y (whe=
n Y is a namespace name); or auto &amp;X =3D Y (when Y is a function or an =
object); this is similar to how using X =3D Y is a valid alternative to typ=
edef Y X (when Y is a type).<br></div><div><br></div><div>Motivation: the c=
urrent means of creating alternative names for language entities create lea=
ky abstractions and have corresponding maintenance costs. Consider this:</d=
iv><div><br></div><div>// unit 1</div><div>struct A {};</div><div><br></div=
><div>// unit 2</div><div>using X =3D A;</div><div>auto a =3D X();<br></div=
><div><br></div><div>At some later time, the code in unit 1 changes to:</di=
v><div><br></div><div>B A();</div><div><br></div><div>The code in unit 2 is=
 no longer valid.</div><div><br></div><div>Cheers,</div><div>V.</div><div><=
br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7b471e0092062e0527195ee5--

.

------=_Part_1122_1424891915.1450374532554
Content-Type: multipart/alternative;
 boundary="----=_Part_1123_172305839.1450374532555"

------=_Part_1123_172305839.1450374532555
Content-Type: text/plain; charset=UTF-8

On Thursday, December 17, 2015 at 10:06:40 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Dec 17, 2015 at 3:17 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
>> On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote:
>>>
>>> Consider the following:
>>>
>>> namespace foo
>>> {
>>>     struct bar {};
>>>     void baz() {}
>>>     int qux;
>>> }
>>>
>>> namespace A = foo;
>>> using B = foo::bar;
>>> auto &C = foo::baz;
>>> auto &D = foo::qux;
>>>
>>> The question is, why do we have to use at least three different ways in
>>> order to say use X as an alias of Y?
>>>
>>
>> Because they're not the same thing. However much you may want to think of
>> `C` and `D` as "aliases", they are not. They are *references to objects*.
>>
>
> I did not mean to ask why different syntaxes had to be used per the
> current standard. My question was a proposal, which I thought would be
> self-evident in this forum; let me re-formulate it more explicitly.
>
> Proposal: make syntax using X = Y a valid alternative to namespace X = Y
> (when Y is a namespace name); or auto &X = Y (when Y is a function or an
> object); this is similar to how using X = Y is a valid alternative to
> typedef Y X (when Y is a type).
>

And the reason not to allow such a proposal is exactly what I said: it
confuses the language. These three circumstances are *not the same thing*,
so the syntax should *not* make them look like they are.


> Motivation: the current means of creating alternative names for language
> entities create leaky abstractions and have corresponding maintenance
> costs. Consider this:
>
> // unit 1
> struct A {};
>
> // unit 2
> using X = A;
> auto a = X();
>
> At some later time, the code in unit 1 changes to:
>
> B A();
>
> The code in unit 2 is no longer valid.
>

You have proven my point. With that change, your code *should be invalid*.

You cannot exchange a struct for a *function*. That is not a valid thing
you can do and expect to get sane code. After all, `unit 2` could easily
have been written as:

using X = A;
auto a = X{};

Now it doesn't work, even if the using declaration works as you wanted. Nor
do any of the following *perfectly valid uses*:

sizeof(X); //Cannot take the size of a reference.
vector<X>; //Can't pass a reference as a typename template parameter.

Indeed, the specific case you described is probably the *only* case where
you could use a reference and a type in the same way. In every other way,
it would not work.

So I find your motivation to be exceedingly weak.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Thursday, December 17, 2015 at 10:06:40 AM UTC-5, Viacheslav Usov 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><div cla=
ss=3D"gmail_quote">On Thu, Dec 17, 2015 at 3:17 PM, Nicol Bolas <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"NmEiDCGNDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">jmck...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr">On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Us=
ov wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-styl=
e:solid;padding-left:1ex"><div dir=3D"ltr">Consider the following:<div><br>=
</div><div>namespace foo</div><div>{</div><div>=C2=A0 =C2=A0 struct bar {};=
</div><div>=C2=A0 =C2=A0 void baz() {}</div><div>=C2=A0 =C2=A0 int qux;</di=
v><div>}</div><div><br></div><div>namespace A =3D foo;</div><div>using B =
=3D foo::bar;</div><div>auto &amp;C =3D foo::baz;</div><div>auto &amp;D =3D=
 foo::qux;</div><div><br></div><div>The question is, why do we have to use =
at least three different ways in order to say use X as an alias of Y?</div>=
</div></blockquote><div><br>Because they&#39;re not the same thing. However=
 much you may want to think of `C` and `D` as &quot;aliases&quot;, they are=
 not. They are <i>references to objects</i>.<br></div></div></blockquote><d=
iv><br></div><div>I did not mean to ask why different syntaxes had to be us=
ed per the current standard. My question was a proposal, which I thought wo=
uld be self-evident in this forum; let me re-formulate it more explicitly.<=
/div><div><br></div><div>Proposal: make=C2=A0syntax using X =3D Y a valid a=
lternative to namespace X =3D Y (when Y is a namespace name); or auto &amp;=
X =3D Y (when Y is a function or an object); this is similar to how using X=
 =3D Y is a valid alternative to typedef Y X (when Y is a type).<br></div><=
/div></div></div></blockquote><div><br>And the reason not to allow such a p=
roposal is exactly what I said: it confuses the language. These three circu=
mstances are <i>not the same thing</i>, so the syntax should <i>not</i> mak=
e them look like they are.<br>=C2=A0</div><blockquote class=3D"gmail_quote"=
 style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-=
left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"><div></div><di=
v></div><div>Motivation: the current means of creating alternative names fo=
r language entities create leaky abstractions and have corresponding mainte=
nance costs. Consider this:</div><div><br></div><div>// unit 1</div><div>st=
ruct A {};</div><div><br></div><div>// unit 2</div><div>using X =3D A;</div=
><div>auto a =3D X();<br></div><div><br></div><div>At some later time, the =
code in unit 1 changes to:</div><div><br></div><div>B A();</div><div><br></=
div><div>The code in unit 2 is no longer valid.</div></div></div></div></bl=
ockquote><div><br>You have proven my point. With that change, your code <i>=
should be invalid</i>.<br><br>You cannot exchange a struct for a <i>functio=
n</i>. That is not a valid thing you can do and expect to get sane code. Af=
ter all, `unit 2` could easily have been written as:<br><br><div class=3D"p=
rettyprint" style=3D"background-color: rgb(250, 250, 250); border-color: rg=
b(187, 187, 187); border-style: solid; border-width: 1px; word-wrap: break-=
word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"><span styl=
e=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"> A</span><span style=3D"color: #660;" class=3D=
"styled-by-prettify">;</span><span style=3D"color: #000;" class=3D"styled-b=
y-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">auto</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 a </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> X</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">{};</span></div></code=
></div><br>Now it doesn&#39;t work, even if the using declaration works as =
you wanted. Nor do any of the following <i>perfectly valid uses</i>:<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">sizeof</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">(</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">X</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">);</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" clas=
s=3D"styled-by-prettify">//Cannot take the size of a reference.</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"><br>vector</span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify">X</span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">&gt;;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" class=
=3D"styled-by-prettify">//Can&#39;t pass a reference as a typename template=
 parameter.</span></div></code></div><br>Indeed, the specific case you desc=
ribed is probably the <i>only</i> case where you could use a reference and =
a type in the same way. In every other way, it would not work.<br><br>So I =
find your motivation to be exceedingly weak.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1123_172305839.1450374532555--
------=_Part_1122_1424891915.1450374532554--

.

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

On Thu, Dec 17, 2015 at 4:52 AM, Viacheslav Usov <via.usov@gmail.com> wrote:

> Consider the following:
>
> namespace foo
> {
>     struct bar {};
>     void baz() {}
>     int qux;
> }
>
> namespace A = foo;
> using B = foo::bar;
> auto &C = foo::baz;
> auto &D = foo::qux;
>
> The question is, why do we have to use at least three different ways in
> order to say use X as an alias of Y?
>
> Is there any fundamental reason why using X = Y cannot (or should not) be
> valid for all kinds of names?
>

For prior work in this area, see section 2 of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf -- this
was considered when the "using X = Y;" syntax was first proposed as a
possible eventual extension.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 17, 2015 at 4:52 AM, Viacheslav Usov <span dir=3D"ltr">&lt;<a href=
=3D"mailto:via.usov@gmail.com" target=3D"_blank">via.usov@gmail.com</a>&gt;=
</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-=
left-style:solid;padding-left:1ex"><div dir=3D"ltr">Consider the following:=
<div><br></div><div>namespace foo</div><div>{</div><div>=C2=A0 =C2=A0 struc=
t bar {};</div><div>=C2=A0 =C2=A0 void baz() {}</div><div>=C2=A0 =C2=A0 int=
 qux;</div><div>}</div><div><br></div><div>namespace A =3D foo;</div><div>u=
sing B =3D foo::bar;</div><div>auto &amp;C =3D foo::baz;</div><div>auto &am=
p;D =3D foo::qux;</div><div><br></div><div>The question is, why do we have =
to use at least three different ways in order to say use X as an alias of Y=
?</div><div><br></div><div>Is there any fundamental reason why using X =3D =
Y cannot (or should not) be valid for all kinds of names?</div></div></bloc=
kquote><div><br></div><div>For prior work in this area, see section 2 of=C2=
=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489=
..pdf">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf</a>=
 -- this was considered when the &quot;using X =3D Y;&quot; syntax was firs=
t proposed as a possible eventual extension.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143ff3428e6ca05271cf7a7--

.

------=_Part_1476_517388630.1450395467198
Content-Type: multipart/alternative;
 boundary="----=_Part_1477_1549125211.1450395467198"

------=_Part_1477_1549125211.1450395467198
Content-Type: text/plain; charset=UTF-8

On Thursday, December 17, 2015 at 2:24:05 PM UTC-5, Richard Smith wrote:
>
> On Thu, Dec 17, 2015 at 4:52 AM, Viacheslav Usov <via....@gmail.com
> <javascript:>> wrote:
>
>> Consider the following:
>>
>> namespace foo
>> {
>>     struct bar {};
>>     void baz() {}
>>     int qux;
>> }
>>
>> namespace A = foo;
>> using B = foo::bar;
>> auto &C = foo::baz;
>> auto &D = foo::qux;
>>
>> The question is, why do we have to use at least three different ways in
>> order to say use X as an alias of Y?
>>
>> Is there any fundamental reason why using X = Y cannot (or should not) be
>> valid for all kinds of names?
>>
>
> For prior work in this area, see section 2 of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf -- this
> was considered when the "using X = Y;" syntax was first proposed as a
> possible eventual extension.
>

Actually, that made me remember something. P0109
<http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0109r0.pdf>
actually came up with a good reason to allow function aliasing. It's
primarily used as a way of implementing certain aspects of strong typedefs
though.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Thursday, December 17, 2015 at 2:24:05 PM UTC-5, Richard Smith wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Dec 17, 2015 at 4:52 AM, Viacheslav Usov <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"WwNMMy2bDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">via....@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div di=
r=3D"ltr">Consider the following:<div><br></div><div>namespace foo</div><di=
v>{</div><div>=C2=A0 =C2=A0 struct bar {};</div><div>=C2=A0 =C2=A0 void baz=
() {}</div><div>=C2=A0 =C2=A0 int qux;</div><div>}</div><div><br></div><div=
>namespace A =3D foo;</div><div>using B =3D foo::bar;</div><div>auto &amp;C=
 =3D foo::baz;</div><div>auto &amp;D =3D foo::qux;</div><div><br></div><div=
>The question is, why do we have to use at least three different ways in or=
der to say use X as an alias of Y?</div><div><br></div><div>Is there any fu=
ndamental reason why using X =3D Y cannot (or should not) be valid for all =
kinds of names?</div></div></blockquote><div><br></div><div>For prior work =
in this area, see section 2 of=C2=A0<a href=3D"http://www.open-std.org/jtc1=
/sc22/wg21/docs/papers/2003/n1489.pdf" target=3D"_blank" rel=3D"nofollow" o=
nmousedown=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fw=
ww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\46s=
a\75D\46sntz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return tr=
ue;" onclick=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2=
Fwww.open-std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\4=
6sa\75D\46sntz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return =
true;">http://www.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2003/n1=
489.pdf</a> -- this was considered when the &quot;using X =3D Y;&quot; synt=
ax was first proposed as a possible eventual extension.</div></div></div></=
div></blockquote><div><br>Actually, that made me remember something. <a hre=
f=3D"http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2015/p0109r0.pdf">P=
0109</a> actually came up with a good reason to allow function aliasing. It=
&#39;s primarily used as a way of implementing certain aspects of strong ty=
pedefs though.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1477_1549125211.1450395467198--
------=_Part_1476_517388630.1450395467198--

.

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

On Thu, Dec 17, 2015 at 6:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> And the reason not to allow such a proposal is exactly what I said: it
confuses the language. These three circumstances are *not the same thing*,
so the syntax should *not* make them look like they are.

Oh yes. And we should never have allowed the use of 'auto' for type
deduction, because different types are never the same thing, so the syntax
should *not* make them look like they are.

> You cannot exchange a struct for a *function*.

Except when we can. And we can do so very often.

The premises of your argument are invalid.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 17, 2015 at 6:48 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; And the reason not to allow such a proposal is exactly what I sa=
id: it confuses the language. These three circumstances are <i>not the same=
 thing</i>, so the syntax should <i>not</i> make them look like they are.</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Oh yes.=
 And we should never have allowed the use of &#39;auto&#39; for type deduct=
ion, because different types are never the same thing, so the syntax should=
=C2=A0<i>not</i>=C2=A0make them look like they are.</div><div class=3D"gmai=
l_quote"><br></div><div class=3D"gmail_quote">&gt; You cannot exchange a st=
ruct for a <i>function</i>.</div><div class=3D"gmail_quote"><br></div><div =
class=3D"gmail_quote">Except when we can. And we can do so very often.</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The premis=
es of your argument are invalid.</div><div class=3D"gmail_quote"><br></div>=
<div class=3D"gmail_quote">Cheers,<br></div><div class=3D"gmail_quote">V.</=
div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0149c94e92691305272ac7b9--

.

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

On Thu, Dec 17, 2015 at 8:24 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

> For prior work in this area, see section 2 of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf -- this
was considered when the "using X = Y;" syntax was first proposed as a
possible eventual extension.

Thanks for the pointer. What I see there, though, is that the syntax was
*not* proposed, they merely admitted it was possible for things other than
types. It seems they were quite certain that the extension covering
namespaces would be a good thing: "The alias-declaration syntax appears to
be more general and more uniform. It also contains the traditional
using-declaration as a special case." I am not sure why the same could not
be said verbatim in section 2.3.

It is definitely true that a general mechanism that can select and define
an alias for an entity is a good thing. The need to lift some elaborately
decorated entities into current scope and use them via aliases is real, it
is understood and addressed in the current language, except this is done
via three different syntaxes (or four, if we count pointers). If nothing
else, the uniform syntax addressing the need would be easy to learn, and
add a bit more of DRY to the language. This is similar to how much more
clarity we have now with auto.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
hu, Dec 17, 2015 at 8:24 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">&gt; For prior work in this area, see section 2 of=C2=A0<a href=
=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf" targ=
et=3D"_blank">http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489=
..pdf</a> -- this was considered when the &quot;using X =3D Y;&quot; syntax =
was first proposed as a possible eventual extension.</div><div class=3D"gma=
il_quote"><br></div><div class=3D"gmail_quote">Thanks for the pointer. What=
 I see there, though, is that the syntax was <i>not</i>=C2=A0proposed, they=
 merely admitted it was possible for things other than types. It seems they=
 were quite certain that the extension covering namespaces would be a good =
thing: &quot;The alias-declaration syntax appears to be more general and mo=
re uniform.
It also contains the traditional using-declaration as a special case.&quot;=
 I am not sure why the same could not be said verbatim in section 2.3.</div=
><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">It is defi=
nitely true that a general mechanism that can select and define an alias fo=
r an entity is a good thing. The need to lift some elaborately decorated en=
tities into current scope and use them via aliases is real, it is understoo=
d and addressed in the current language, except this is done via three diff=
erent syntaxes (or four, if we count pointers). If nothing else, the unifor=
m syntax addressing the need would be easy to learn, and add a bit more of =
DRY to the language. This is similar to how much more clarity we have now w=
ith auto.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">Cheers,</div><div class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e01537084ba08e605272b0a15--

.

------=_Part_27_447031498.1450448190973
Content-Type: multipart/alternative;
 boundary="----=_Part_28_1794795384.1450448190974"

------=_Part_28_1794795384.1450448190974
Content-Type: text/plain; charset=UTF-8



On Friday, December 18, 2015 at 6:52:57 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Dec 17, 2015 at 6:48 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > And the reason not to allow such a proposal is exactly what I said: it
> confuses the language. These three circumstances are *not the same thing*,
> so the syntax should *not* make them look like they are.
>
> Oh yes. And we should never have allowed the use of 'auto' for type
> deduction, because different types are never the same thing, so the syntax
> should *not* make them look like they are.
>

.... what are you even talking about?

There's a huge difference between "deduce a different type" and "turn a
typename into a function."


> > You cannot exchange a struct for a *function*.
>
> Except when we can. And we can do so very often.
>
> The premises of your argument are invalid.
>

Declaring something to be invalid does not make it invalid.

If you want to argue that *transparently* exchanging a struct for a
function is something you can do, prove it. Show me under what
circumstances this is acceptable. And then show that the other
circumstances which would prevent it are not usable.

Because right now, the only way you can transparently exchange a struct for
a function is if the *only uses* of that struct's typename were of the
exact form:

auto x = Struct(...);

If you did any of these other *perfectly valid* and very common forms of
initialization, your idea doesn't work:

auto x = Struct{...};
Struct x(...);
Struct x{...};
Struct x = Struct(...); //Not everyone uses auto everywhere
auto x = make_unique<Struct>(...); //Oh right, heap allocation
auto x = new Struct(...); //Even old-school heap allocation fails

Plus, if you used that typename in any other way, your code is broken. In
particular, you cannot:

   - Use it as a template argument.
   - Get a member pointer to one of the members of the struct, perhaps for
   a callback.
   - Make a non-static data member of that class type.
   - Call the destructor directly.
   - Use it as a (non-deduced) return type of a function.

So I'm not buying that this is a particularly useful case.

If you want to argue that transparently exchanging a struct for a function
happens "very often", again prove it. Show me a codebase where this has
happened a lot. Show me libraries that has gone though API revisions that
transparently turn a struct into a function. And show me that users have
not been broken by these changes.

You're the one making the argument for this idea, so the burden of proof is
on you. You claim that this is a common thing, so prove it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Friday, December 18, 2015 at 6:52:57 AM UTC-5, Viacheslav Usov w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote">On Thu, Dec 17, 2015 at 6:48 PM, Nicol Bolas <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"-qKHeSPRDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">jmck...@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">&gt; And the reason not to all=
ow such a proposal is exactly what I said: it confuses the language. These =
three circumstances are <i>not the same thing</i>, so the syntax should <i>=
not</i> make them look like they are.</div><div class=3D"gmail_quote"><br><=
/div><div class=3D"gmail_quote">Oh yes. And we should never have allowed th=
e use of &#39;auto&#39; for type deduction, because different types are nev=
er the same thing, so the syntax should=C2=A0<i>not</i>=C2=A0make them look=
 like they are.</div></div></div></blockquote><div><br>... what are you eve=
n talking about?<br><br>There&#39;s a huge difference between &quot;deduce =
a different type&quot; and &quot;turn a typename into a function.&quot;<br>=
=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><=
div><div class=3D"gmail_quote"></div><div class=3D"gmail_quote">&gt; You ca=
nnot exchange a struct for a <i>function</i>.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Except when we can. And we can do s=
o very often.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">The premises of your argument are invalid.</div></div></div></block=
quote><div><br>Declaring something to be invalid does not make it invalid.<=
br><br>If you want to argue that <i>transparently</i> exchanging a struct f=
or a function is something you can do, prove it. Show me under what circums=
tances this is acceptable. And then show that the other circumstances which=
 would prevent it are not usable.<br><br>Because right now, the only way yo=
u can transparently exchange a struct for a function is if the <b><i>only u=
ses</i></b> of that struct&#39;s typename were of the exact form:<br><br><d=
iv class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bor=
der-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word=
-wrap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprin=
t"><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> x </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: #606=
;" class=3D"styled-by-prettify">Struct</span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">(...);</span></div></code></div><br>If you did =
any of these other <i>perfectly valid</i> and very common forms of initiali=
zation, your idea doesn&#39;t work:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" class=3D"st=
yled-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=
">Struct</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: #606;" class=3D"styled-by-prettify">Struct</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> x</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">(...);</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #606;" class=3D"styled-by-prettify">Struct</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;" clas=
s=3D"styled-by-prettify"><br></span><span style=3D"color: #606;" class=3D"s=
tyled-by-prettify">Struct</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> x </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Struct</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">(...);</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #800;" class=3D"styled-by-prettify">//Not everyone uses auto =
everywhere</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
<br></span><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> x </span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"> make_unique</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Struct</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;(...);</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #8=
00;" class=3D"styled-by-prettify">//Oh right, heap allocation</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify"> </span><span style=3D"color: #008;" class=3D"st=
yled-by-prettify">new</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify=
">Struct</span><span style=3D"color: #660;" class=3D"styled-by-prettify">(.=
...);</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </spa=
n><span style=3D"color: #800;" class=3D"styled-by-prettify">//Even old-scho=
ol heap allocation fails</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"><br></span></div></code></div><br>Plus, if you used that type=
name in any other way, your code is broken. In particular, you cannot:<br><=
ul><li>Use it as a template argument.</li><li>Get a member pointer to one o=
f the members of the struct, perhaps for a callback.</li><li>Make a non-sta=
tic data member of that class type.</li><li>Call the destructor directly.</=
li><li>Use it as a (non-deduced) return type of a function.<br></li></ul>So=
 I&#39;m not buying that this is a particularly useful case.<br><br>If you =
want to argue that transparently exchanging a struct for a function happens=
 &quot;very often&quot;, again prove it. Show me a codebase where this has =
happened a lot. Show me libraries that has gone though API revisions that t=
ransparently turn a struct into a function. And show me that users have not=
 been broken by these changes.<br><br>You&#39;re the one making the argumen=
t for this idea, so the burden of proof is on you. You claim that this is a=
 common thing, so prove it.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_28_1794795384.1450448190974--
------=_Part_27_447031498.1450448190973--

.

------=_Part_668_1901462102.1450449765999
Content-Type: multipart/alternative;
 boundary="----=_Part_669_883021975.1450449766000"

------=_Part_669_883021975.1450449766000
Content-Type: text/plain; charset=UTF-8

On Friday, December 18, 2015 at 7:11:44 AM UTC-5, Viacheslav Usov wrote:
>
> On Thu, Dec 17, 2015 at 8:24 PM, Richard Smith <ric...@metafoo.co.uk
> <javascript:>> wrote:
>
> > For prior work in this area, see section 2 of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf -- this
> was considered when the "using X = Y;" syntax was first proposed as a
> possible eventual extension.
>
> Thanks for the pointer. What I see there, though, is that the syntax was
> *not* proposed, they merely admitted it was possible for things other
> than types. It seems they were quite certain that the extension covering
> namespaces would be a good thing: "The alias-declaration syntax appears to
> be more general and more uniform. It also contains the traditional
> using-declaration as a special case." I am not sure why the same could not
> be said verbatim in section 2.3.
>

>
It is definitely true that a general mechanism that can select and define
> an alias for an entity is a good thing.
>

No, it is not "definitely true"; that's what you're trying to prove. You
cannot prove something by assuming it.


> The need to lift some elaborately decorated entities into current scope
> and use them via aliases is real, it is understood and addressed in the
> current language, except this is done via three different syntaxes (or
> four, if we count pointers).
>

And all of these create different constructs.

Namespaces are different from typenames. Typenames are different from
variables. Variables are different from functions. Having a single syntax
that treats these "aliases" of different things as though they were the
same is *lying* to the coder by making them think that they are
interchangeable.

Also, a pointer is not an alias. It's not even a reference; it's an *object*
..

If nothing else, the uniform syntax addressing the need would be easy to
> learn, and add a bit more of DRY to the language. This is similar to how
> much more clarity we have now with auto.
>

You've made three claims here: ease of learning, removing repetition, and
improving clarity. I'll take them one at a time.

The ease of learning issue. Well, your syntax only covers the case of
creating non-const l-value references from an actual variable. That is, it
only covers this:

auto & var = other_var;
using var = other_var;

Well, what if the user needs to create a const reference? Are you going to
allow:

const using var = other_var;

But we're talking about learning here. And learning is exactly the problem.
See, the user still needs to know how to create references, because they're
going to be using them in other ways. For example:

for(auto &var: some_vector)
{...}

Is the user going to be able to use `using` syntax to create references
from that? If not, then the user *still* has to know how the old syntax
works. And that's not the only place where they'll have to declare
references. The user still has to know how to declare reference variables
as function parameters too. There'd be no reasonable way to stick `using`
in there.

So the *only* place where learning would allegedly be eased is when you are
declaring a naked stack variable declared as `auto &`. But the user already
needs to know how `auto` works as well as how references work. So... how
have you improved learning, when they still need to know the old way too?

All you've done is given users *more* to learn, not less; that's not
helping them learn. So long as the user still needs to use references
directly, I see no benefit to learning this `using` syntax.

As for repetition and clarity... what are you talking about? Where is the
repetition you're trying to avoid? Where is the lack of clarity that you
want to impvoe? Your suggestion is to exchange this:

namespace Name = OtherNamespace;
using Type = OtherType;
auto &Var = OtherVariable;

For this:

using Name = OtherNamespace;
using Type = OtherType;
using Var = OtherVariable;

The current case has no repetition. Indeed, the two cases have almost the
exact same number of tokens (the reference case requiring the `&` token),
and the difference in keystrokes between them is minimal.

The current case is no less clear than what you want. It's readily apparent
what's going on in both cases. So you aren't improving clarity at all.

So again, I find your motivation for this proposal lacking.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Friday, December 18, 2015 at 7:11:44 AM UTC-5, Viacheslav Usov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border=
-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Thu, Dec 17, 2015 at 8:24 PM, Richard Smith <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"y11Q-inSDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">ric...@metafoo.co.uk</a>&gt;</span> wrote:</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">&gt; For prior work in this ar=
ea, see section 2 of=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21=
/docs/papers/2003/n1489.pdf" target=3D"_blank" rel=3D"nofollow" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-=
std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return true;">htt=
p://www.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2003/n1489.pdf</a=
> -- this was considered when the &quot;using X =3D Y;&quot; syntax was fir=
st proposed as a possible eventual extension.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Thanks for the pointer. What I see =
there, though, is that the syntax was <i>not</i>=C2=A0proposed, they merely=
 admitted it was possible for things other than types. It seems they were q=
uite certain that the extension covering namespaces would be a good thing: =
&quot;The alias-declaration syntax appears to be more general and more unif=
orm.
It also contains the traditional using-declaration as a special case.&quot;=
 I am not sure why the same could not be said verbatim in section 2.3.</div=
></div></div></blockquote><blockquote style=3D"margin: 0px 0px 0px 0.8ex; b=
order-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;" class=3D"gmai=
l_quote"><div>=C2=A0</div></blockquote><blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote"></div><div class=
=3D"gmail_quote">It is definitely true that a general mechanism that can se=
lect and define an alias for an entity is a good thing.</div></div></div></=
blockquote><div><br>No, it is not &quot;definitely true&quot;; that&#39;s w=
hat you&#39;re trying to prove. You cannot prove something by assuming it.<=
br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote">The need to lift some elaborately decorat=
ed entities into current scope and use them via aliases is real, it is unde=
rstood and addressed in the current language, except this is done via three=
 different syntaxes (or four, if we count pointers).</div></div></div></blo=
ckquote><div><br>And all of these create different constructs.<br><br>Names=
paces are different from typenames. Typenames are different from variables.=
 Variables are different from functions. Having a single syntax that treats=
 these &quot;aliases&quot; of different things as though they were the same=
 is <i>lying</i> to the coder by making them think that they are interchang=
eable.<br><br>Also, a pointer is not an alias. It&#39;s not even a referenc=
e; it&#39;s an <i>object</i>.<br><br></div><blockquote class=3D"gmail_quote=
" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding=
-left: 1ex;"><div dir=3D"ltr"><div><div class=3D"gmail_quote">If nothing el=
se, the uniform syntax addressing the need would be easy to learn, and add =
a bit more of DRY to the language. This is similar to how much more clarity=
 we have now with auto.</div></div></div></blockquote><div><br>You&#39;ve m=
ade three claims here: ease of learning, removing repetition, and improving=
 clarity. I&#39;ll take them one at a time.<br><br>The ease of learning iss=
ue. Well, your syntax only covers the case of creating non-const l-value re=
ferences from an actual variable. That is, it only covers this:<br><br><div=
 class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); borde=
r-color: rgb(187, 187, 187); border-style: solid; border-width: 1px; word-w=
rap: break-word;"><code class=3D"prettyprint"><div class=3D"subprettyprint"=
><span style=3D"color: #008;" class=3D"styled-by-prettify">auto</span><span=
 style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">&amp;</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;"=
 class=3D"styled-by-prettify">var</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> other_var</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">using</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n style=3D"color: #008;" class=3D"styled-by-prettify">var</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> other_var</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">;</span></div></code></div><br>Well, what if=
 the user needs to create a const reference? Are you going to allow:<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">const</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">var</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> other_var</span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify">;</span></div></code></div><br>But we&#39;re talking about=
 learning here. And learning is exactly the problem. See, the user still ne=
eds to know how to create references, because they&#39;re going to be using=
 them in other ways. For example:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">for</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #008;" class=3D"style=
d-by-prettify">auto</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&amp;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">var</=
span><span style=3D"color: #660;" class=3D"styled-by-prettify">:</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> some_vector</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">)</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"co=
lor: #660;" class=3D"styled-by-prettify">{...}</span></div></code></div><br=
>Is the user going to be able to use `using` syntax to create references fr=
om that? If not, then the user <i>still</i> has to know how the old syntax =
works. And that&#39;s not the only place where they&#39;ll have to declare =
references. The user still has to know how to declare reference variables a=
s function parameters too. There&#39;d be no reasonable way to stick `using=
` in there.<br><br>So the <i>only</i> place where learning would allegedly =
be eased is when you are declaring a naked stack variable declared as `auto=
 &amp;`. But the user already needs to know how `auto` works as well as how=
 references work. So... how have you improved learning, when they still nee=
d to know the old way too?<br><br>All you&#39;ve done is given users <i>mor=
e</i> to learn, not less; that&#39;s not helping them learn. So long as the=
 user still needs to use references directly, I see no benefit to learning =
this `using` syntax.<br><br>As for repetition and clarity... what are you t=
alking about? Where is the repetition you&#39;re trying to avoid? Where is =
the lack of clarity that you want to impvoe? Your suggestion is to exchange=
 this:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(250=
, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; border-=
width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div class=
=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-prettif=
y">namespace</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
"> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Name</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">OtherNamespace</span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><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">Type</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> </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">OtherType</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">auto</span><span style=3D"color:=
 #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" c=
lass=3D"styled-by-prettify">&amp;</span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Var</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-pr=
ettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">OtherVar=
iable</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</sp=
an></div></code></div><br>For this:<br><br><div class=3D"prettyprint" style=
=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187);=
 border-style: solid; border-width: 1px; word-wrap: break-word;"><code clas=
s=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;=
" class=3D"styled-by-prettify">using</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"sty=
led-by-prettify">Name</span><span style=3D"color: #000;" class=3D"styled-by=
-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </sp=
an><span style=3D"color: #606;" class=3D"styled-by-prettify">OtherNamespace=
</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span st=
yle=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Type</span><span style=3D"color: #000=
;" class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"sty=
led-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-pr=
ettify">OtherType</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><b=
r></span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</s=
pan><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span=
 style=3D"color: #606;" class=3D"styled-by-prettify">Var</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;=
" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">OtherVariable</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">;</span></div></code></div><br>The current case =
has no repetition. Indeed, the two cases have almost the exact same number =
of tokens (the reference case requiring the `&amp;` token), and the differe=
nce in keystrokes between them is minimal.<br><br>The current case is no le=
ss clear than what you want. It&#39;s readily apparent what&#39;s going on =
in both cases. So you aren&#39;t improving clarity at all.<br></div><br>So =
again, I find your motivation for this proposal lacking.<br><br>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_669_883021975.1450449766000--
------=_Part_668_1901462102.1450449765999--

.

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

On Fri, Dec 18, 2015 at 3:16 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> There's a huge difference between "deduce a different type" and "turn a
typename into a function."

This is a straw man; nothing in my proposal suggests the latter.

> If you want to argue that *transparently* exchanging a struct for a
function is something you can do, prove it

You want to argue about that. I have no interest in that.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 3:16 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; There&#39;s a huge difference between &quot;deduce a different t=
ype&quot; and &quot;turn a typename into a function.&quot;</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">This is a straw man; =
nothing in my proposal suggests the latter.</div><div class=3D"gmail_quote"=
><div><br></div><div>&gt; If you want to argue that <i>transparently</i> ex=
changing a struct for a function is something you can do, prove it</div><di=
v><br></div><div>You want to argue about that. I have no interest in that.<=
/div><div><br></div><div>Cheers,</div><div>V.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e011834263dc54805272d2b21--

.

------=_Part_934_1453687148.1450450106669
Content-Type: multipart/alternative;
 boundary="----=_Part_935_2098048050.1450450106670"

------=_Part_935_2098048050.1450450106670
Content-Type: text/plain; charset=UTF-8



On Friday, December 18, 2015 at 9:43:57 AM UTC-5, Viacheslav Usov wrote:
>
> On Fri, Dec 18, 2015 at 3:16 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > There's a huge difference between "deduce a different type" and "turn a
> typename into a function."
>
> This is a straw man; nothing in my proposal suggests the latter.
>
> > If you want to argue that *transparently* exchanging a struct for a
> function is something you can do, prove it
>
> You want to argue about that. I have no interest in that.
>

Then *why did you bring it up?* Here is your post that started this path of
discussion:

Motivation: the current means of creating alternative names for language
> entities create leaky abstractions and have corresponding maintenance
> costs. Consider this:
>
> // unit 1
> struct A {};
>
> // unit 2
> using X = A;
> auto a = X();
>
> At some later time, the code in unit 1 changes to:
>
> B A();
>
> The code in unit 2 is no longer valid.
>

You claimed that this, the ability to transform a typename into a function,
was a motivating example for your proposal.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Friday, December 18, 2015 at 9:43:57 AM UTC-5, Viacheslav Usov w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote">On Fri, Dec 18, 2015 at 3:16 PM, Nicol Bolas <span =
dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-ma=
ilto=3D"wrCfV3jaDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;java=
script:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;ret=
urn true;">jmck...@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">&gt; There&#39;s a huge differ=
ence between &quot;deduce a different type&quot; and &quot;turn a typename =
into a function.&quot;</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">This is a straw man; nothing in my proposal suggests the l=
atter.</div><div class=3D"gmail_quote"><div><br></div><div>&gt; If you want=
 to argue that <i>transparently</i> exchanging a struct for a function is s=
omething you can do, prove it</div><div><br></div><div>You want to argue ab=
out that. I have no interest in that.<br></div></div></div></div></blockquo=
te><div><br>Then <b><i>why did you bring it up?</i></b> Here is your post t=
hat started this path of discussion:<br><br><blockquote style=3D"margin: 0p=
x 0px 0px 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1=
ex;" class=3D"gmail_quote"><div>Motivation: the current means of creating a=
lternative names for=20
language entities create leaky abstractions and have corresponding=20
maintenance costs. Consider this:</div><div><br></div><div>// unit 1</div><=
div>struct A {};</div><div><br></div><div>// unit 2</div><div>using X =3D A=
;</div><div>auto a =3D X();<br></div><div><br></div><div>At some later time=
, the code in unit 1 changes to:</div><div><br></div><div>B A();</div><div>=
<br></div><div>The code in unit 2 is no longer valid.</div></blockquote><di=
v><br>You claimed that this, the ability to transform a typename into a fun=
ction, was a motivating example for your proposal.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_935_2098048050.1450450106670--
------=_Part_934_1453687148.1450450106669--

.

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

On Fri, Dec 18, 2015 at 3:42 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> No, it is not "definitely true"; that's what you're trying to prove. You
cannot prove something by assuming it.

We are not proving a theorem here, Nicol. If you find that "a general
mechanism that can select and define an alias for an entity is a good
thing" needs to be substantiated further, then I can only suggest that you
should practice programming for a few more years.

> Having a single syntax that treats these "aliases" of different things as
though they were the same is *lying* to the coder by making them think that
they are interchangeable.

Nonsense. The proposed syntax does not treat aliases as though they were
the same; it merely creates them uniformly.

> Also, a pointer is not an alias. It's not even a reference; it's an
*object*.

Are you arguing just for the sake of arguing?

> Well, what if the user needs to create a const reference? Are you going
to allow:

In what clause of my proposal have you found that? Is this another straw
man?

And by the way, in my proposal I identified using X = Y with auto &X = Y
when Y is a variable or a function; this is, however, not essential for the
proposal. The desired semantics is "X is another name for Y", not really "X
is a reference to Y" even though the latter means very nearly the former.

> All you've done is given users *more* to learn, not less; that's not
helping them learn.

No. using X = Y is already something that must be learnt. It is easier to
learn that everything aliasable can be aliased with this one mechanism.

> The current case has no repetition.

Repetition here is not in keystrokes. It is in having to express, again,
that OtherNamespace is a namespace, OtherType is a type, and OtherVariable
is a variable.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 3:42 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; No, it is not &quot;definitely true&quot;; that&#39;s what you&#=
39;re trying to prove. You cannot prove something by assuming it.</div><div=
 class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">We are not prov=
ing a theorem here, Nicol. If you find that<span style=3D"font-size:12.8px"=
>=C2=A0&quot;a general mechanism that can select and define an alias for an=
 entity is a good thing&quot; needs to be substantiated further, then I can=
 only suggest that you should practice programming for a few more years.</s=
pan></div><div class=3D"gmail_quote"><div><br></div><div>&gt; Having a sing=
le syntax that treats these &quot;aliases&quot; of different things as thou=
gh they were the same is <i>lying</i> to the coder by making them think tha=
t they are interchangeable.</div><div><br></div><div>Nonsense. The proposed=
 syntax does not treat aliases as though they were the same; it merely crea=
tes them uniformly.</div><div><br></div><div>&gt; Also, a pointer is not an=
 alias. It&#39;s not even a reference; it&#39;s an <i>object</i>.</div><div=
><br></div><div>Are you arguing just for the sake of arguing?</div><div><br=
></div><div>&gt; Well, what if the user needs to create a const reference? =
Are you going to allow:</div><div><br></div><div>In what clause of my propo=
sal have you found that? Is this another straw man?</div><div><br></div><di=
v><div>And by the way, in my proposal I identified using X =3D Y with auto =
&amp;X =3D Y when Y is a variable or a function; this is, however, not esse=
ntial for the proposal. The desired semantics is &quot;X is another name fo=
r Y&quot;, not really &quot;X is a reference to Y&quot; even though the lat=
ter means very nearly the former.</div></div><div><br></div><div>&gt; All y=
ou&#39;ve done is given users <i>more</i> to learn, not less; that&#39;s no=
t helping them learn.</div><div><br></div><div>No. using X =3D Y is already=
 something that must be learnt. It is easier to learn that everything alias=
able can be aliased with this one mechanism.</div><div><br></div><div>&gt; =
The current case has no repetition.</div><div><br></div><div>Repetition her=
e is not in keystrokes. It is in having to express, again, that OtherNamesp=
ace is a namespace, OtherType is a type, and OtherVariable is a variable.</=
div><div><br></div><div>Cheers,<br></div><div>V.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e01183426e0bc9205272df1ef--

.

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

On Fri, Dec 18, 2015 at 3:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Then *why did you bring it up?*

To illustrate this:

> Motivation: the current means of creating alternative names for language
entities create leaky abstractions and have corresponding maintenance costs.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 3:48 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; Then <b><i>why did you bring it up?</i></b></div><div class=3D"g=
mail_quote"><br></div><div class=3D"gmail_quote">To illustrate this:</div><=
div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; Motivat=
ion: the current means of creating alternative names for=20
language entities create leaky abstractions and have corresponding=20
maintenance costs.</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">Cheers,</div><div class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0122ac9c77a03105272dfead--

.

On 2015-12-18 09:43, Viacheslav Usov wrote:
> On Fri, Dec 18, 2015 at 3:16 PM, Nicol Bolas wrote:
>> If you want to argue that *transparently* exchanging a struct for a
>> function is something you can do, prove it
>
> You want to argue about that. I have no interest in that.

Ahem:

On 2015-12-18 06:52, Viacheslav Usov wrote:
> On Thu, Dec 17, 2015 at 6:48 PM, Nicol Bolas wrote:
>> You cannot exchange a struct for a *function*.
> Except when we can. And we can do so very often.

If that's not "interest", then I have no idea what you are trying to say.

Also, the basis of your proposal is to blur the line between types,
functions, and variables. Which has been pointed out repeatedly seems
like a bad idea.


--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-18 09:16, Nicol Bolas wrote:
> On Friday, December 18, 2015 at 6:52:57 AM UTC-5, Viacheslav Usov wrote:
>> On Thu, Dec 17, 2015 at 6:48 PM, Nicol Bolas wrote:
>>> You cannot exchange a struct for a *function*.
>>
>> Except when we can. And we can do so very often.
>>
>> The premises of your argument are invalid.
>
> Declaring something to be invalid does not make it invalid.
>
> If you want to argue that *transparently* exchanging a struct for a
> function is something you can do, prove it. Show me under what
> circumstances this is acceptable. And then show that the other
> circumstances which would prevent it are not usable.

  class Foo { /* details unimportant */ };
  auto ct = Foo; // note; no construction
  auto x = ct{}; // construction
  assert(std::is_same_type<decltype(x), Foo>::value);

....of course that doesn't work in C++. Making it work in a strongly
typed language would be... difficult. In particular, I don't see how
runtime method dispatch could be made to work (not, anyway, without
twisting the language into a bowl of spaghetti).

It works in Python ;-). But I don't see it happening in C++.

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> If that's not "interest", then I have no idea what you are trying to say.

I said that "You cannot exchange a struct for a *function*" was invalid.
But that is not something that I really want to talk about; my proposal is
orthogonal to that.

> Also, the basis of your proposal is to blur the line between types,
functions, and variables.

Then explain why the use of auto is not to blur the line between different
types; or why that is not a bad idea.

Before we had the revamped auto, one would have to say to the compiler:
"create a variable of type X and initialize it from the expression" (whose
type must be convertible to Y; this and further parenthetical remarks are
not to be spelled out). Now we just say "please create and initialize a
variable from the expression" (choosing an appropriate type).

With the current means of aliasing, we have to say: "we both know that Y is
a namespace (or a type; or a var). Let X be another name for that." What I
am proposing is a way of saying "Let X be another name for Y" (whatever Y
is, provided it can be validly aliased).

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">&gt; If that&#39;s not &quot;interest&quot;, then I ha=
ve no idea what you are trying to say.<br></div><div class=3D"gmail_quote">=
<div><br></div><div>I said that &quot;<span style=3D"font-size:12.8px">You =
cannot exchange a struct for a *function*&quot; was invalid. But that is no=
t something that I really want to talk about; my proposal is orthogonal to =
that.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><d=
iv><span style=3D"font-size:12.8px">&gt;=C2=A0</span>Also, the basis of you=
r proposal is to blur the line between types, functions, and variables.</di=
v><div><br></div><div>Then explain why the use of auto is not to blur the l=
ine between different types; or why that is not a bad idea.</div><div><br><=
/div><div>Before we had the revamped auto, one would have to say to the com=
piler: &quot;create a variable of type X and initialize it from the express=
ion&quot; (whose type must be convertible to Y; this and further parentheti=
cal remarks are not to be spelled out). Now we just say &quot;please create=
 and initialize a variable from the expression&quot; (choosing an appropria=
te type).</div><div><br></div><div>With the current means of aliasing, we h=
ave to say: &quot;we both know that Y is a namespace (or a type; or a var).=
 Let X be another name for that.&quot; What I am proposing is a way of sayi=
ng &quot;Let X be another name for Y&quot; (whatever Y is, provided it can =
be validly aliased).</div><div><br></div><div>Cheers,</div><div>V.</div></d=
iv></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0149c94ea288a705272e6fad--

.

On 18 December 2015 at 18:14, Viacheslav Usov <via.usov@gmail.com> wrote:
> With the current means of aliasing, we have to say: "we both know that Y is
> a namespace (or a type; or a var). Let X be another name for that." What I
> am proposing is a way of saying "Let X be another name for Y" (whatever Y
> is, provided it can be validly aliased).


While that may be reasonable, it shouldn't be done so that people who use
the current way of saying "let X be another name for type Y, and if Y
isn't a type,
the code must be ill-formed" have their code broken. In other words, you should
strive for a different syntax for such "universal aliases", whatever
that syntax might be.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 2015-12-18 11:14, Viacheslav Usov wrote:
> On Fri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke wrote:
>> Also, the basis of your proposal is to blur the line between types,
>> functions, and variables.
>
> Then explain why the use of auto is not to blur the line between different
> types; or why that is not a bad idea.

That's like saying "because it's okay to blur the lines between a
Rottweiler and a Pug, it must also be okay to blur the line between a
dog and a cucumber... or a socket wrench".

Uh... yeah. I think that sums it up nicely.

(Also, what Ville said.)

--
Matthew

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 18, 2015 at 5:18 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> While that may be reasonable, it shouldn't be done so that people who use
the current way of saying "let X be another name for type Y, and if Y isn't
a type, the code must be ill-formed" have their code broken.

That is a good point. However, as far as I can tell, and I can easily be
mistaken here, using X = Y when Y is not a type is undefined behaviour
currently.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 5:18 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><div><br></div><div>&gt; While that ma=
y be reasonable, it shouldn&#39;t be done so that people who use the curren=
t way of saying &quot;let X be another name for type Y, and if Y isn&#39;t =
a type, the code must be ill-formed&quot; have their code broken.</div><div=
><br></div><div>That is a good point. However, as far as I can tell, and I =
can easily be mistaken here, using X =3D Y when Y is not a type is undefine=
d behaviour currently.</div><div><br></div><div>Cheers,</div><div>V.</div><=
/div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7b471e00b4255905272eaa88--

.

On 18 December 2015 at 18:31, Viacheslav Usov <via.usov@gmail.com> wrote:
> That is a good point. However, as far as I can tell, and I can easily be
> mistaken here, using X = Y when Y is not a type is undefined behaviour
> currently.


I don't know how you come to such a conclusion; it's not undefined behaviour,
it's ill-formed.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 18, 2015 at 5:28 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> That's like saying "because it's okay to blur the lines between a
Rottweiler and a Pug, it must also be okay to blur the line between a dog
and a cucumber... or a socket wrench".

It might be. Or may not. Unless you explain why doing it is OK in one case
and not OK in the other, I do not think we can argue about that rationally.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 5:28 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">&gt; That&#39;s like saying &quot;because it&#39;s oka=
y to blur the lines between a Rottweiler and a Pug, it must also be okay to=
 blur the line between a dog and a cucumber... or a socket wrench&quot;.</d=
iv><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">It might=
 be. Or may not. Unless you explain why doing it is OK in one case and not =
OK in the other, I do not think we can argue about that rationally.</div><d=
iv class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div>=
<div class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7b471e0044fe3705272ebdb6--

.

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

On Fri, Dec 18, 2015 at 5:33 PM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> I don't know how you come to such a conclusion; it's not undefined
behaviour, it's ill-formed.

As I said, I could easily have been mistaken :)

I accept your point as a valid consideration against the proposed syntax.
Yet, as far as I can tell, making ill-formed code well-formed has not
always been enough to dismiss a proposal.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 5:33 PM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote">&gt; I don&#39;t know how you come to such a co=
nclusion; it&#39;s not undefined behaviour, it&#39;s ill-formed.</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">As I said, I cou=
ld easily have been mistaken :)</div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">I accept your point as a valid consideration agai=
nst the proposed syntax. Yet, as far as I can tell, making ill-formed code =
well-formed has not always been enough to dismiss a proposal.</div><div cla=
ss=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,<br></div><d=
iv class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113da78e4a855305272eff14--

.

On 18 December 2015 at 18:54, Viacheslav Usov <via.usov@gmail.com> wrote:
>> I don't know how you come to such a conclusion; it's not undefined
>> behaviour, it's ill-formed.
> As I said, I could easily have been mistaken :)
> I accept your point as a valid consideration against the proposed syntax.
> Yet, as far as I can tell, making ill-formed code well-formed has not always
> been enough to dismiss a proposal.


In this case I daresay it would be.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Friday 18 December 2015 16:42:59 Viacheslav Usov wrote:
> On Fri, Dec 18, 2015 at 3:48 PM, Nicol Bolas <jmckesson@gmail.com> wrote:
> > Then *why did you bring it up?*
>
> To illustrate this:
> > Motivation: the current means of creating alternative names for language
>
> entities create leaky abstractions and have corresponding maintenance costs.

That's because it was never intended to be an abstraction in the first place.

You're the one proposing creating an abstraction layer.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 18, 2015 at 8:18 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 18 December 2015 at 18:14, Viacheslav Usov <via.usov@gmail.com> wrote:
> > With the current means of aliasing, we have to say: "we both know that Y
> is
> > a namespace (or a type; or a var). Let X be another name for that." What
> I
> > am proposing is a way of saying "Let X be another name for Y" (whatever Y
> > is, provided it can be validly aliased).
>
> While that may be reasonable, it shouldn't be done so that people who use
> the current way of saying "let X be another name for type Y, and if Y
> isn't a type,
> the code must be ill-formed" have their code broken. In other words, you
> should
> strive for a different syntax for such "universal aliases", whatever
> that syntax might be.


If you're saying that we can't use "using X = Y;" for anything other than
types because we already use it for types, then I think we made a major
mistake using such a general syntax for such a specific thing.

I think the feature being proposed is useful, but I don't think the
discussion thus far has really captured a good motivation for it. So here's
why I want it:

Refactoring.

This feature allows an entity to be incrementally renamed, in a uniform way
that does not depend on what kind of entity you started with. (You first
add "using NewName = OldName;", then update all the users, then remove the
alias declaration.) To do this today involves using a different syntax,
possibly with subtly-different semantics, for each different kind of entity
(for examples where this is hard today, try renaming a template or an
overload set of functions).

This is exactly analogous to using-declarations, which allow an entity to
be incrementally moved from one namespace to another, independent of the
kind of entity.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 8:18 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilaine=
n@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span c=
lass=3D"">On 18 December 2015 at 18:14, Viacheslav Usov &lt;<a href=3D"mail=
to:via.usov@gmail.com">via.usov@gmail.com</a>&gt; wrote:<br>
&gt; With the current means of aliasing, we have to say: &quot;we both know=
 that Y is<br>
&gt; a namespace (or a type; or a var). Let X be another name for that.&quo=
t; What I<br>
&gt; am proposing is a way of saying &quot;Let X be another name for Y&quot=
; (whatever Y<br>
&gt; is, provided it can be validly aliased).<br><br>
</span>While that may be reasonable, it shouldn&#39;t be done so that peopl=
e who use<br>
the current way of saying &quot;let X be another name for type Y, and if Y<=
br>
isn&#39;t a type,<br>
the code must be ill-formed&quot; have their code broken. In other words, y=
ou should<br>
strive for a different syntax for such &quot;universal aliases&quot;, whate=
ver<br>
that syntax might be.</blockquote><div><br></div><div>If you&#39;re saying =
that we can&#39;t use &quot;using X =3D Y;&quot; for anything other than ty=
pes because we already use it for types, then I think we made a major mista=
ke using such a general syntax for such a specific thing.</div><div><br></d=
iv><div>I think the feature being proposed is useful, but I don&#39;t think=
 the discussion thus far has really captured a good motivation for it. So h=
ere&#39;s why I want it:</div><div><br></div><div>Refactoring.</div><div><b=
r></div><div>This feature allows an entity to be incrementally renamed, in =
a uniform way that does not depend on what kind of entity you started with.=
 (You first add &quot;using NewName =3D OldName;&quot;, then update all the=
 users, then remove the alias declaration.) To do this today involves using=
 a different syntax, possibly with subtly-different semantics, for each dif=
ferent kind of entity (for examples where this is hard today, try renaming =
a template or an overload set of functions).</div><div><br></div><div>This =
is exactly analogous to using-declarations, which allow an entity to be inc=
rementally moved from one namespace to another, independent of the kind of =
entity.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1142d87c43af33052730db95--

.

On 18 December 2015 at 21:07, Richard Smith <richard@metafoo.co.uk> wrote:
>> While that may be reasonable, it shouldn't be done so that people who use
>> the current way of saying "let X be another name for type Y, and if Y
>> isn't a type,
>> the code must be ill-formed" have their code broken. In other words, you
>> should
>> strive for a different syntax for such "universal aliases", whatever
>> that syntax might be.
> If you're saying that we can't use "using X = Y;" for anything other than
> types because we already use it for types, then I think we made a major
> mistake using such a general syntax for such a specific thing.

Perhaps so, but that mistake was made before C++11 was published, and
changing it is a silent breaking change that potentially turns
compile-time errors
into run-time errors.

> I think the feature being proposed is useful, but I don't think the
> discussion thus far has really captured a good motivation for it. So here's
> why I want it:
> Refactoring.
> This feature allows an entity to be incrementally renamed, in a uniform way
> that does not depend on what kind of entity you started with. (You first add
> "using NewName = OldName;", then update all the users, then remove the alias
> declaration.) To do this today involves using a different syntax, possibly
> with subtly-different semantics, for each different kind of entity (for
> examples where this is hard today, try renaming a template or an overload
> set of functions).

N.B. I have no doubt a facility like this would be useful, nor do I have trouble
imagining practical uses for it.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Fri, Dec 18, 2015 at 11:40 AM, Ville Voutilainen <
ville.voutilainen@gmail.com> wrote:

> On 18 December 2015 at 21:07, Richard Smith <richard@metafoo.co.uk> wrote:
> >> While that may be reasonable, it shouldn't be done so that people who
> use
> >> the current way of saying "let X be another name for type Y, and if Y
> >> isn't a type,
> >> the code must be ill-formed" have their code broken. In other words, you
> >> should
> >> strive for a different syntax for such "universal aliases", whatever
> >> that syntax might be.
> > If you're saying that we can't use "using X = Y;" for anything other than
> > types because we already use it for types, then I think we made a major
> > mistake using such a general syntax for such a specific thing.
>
> Perhaps so, but that mistake was made before C++11 was published, and
> changing it is a silent breaking change that potentially turns
> compile-time errors
> into run-time errors.


Do you have a specific example in mind? I can imagine contrived cases, but
so far I've failed at inventing one that is plausible.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 11:40 AM, Ville Voutilainen <span dir=3D"ltr">&lt;<a hr=
ef=3D"mailto:ville.voutilainen@gmail.com" target=3D"_blank">ville.voutilain=
en@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span =
class=3D"">On 18 December 2015 at 21:07, Richard Smith &lt;<a href=3D"mailt=
o:richard@metafoo.co.uk">richard@metafoo.co.uk</a>&gt; wrote:<br>
&gt;&gt; While that may be reasonable, it shouldn&#39;t be done so that peo=
ple who use<br>
&gt;&gt; the current way of saying &quot;let X be another name for type Y, =
and if Y<br>
&gt;&gt; isn&#39;t a type,<br>
&gt;&gt; the code must be ill-formed&quot; have their code broken. In other=
 words, you<br>
&gt;&gt; should<br>
&gt;&gt; strive for a different syntax for such &quot;universal aliases&quo=
t;, whatever<br>
&gt;&gt; that syntax might be.<br>
&gt; If you&#39;re saying that we can&#39;t use &quot;using X =3D Y;&quot; =
for anything other than<br>
&gt; types because we already use it for types, then I think we made a majo=
r<br>
&gt; mistake using such a general syntax for such a specific thing.<br>
<br>
</span>Perhaps so, but that mistake was made before C++11 was published, an=
d<br>
changing it is a silent breaking change that potentially turns<br>
compile-time errors<br>
into run-time errors.</blockquote><div><br></div><div>Do you have a specifi=
c example in mind? I can imagine contrived cases, but so far I&#39;ve faile=
d at inventing one that is plausible.</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a11433c0815989105273774a9--

.

On 19 December 2015 at 05:00, Richard Smith <richard@metafoo.co.uk> wrote:
>> Perhaps so, but that mistake was made before C++11 was published, and
>> changing it is a silent breaking change that potentially turns
>> compile-time errors
>> into run-time errors.
> Do you have a specific example in mind? I can imagine contrived cases, but
> so far I've failed at inventing one that is plausible.

I have nothing too specific, no. I suppose such breakage would need changing
an object to a type so that parentheses-initialization of an object of
said type would have
compatible syntax to invoking a function call on the object. Or vice
versa. Any examples
I can come up with are indeed also somewhat contrived, but I tend to
become categorically
cautious when compile-time errors turn into run-time behavior change,
if not outright
breakage. And again, sometimes that's very useful and exactly what's
intended; my concern
is for cases where it might not be. :)

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_524_1612591450.1450684374830
Content-Type: multipart/alternative;
 boundary="----=_Part_525_1776070382.1450684374830"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8817=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=8810:17:43=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote=
:
>>
>> Consider the following:
>>
>> namespace foo
>> {
>>     struct bar {};
>>     void baz() {}
>>     int qux;
>> }
>>
>> namespace A =3D foo;
>> using B =3D foo::bar;
>> auto &C =3D foo::baz;
>> auto &D =3D foo::qux;
>>
>> The question is, why do we have to use at least three different ways in=
=20
>> order to say use X as an alias of Y?
>>
>
> Because they're not the same thing. However much you may want to think of=
=20
> `C` and `D` as "aliases", they are not. They are *references to objects*.
>
> "Thing" is not a term in C++. So it is depend on the meaning of "thing".=
=20
They can be same things because `B`, `C`, `D` are "names", which denotes=20
"entities".

Variable of reference type may be used as aliases. They are similar in=20
usage.

One more example is namespace alias. Why they should have different syntax=
=20
at first? Though "auto& alias =3D ns;" is horrible without type system=20
support, but what about "using"?

Doing `B b{};` is legal. Doing `C c{};` is not. It makes perfect sense that=
=20
> creating a typename alias and creating an object reference would require=
=20
> different syntax. Just as creating a namespace alias uses different synta=
x=20
> from a typename alias.
>
=20
This is not required by "alias".

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8817=E6=97=A5=E6=98=9F=E6=9C=9F=E5=
=9B=9B UTC+8=E4=B8=8B=E5=8D=8810:17:43=EF=BC=8CNicol Bolas=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">O=
n Thursday, December 17, 2015 at 7:52:11 AM UTC-5, Viacheslav Usov wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-=
left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Consider the followi=
ng:<div><br></div><div>namespace foo</div><div>{</div><div>=C2=A0 =C2=A0 st=
ruct bar {};</div><div>=C2=A0 =C2=A0 void baz() {}</div><div>=C2=A0 =C2=A0 =
int qux;</div><div>}</div><div><br></div><div>namespace A =3D foo;</div><di=
v>using B =3D foo::bar;</div><div>auto &amp;C =3D foo::baz;</div><div>auto =
&amp;D =3D foo::qux;</div><div><br></div><div>The question is, why do we ha=
ve to use at least three different ways in order to say use X as an alias o=
f Y?</div></div></blockquote><div><br>Because they&#39;re not the same thin=
g. However much you may want to think of `C` and `D` as &quot;aliases&quot;=
, they are not. They are <i>references to objects</i>.<br><br></div></div><=
/blockquote><div>&quot;Thing&quot; is not a term in C++. So it is depend on=
 the meaning of &quot;thing&quot;. They can be same things because `B`, `C`=
, `D` are &quot;names&quot;, which denotes &quot;entities&quot;.<br><br>Var=
iable of reference type may be used as aliases. They are similar in usage.<=
br><br>One more example is namespace alias. Why they should have different =
syntax at first? Though &quot;auto&amp; alias =3D ns;&quot; is horrible wit=
hout type system support, but what about &quot;using&quot;?<br><br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>Doing `B b=
{};` is legal. Doing `C c{};` is not. It makes perfect sense that creating =
a typename alias and creating an object reference would require different s=
yntax. Just as creating a namespace alias uses different syntax from a type=
name alias.<br></div></div></blockquote><div>=C2=A0<br>This is not required=
 by &quot;alias&quot;.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_525_1776070382.1450684374830--
------=_Part_524_1612591450.1450684374830--

.

------=_Part_685_1045457567.1450686610995
Content-Type: multipart/alternative;
 boundary="----=_Part_686_1671731638.1450686610996"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=BA=94 UT=
C+8=E4=B8=8B=E5=8D=8810:42:46=EF=BC=8CNicol Bolas=E5=86=99=E9=81=93=EF=BC=
=9A
>
> On Friday, December 18, 2015 at 7:11:44 AM UTC-5, Viacheslav Usov wrote:
>>
>> On Thu, Dec 17, 2015 at 8:24 PM, Richard Smith <ric...@metafoo.co.uk>=20
>> wrote:
>>
>> > For prior work in this area, see section 2 of=20
>> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1489.pdf --=20
>> this was considered when the "using X =3D Y;" syntax was first proposed =
as a=20
>> possible eventual extension.
>>
>> Thanks for the pointer. What I see there, though, is that the syntax was=
=20
>> *not* proposed, they merely admitted it was possible for things other=20
>> than types. It seems they were quite certain that the extension covering=
=20
>> namespaces would be a good thing: "The alias-declaration syntax appears =
to=20
>> be more general and more uniform. It also contains the traditional=20
>> using-declaration as a special case." I am not sure why the same could n=
ot=20
>> be said verbatim in section 2.3.
>>
> =20
>>
> It is definitely true that a general mechanism that can select and define=
=20
>> an alias for an entity is a good thing.
>>
>
> No, it is not "definitely true"; that's what you're trying to prove. You=
=20
> cannot prove something by assuming it.
>
It is easy to illustrate the negative proposition: it's true that lack of=
=20
such abilities in the language is not a good thing, for some general tasks.=
=20
(Why we bother reflection if the language has already be homoiconic?)
=20

> =20
>
>> The need to lift some elaborately decorated entities into current scope=
=20
>> and use them via aliases is real, it is understood and addressed in the=
=20
>> current language, except this is done via three different syntaxes (or=
=20
>> four, if we count pointers).
>>
>
> And all of these create different constructs.
>
> Namespaces are different from typenames. Typenames are different from=20
> variables. Variables are different from functions. Having a single syntax=
=20
> that treats these "aliases" of different things as though they were the=
=20
> same is *lying* to the coder by making them think that they are=20
> interchangeable.
>
> Also, a pointer is not an alias. It's not even a reference; it's an=20
> *object*.
>
> The difference is by design. The design may be not good at first. It is=
=20
not immutable. At least, it should be open to be extended.

For example, there are no references in C. C++ copied most of the type=20
system, and added references (with other modifications). References are=20
definitely not object types. However, declared objects, functions and (non=
=20
data member) references can be all treated as "variables". When only=20
"variables" are needed (e.g. in lambda capture), you should not care=20
whether it is a reference or not. Note that C has no "variable" in this=20
means. It is nonsense to talk about the latter in C rules. The design of C=
=20
here is disabled.

For another example, there are no lambdas in C++98. C++11 added lambda=20
expressions. They are definitely not functions. However, they can be=20
treated as same thing in some rewriting systems, notably, lambda calculi.=
=20
C++ has no support to such systems. So if there are need to put them=20
together, current C++ rules are not enough. The design of current C++ here=
=20
is disabled.

Note that I don't support such proposals just for these reasons. The amount=
=20
of work to adding lambda expressions are reasonable and the work is=20
actually done, but change the whole type system or even typing discipline=
=20
is certainly not. Change rules out of the type system is even more=20
dangerous. But the underlying principle should be clear: prevent=20
modification of the language by the current design, not by intention.=20
Distinction on current features serve for different goals, but they do not=
=20
make the ability to ignore the differences invalid. (Oh, why some C guys=20
prefer manual single method dispatch over C++ virtual functions?)


--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8818=E6=97=A5=E6=98=9F=E6=9C=9F=E4=
=BA=94 UTC+8=E4=B8=8B=E5=8D=8810:42:46=EF=BC=8CNicol Bolas=E5=86=99=E9=81=
=93=EF=BC=9A<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Friday, Decembe=
r 18, 2015 at 7:11:44 AM UTC-5, Viacheslav Usov wrote:<blockquote class=3D"=
gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div dir=3D"ltr"><div><div class=3D"gmail_quote">On Thu,=
 Dec 17, 2015 at 8:24 PM, Richard Smith <span dir=3D"ltr">&lt;<a rel=3D"nof=
ollow">ric...@metafoo.co.uk</a>&gt;</span> wrote:</div><div class=3D"gmail_=
quote"><br></div><div class=3D"gmail_quote">&gt; For prior work in this are=
a, see section 2 of=C2=A0<a href=3D"http://www.open-std.org/jtc1/sc22/wg21/=
docs/papers/2003/n1489.pdf" rel=3D"nofollow" target=3D"_blank" onmousedown=
=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-st=
d.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return true;" oncli=
ck=3D"this.href=3D&#39;http://www.google.com/url?q\75http%3A%2F%2Fwww.open-=
std.org%2Fjtc1%2Fsc22%2Fwg21%2Fdocs%2Fpapers%2F2003%2Fn1489.pdf\46sa\75D\46=
sntz\0751\46usg\75AFQjCNG6tD5uEl_d1WhaBLAjns3uCOfE9g&#39;;return true;">htt=
p://www.open-std.org/<wbr>jtc1/sc22/wg21/docs/papers/<wbr>2003/n1489.pdf</a=
> -- this was considered when the &quot;using X =3D Y;&quot; syntax was fir=
st proposed as a possible eventual extension.</div><div class=3D"gmail_quot=
e"><br></div><div class=3D"gmail_quote">Thanks for the pointer. What I see =
there, though, is that the syntax was <i>not</i>=C2=A0proposed, they merely=
 admitted it was possible for things other than types. It seems they were q=
uite certain that the extension covering namespaces would be a good thing: =
&quot;The alias-declaration syntax appears to be more general and more unif=
orm.
It also contains the traditional using-declaration as a special case.&quot;=
 I am not sure why the same could not be said verbatim in section 2.3.</div=
></div></div></blockquote><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"=
><div>=C2=A0</div></blockquote><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><div class=3D"gmail_quote"></div><div class=3D"gmail_quot=
e">It is definitely true that a general mechanism that can select and defin=
e an alias for an entity is a good thing.</div></div></div></blockquote><di=
v><br>No, it is not &quot;definitely true&quot;; that&#39;s what you&#39;re=
 trying to prove. You cannot prove something by assuming it.<br></div></blo=
ckquote><div>It is easy to illustrate the negative proposition: it&#39;s tr=
ue that lack of such abilities in the language is not a good thing, for som=
e general tasks. (Why we bother reflection if the language has already be h=
omoiconic?)<br>=C2=A0<br></div><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0;margi=
n-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">=
<div><div class=3D"gmail_quote">The need to lift some elaborately decorated=
 entities into current scope and use them via aliases is real, it is unders=
tood and addressed in the current language, except this is done via three d=
ifferent syntaxes (or four, if we count pointers).</div></div></div></block=
quote><div><br>And all of these create different constructs.<br><br></div><=
/blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div>Namespaces ar=
e different from typenames. Typenames are different from variables. Variabl=
es are different from functions. Having a single syntax that treats these &=
quot;aliases&quot; of different things as though they were the same is <i>l=
ying</i> to the coder by making them think that they are interchangeable.<b=
r><br>Also, a pointer is not an alias. It&#39;s not even a reference; it&#3=
9;s an <i>object</i>.<br><br></div></blockquote><div>The difference is by d=
esign. The design may be not good at first. It is not <span class=3D"op_dic=
t3_font24 op_dict3_marginRight">immutable. At least, it should be open to b=
e extended.<br><br>For example, there are no references in C. C++ copied mo=
st of the type system, and added references (with other modifications). Ref=
erences are definitely not object types. However, declared objects, functio=
ns and (non data member) references can be all treated as &quot;variables&q=
uot;. When only &quot;variables&quot; are needed (e.g. in lambda capture), =
you should not care whether it is a reference or not. Note that C has no &q=
uot;variable&quot; in this means. It is nonsense to talk about the latter i=
n C rules. The design of C here is disabled.<br><br>For another example, th=
ere are no lambdas in C++98. C++11 added lambda expressions. They are defin=
itely not functions. However, they can be treated as same thing in some rew=
riting systems, notably, lambda calculi. C++ has no support to such systems=
.. So if there are need to put them together, current C++ rules are not enou=
gh. </span><span class=3D"op_dict3_font24 op_dict3_marginRight"><span class=
=3D"op_dict3_font24 op_dict3_marginRight">The design of current C++ here is=
 disabled.</span></span><br><br>Note that I don&#39;t support such proposal=
s just for these reasons. The amount of work to adding lambda expressions a=
re reasonable and the work is actually done, but change the whole type syst=
em or even typing discipline is certainly not. Change rules out of the type=
 system is even more dangerous. But the underlying principle should be clea=
r: prevent modification of the language by the current design, not by inten=
tion. Distinction on current features serve for different goals, but they d=
o not make the ability to ignore the differences invalid. (Oh, why some C g=
uys prefer manual single method dispatch over C++ virtual functions?)<br><b=
r><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_686_1671731638.1450686610996--
------=_Part_685_1045457567.1450686610995--

.

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

On Fri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
wrote:

> Also, the basis of your proposal is to blur the line between types,
functions, and variables.

I'd like to dispute this point once more.

Consider this code:

A::B();

Without seeing how A and B were defined or declared, one can only say that
A can be a namespace or a class type, and B can be a function, a type, or
an object, and I hope I have not missed some other possibility. It is
probably going to far if we say say that A and B can be pretty much
everything that C++ has to offer, but it is not much less than that.

Now, if we say (using proposed syntax)

using X = A;
using Y = B;
X::Y();

Has that blurred the line between types, functions and variables *any
more* than
it was blurred in the first excerpt? In my opinion, it has not. Your
objection, in my opinion, is in that the current semantics of using X = Y
is partly to *disambiguate* the nature of Y, making it clear it is a type
and nothing else, and we lose this feature in my proposal So it is entirely
equivalent to the objection by Ville Voutilaine.

But the question is, was using X = Y ever supposed to be such a
disambiguator? I doubt it was the case and I concur with Richard Smith that
we would be making a major mistake if we lock this syntax into this
unintended role.

I could trivially modify my proposal to satisfy Ville
Voutilaine's constraint, say into 'using X for Y'; but then we would have
yet another syntax for aliasing, despite the fact 'using X = Y' was clearly
earmarked for more general use in the original proposal.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke <span dir=3D"ltr">&lt;<a href=
=3D"mailto:mwoehlke.floss@gmail.com" target=3D"_blank">mwoehlke.floss@gmail=
..com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div c=
lass=3D"gmail_quote">&gt; Also, the basis of your proposal is to blur the l=
ine between types, functions, and variables.</div><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote">I&#39;d like to dispute this point o=
nce more.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">Consider this code:</div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">A::B();</div><div class=3D"gmail_quote"><br></div><div cl=
ass=3D"gmail_quote">Without seeing how A and B were defined or declared, on=
e can only say that A can be a namespace or a class type, and B can be a fu=
nction, a type, or an object, and I hope I have not missed some other possi=
bility. It is probably going to far if we say say that A and B can be prett=
y much everything that C++ has to offer, but it is not much less than that.=
</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Now, =
if we say (using proposed syntax)</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote">using X =3D A;</div><div class=3D"gmail_quote">=
using Y =3D B;</div><div class=3D"gmail_quote">X::Y();</div><div class=3D"g=
mail_quote"><br></div><div class=3D"gmail_quote">Has that blurred the line =
between types, functions and variables <i>any more</i>=C2=A0than it was blu=
rred in the first excerpt? In my opinion, it has not. Your objection, in my=
 opinion, is in that the current semantics of using X =3D Y is partly to <i=
>disambiguate</i>=C2=A0the nature of Y, making it clear it is a type and no=
thing else, and we lose this feature in my proposal So it is entirely equiv=
alent to the objection by<span style=3D"font-size:12.8px">=C2=A0Ville Vouti=
laine.</span></div><div class=3D"gmail_quote"><span style=3D"font-size:12.8=
px"><br></span></div><div class=3D"gmail_quote"><span style=3D"font-size:12=
..8px">But the question is, was using X =3D Y ever supposed to be such a dis=
ambiguator? I doubt it was the case and I concur with Richard Smith that we=
 would be making a major mistake if we lock this syntax into this unintende=
d role.</span></div><div class=3D"gmail_quote"><span style=3D"font-size:12.=
8px"><br></span></div><div class=3D"gmail_quote"><span style=3D"font-size:1=
2.8px">I could trivially modify my proposal to satisfy=C2=A0Ville Voutilain=
e&#39;s=C2=A0constraint, say into &#39;using X for Y&#39;; but then we woul=
d have yet another syntax for aliasing, despite the fact &#39;using X =3D Y=
&#39; was clearly earmarked for more general use in the original proposal.<=
/span></div><div class=3D"gmail_quote"><span style=3D"font-size:12.8px"><br=
></span></div><div class=3D"gmail_quote"><span style=3D"font-size:12.8px">C=
heers,</span></div><div class=3D"gmail_quote"><span style=3D"font-size:12.8=
px">V.</span></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7b471e00eb582b052764963b--

.

------=_Part_5950_1558980135.1450688110584
Content-Type: multipart/alternative;
 boundary="----=_Part_5951_208868622.1450688110584"

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



=E5=9C=A8 2015=E5=B9=B412=E6=9C=8817=E6=97=A5=E6=98=9F=E6=9C=9F=E5=9B=9B UT=
C+8=E4=B8=8B=E5=8D=888:52:11=EF=BC=8CViacheslav Usov=E5=86=99=E9=81=93=EF=
=BC=9A
>
> Consider the following:
>
> namespace foo
> {
>     struct bar {};
>     void baz() {}
>     int qux;
> }
>
> namespace A =3D foo;
> using B =3D foo::bar;
> auto &C =3D foo::baz;
> auto &D =3D foo::qux;
>
> The question is, why do we have to use at least three different ways in=
=20
> order to say use X as an alias of Y?
>
> Is there any fundamental reason why using X =3D Y cannot (or should not) =
be=20
> valid for all kinds of names?
>
> Cheers,
> V.
>

There is no reason to prevent this feature in the language rules=20
generally,  but not for C++. C++ is not designed with such use cases in=20
mind (it is based on C; and C does not, either). And it is not easy to=20
patch current C++ rules to adopt this feature. There are some subtle=20
issues, e.g. as N1489 mentioned. So it is likely not worth doing, for C++.

If you strongly want to use this feature, you can invent a language with=20
it, and implement it by translating it to C++, like the ancient "C with=20
classes" did.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><br><br>=E5=9C=A8 2015=E5=B9=B412=E6=9C=8817=E6=97=A5=E6=
=98=9F=E6=9C=9F=E5=9B=9B UTC+8=E4=B8=8B=E5=8D=888:52:11=EF=BC=8CViacheslav =
Usov=E5=86=99=E9=81=93=EF=BC=9A<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">Consider the following:<div><br></div><div>namespace foo<=
/div><div>{</div><div>=C2=A0 =C2=A0 struct bar {};</div><div>=C2=A0 =C2=A0 =
void baz() {}</div><div>=C2=A0 =C2=A0 int qux;</div><div>}</div><div><br></=
div><div>namespace A =3D foo;</div><div>using B =3D foo::bar;</div><div>aut=
o &amp;C =3D foo::baz;</div><div>auto &amp;D =3D foo::qux;</div><div><br></=
div><div>The question is, why do we have to use at least three different wa=
ys in order to say use X as an alias of Y?</div><div><br></div><div>Is ther=
e any fundamental reason why using X =3D Y cannot (or should not) be valid =
for all kinds of names?</div><div><br></div><div>Cheers,</div><div>V.</div>=
</div></blockquote><div><br>There is no reason to prevent this feature in t=
he language rules generally,=C2=A0 but not for C++. C++ is not designed wit=
h such use cases in mind (it is based on C; and C does not, either). And it=
 is not easy to patch current C++ rules to adopt this feature. There are so=
me subtle issues, e.g. as  N1489 mentioned. So it is likely not worth doing=
, for C++.<br><br>If you strongly want to use this feature, you can invent =
a language with it, and implement it by translating it to C++, like the anc=
ient &quot;C with classes&quot; did.<br><br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_5951_208868622.1450688110584--
------=_Part_5950_1558980135.1450688110584--

.

On Mon, Dec 21, 2015 at 09:51:05AM +0100, Viacheslav Usov wrote:
> On Fri, Dec 18, 2015 at 4:54 PM, Matthew Woehlke <mwoehlke.floss@gmail.com>
> wrote:
>
> > Also, the basis of your proposal is to blur the line between types,
> functions, and variables.
>
> I'd like to dispute this point once more.
>
> Consider this code:
>
> A::B();
>
> Without seeing how A and B were defined or declared, one can only say that
> A can be a namespace or a class type, and B can be a function, a type, or
> an object, and I hope I have not missed some other possibility. It is
> probably going to far if we say say that A and B can be pretty much
> everything that C++ has to offer, but it is not much less than that.
>
> Now, if we say (using proposed syntax)
>
> using X = A;
> using Y = B;
> X::Y();

Is this really what you mean to propose?

Would, at this point,

C::Y();

call C::B()?, i.e. is your using some kind of macro facility?

Also, what happens with A::Y(), would that be inaccessible after the
using declarations?

/MF

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Mon, Dec 21, 2015 at 10:07 AM, Magnus Fromreide <magfr@lysator.liu.se>
wrote:

> Is this really what you mean to propose?

Oops, I really meant to say this:

using X = A;
using Y = X::B;
Y();

It is a not macro-kind-of thing.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 21, 2015 at 10:07 AM, Magnus Fromreide <span dir=3D"ltr">&lt;<a hre=
f=3D"mailto:magfr@lysator.liu.se" target=3D"_blank">magfr@lysator.liu.se</a=
>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">&gt; Is this really what you mean to propose?</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Oops, I really meant =
to say this:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">using X =3D A;</div><div class=3D"gmail_quote">using Y =3D X::B;</di=
v><div class=3D"gmail_quote">Y();</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote">It is a not macro-kind-of thing.</div><div clas=
s=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div cl=
ass=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--047d7b471e0016a965052764fa08--

.

On Monday 21 December 2015 09:51:05 Viacheslav Usov wrote:
> A::B();
>
> Without seeing how A and B were defined or declared, one can only say that
> A can be a namespace or a class type, and B can be a function, a type, or
> an object, and I hope I have not missed some other possibility. It is
> probably going to far if we say say that A and B can be pretty much
> everything that C++ has to offer, but it is not much less than that.

No one writes code like that. This is not a valid example.

First of all, if any of your co-workers is writing namespaces, function names
or class names with single letters, they require retraining. There may be
exceptions, but those exceptions can only be accepted if the entire
development team knows about it, in which case you know what A::B() is.

Second, even if it weren't the case, most projects have coding conventions.
For example, since B starts with a capital letter, I conclude it's the name of
a type, so the statement above creates a temporary and destroys it. Whether A
is a namespace or whether it's a class name and B is a typedef to A inside of
A, it's not relevant.

If you're trying to solve the case of a third-party code that is so bad that
you can't tell what it is doing, then you *need* to know what A and B are. So
you'll look them up, then apply code refactoring to rename them so you'll know
later (we've done that recently in an old C project without comments and with
functions named with one letter, each).

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On 12/21/2015 07:12 AM, Thiago Macieira wrote:
> On Monday 21 December 2015 09:51:05 Viacheslav Usov wrote:
>> A::B();
>>
>> Without seeing how A and B were defined or declared, one can only say that
>> A can be a namespace or a class type, and B can be a function, a type, or
>> an object, and I hope I have not missed some other possibility. It is
>> probably going to far if we say say that A and B can be pretty much
>> everything that C++ has to offer, but it is not much less than that.
>
> No one writes code like that. This is not a valid example.
>
> First of all, if any of your co-workers is writing namespaces, function names
> or class names with single letters, they require retraining. There may be
> exceptions, but those exceptions can only be accepted if the entire
> development team knows about it, in which case you know what A::B() is.
>
> Second, even if it weren't the case, most projects have coding conventions.
> For example, since B starts with a capital letter, I conclude it's the name of
> a type, so the statement above creates a temporary and destroys it. Whether A
> is a namespace or whether it's a class name and B is a typedef to A inside of
> A, it's not relevant.
>
> If you're trying to solve the case of a third-party code that is so bad that
> you can't tell what it is doing, then you *need* to know what A and B are. So
> you'll look them up, then apply code refactoring to rename them so you'll know
> later (we've done that recently in an old C project without comments and with
> functions named with one letter, each).
>

I'm pretty sure Mr. Usov was using single letter names solely to
make the example easier to read.  After all, the only purpose of
using longer names is to make the names more meaningful, but
the only "meaning" of A,B,X,Y in Usov's example is to represent
some name, which, in the real world, would be the more meaningful
names which a "properly trained co-worker" would supply.

-regards,
Larry



--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Mon, Dec 21, 2015 at 2:12 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> On Monday 21 December 2015 09:51:05 Viacheslav Usov wrote:
> > A::B();
> >
> > Without seeing how A and B were defined or declared, one can only say
> that
> > A can be a namespace or a class type, and B can be a function, a type, or
> > an object, and I hope I have not missed some other possibility. It is
> > probably going to far if we say say that A and B can be pretty much
> > everything that C++ has to offer, but it is not much less than that.
>
> No one writes code like that. This is not a valid example.
>
> First of all, if any of your co-workers is writing namespaces, function
> names
> or class names with single letters, they require retraining. There may be
> exceptions, but those exceptions can only be accepted if the entire
> development team knows about it, in which case you know what A::B() is.
>
> Second, even if it weren't the case, most projects have coding conventions.
> For example, since B starts with a capital letter, I conclude it's the
> name of
> a type, so the statement above creates a temporary and destroys it.
> Whether A
> is a namespace or whether it's a class name and B is a typedef to A inside
> of
> A, it's not relevant.
>

The point that was I disputing was that the extended syntax 'using X = Y'
blurs the line between types, namespaces, functions and variables.

If we stipulate that Y makes that unambiguous, then the whole point is moot.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On M=
on, Dec 21, 2015 at 2:12 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Monday 21 December 20=
15 09:51:05 Viacheslav Usov wrote:<br>
&gt; A::B();<br>
&gt;<br>
&gt; Without seeing how A and B were defined or declared, one can only say =
that<br>
&gt; A can be a namespace or a class type, and B can be a function, a type,=
 or<br>
&gt; an object, and I hope I have not missed some other possibility. It is<=
br>
&gt; probably going to far if we say say that A and B can be pretty much<br=
>
&gt; everything that C++ has to offer, but it is not much less than that.<b=
r>
<br>
No one writes code like that. This is not a valid example.<br>
<br>
First of all, if any of your co-workers is writing namespaces, function nam=
es<br>
or class names with single letters, they require retraining. There may be<b=
r>
exceptions, but those exceptions can only be accepted if the entire<br>
development team knows about it, in which case you know what A::B() is.<br>
<br>
Second, even if it weren&#39;t the case, most projects have coding conventi=
ons.<br>
For example, since B starts with a capital letter, I conclude it&#39;s the =
name of<br>
a type, so the statement above creates a temporary and destroys it. Whether=
 A<br>
is a namespace or whether it&#39;s a class name and B is a typedef to A ins=
ide of<br>
A, it&#39;s not relevant.<br></blockquote><div><br></div><div>The point tha=
t was I disputing was that the extended syntax &#39;using X =3D Y&#39; blur=
s the line between types, namespaces, functions and variables.</div><div><b=
r></div><div>If we stipulate that Y makes that unambiguous, then the whole =
point is moot.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br>=
</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e015374ecf5ebfa052768ace4--

.

------=_Part_1046_826886492.1450746764218
Content-Type: multipart/alternative;
 boundary="----=_Part_1047_836558987.1450746764218"

------=_Part_1047_836558987.1450746764218
Content-Type: text/plain; charset=UTF-8



On Monday, December 21, 2015 at 2:43:38 PM UTC+1, Viacheslav Usov wrote:
>
> On Mon, Dec 21, 2015 at 2:12 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
>> On Monday 21 December 2015 09:51:05 Viacheslav Usov wrote:
>> > A::B();
>> >
>> > Without seeing how A and B were defined or declared, one can only say
>> that
>> > A can be a namespace or a class type, and B can be a function, a type,
>> or
>> > an object, and I hope I have not missed some other possibility. It is
>> > probably going to far if we say say that A and B can be pretty much
>> > everything that C++ has to offer, but it is not much less than that.
>>
>> No one writes code like that. This is not a valid example.
>>
>> First of all, if any of your co-workers is writing namespaces, function
>> names
>> or class names with single letters, they require retraining. There may be
>> exceptions, but those exceptions can only be accepted if the entire
>> development team knows about it, in which case you know what A::B() is.
>>
>> Second, even if it weren't the case, most projects have coding
>> conventions.
>> For example, since B starts with a capital letter, I conclude it's the
>> name of
>> a type, so the statement above creates a temporary and destroys it.
>> Whether A
>> is a namespace or whether it's a class name and B is a typedef to A
>> inside of
>> A, it's not relevant.
>>
>
> The point that was I disputing was that the extended syntax 'using X = Y'
> blurs the line between types, namespaces, functions and variables.
>
> If we stipulate that Y makes that unambiguous, then the whole point is
> moot.
>
> Cheers,
> V.
>
> Only place for me where this could be used is templates parameters where
you could accept values and types as one parameter:
template<template<using... > typename F, using First, using Second>
struct X
{
    using F = First; //can by type or constexpr value, can't be used
directly otherwise
    using type = F<First, Second>; //indirect use
};

typename X<std::array, int, 3>::type a;
typename X<std::vector, int, my_alloc>::type b;
This isn't exactly same proposal, but share one common thing: treating
`using` as catch all case.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Monday, December 21, 2015 at 2:43:38 PM UTC+1, Viacheslav Usov w=
rote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8e=
x;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><di=
v class=3D"gmail_quote">On Mon, Dec 21, 2015 at 2:12 PM, Thiago Macieira <s=
pan dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscate=
d-mailto=3D"CqRAdOvCDgAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;=
javascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;=
;return true;">thi...@macieira.org</a>&gt;</span> wrote:<br><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex">On Monday 21 December 2015 09:51:05 Viacheslav Usov wrote:<=
br>
&gt; A::B();<br>
&gt;<br>
&gt; Without seeing how A and B were defined or declared, one can only say =
that<br>
&gt; A can be a namespace or a class type, and B can be a function, a type,=
 or<br>
&gt; an object, and I hope I have not missed some other possibility. It is<=
br>
&gt; probably going to far if we say say that A and B can be pretty much<br=
>
&gt; everything that C++ has to offer, but it is not much less than that.<b=
r>
<br>
No one writes code like that. This is not a valid example.<br>
<br>
First of all, if any of your co-workers is writing namespaces, function nam=
es<br>
or class names with single letters, they require retraining. There may be<b=
r>
exceptions, but those exceptions can only be accepted if the entire<br>
development team knows about it, in which case you know what A::B() is.<br>
<br>
Second, even if it weren&#39;t the case, most projects have coding conventi=
ons.<br>
For example, since B starts with a capital letter, I conclude it&#39;s the =
name of<br>
a type, so the statement above creates a temporary and destroys it. Whether=
 A<br>
is a namespace or whether it&#39;s a class name and B is a typedef to A ins=
ide of<br>
A, it&#39;s not relevant.<br></blockquote><div><br></div><div>The point tha=
t was I disputing was that the extended syntax &#39;using X =3D Y&#39; blur=
s the line between types, namespaces, functions and variables.</div><div><b=
r></div><div>If we stipulate that Y makes that unambiguous, then the whole =
point is moot.</div><div><br></div><div>Cheers,</div><div>V.</div><div><br>=
</div></div></div></div></blockquote><div>Only place for me where this coul=
d be used is templates parameters where you could accept values and types a=
s one parameter:<br><div class=3D"prettyprint" style=3D"background-color: r=
gb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: solid; b=
order-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint"><div =
class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"styled-by-pr=
ettify">template</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&lt;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">=
template</span><span style=3D"color: #660;" class=3D"styled-by-prettify">&l=
t;</span><span style=3D"color: #008;" class=3D"styled-by-prettify">using</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">...</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">&gt;</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008=
;" class=3D"styled-by-prettify">typename</span><span style=3D"color: #000;"=
 class=3D"styled-by-prettify"> F</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
> </span><span style=3D"color: #606;" class=3D"styled-by-prettify">First</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 style=3D=
"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"colo=
r: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;"=
 class=3D"styled-by-prettify">Second</span><span style=3D"color: #660;" cla=
ss=3D"styled-by-prettify">&gt;</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">struct</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> X<br></span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">{</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br=
>=C2=A0 =C2=A0 </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">using</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 F </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: #606;" class=3D"styled-by-prettify">First</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//can by type or constexpr value, can&#39;t be=
 used directly otherwise</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">using</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> type </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> F</span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
&lt;</span><span style=3D"color: #606;" class=3D"styled-by-prettify">First<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Second</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">&gt;;</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #800;" =
class=3D"styled-by-prettify">//indirect use</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"><br></span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"><br><br></span><span style=3D"color: #008;" class=3D"sty=
led-by-prettify">typename</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> X</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">&lt;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"=
>std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">::</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify">array</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #008;" class=3D"styled-by-prettify">int</span><span style=3D"color: #660;=
" class=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #066;" class=3D"style=
d-by-prettify">3</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">&gt;::</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">type a</span><span style=3D"color: #660;" class=3D"styled-by-prettify">;<=
/span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> X</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span style=3D"c=
olor: #000;" class=3D"styled-by-prettify">std</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">::</span><span style=3D"color: #000;" cl=
ass=3D"styled-by-prettify">vector</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">,</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-pret=
tify">int</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> my_alloc<=
/span><span style=3D"color: #660;" class=3D"styled-by-prettify">&gt;::</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify">type b</span><s=
pan style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"><br></span></div></code></di=
v>This isn&#39;t exactly same proposal, but share one common thing: treatin=
g `using` as catch all case.<br><br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_1047_836558987.1450746764218--
------=_Part_1046_826886492.1450746764218--

.

On Monday 21 December 2015 07:43:06 Larry Evans wrote:
> I'm pretty sure Mr. Usov was using single letter names solely to
> make the example easier to read.  After all, the only purpose of
> using longer names is to make the names more meaningful, but
> the only "meaning" of A,B,X,Y in Usov's example is to represent
> some name, which, in the real world, would be the more meaningful
> names which a "properly trained co-worker" would supply.

I understand that, but that made the example invalid.

Let's try hearing the argument again when A, B, X, and Y are replaced with
names that unambiguously explain whether they're namespaces, type names, or
function names.

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

------=_Part_12_139941028.1450880770038
Content-Type: multipart/alternative;
 boundary="----=_Part_13_1158828991.1450880770039"

------=_Part_13_1158828991.1450880770039
Content-Type: text/plain; charset=UTF-8

On Wednesday, December 23, 2015 at 6:33:23 AM UTC-5, Thiago Macieira wrote:
>
> On Monday 21 December 2015 07:43:06 Larry Evans wrote:
> > I'm pretty sure Mr. Usov was using single letter names solely to
> > make the example easier to read.  After all, the only purpose of
> > using longer names is to make the names more meaningful, but
> > the only "meaning" of A,B,X,Y in Usov's example is to represent
> > some name, which, in the real world, would be the more meaningful
> > names which a "properly trained co-worker" would supply.
>
> I understand that, but that made the example invalid.
>
> Let's try hearing the argument again when A, B, X, and Y are replaced with
> names that unambiguously explain whether they're namespaces, type names,
> or
> function names.
>

I'm not sure that's possible. I have seen very few cases where the name of
a construct automatically tells you whether it's a typename or a namespace.
Variables and types tend to have more distinguishing names., but not
typenames and namespaces.

But let's look at some of the namespace names we have in C++, just in the
standard library:

* std
* filesystem
* literals

`std` is so nebulous that who knows what it even means; you learn that one
by convention. However, there are *many* libraries that have "filesystem"
objects, so `filesystem` could easily be a typename. Or even a variable,
representing a global filesystem.

`literals`... if you know that refers to user-defined literals, then you
can probably assume it's a namespace. But otherwise... who knows.

Yes, there are some namespace names that are named differently from types.
But these tend to be the root namespace for a library. Once you start
subdividing namespaces more finely, you'll find some overlap between
namespace naming and typenames.

Of course, that only torpedoes his argument even more. Being able to see a
difference at the time when a declaration is made as to whether or not it's
a namespace or a type is very important, and this is one reason why. If you
can't see a difference between `namespace X = Y` and `using W = Z`, then
you would have to track down the declaration of `Y` and `Z` to figure out
what's actually going on.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr">On Wednesday, December 23, 2015 at 6:33:23 AM UTC-5, Thiag=
o Macieira wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margi=
n-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On Monday 21 =
December 2015 07:43:06 Larry Evans wrote:
<br>&gt; I&#39;m pretty sure Mr. Usov was using single letter names solely =
to
<br>&gt; make the example easier to read. =C2=A0After all, the only purpose=
 of
<br>&gt; using longer names is to make the names more meaningful, but
<br>&gt; the only &quot;meaning&quot; of A,B,X,Y in Usov&#39;s example is t=
o represent
<br>&gt; some name, which, in the real world, would be the more meaningful
<br>&gt; names which a &quot;properly trained co-worker&quot; would supply.
<br>
<br>I understand that, but that made the example invalid.
<br>
<br>Let&#39;s try hearing the argument again when A, B, X, and Y are replac=
ed with=20
<br>names that unambiguously explain whether they&#39;re namespaces, type n=
ames, or=20
<br>function names.
<br></blockquote><div><br>I&#39;m not sure that&#39;s possible. I have seen=
 very few cases where the name of a construct automatically tells you wheth=
er it&#39;s a typename or a namespace. Variables and types tend to have mor=
e distinguishing names., but not typenames and namespaces.<br><br>But let&#=
39;s look at some of the namespace names we have in C++, just in the standa=
rd library:<br><br>* std<br>* filesystem<br>* literals<br><br>`std` is so n=
ebulous that who knows what it even means; you learn that one by convention=
.. However, there are *many* libraries that have &quot;filesystem&quot; obje=
cts, so `filesystem` could easily be a typename. Or even a variable, repres=
enting a global filesystem.<br><br>`literals`... if you know that refers to=
 user-defined literals, then you can probably assume it&#39;s a namespace. =
But otherwise... who knows.<br><br>Yes, there are some namespace names that=
 are named differently from types. But these tend to be the root namespace =
for a library. Once you start subdividing namespaces more finely, you&#39;l=
l find some overlap between namespace naming and typenames.<br><br>Of cours=
e, that only torpedoes his argument even more. Being able to see a differen=
ce at the time when a declaration is made as to whether or not it&#39;s a n=
amespace or a type is very important, and this is one reason why. If you ca=
n&#39;t see a difference between `namespace X =3D Y` and `using W =3D Z`, t=
hen you would have to track down the declaration of `Y` and `Z` to figure o=
ut what&#39;s actually going on.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_13_1158828991.1450880770039--
------=_Part_12_139941028.1450880770038--

.

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

On Wed, Dec 23, 2015 at 3:26 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> Of course, that only torpedoes his argument even more.

Yup; not referencing "his argument" makes for a firing solution that always
works.

My argument in this particular branch of the discussion:

If one can grasp from the name Y whether it is a namespace or a type or
whatever, then using X = Y does not blur anything.

And being unable to grasp that was ruled out by Thiago Macieira [1].

Cheers,
V.

[1] "No one writes code like that. This is not a valid example."

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 23, 2015 at 3:26 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; Of course, that only torpedoes his argument even more.</div><div=
 class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Yup; not refere=
ncing &quot;his argument&quot; makes for a firing solution that always work=
s.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">My =
argument in this particular branch of the discussion:</div><div class=3D"gm=
ail_quote"><br></div><div class=3D"gmail_quote">If one can grasp from the n=
ame Y whether it is a namespace or a type or whatever, then using X =3D Y d=
oes not blur anything.</div><div class=3D"gmail_quote"><br></div><div class=
=3D"gmail_quote">And being unable to grasp that was ruled out by=C2=A0<span=
 style=3D"font-size:12.8px">Thiago Macieira [1].</span></div><div class=3D"=
gmail_quote"><span style=3D"font-size:12.8px"><br></span></div><div class=
=3D"gmail_quote"><span style=3D"font-size:12.8px">Cheers,</span></div><div =
class=3D"gmail_quote"><span style=3D"font-size:12.8px">V.</span></div><div =
class=3D"gmail_quote"><span style=3D"font-size:12.8px"><br></span></div><di=
v class=3D"gmail_quote"><span style=3D"font-size:12.8px">[1] &quot;</span><=
span style=3D"font-size:12.8px">No one writes code like that. This is not a=
 valid example.&quot;</span></div><div class=3D"gmail_quote"><span style=3D=
"font-size:12.8px"><br></span></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113de95689638f0527922815--

.

On Wednesday 23 December 2015 16:13:02 Viacheslav Usov wrote:
> If one can grasp from the name Y whether it is a namespace or a type or
> whatever, then using X = Y does not blur anything.

Indeed. But then what's the value of having a unified syntax?

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

On Wednesday 23 December 2015 06:26:09 Nicol Bolas wrote:
> I'm not sure that's possible. I have seen very few cases where the name of
> a construct automatically tells you whether it's a typename or a namespace.
> Variables and types tend to have more distinguishing names., but not
> typenames and namespaces.

Maybe you should seek frameworks that have better coding conventions instead.

> But let's look at some of the namespace names we have in C++, just in the
> standard library:
>
> * std
> * filesystem
> * literals

<purely subjective>
And that would be  an example of a framework with a bad coding convention,
where everything is lowercase, some things are separated by space and some
things not (type_info in <typeinfo>), methods are not consistently named after
verbs in a particular tense reflecting their purpose, and the list goes on.
Your are more evidence of this.
</purely subjective>

Note that "no one writes code like that" does not apply here. That was to
entities named after one letters.

> `std` is so nebulous that who knows what it even means; you learn that one
> by convention. However, there are *many* libraries that have "filesystem"
> objects, so `filesystem` could easily be a typename. Or even a variable,
> representing a global filesystem.

"std" is a name apart because everyone knows what it is. How it came to be
named is irrelevant and never should be in any argument. That includes reasons
for naming other namespaces.

[snip the rest]

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

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

.

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

On Wed, Dec 23, 2015 at 10:26 PM, Thiago Macieira <thiago@macieira.org>
wrote:

> Indeed. But then what's the value of having a unified syntax?

That was addressed earlier, by me and Richard Smith, so I won't repeat that
again.

But perhaps there is another argument. What is the value of 'using' over
'typedef', except in dealing with templates? I would say it is marginal in
the slightly less weird type specification in complicated cases. Yet I find
(looking at my and my colleagues' code) that we do not need 'typedef' at
all, even in the simplest cases. The generality of 'using' *alone* makes it
preferable to other means in *every *case.

Yet another argument is given in n1449:

The original draft of this proposal was well received by the Evolution
Working Group at the Oxford meeting. After the initial presentation of this
paper we worked on carrying these ideas further. First we considered
extending the proposal to include the notion of function template aliases:

template using F =3D f >(int, char); // does this require a signature?

We also briefly considered non-template aliasing:

using F =3D f(int);
using Cos =3D cos; // whole overload set?

Two straw polls were taken regarding syntax. A strong majority voted to
avoid the typedef template syntax, in favor of the =E2=80=9C=3D=E2=80=9D sy=
ntax. A second
vote indicated strong preference for the =E2=80=9Cusing=E2=80=9D keyword as=
 opposed to a
word like =E2=80=9Calias=E2=80=9D or the absence of any keyword as in the d=
raft version of
this proposal. *The motivation for using any keyword at all stemmed partly
from the desire to use a syntax that might be compatible with the
non-template aliasing direction briefly outlined above.*

(end quote)

The current 'using' syntax was introduced at least partly because EWG saw a
value in its suitability for other kinds of aliasing. That was re-affirmed
in n2258, which made it into the standard.

Cheers,
V.

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos=
als/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On W=
ed, Dec 23, 2015 at 10:26 PM, Thiago Macieira <span dir=3D"ltr">&lt;<a href=
=3D"mailto:thiago@macieira.org" target=3D"_blank">thiago@macieira.org</a>&g=
t;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">&gt; Indeed. But then what&#39;s the value of having a unified s=
yntax?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote"=
>That was addressed earlier, by me and Richard Smith, so I won&#39;t repeat=
 that again.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_=
quote">But perhaps there is another argument. What is the value of &#39;usi=
ng&#39; over &#39;typedef&#39;, except in dealing with templates? I would s=
ay it is marginal in the slightly less weird type specification in complica=
ted cases. Yet I find (looking at my and my colleagues&#39; code) that we d=
o not need &#39;typedef&#39; at all, even in the simplest cases. The genera=
lity of &#39;using&#39; <i>alone</i>=C2=A0makes it preferable to other mean=
s in <i>every </i>case.</div><div class=3D"gmail_quote"><br></div><div clas=
s=3D"gmail_quote">Yet another argument is given in n1449:</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">The original draft of=
 this proposal was well received by the Evolution Working Group at the Oxfo=
rd
meeting. After the initial presentation of this paper we worked on carrying=
 these ideas further. First we
considered extending the proposal to include the notion of function templat=
e aliases:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_qu=
ote">template=20
using F =3D f &gt;(int, char); // does this require a signature?</div><div =
class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">We also briefly =
considered non-template aliasing:</div><div class=3D"gmail_quote"><br></div=
><div class=3D"gmail_quote">using F =3D f(int);</div><div class=3D"gmail_qu=
ote">using Cos =3D cos; // whole overload set?</div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">Two straw polls were taken regardi=
ng syntax. A strong majority voted to avoid the typedef template
syntax, in favor of the =E2=80=9C=3D=E2=80=9D syntax. A second vote indicat=
ed strong preference for the =E2=80=9Cusing=E2=80=9D keyword
as opposed to a word like =E2=80=9Calias=E2=80=9D or the absence of any key=
word as in the draft version of this proposal.
<i>The motivation for using any keyword at all stemmed partly from the desi=
re to use a syntax that might
be compatible with the non-template aliasing direction briefly outlined abo=
ve.</i><br></div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">(end quote)</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">The current &#39;using&#39; syntax was introduced at least part=
ly because EWG saw a value in its suitability for other kinds of aliasing. =
That was re-affirmed in n2258, which made it into the standard.</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div=
 class=3D"gmail_quote">V.</div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a114075eaa5b144052806fdb4--

.

------=_Part_457_779500613.1451400825895
Content-Type: multipart/alternative;
 boundary="----=_Part_458_810080553.1451400825895"

------=_Part_458_810080553.1451400825895
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 29, 2015 at 5:36:15 AM UTC-5, Viacheslav Usov wrote:
>
> On Wed, Dec 23, 2015 at 10:26 PM, Thiago Macieira <thi...@macieira.org
> <javascript:>> wrote:
>
> > Indeed. But then what's the value of having a unified syntax?
>
> That was addressed earlier, by me and Richard Smith, so I won't repeat
> that again.
>

>
But perhaps there is another argument. What is the value of 'using' over
> 'typedef', except in dealing with templates?
>

It fits normal C++ convention. Non-variable declarations of names tend to
be of the form:

Keyword(s) IntroducedName <Other Stuff Describing Name>;

C++11 even allowed function declarations to fit that model:

auto FunctionName(parameters) -> Return;

While this was added for an entirely different purpose, it does make the
syntax for declarations more regular as well.

Typedefs have been the odd man out in this regard. The typename comes
*last* instead of first. Or in the case of function pointers, in the middle
somewhere.

I would say it is marginal in the slightly less weird type specification in
> complicated cases. Yet I find (looking at my and my colleagues' code) that
> we do not need 'typedef' at all, even in the simplest cases. The generality
> of 'using' *alone* makes it preferable to other means in *every *case.
>

No, it does not.

`using` is better than `typedef` because it makes more sense. It fits C++
syntax better, as shown above. That's why it was adapted to subsume all
uses of `typedefs`, rather than just the template case.

Typedefs for function pointers are a particular pain point:

typedef Return (*IntroducedName)(Parameters);

It's hard to figure out where the new name is supposed to be in that.
Especially if `Return` is something big and complex. By contrast:

using IntroducedName = Return(*)(Parameters);

This is much more legible. The important information, the new name, is
easily visible.

Yet another argument is given in n1449:
>

No, that is an argument for applying `using` in the cases of all *type*
aliases. It is *not* an argument for applying `using` in the case of all
aliases period.

An argument for expanding `using` to subsume one syntax is *not* an
argument for subsuming another syntax.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, December 29, 2015 at 5:36:15 AM UTC-5, Viacheslav Usov wrote:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=
=3D"gmail_quote">On Wed, Dec 23, 2015 at 10:26 PM, Thiago Macieira <span di=
r=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mail=
to=3D"qenGY1YtEQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javasc=
ript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;retur=
n true;">thi...@macieira.org</a>&gt;</span> wrote:</div><div class=3D"gmail=
_quote"><br></div><div class=3D"gmail_quote">&gt; Indeed. But then what&#39=
;s the value of having a unified syntax?</div><div class=3D"gmail_quote"><b=
r></div><div class=3D"gmail_quote">That was addressed earlier, by me and Ri=
chard Smith, so I won&#39;t repeat that again.</div></div></div></blockquot=
e><blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rg=
b(204, 204, 204); padding-left: 1ex;" class=3D"gmail_quote"><div>=C2=A0</di=
v></blockquote><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-=
left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr=
"><div><div class=3D"gmail_quote"></div><div class=3D"gmail_quote">But perh=
aps there is another argument. What is the value of &#39;using&#39; over &#=
39;typedef&#39;, except in dealing with templates?</div></div></div></block=
quote><div><br>It fits normal C++ convention. Non-variable declarations of =
names tend to be of the form:<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: #606;" clas=
s=3D"styled-by-prettify">Keyword</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(</span><span style=3D"color: #000;" class=3D"style=
d-by-prettify">s</span><span style=3D"color: #660;" class=3D"styled-by-pret=
tify">)</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
span><span style=3D"color: #606;" class=3D"styled-by-prettify">IntroducedNa=
me</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">&lt;</span><span =
style=3D"color: #606;" class=3D"styled-by-prettify">Other</span><span style=
=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color=
: #606;" class=3D"styled-by-prettify">Stuff</span><span style=3D"color: #00=
0;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=
=3D"styled-by-prettify">Describing</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #606;" class=3D"style=
d-by-prettify">Name</span><span style=3D"color: #660;" class=3D"styled-by-p=
rettify">&gt;;</span></div></code></div><br>C++11 even allowed function dec=
larations to fit that model:<br><br><div class=3D"prettyprint" style=3D"bac=
kground-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border=
-style: solid; border-width: 1px; word-wrap: break-word;"><code class=3D"pr=
ettyprint"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=
=3D"styled-by-prettify">auto</span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"> </span><span style=3D"color: #606;" class=3D"styled-by-p=
rettify">FunctionName</span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">(</span><span style=3D"color: #000;" class=3D"styled-by-prettify=
">parameters</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">-&gt;</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">Return</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">;</span></div></code></div><br>W=
hile this was added for an entirely different purpose, it does make the syn=
tax for declarations more regular as well.<br><br>Typedefs have been the od=
d man out in this regard. The typename comes *last* instead of first. Or in=
 the case of function pointers, in the middle somewhere.<br><br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">I would say it is marginal in the slightly less weird type sp=
ecification in complicated cases. Yet I find (looking at my and my colleagu=
es&#39; code) that we do not need &#39;typedef&#39; at all, even in the sim=
plest cases. The generality of &#39;using&#39; <i>alone</i>=C2=A0makes it p=
referable to other means in <i>every </i>case.</div></div></div></blockquot=
e><div><br>No, it does not.<br><br>`using` is better than `typedef` because=
 it makes more sense. It fits C++ syntax better, as shown above. That&#39;s=
 why it was adapted to subsume all uses of `typedefs`, rather than just the=
 template case.<br><br>Typedefs for function pointers are a particular pain=
 point:<br><br><div class=3D"prettyprint" style=3D"background-color: rgb(25=
0, 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: #008;" class=3D"styled-by-prettif=
y">typedef</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #606;" class=3D"styled-by-prettify">Return</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: #606;" class=3D"styled-by-prettify">IntroducedName</span><span s=
tyle=3D"color: #660;" class=3D"styled-by-prettify">)(</span><span style=3D"=
color: #606;" class=3D"styled-by-prettify">Parameters</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">);</span></div></code></div><br>=
It&#39;s hard to figure out where the new name is supposed to be in that. E=
specially if `Return` is something big and complex. By contrast:<br><br><di=
v class=3D"prettyprint" style=3D"background-color: rgb(250, 250, 250); bord=
er-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: #008;" class=3D"styled-by-prettify">using</span><sp=
an style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=
=3D"color: #606;" class=3D"styled-by-prettify">IntroducedName</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">=3D</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #606;" cla=
ss=3D"styled-by-prettify">Return</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">(*)(</span><span style=3D"color: #606;" class=3D"st=
yled-by-prettify">Parameters</span><span style=3D"color: #660;" class=3D"st=
yled-by-prettify">);</span></div></code></div><br>This is much more legible=
.. The important information, the new name, is easily visible.<br><br></div>=
<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><div cla=
ss=3D"gmail_quote"></div><div class=3D"gmail_quote">Yet another argument is=
 given in n1449:</div></div></div></blockquote><div><br>No, that is an argu=
ment for applying `using` in the cases of all <i>type</i> aliases. It is <i=
>not</i> an argument for applying `using` in the case of all aliases period=
..<br><br>An argument for expanding `using` to subsume one syntax is <i>not<=
/i> an argument for subsuming another syntax.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_458_810080553.1451400825895--
------=_Part_457_779500613.1451400825895--

.

------=_Part_4662_235540541.1451402440662
Content-Type: multipart/alternative;
 boundary="----=_Part_4663_411861612.1451402440673"

------=_Part_4663_411861612.1451402440673
Content-Type: text/plain; charset=UTF-8

On Friday, December 18, 2015 at 2:07:56 PM UTC-5, Richard Smith wrote:
>
> On Fri, Dec 18, 2015 at 8:18 AM, Ville Voutilainen <ville.vo...@gmail.com
> <javascript:>> wrote:
>
>> On 18 December 2015 at 18:14, Viacheslav Usov <via....@gmail.com
>> <javascript:>> wrote:
>> > With the current means of aliasing, we have to say: "we both know that
>> Y is
>> > a namespace (or a type; or a var). Let X be another name for that."
>> What I
>> > am proposing is a way of saying "Let X be another name for Y" (whatever
>> Y
>> > is, provided it can be validly aliased).
>>
>> While that may be reasonable, it shouldn't be done so that people who use
>> the current way of saying "let X be another name for type Y, and if Y
>> isn't a type,
>> the code must be ill-formed" have their code broken. In other words, you
>> should
>> strive for a different syntax for such "universal aliases", whatever
>> that syntax might be.
>
>
> If you're saying that we can't use "using X = Y;" for anything other than
> types because we already use it for types, then I think we made a major
> mistake using such a general syntax for such a specific thing.
>
> I think the feature being proposed is useful, but I don't think the
> discussion thus far has really captured a good motivation for it. So here's
> why I want it:
>
> Refactoring.
>
> This feature allows an entity to be incrementally renamed, in a uniform
> way that does not depend on what kind of entity you started with. (You
> first add "using NewName = OldName;", then update all the users, then
> remove the alias declaration.) To do this today involves using a different
> syntax, possibly with subtly-different semantics, for each different kind
> of entity (for examples where this is hard today, try renaming a template
> or an overload set of functions).
>

OK, there are two issues here:

1) Cases that other alias methods already cover.

2) Cases that other alias methods don't cover.

There's an argument for having coverage for #2. Indeed, part of P0109
(strong type aliases) includes a section specifically about adding function
aliases, as a means of specifying "trampolines", but also as a generalized
mechanism. It can even alias a function with an object, which is rather...
odd, and it's not really clear what that means for doing things like
getting function pointers and the like.

My issue is primarily with #1: cases which we have perfectly valid
mechanisms for. Unless you are explicitly trying to change the *meaning* of
such aliases, then I don't see the point. So long as these two declarations
would do the same thing:

namespace alias = original;
using alias = original;

I don't know why we should blur the line between a namespace alias
declaration and a using declaration.

That brings up another point you raised: "possibly with subtly-different
semantics". Well, possibly different semantics with what, exactly?

Variable aliases are a big issue here. That's because the language doesn't
define "variable aliases"; it defines *references*. The OP wanted `using`
to declare a *reference*, not an alias. And as much as the OP would like to
believe it, they aren't the same thing.

So if `using` were to be able to create "variable aliases", would you want
them to behave like aliases (different name, same object) or references
(different *variable*, same object)?


> This is exactly analogous to using-declarations, which allow an entity to
> be incrementally moved from one namespace to another, independent of the
> kind of entity.
>

Except that it doesn't. Not really. It simply makes the name visible in
that new namespace. It doesn't change, for example, ADL lookup rules
<http://ideone.com/W75Hhm>. The "moved" entity is not really in that
namespace.

That's why we invented inline namespaces <http://ideone.com/7MemB6>.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Friday, December 18, 2015 at 2:07:56 PM UTC-5, Richard Smith wrote:<bloc=
kquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-l=
eft: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div class=3D=
"gmail_quote">On Fri, Dec 18, 2015 at 8:18 AM, Ville Voutilainen <span dir=
=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailt=
o=3D"1MyPQODoDQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascr=
ipt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return=
 true;">ville.vo...@gmail.com</a>&gt;</span> wrote:<br><blockquote class=3D=
"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding=
-left:1ex"><span>On 18 December 2015 at 18:14, Viacheslav Usov &lt;<a href=
=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=3D"1MyPQODoDQAJ" r=
el=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascript:&#39;;return tru=
e;" onclick=3D"this.href=3D&#39;javascript:&#39;;return true;">via....@gmai=
l.com</a>&gt; wrote:<br>
&gt; With the current means of aliasing, we have to say: &quot;we both know=
 that Y is<br>
&gt; a namespace (or a type; or a var). Let X be another name for that.&quo=
t; What I<br>
&gt; am proposing is a way of saying &quot;Let X be another name for Y&quot=
; (whatever Y<br>
&gt; is, provided it can be validly aliased).<br><br>
</span>While that may be reasonable, it shouldn&#39;t be done so that peopl=
e who use<br>
the current way of saying &quot;let X be another name for type Y, and if Y<=
br>
isn&#39;t a type,<br>
the code must be ill-formed&quot; have their code broken. In other words, y=
ou should<br>
strive for a different syntax for such &quot;universal aliases&quot;, whate=
ver<br>
that syntax might be.</blockquote><div><br></div><div>If you&#39;re saying =
that we can&#39;t use &quot;using X =3D Y;&quot; for anything other than ty=
pes because we already use it for types, then I think we made a major mista=
ke using such a general syntax for such a specific thing.</div><div><br></d=
iv><div>I think the feature being proposed is useful, but I don&#39;t think=
 the discussion thus far has really captured a good motivation for it. So h=
ere&#39;s why I want it:</div><div><br></div><div>Refactoring.</div><div><b=
r></div><div>This feature allows an entity to be incrementally renamed, in =
a uniform way that does not depend on what kind of entity you started with.=
 (You first add &quot;using NewName =3D OldName;&quot;, then update all the=
 users, then remove the alias declaration.) To do this today involves using=
 a different syntax, possibly with subtly-different semantics, for each dif=
ferent kind of entity (for examples where this is hard today, try renaming =
a template or an overload set of functions).</div></div></div></div></block=
quote><div><br>OK, there are two issues here:<br><br>1) Cases that other al=
ias methods already cover.<br><br>2) Cases that other alias methods don&#39=
;t cover.<br><br>There&#39;s an argument for having coverage for #2. Indeed=
, part of P0109 (strong type aliases) includes a section specifically about=
 adding function aliases, as a means of specifying &quot;trampolines&quot;,=
 but also as a generalized mechanism. It can even alias a function with an =
object, which is rather... odd, and it&#39;s not really clear what that mea=
ns for doing things like getting function pointers and the like.<br><br>My =
issue is primarily with #1: cases which we have perfectly valid mechanisms =
for. Unless you are explicitly trying to change the *meaning* of such alias=
es, then I don&#39;t see the point. So long as these two declarations would=
 do the same thing:<br><br><div class=3D"prettyprint" style=3D"background-c=
olor: rgb(250, 250, 250); border-color: rgb(187, 187, 187); border-style: s=
olid; border-width: 1px; word-wrap: break-word;"><code class=3D"prettyprint=
"><div class=3D"subprettyprint"><span style=3D"color: #008;" class=3D"style=
d-by-prettify">namespace</span><span style=3D"color: #000;" class=3D"styled=
-by-prettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prett=
ify">alias</span><span style=3D"color: #000;" class=3D"styled-by-prettify">=
 </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span=
><span style=3D"color: #000;" class=3D"styled-by-prettify"> original</span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">;</span><span sty=
le=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span style=3D"=
color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #008;" =
class=3D"styled-by-prettify">alias</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> original</span><span style=3D"color: #660;" class=3D"styled-by-pre=
ttify">;</span></div></code></div><br>I don&#39;t know why we should blur t=
he line between a namespace alias declaration and a using declaration.<br><=
br>That brings up another point you raised: &quot;possibly with subtly-diff=
erent semantics&quot;. Well, possibly different semantics with what, exactl=
y?<br><br>Variable aliases are a big issue here. That&#39;s because the lan=
guage doesn&#39;t define &quot;variable aliases&quot;; it defines <i>refere=
nces</i>. The OP wanted `using` to declare a <i>reference</i>, not an alias=
.. And as much as the OP would like to believe it, they aren&#39;t the same =
thing.<br><br>So if `using` were to be able to create &quot;variable aliase=
s&quot;, would you want them to behave like aliases (different name, same o=
bject) or references (different <i>variable</i>, same object)?<br>=C2=A0</d=
iv><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;=
border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div =
class=3D"gmail_quote"><div>This is exactly analogous to using-declarations,=
 which allow an entity to be incrementally moved from one namespace to anot=
her, independent of the kind of entity.</div></div></div></div></blockquote=
><div><br>Except that it doesn&#39;t. Not really. It simply makes the name =
visible in that new namespace. It doesn&#39;t change, for example, <a href=
=3D"http://ideone.com/W75Hhm">ADL lookup rules</a>. The &quot;moved&quot; e=
ntity is not really in that namespace.<br><br>That&#39;s why we invented <a=
 href=3D"http://ideone.com/7MemB6">inline namespaces</a>.<br></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4663_411861612.1451402440673--
------=_Part_4662_235540541.1451402440662--

.

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

On Tue, Dec 29, 2015 at 3:53 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

I wrote:

> The generality of 'using' *alone* makes it preferable to other means in *every
*case.

To which you respond:

> No, it does not.

And then you expand verbosely how 'using' is much better than 'typedef' for
reasons *other than generality*, while failing to show that generality
alone does *not* make it preferable.

I wrote:

> The current 'using' syntax was introduced at least partly because EWG saw
a value in its suitability for other kinds of aliasing.

To which you respond:

> No, that is an argument for applying `using` in the cases of all *type*
aliases. It is *not* an argument for applying `using` in the case of all
aliases period.

Which, again, falls short of being a true negation of what I wrote.

I could say that your use of 'no' is merely illogical; but given how
carefully you redacted my reference to n2258, what I see is really just
splitting hairs.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 3:53 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">I wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmai=
l_quote">&gt; The generality of &#39;using&#39; <i>alone</i>=C2=A0makes it =
preferable to other means in <i>every </i>case.</div><div class=3D"gmail_qu=
ote"><br></div><div class=3D"gmail_quote">To which you respond:</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; No, it does =
not.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">A=
nd then you expand verbosely how &#39;using&#39; is much better than &#39;t=
ypedef&#39; for reasons <i>other than generality</i>, while failing to show=
 that generality alone does <i>not</i>=C2=A0make it preferable.</div><div c=
lass=3D"gmail_quote"><br></div><div class=3D"gmail_quote">I wrote:</div><di=
v class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt;=C2=A0<spa=
n style=3D"font-size:12.8px">The current &#39;using&#39; syntax was introdu=
ced at least partly because EWG saw a value in its suitability for other ki=
nds of aliasing.</span></div><div class=3D"gmail_quote"><span style=3D"font=
-size:12.8px"><br></span></div><div class=3D"gmail_quote"><span style=3D"fo=
nt-size:12.8px">To which you respond:</span></div><div class=3D"gmail_quote=
"><br></div><div class=3D"gmail_quote">&gt; No, that is an argument for app=
lying `using` in the cases of all <i>type</i> aliases. It is <i>not</i> an =
argument for applying `using` in the case of all aliases period.<br></div><=
div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Which, again=
, falls short of being a true negation of what I wrote.</div><div class=3D"=
gmail_quote"><br></div><div class=3D"gmail_quote">I could say that your use=
 of &#39;no&#39; is merely illogical; but given how carefully you redacted =
my reference to n2258, what I see is really just splitting hairs.<br></div>=
<div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</di=
v><div class=3D"gmail_quote">V.</div><div class=3D"gmail_quote"><br></div><=
/div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1134a23cb9a7df05280b1195--

.

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

On Tue, Dec 29, 2015 at 4:20 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> The OP wanted `using` to declare a *reference*, not an alias. And as much
as the OP would like to believe it, they aren't the same thing.

False. The OP said:

> And by the way, in my proposal I identified using X = Y with auto &X = Y
when Y is a variable or a function; this is, however, not essential for the
proposal. The desired semantics is "X is another name for Y", not really "X
is a reference to Y" even though the latter means very nearly the former.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 4:20 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote"><div>&gt; The OP wanted `using` to declare a <i>reference</i>, not an=
 alias. And as much as the OP would like to believe it, they aren&#39;t the=
 same thing.</div><div><br></div><div>False. The OP said:</div><div><br></d=
iv><div>&gt;=C2=A0<span style=3D"font-size:12.8px">And by the way, in my pr=
oposal I identified using X =3D Y with auto &amp;X =3D Y when Y is a variab=
le or a function; this is, however, not essential for the proposal. The des=
ired semantics is &quot;X is another name for Y&quot;, not really &quot;X i=
s a reference to Y&quot; even though the latter means very nearly the forme=
r.</span></div><div><span style=3D"font-size:12.8px"><br></span></div><div>=
Cheers,<br></div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113de956c55db105280b20d6--

.

------=_Part_86_4127912.1451404324936
Content-Type: multipart/alternative;
 boundary="----=_Part_87_183679271.1451404324936"

------=_Part_87_183679271.1451404324936
Content-Type: text/plain; charset=UTF-8



On Tuesday, December 29, 2015 at 10:32:26 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Dec 29, 2015 at 4:20 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > The OP wanted `using` to declare a *reference*, not an alias. And as
> much as the OP would like to believe it, they aren't the same thing.
>
> False. The OP said:
>
> > And by the way, in my proposal I identified using X = Y with auto &X =
> Y when Y is a variable or a function; this is, however, not essential for
> the proposal. The desired semantics is "X is another name for Y", not
> really "X is a reference to Y" even though the latter means very nearly the
> former.
>

Maybe you need to re-read your own posts:

Proposal: make syntax using X = Y a valid alternative to namespace X = Y
> (when Y is a namespace name); or auto &X = Y (when Y is a function or an
> object); this is similar to how using X = Y is a valid alternative to
> typedef Y X (when Y is a type).
>

That was what you said.
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ>
I cannot read your mind; if you ask for `using X = Y` to become `auto &X =
Y`, then I must assume that's what you want.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<br><br>On Tuesday, December 29, 2015 at 10:32:26 AM UTC-5, Viacheslav Usov=
 wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.=
8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><=
div class=3D"gmail_quote">On Tue, Dec 29, 2015 at 4:20 PM, Nicol Bolas <spa=
n dir=3D"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"hfQhA4A9EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;ja=
vascript:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;r=
eturn true;">jmck...@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gma=
il_quote"><br></div><div class=3D"gmail_quote"><div>&gt; The OP wanted `usi=
ng` to declare a <i>reference</i>, not an alias. And as much as the OP woul=
d like to believe it, they aren&#39;t the same thing.</div><div><br></div><=
div>False. The OP said:</div><div><br></div><div>&gt;=C2=A0<span style=3D"f=
ont-size:12.8px">And by the way, in my proposal I identified using X =3D Y =
with auto &amp;X =3D Y when Y is a variable or a function; this is, however=
, not essential for the proposal. The desired semantics is &quot;X is anoth=
er name for Y&quot;, not really &quot;X is a reference to Y&quot; even thou=
gh the latter means very nearly the former.</span><br></div></div></div></d=
iv></blockquote><div><br>Maybe you need to re-read your own posts:<br><br><=
blockquote style=3D"margin: 0px 0px 0px 0.8ex; border-left: 1px solid rgb(2=
04, 204, 204); padding-left: 1ex;" class=3D"gmail_quote">Proposal: make=C2=
=A0syntax using X =3D Y a valid alternative to namespace X =3D Y
 (when Y is a namespace name); or auto &amp;X =3D Y (when Y is a function=
=20
or an object); this is similar to how using X =3D Y is a valid alternative
 to typedef Y X (when Y is a type). <br></blockquote><div><br><a href=3D"ht=
tps://groups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDC=
GNDQAJ">That was what you said.</a> I cannot read your mind; if you ask for=
 `using X =3D Y` to become `auto &amp;X =3D Y`, then I must assume that&#39=
;s what you want.<br></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_87_183679271.1451404324936--
------=_Part_86_4127912.1451404324936--

.

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

On Tue, Dec 29, 2015 at 4:52 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> That was what you said.
<https://groups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ>


And, of course, subsequent clarifications are to be ignored.

> I cannot read your mind

You do not have to. You just need to learn to read your email.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 4:52 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt;=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d/msg/std=
-proposals/4PR7LUngZFw/NmEiDCGNDQAJ" target=3D"_blank">That was what you sa=
id.</a>=C2=A0</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail=
_quote">And, of course, subsequent clarifications are to be ignored.</div><=
div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">&gt; I canno=
t read your mind</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_quote">You do not have to. You just need to learn to read your email.</=
div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,=
</div><div class=3D"gmail_quote">V.</div><div class=3D"gmail_quote"><br></d=
iv></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113d5348c1c25005280b87a1--

.

------=_Part_4534_771918119.1451406762079
Content-Type: multipart/alternative;
 boundary="----=_Part_4535_83410150.1451406762079"

------=_Part_4535_83410150.1451406762079
Content-Type: text/plain; charset=UTF-8

On Tuesday, December 29, 2015 at 11:01:13 AM UTC-5, Viacheslav Usov wrote:
>
> On Tue, Dec 29, 2015 at 4:52 PM, Nicol Bolas <jmck...@gmail.com
> <javascript:>> wrote:
>
> > That was what you said.
> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ>
>
>
> And, of course, subsequent clarifications are to be ignored.
>

OK, I admit that I missed that line. That doesn't change one important fact:

That wasn't a "clarification". That was a *change to your idea*.

That's not something that should be buried in the middle of a random post.
It should be something that you should make abundantly clear to everyone
that a change has occurred. Not everyone is going to remember every minor
detail of every sentence from a post you wrote weeks ago.

If you're going to add new aspects to a proposal (and this is new), that
needs to be made clear. You should have created a new post that said,
"Earlier, I said that I wanted `using X = Y` to be `auto &X = Y` for
objects. I realize now that I want it to mean something new instead."
Followed of course by an explanation of how this "something new" should
behave (C++ doesn't have "variable aliases", so you have to explain what
the rules for them are).

That's something that people would notice and be aware of (and comment on.
Note that nobody actually responded to the post including your change).
Changes to your proposal due to issues brought up in debate are good. But
you need to make it more visible when such changes happen.

Now that we have that out of the way, you still need to explain what a
"variable alias" does.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

On Tuesday, December 29, 2015 at 11:01:13 AM UTC-5, Viacheslav Usov wrote:<=
blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;bord=
er-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><div><div clas=
s=3D"gmail_quote">On Tue, Dec 29, 2015 at 4:52 PM, Nicol Bolas <span dir=3D=
"ltr">&lt;<a href=3D"javascript:" target=3D"_blank" gdf-obfuscated-mailto=
=3D"mJkoChI_EQAJ" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;javascri=
pt:&#39;;return true;" onclick=3D"this.href=3D&#39;javascript:&#39;;return =
true;">jmck...@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quo=
te"><br></div><div class=3D"gmail_quote">&gt;=C2=A0<a href=3D"https://group=
s.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ" tar=
get=3D"_blank" rel=3D"nofollow" onmousedown=3D"this.href=3D&#39;https://gro=
ups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ&#3=
9;;return true;" onclick=3D"this.href=3D&#39;https://groups.google.com/a/is=
ocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ&#39;;return true;">Th=
at was what you said.</a>=C2=A0</div><div class=3D"gmail_quote"><br></div><=
div class=3D"gmail_quote">And, of course, subsequent clarifications are to =
be ignored.</div></div></div></blockquote><div><br>OK, I admit that I misse=
d that line. That doesn&#39;t change one important fact:<br><br>That wasn&#=
39;t a &quot;clarification&quot;. That was a <i>change to your idea</i>.<br=
><br>That&#39;s not something that should be buried in the middle of a rand=
om post. It should be something that you should make abundantly clear to ev=
eryone that a change has occurred. Not everyone is going to remember every =
minor detail of every sentence from a post you wrote weeks ago.<br><br>If y=
ou&#39;re going to add new aspects to a proposal (and this is new), that ne=
eds to be made clear. You should have created a new post that said, &quot;E=
arlier, I said that I wanted `using X =3D Y` to be `auto &amp;X =3D Y` for =
objects. I realize now that I want it to mean something new instead.&quot; =
Followed of course by an explanation of how this &quot;something new&quot; =
should behave (C++ doesn&#39;t have &quot;variable aliases&quot;, so you ha=
ve to explain what the rules for them are).<br><br>That&#39;s something tha=
t people would notice and be aware of (and comment on. Note that nobody act=
ually responded to the post including your change). Changes to your proposa=
l due to issues brought up in debate are good. But you need to make it more=
 visible when such changes happen.<br><br>Now that we have that out of the =
way, you still need to explain what a &quot;variable alias&quot; does.<br><=
/div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

------=_Part_4535_83410150.1451406762079--
------=_Part_4534_771918119.1451406762079--

.

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

On Tue, Dec 29, 2015 at 5:32 PM, Nicol Bolas <jmckesson@gmail.com> wrote:

> That wasn't a "clarification". That was a *change to your idea*.

I never said I wanted to introduce a new concept such as a "variable
alias". I am not entirely sure whether there *is* or *should be *a true
difference between a reference and variable alias. I *think* a reference
could be sufficient, but if there are valid arguments against that or a
better way to define a variable alias, let's see them, but let's not
dismiss the proposal just because of that. That was the whole point of my
clarification.

> That's not something that should be buried in the middle of a random post.

A clarification is made when it becomes clear that something is unclear. It
is made when it is felt it needs to be made. Labelling the message with the
clarification as a "random post" is baseless.

> It should be something that you should make abundantly clear to everyone
that a change has occurred. Not everyone is going to remember every minor
detail of every sentence from a post you wrote weeks ago.

Everyone? The clarification was made in response to your message. And it
was you who missed it. If you cannot be bothered to read responses to your
own messages, then I am not even sure why you post here.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 5:32 PM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_q=
uote">&gt; That wasn&#39;t a &quot;clarification&quot;. That was a <i>chang=
e to your idea</i>.</div><div class=3D"gmail_quote"><br></div><div class=3D=
"gmail_quote">I never said I wanted to introduce a new concept such as a &q=
uot;variable alias&quot;. I am not entirely sure whether there <i>is</i>=C2=
=A0or <i>should be=C2=A0</i>a true difference between a reference and varia=
ble alias. I <i>think</i>=C2=A0a reference could be sufficient, but if ther=
e are valid arguments against that or a better way to define a variable ali=
as, let&#39;s see them, but let&#39;s not dismiss the proposal just because=
 of that. That was the whole point of my clarification.</div><div class=3D"=
gmail_quote"><div><br></div><div>&gt; That&#39;s not something that should =
be buried in the middle of a random post.</div><div><br></div><div>A clarif=
ication is made when it becomes clear that something is unclear. It is made=
 when it is felt it needs to be made. Labelling the message with the clarif=
ication as a &quot;random post&quot; is baseless.</div><div><br></div><div>=
&gt; It should be something that you should make abundantly clear to everyo=
ne that a change has occurred. Not everyone is going to remember every mino=
r detail of every sentence from a post you wrote weeks ago.</div><div><br><=
/div><div>Everyone? The clarification was made in response to your message.=
 And it was you who missed it. If you cannot be bothered to read responses =
to your own messages, then I am not even sure why you post here.</div><div>=
<br></div><div><div>Cheers,</div><div>V.</div></div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a113da78e00eb0105280c5860--

.

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

On Tue, Dec 29, 2015 at 8:32 AM, Nicol Bolas <jmckesson@gmail.com> wrote:

> On Tuesday, December 29, 2015 at 11:01:13 AM UTC-5, Viacheslav Usov wrote:
>>
>> On Tue, Dec 29, 2015 at 4:52 PM, Nicol Bolas <jmck...@gmail.com> wrote:
>>
>> > That was what you said.
>> <https://groups.google.com/a/isocpp.org/d/msg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ>
>>
>>
>> And, of course, subsequent clarifications are to be ignored.
>>
>
> OK, I admit that I missed that line. That doesn't change one important
> fact:
>
> That wasn't a "clarification". That was a *change to your idea*.
>
> That's not something that should be buried in the middle of a random post.
> It should be something that you should make abundantly clear to everyone
> that a change has occurred. Not everyone is going to remember every minor
> detail of every sentence from a post you wrote weeks ago.
>
> If you're going to add new aspects to a proposal (and this is new), that
> needs to be made clear. You should have created a new post that said,
> "Earlier, I said that I wanted `using X = Y` to be `auto &X = Y` for
> objects. I realize now that I want it to mean something new instead."
>

Forking the discussion thread every time the idea is slightly adjusted will
make it near-impossible to follow the discussion as a whole, people will
inevitably respond to the wrong thread, and so on.

I think the best thing to do would be to write a short paper, update it
based on feedback, and post new versions to the discussion thread whenever
the paper is materially updated, with a brief description of the changes
made. Writing a paper is also a good way to ensure that your thoughts on
the subject are organized, coherent, consistent, and well-motivated.

Followed of course by an explanation of how this "something new" should
> behave (C++ doesn't have "variable aliases", so you have to explain what
> the rules for them are).
>
> That's something that people would notice and be aware of (and comment on.
> Note that nobody actually responded to the post including your change).
> Changes to your proposal due to issues brought up in debate are good. But
> you need to make it more visible when such changes happen.
>

To my reading, mapping "using X = Y" to a reference declaration was not
proposed by Viacheslav (the reference declaration was part of the
description of the problem, not part of the proposed solution). What was
proposed was to make "using X = Y be valid for all kinds of names", without
a precise specification for what that means. But I can see how you'd read
the introductory email in a different way.

Now that we have that out of the way, you still need to explain what a
> "variable alias" does.
>

(This is what I'd like to see, not necessarily what Viacheslav was
proposing.) Consider this in today's C++:

  namespace X {
    int n;
  }
  using X::n; // creates an alias ::n

There's no fundamental reason that the alias must have the same
unqualified-id as the original, and being able to rename the declaration is
every bit as useful as being able to make it appear within a different
namespace. So, suppose we allow:

  using m = X::n;

as an exact analogue of the existing using-declaration, but one that gives
the alias a different name.

When an alias-declaration is viewed as a renaming analogue of a
using-declaration, it's really odd that an alias-declaration can be used
only for types, whereas a using-declaration can be used for any kind of
entity (except namespaces and scoped enumerators -- more warts!).

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 8:32 AM, Nicol Bolas <span dir=3D"ltr">&lt;<a href=3D"m=
ailto:jmckesson@gmail.com" target=3D"_blank">jmckesson@gmail.com</a>&gt;</s=
pan> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">On Tuesday, December 29, 2015 at 11:01:13 A=
M UTC-5, Viacheslav Usov wrote:<span class=3D""><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=
=3D"ltr"><div><div class=3D"gmail_quote">On Tue, Dec 29, 2015 at 4:52 PM, N=
icol Bolas <span dir=3D"ltr">&lt;<a rel=3D"nofollow">jmck...@gmail.com</a>&=
gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">&gt;=C2=A0<a href=3D"https://groups.google.com/a/isocpp.org/d/m=
sg/std-proposals/4PR7LUngZFw/NmEiDCGNDQAJ" rel=3D"nofollow" target=3D"_blan=
k">That was what you said.</a>=C2=A0</div><div class=3D"gmail_quote"><br></=
div><div class=3D"gmail_quote">And, of course, subsequent clarifications ar=
e to be ignored.</div></div></div></blockquote></span><div><br>OK, I admit =
that I missed that line. That doesn&#39;t change one important fact:<br><br=
>That wasn&#39;t a &quot;clarification&quot;. That was a <i>change to your =
idea</i>.<br><br>That&#39;s not something that should be buried in the midd=
le of a random post. It should be something that you should make abundantly=
 clear to everyone that a change has occurred. Not everyone is going to rem=
ember every minor detail of every sentence from a post you wrote weeks ago.=
<br><br>If you&#39;re going to add new aspects to a proposal (and this is n=
ew), that needs to be made clear. You should have created a new post that s=
aid, &quot;Earlier, I said that I wanted `using X =3D Y` to be `auto &amp;X=
 =3D Y` for objects. I realize now that I want it to mean something new ins=
tead.&quot;</div></blockquote><div><br></div><div>Forking the discussion th=
read every time the idea is slightly adjusted will make it near-impossible =
to follow the discussion as a whole, people will inevitably respond to the =
wrong thread, and so on.</div><div><br></div><div>I think the best thing to=
 do would be to write a short paper, update it based on feedback, and post =
new versions to the discussion thread whenever the paper is materially upda=
ted, with a brief description of the changes made. Writing a paper is also =
a good way to ensure that your thoughts on the subject are organized, coher=
ent, consistent, and well-motivated.</div><div><br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">=
<div>Followed of course by an explanation of how this &quot;something new&q=
uot; should behave (C++ doesn&#39;t have &quot;variable aliases&quot;, so y=
ou have to explain what the rules for them are).<br><br>That&#39;s somethin=
g that people would notice and be aware of (and comment on. Note that nobod=
y actually responded to the post including your change). Changes to your pr=
oposal due to issues brought up in debate are good. But you need to make it=
 more visible when such changes happen.<br></div></blockquote><div><br></di=
v><div>To my reading, mapping &quot;using X =3D Y&quot; to a reference decl=
aration was not proposed by Viacheslav (the reference declaration was part =
of the description of the problem, not part of the proposed solution). What=
 was proposed was to make &quot;<span style=3D"font-size:12.8px">using X =
=3D Y be valid for all kinds of names&quot;, without a precise specificatio=
n for what that means. But I can see how you&#39;d read the introductory em=
ail in a different way.</span></div><div><br></div><blockquote class=3D"gma=
il_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-le=
ft-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>No=
w that we have that out of the way, you still need to explain what a &quot;=
variable alias&quot; does.</div></blockquote><div><br></div><div>(This is w=
hat I&#39;d like to see, not necessarily what Viacheslav was proposing.) Co=
nsider this in today&#39;s C++:<br></div><div><br></div><div>=C2=A0 namespa=
ce X {</div><div>=C2=A0 =C2=A0 int n;</div><div>=C2=A0 }</div><div>=C2=A0 u=
sing X::n; // creates an alias ::n</div><div><br></div><div>There&#39;s no =
fundamental reason that the alias must have the same unqualified-id as the =
original, and being able to rename the declaration is every bit as useful a=
s being able to make it appear within a different namespace. So, suppose we=
 allow:</div><div><br></div><div>=C2=A0 using m =3D X::n;</div><div><br></d=
iv><div>as an exact analogue of the existing using-declaration, but one tha=
t gives the alias a different name.</div><div><br></div><div>When an alias-=
declaration is viewed as a renaming analogue of a using-declaration, it&#39=
;s really odd that an alias-declaration can be used only for types, whereas=
 a using-declaration can be used for any kind of entity (except namespaces =
and scoped enumerators -- more warts!).</div></div></div></div>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--001a1143a94c1b168305280ef56f--

.

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

On Tue, Dec 29, 2015 at 9:06 PM, Richard Smith <richard@metafoo.co.uk>
wrote:

> I think the best thing to do would be to write a short paper

This is my conclusion as well. I will do so early next year.

Cheers,
V.

--

---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals/.

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

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 29, 2015 at 9:06 PM, Richard Smith <span dir=3D"ltr">&lt;<a href=3D=
"mailto:richard@metafoo.co.uk" target=3D"_blank">richard@metafoo.co.uk</a>&=
gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"g=
mail_quote">&gt; I think the best thing to do would be to write a short pap=
er</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Thi=
s is my conclusion as well. I will do so early next year.</div><div class=
=3D"gmail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div cla=
ss=3D"gmail_quote">V.</div><div class=3D"gmail_quote"><br></div></div></div=
>

<p></p>

-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
Visit this group at <a href=3D"https://groups.google.com/a/isocpp.org/group=
/std-proposals/">https://groups.google.com/a/isocpp.org/group/std-proposals=
/</a>.<br />

--089e0149c94e1f46b005281fd3e0--

.