------=_Part_885_132275077.1455302712827
Content-Type: multipart/alternative;
 boundary="----=_Part_886_2036665779.1455302712828"

------=_Part_886_2036665779.1455302712828
Content-Type: text/plain; charset=UTF-8

Did this proposal go any further than this forum? i.e. Is there a paper for
it submitted for discussion at Jacksonville?


On Wednesday, January 27, 2016 at 6:56:08 AM UTC-8, Viacheslav Usov wrote:
>
> Prior work:
>
> [1] n1449
>
> [2] n1489
>
> Nothing in this proposal is really new. It was nearly fully anticipated in
> [2], and, per [1], the strong preference at a straw poll at an Evolution
> Working Group meeting in favour of the syntax 'using X = Y' *stemmed
> partly from the desire to use a syntax that might be compatible with the
> non-template aliasing direction briefly outlined above*, where *the
> non-template aliasing direction *was a way to alias functions, which was
> not standardised.
>
> What's wrong with 'using', anyway?
>
> Currently, the keyword 'using' is part of
>
> 1. A *using-declaration: *using typename_opt *nested-name-specifier
> unqualified-id *[namespace.udecl];
>
> 2. A *using-directive*: *attribute-specifier-seq*_opt using namespace *nested-name-specifier_opt
> namespace-name *[namespace.udir];
>
> 3. An *alias-declaration:* using *identifier attribute-specifier-seq_opt
> = type-id *[dcl.dcl];
>
> 4. An *alias template *[temp.alias].
>
> Despite the seemingly similar syntax in all the cases, there are some
> arcane limitations that are difficult to characterize except as arbitrary.
> For example:
>
> namespace A
> {
>     struct c { static int k; };
>     int i;
>     void f() {}
>     void h(int) {};
>     void h(double) {};
>     namespace n {}
>     enum class e { v };
>     template<typename X, typename Y> struct s {};
>     template<typename X, typename Y> void g() {}
> }
>
> using A::c; // OK
> using C = A::c; // OK
> using A::c::k; // ill-formed, instead use the following
> auto &k = A::c::k;
> using K = A::c::k; // ill-formed, instead use the following
> auto &K = A::c::k;
> using A::i; // OK
> using I = A::i; // ill-formed, instead use the following
> auto &I = A::i;
> using A::f; // OK
> using F = A::f; // ill-formed, instead use the following
> auto &F = A::f;
> using A::h; // OK
> using H = A::h; // ill-formed, and the following does not work
> auto &H = A::h; // oops, but the following works
> template<typename ...X> // simplicity itself
> auto H(X &&...x) -> decltype(A::h(std::forward<X>(x)...))
> { return A::h(std::forward<X>(x)...); }
> using Hi = A::h(int); // ill-formed, instead use the following
> auto Hi(int x) -> decltype(A::h(x)) { return A::h(x); } // OK
> using A::n; // ill-formed, instead use the following
> using namespace A::n;
> using N = A::n; // ill-formed, instead use the following
> namespace N = A::n;
> using A::e::v; // ill-formed, instead use the following
> enum { v = A::e::v }; // but ::v is not fully equivalent to A::e::v
> using V = A::e::v; // ill-formed, instead use the following
> enum { V = A::e::v }; // but ::V is not fully equivalent to A::e::v
> template<typename X> using A::s<X, int>; // ill-formed, instead use the
> following
> template<typename X> using s = A::s<X, int>;
> template<typename X> using A::g<X, int>; // ill-formed, instead use the
> following
> template<typename X> auto g() -> decltype(A::g<X, int>()) { return A::g<X,
> int>(); }
> template<typename X> using G = A::g<X, int>; // ill-formed, instead use
> the following
> template<typename X> auto G() -> decltype(A::g<X, int>()) { return A::g<X,
> int>(); }
>
> In the example above, every mention of 'using' was an attempt to create an
> alias for an existing entity, sometimes with a narrower meaning of the
> alias. The example above demonstrates that current C++, while having a way
> to define an alias for an entity in (just about) every practical case, does
> not do so uniformly, thus lacking an important idiom. Sometimes correct C++
> for an alias is trivial, sometimes highly involved.
>
> A particular problem is that, without a uniform syntax for aliasing, some
> generic code is impossible to write (or, at least, to write it easily). For
> example, given entity E, there is no simple way to define alias F for E so
> that F() is valid whenever E() is valid.
>
> Proposal
>
> I propose *uniform aliasing*, which is, essentially, making every mention
> of 'using' in the example above (and similar cases that make sense) valid.
> More generally, it is a simple way to say "X is another name for Y", no
> matter what Y is.
>
> In more concrete terms, the proposed syntax is a fusion of all the four
> above-mentioned cases. I am not specifying the details of the syntax, but
> the idea is that 'using Y' and 'using X = Y' should be possible whenever Y
> denotes something that can be *meaningfully aliased*. *Meaningfully
> aliased *is not yet defined; to initiate a discussion, I would say that
> at least the following should be possible as Y: a namespace, a type, a
> function (with optional overload selection as in [2]), an lvalue, or an
> enumerator.
>
> When it is desirable to disambiguate explicitly what kind of entity Y is,
> one of 'auto', 'namespace' and 'typename' can be specified after 'using';
> 'using auto' signifies that Y is neither a namespace nor a type.
>
> Please comment.
>
> 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/.

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

<div dir=3D"ltr"><div>Did this proposal go any further than this forum? i.e=
.. Is there a paper for it submitted for discussion at Jacksonville?</div><b=
r><br>On Wednesday, January 27, 2016 at 6:56:08 AM UTC-8, 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">Prior wo=
rk:<div><br></div><div>[1] n1449</div><div><br></div><div>[2] n1489<br></di=
v><div><br></div><div>Nothing in this proposal is really new. It was nearly=
 fully anticipated in [2], and, per [1], the strong preference at a straw p=
oll at an Evolution Working Group meeting in favour of the syntax &#39;usin=
g X =3D Y&#39;=C2=A0<i style=3D"font-size:12.8px">stemmed partly from the d=
esire to use a syntax that might be compatible with the non-template aliasi=
ng direction briefly outlined above</i>, where=C2=A0<i style=3D"font-size:1=
2.8px">the non-template aliasing direction=C2=A0</i>was a way to alias func=
tions, which was not standardised.</div><div><br></div><div>What&#39;s wron=
g with &#39;using&#39;, anyway?</div><div><br></div><div>Currently, the key=
word &#39;using&#39; is part of</div><div><br></div><div>1. A <i>using-decl=
aration:=C2=A0</i>using typename_opt <i>nested-name-specifier unqualified-i=
d=C2=A0</i>[namespace.<wbr>udecl];</div><div><br></div><div>2. A <i>using-d=
irective</i>:=C2=A0<i>attribute-<wbr>specifier-seq</i>_opt using namespace =
<i>nested-name-specifier_opt namespace-name=C2=A0</i>[namespace.<wbr>udir];=
</div><div><br></div><div>3. An <i>alias-declaration:</i> using <i>identifi=
er attribute-specifier-seq_opt =3D type-id=C2=A0</i>[dcl.dcl];</div><div><b=
r></div><div>4. An <i>alias template=C2=A0</i>[temp.alias].</div><div><br><=
/div><div>Despite the seemingly similar syntax in all the cases, there are =
some arcane limitations that are difficult to characterize except as arbitr=
ary. For example:</div><div><br></div><div><div><div>namespace A</div><div>=
{</div><div>=C2=A0 =C2=A0 struct c { static int k; };</div><div>=C2=A0 =C2=
=A0 int i;</div><div>=C2=A0 =C2=A0 void f() {}</div><div>=C2=A0 =C2=A0 void=
 h(int) {};</div><div>=C2=A0 =C2=A0 void h(double) {};</div><div>=C2=A0 =C2=
=A0 namespace n {}</div><div>=C2=A0 =C2=A0 enum class e { v };</div><div>=
=C2=A0 =C2=A0 template&lt;typename X, typename Y&gt; struct s {};</div><div=
>=C2=A0 =C2=A0 template&lt;typename X, typename Y&gt; void g() {}</div><div=
>}</div><div><br></div><div>using A::c; // OK</div><div>using C =3D A::c; /=
/ OK</div><div>using A::c::k; // ill-formed, instead use the following</div=
><div>auto &amp;k =3D A::c::k;</div><div>using K =3D A::c::k; // ill-formed=
, instead use the following</div><div>auto &amp;K =3D A::c::k;</div><div>us=
ing A::i; // OK</div><div>using I =3D A::i; // ill-formed, instead use the =
following</div><div>auto &amp;I =3D A::i;</div><div>using A::f; // OK</div>=
<div>using F =3D A::f; // ill-formed, instead use the following</div><div>a=
uto &amp;F =3D A::f;</div><div>using A::h; // OK</div><div>using H =3D A::h=
; // ill-formed, and the following does not work</div><div>auto &amp;H =3D =
A::h; // oops, but the following works</div><div>template&lt;typename ...X&=
gt; // simplicity itself</div><div>auto H(X &amp;&amp;...x) -&gt; decltype(=
A::h(std::forward&lt;X&gt;(<wbr>x)...))</div><div>{ return A::h(std::forwar=
d&lt;X&gt;(x)...); }</div><div>using Hi =3D A::h(int); // ill-formed, inste=
ad use the following</div><div>auto Hi(int x) -&gt; decltype(A::h(x)) { ret=
urn A::h(x); } // OK</div><div>using A::n; // ill-formed, instead use the f=
ollowing</div><div>using namespace A::n;</div><div>using N =3D A::n; // ill=
-formed, instead use the following</div><div>namespace N =3D A::n;</div><di=
v>using A::e::v; // ill-formed, instead use the following</div><div>enum { =
v =3D A::e::v }; // but ::v is not fully equivalent to A::e::v</div><div>us=
ing V =3D A::e::v; // ill-formed, instead use the following</div><div>enum =
{ V =3D A::e::v }; // but ::V is not fully equivalent to A::e::v</div><div>=
template&lt;typename X&gt; using A::s&lt;X, int&gt;; // ill-formed, instead=
 use the following</div><div>template&lt;typename X&gt; using s =3D A::s&lt=
;X, int&gt;;</div><div>template&lt;typename X&gt; using A::g&lt;X, int&gt;;=
 // ill-formed, instead use the following</div><div>template&lt;typename X&=
gt; auto g() -&gt; decltype(A::g&lt;X, int&gt;()) { return A::g&lt;X, int&g=
t;(); }</div><div>template&lt;typename X&gt; using G =3D A::g&lt;X, int&gt;=
; // ill-formed, instead use the following</div><div>template&lt;typename X=
&gt; auto G() -&gt; decltype(A::g&lt;X, int&gt;()) { return A::g&lt;X, int&=
gt;(); }</div></div></div><div><br></div><div>In the example above, every m=
ention of &#39;using&#39; was an attempt to create an alias for an existing=
 entity, sometimes with a narrower meaning of the alias. The example above =
demonstrates that current C++, while having a way to define an alias for an=
 entity in (just about) every practical case, does not do so uniformly, thu=
s lacking an important idiom. Sometimes correct C++ for an alias is trivial=
, sometimes highly involved.<br></div><div><br></div><div>A particular prob=
lem is that, without a uniform syntax for aliasing, some generic code is im=
possible to write (or, at least, to write it easily). For example, given en=
tity E, there is no simple way to define alias F for E so that F() is valid=
 whenever E() is valid.</div><div><br></div><div>Proposal<br></div><div><br=
></div><div>I propose <i>uniform aliasing</i>, which is, essentially, makin=
g every mention of &#39;using&#39; in the example above (and similar cases =
that make sense) valid. More generally, it is a simple way to say &quot;X i=
s another name for Y&quot;, no matter what Y is.</div><div><br></div><div>I=
n more concrete terms, the proposed syntax is a fusion of all the four abov=
e-mentioned cases. I am not specifying the details of the syntax, but the i=
dea is that &#39;using Y&#39; and &#39;using X =3D Y&#39; should be possibl=
e whenever Y denotes something that can be <i>meaningfully aliased</i>. <i>=
Meaningfully aliased=C2=A0</i>is not yet defined; to initiate a discussion,=
 I would say that at least the following should be possible as Y: a namespa=
ce, a type, a function (with optional overload selection as in [2]), an lva=
lue, or an enumerator.</div><div><br></div><div>When it is desirable to dis=
ambiguate explicitly what kind of entity Y is, one of &#39;auto&#39;, &#39;=
namespace&#39; and &#39;typename&#39; can be specified after &#39;using&#39=
;; &#39;using auto&#39; signifies that Y is neither a namespace nor a type.=
<br></div><div><br></div><div>Please comment.</div><div><br></div><div>Chee=
rs,</div><div>V.</div><div><br></div></div>
</blockquote></div>

<p></p>

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

------=_Part_886_2036665779.1455302712828--
------=_Part_885_132275077.1455302712827--

.

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

On Fri, Feb 12, 2016 at 7:45 PM, Michael Price - Dev <
michael.b.price.dev@gmail.com> wrote:

> Did this proposal go any further than this forum? i.e. Is there a paper
for it submitted for discussion at Jacksonville?

Not at this stage. Primarily because I think submitting a paper for
Jacksonville without someone being there to back it is a waste of time. I
know I won't be there, and so far no one else has seemed interested enough
to do so.

But it takes only one person to change all 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/.

--001a113d38ce719ac5052bcf1d3b
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, Feb 12, 2016 at 7:45 PM, Michael Price - Dev <span dir=3D"ltr">&lt;<a h=
ref=3D"mailto:michael.b.price.dev@gmail.com" target=3D"_blank">michael.b.pr=
ice.dev@gmail.com</a>&gt;</span> wrote:</div><div class=3D"gmail_quote"><br=
></div><div class=3D"gmail_quote">&gt; Did this proposal go any further tha=
n this forum? i.e. Is there a paper for it submitted for discussion at Jack=
sonville?</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">Not at this stage. Primarily because I think submitting a paper for Jac=
ksonville without someone being there to back it is a waste of time. I know=
 I won&#39;t be there, and so far no one else has seemed interested enough =
to do so.</div><div class=3D"gmail_quote"><br></div><div class=3D"gmail_quo=
te">But it takes only one person to change all that :)</div><div class=3D"g=
mail_quote"><br></div><div class=3D"gmail_quote">Cheers,</div><div class=3D=
"gmail_quote">V.</div><div class=3D"gmail_quote"><br></div><div class=3D"gm=
ail_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 />

--001a113d38ce719ac5052bcf1d3b--

.