Topic: An implementation of N4035 (auto alias) using clang
Author: Faisal Vali <faisalv@gmail.com>
Date: Sun, 6 Jul 2014 13:36:01 -0500
Raw View
Here you go Peter - per our discussion in Rapperswil - an
implementation to play with in clang:
https://github.com/faisalv/clang/tree/using-auto
To see a sample of what compiles:
https://github.com/faisalv/clang/blob/using-auto/test/SemaCXX/cxx1z-auto-alias.cpp
Hopefully - maybe playing around with the implementation might inform
further discussion and perhaps facilitate convergence towards an
eventual design that seems right for C++ users - or acknowledgment
that the design space might need to be radically revisited.
To highlight features of this patch as they might differ from N4035:
- auto-aliases only kick in for variable declarations and 'auto'
function returns (not during template argument deduction of any other
sort, such as generic lambdas etc).
- currently allowed in unions
- not allowed for decltype(auto)
- do not trigger explicit conversions
EWG's current stance: http://isocpp.org/files/papers/N4101.html#76
Hope this helps Peter!
Faisal Vali
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 7 Jul 2014 09:22:49 +0800
Raw View
--Apple-Mail=_747DD7BD-8AEC-4042-884F-8A2793461D3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-07, at 2:36 AM, Faisal Vali <faisalv@gmail.com> wrote:
> To highlight features of this patch as they might differ from N4035:
> - auto-aliases only kick in for variable declarations and 'auto'
> function returns (not during template argument deduction of any other
> sort, such as generic lambdas etc).
> - currently allowed in unions
> - not allowed for decltype(auto)
> - do not trigger explicit conversions
>=20
> EWG's current stance: http://isocpp.org/files/papers/N4101.html#76
Nice work!
Your extension provides a member typename called auto, right?
The conversion-function-id operator auto is already syntactically valid, it=
s only problem being that auto should be looked up at class scope. It seems=
that you have defined the result of that lookup.
Defining members auto and operator auto() would essentially get back to the=
point of the original proposal, no? I don't think the change sacrifices th=
e "running code" semantic, so much as it reconciles it with the existing co=
re language. Specifying a return type on a conversion function would have b=
een irregular.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_747DD7BD-8AEC-4042-884F-8A2793461D3D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–07, at 2:36 AM, Faisal Vali <<a href=3D"mailto:faisalv@gm=
ail.com">faisalv@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite">To highlight features of this patch a=
s they might differ from N4035:<br> - auto-aliases only kick in for v=
ariable declarations and 'auto'<br>function returns (not during template ar=
gument deduction of any other<br>sort, such as generic lambdas etc).<br> &n=
bsp;- currently allowed in unions<br> - not allowed for decltype(auto=
)<br> - do not trigger explicit conversions<br><br>EWG's current stan=
ce: <a href=3D"http://isocpp.org/files/papers/N4101.html#76">http://i=
socpp.org/files/papers/N4101.html#76</a><br></blockquote></div><br><div>Nic=
e work!</div><div><br></div><div>Your extension provides a member typename =
called <font face=3D"Courier">auto</font>, right?</div><div><br></div><div>=
The <i>conversion-function-id</i> <font face=3D"Courier">operator auto</fon=
t> is already syntactically valid, its only problem being that <font face=
=3D"Courier">auto</font> should be looked up at class scope. It seems that =
you have defined the result of that lookup.</div><div><br></div><div>Defini=
ng members <font face=3D"Courier">auto</font> and <font face=3D"Courier">op=
erator auto()</font> would essentially get back to the point of the or=
iginal proposal, no? I don’t think the change sacrifices the "running=
code” semantic, so much as it reconciles it with the existing core l=
anguage. Specifying a return type on a conversion function would have been =
irregular.</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_747DD7BD-8AEC-4042-884F-8A2793461D3D--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 7 Jul 2014 09:36:09 +0800
Raw View
--Apple-Mail=_D47BD0A4-E020-451B-BF12-76534C49548D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-07, at 2:36 AM, Faisal Vali <faisalv@gmail.com> wrote:
> Here you go Peter - per our discussion in Rapperswil - an
> implementation to play with in clang:
>=20
> https://github.com/faisalv/clang/tree/using-auto
>=20
> To see a sample of what compiles:
> https://github.com/faisalv/clang/blob/using-auto/test/SemaCXX/cxx1z-auto-=
alias.cpp
I've not played with it yet, but just speculating: The mechanical problem b=
eing solved is member references to expiring objects. The generic solution,=
to prolong a what's otherwise a temporary-only class, is to derive from it=
and provide the necessary backing storage. Link the base class references =
to derived class member objects and expose the base interface to the user.
It may not be a solution for matrix expression templates (or it may be so, =
I don't know enough to judge), but it would certainly be attractive for thi=
ngs like iostream manipulators which recently came up in another thread.
Permitting this design pattern would suggest that member typename auto shou=
ld either not be inherited, or there should be a facility for overriding or=
deleting it, or at least that there should be no problem (and no effect) i=
f auto names its enclosing class due to inheritance.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_D47BD0A4-E020-451B-BF12-76534C49548D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–07, at 2:36 AM, Faisal Vali <<a href=3D"mailto:faisalv@gm=
ail.com">faisalv@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite">Here you go Peter - per our discussio=
n in Rapperswil - an<br>implementation to play with in clang:<br><br>=
<a href=3D"https://github.com/faisalv/clang/tree/using-auto">https://github=
..com/faisalv/clang/tree/using-auto</a><br><br>To see a sample of what compi=
les:<br>https://github.com/faisalv/clang/blob/using-auto/test/SemaCXX/cxx1z=
-auto-alias.cpp<br></blockquote></div><br><div>I’ve not played with i=
t yet, but just speculating: The mechanical problem being solved is member =
references to expiring objects. The generic solution, to prolong a what&rsq=
uo;s otherwise a temporary-only class, is to derive from it and provide the=
necessary backing storage. Link the base class references to derived class=
member objects and expose the base interface to the user.</div><div><br></=
div><div>It may not be a solution for matrix expression templates (or it ma=
y be so, I don’t know enough to judge), but it would certainly be att=
ractive for things like iostream manipulators which recently came up in ano=
ther thread.</div><div><br></div><div>Permitting this design pattern would =
suggest that member typename <font face=3D"Courier">auto</font> should eith=
er not be inherited, or there should be a facility for overriding or deleti=
ng it, or at least that there should be no problem (and no effect) if <font=
face=3D"Courier">auto</font> names its enclosing class due to inheritance.=
</div><div><br></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_D47BD0A4-E020-451B-BF12-76534C49548D--
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Sun, 6 Jul 2014 21:17:05 -0500
Raw View
On Sun, Jul 6, 2014 at 8:22 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9307, at 2:36 AM, Faisal Vali <faisalv@gmail.com=
> wrote:
>
> To highlight features of this patch as they might differ from N4035:
> - auto-aliases only kick in for variable declarations and 'auto'
> function returns (not during template argument deduction of any other
> sort, such as generic lambdas etc).
> - currently allowed in unions
> - not allowed for decltype(auto)
> - do not trigger explicit conversions
>
> EWG's current stance: http://isocpp.org/files/papers/N4101.html#76
>
>
> Nice work!
>
> Your extension provides a member typename called auto, right?
No - I did not interpret N4035 to specify it as such. The extension just s=
ays:
- if the type of the initializer being implicitly deduced in an
'auto' containing variable initialization
contains a 'using auto =3D <type-id>' then the 'type-id' is
substituted into the 'auto' within the decl-specifier
of the variable being declared - and then the initialization is done.
For e.g in:
auto *a =3D X{};
The patch checks the type 'X' to see if it is a struct/class/union
type that contains a
'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
it is using auto =3D double)
into the declaration:
double *a =3D X{};
Then it performs the initialization - and if it is ill-formed (it
won't be if X has a conversion to double*)
- then so be it.
Perhaps auto alias is not the best way to describe it - especially
considering Roger Orr pointed out
the discrepancy between member type aliases and 'auto aliases'.
struct N {
using auto =3D double*;
using dptr =3D double*;
void foo() {
auto f =3D 0; // 'auto' does not mean 'double*'
dptr df =3D 0; // dptr does mean 'double*'
}
operator double**() const { return 0; }
}
auto *n =3D N{}; // OK - substitute double* for auto gives us double**,
which N can convert from.
Hope that clarifies things.
Thanks!
>
> The conversion-function-id operator auto is already syntactically valid, =
its
> only problem being that auto should be looked up at class scope. It seems
> that you have defined the result of that lookup.
>
> Defining members auto and operator auto() would essentially get back to t=
he
> point of the original proposal, no? I don=E2=80=99t think the change sacr=
ifices the
> "running code=E2=80=9D semantic, so much as it reconciles it with the exi=
sting core
> language. Specifying a return type on a conversion function would have be=
en
> irregular.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 7 Jul 2014 11:24:45 +0800
Raw View
--Apple-Mail=_5E7AB685-8996-4368-AB73-0825047A26B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-07, at 10:17 AM, Faisal Vali <faisalv@gmail.com> wrote:
> No - I did not interpret N4035 to specify it as such. The extension just=
says:
> - if the type of the initializer being implicitly deduced in an
> 'auto' containing variable initialization
> contains a 'using auto =3D <type-id>' then the 'type-id' is
> substituted into the 'auto' within the decl-specifier
> of the variable being declared - and then the initialization is done.
>=20
> For e.g in:
> auto *a =3D X{};
I don't see where N4035 mentions anything about compound types formed with =
auto. Did I miss something?
> The patch checks the type 'X' to see if it is a struct/class/union
> type that contains a
> 'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
> it is using auto =3D double)
> into the declaration:
> double *a =3D X{};
>=20
> Then it performs the initialization - and if it is ill-formed (it
> won't be if X has a conversion to double*)
> - then so be it.
Hmm, is there a use case for the behavior when it's well-formed? This seems=
like a departure from N4035 and it's a little weird.
> Perhaps auto alias is not the best way to describe it - especially
> considering Roger Orr pointed out
> the discrepancy between member type aliases and 'auto aliases'.
>=20
> struct N {
> using auto =3D double*;
> using dptr =3D double*;
> void foo() {
> auto f =3D 0; // 'auto' does not mean 'double*'
My suggestion is that auto be added to the unqualified-id production in the=
contexts it makes sense, e.g. in a qualified-id or member declarator-id. T=
hen you could say N::auto f =3D 0;. This replaces N4035's auto_result_type<=
T> builtin alias, which I don't see in your example test cases.
Why the "auto alias" discrepancy? Special treatment of auto isn't needed fo=
r the sake of parsing, since usual typenames are already just regular ident=
ifiers which may hide preexisting declarations. The special thing about sim=
ple-type-specifier keywords like auto is that they combine to form construc=
ts like unsigned long int, but that doesn't apply to auto (unless you count=
decltype(auto), which is does not introduce the same potential ambiguity).=
=20
TL;DR: auto already behaves syntactically enough like an identifier that if=
we add one case of overlap (for alias-declarations) we might as well add t=
hem all, subject to semantic constraints.
> Hope that clarifies things.
Yep, thanks! Hope I've added something to the discussion.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_5E7AB685-8996-4368-AB73-0825047A26B7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–07, at 10:17 AM, Faisal Vali <<a href=3D"mailto:faisalv@g=
mail.com">faisalv@gmail.com</a>> wrote:</div><br class=3D"Apple-intercha=
nge-newline"><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-=
style: normal; font-variant: normal; font-weight: normal; letter-spacing: n=
ormal; line-height: normal; orphans: auto; text-align: start; text-indent: =
0px; text-transform: none; white-space: normal; widows: auto; word-spacing:=
0px; -webkit-text-stroke-width: 0px;">No - I did not interpret N4035 to sp=
ecify it as such. The extension just says:<br> - if the type of =
the initializer being implicitly deduced in an<br>'auto' containing variabl=
e initialization<br> contains a 'using auto =3D <type-i=
d>' then the 'type-id' is<br>substituted into the 'auto' within the decl=
-specifier<br> of the variable being declared - and then t=
he initialization is done.<br><br>For e.g in:<br>auto *a =3D X{};<br></div>=
</blockquote><div><br></div><div>I don’t see where N4035 mentions any=
thing about compound types formed with auto. Did I miss something?</div><br=
><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-style: norma=
l; font-variant: normal; font-weight: normal; letter-spacing: normal; line-=
height: normal; orphans: auto; text-align: start; text-indent: 0px; text-tr=
ansform: none; white-space: normal; widows: auto; word-spacing: 0px; -webki=
t-text-stroke-width: 0px;">The patch checks the type 'X' to see if it is a =
struct/class/union<br>type that contains a<br>'using auto =3D <type-id&g=
t;' - and if so, substitutes the type-id (suppose<br>it is using auto =3D d=
ouble)<br>into the declaration:<br>double *a =3D X{};<br><br>Then it perfor=
ms the initialization - and if it is ill-formed (it<br>won't be if X has a =
conversion to double*)<br>- then so be it.<br></div></blockquote><div><br><=
/div><div>Hmm, is there a use case for the behavior when it's well-formed? =
This seems like a departure from N4035 and it’s a little weird.</div>=
<br><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-style: no=
rmal; font-variant: normal; font-weight: normal; letter-spacing: normal; li=
ne-height: normal; orphans: auto; text-align: start; text-indent: 0px; text=
-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -we=
bkit-text-stroke-width: 0px;">Perhaps auto alias is not the best way to des=
cribe it - especially<br>considering Roger Orr pointed out<br>the discrepan=
cy between member type aliases and 'auto aliases'.<br><br>struct N {<br>&nb=
sp;using auto =3D double*;<br> using dptr =3D double*;<br> void f=
oo() {<br> auto f =3D 0; // 'auto' does not mean 'do=
uble*’</div></blockquote><div><br></div><div>My suggestion is that <f=
ont face=3D"Courier">auto</font> be added to the <i>unqualified-id</i>=
production in the contexts it makes sense, e.g. in a <i>qualified-id<=
/i> or member <i>declarator-id</i>. Then you could say <font face=3D"C=
ourier">N::auto f =3D 0;</font>. This replaces N4035’s <font face=3D"=
Courier">auto_result_type<T></font> builtin alias, which I don’=
t see in your example test cases.</div><div><br></div><div>Why the “a=
uto alias” discrepancy? Special treatment of auto isn’t needed =
for the sake of parsing, since usual typenames are already just regular ide=
ntifiers which may hide preexisting declarations. The special thing about <=
i>simple-type-specifier</i> keywords like <font face=3D"Courier">auto</font=
> is that they combine to form constructs like <font face=3D"Courier">unsig=
ned long int</font>, but that doesn’t apply to <font face=3D"Courier"=
>auto</font> (unless you count <font face=3D"Courier">decltype(au=
to)</font>, which is does not introduce the same potential ambiguity). =
;</div><div><br></div><div>TL;DR: <font face=3D"Courier">auto</font>&n=
bsp;already behaves syntactically enough like an identifier that if we add =
one case of overlap (for <i>alias-declarations</i>) we might as well add th=
em all, subject to semantic constraints.</div><br><blockquote type=3D"cite"=
><div style=3D"font-size: 12px; font-style: normal; font-variant: normal; f=
ont-weight: normal; letter-spacing: normal; line-height: normal; orphans: a=
uto; text-align: start; text-indent: 0px; text-transform: none; white-space=
: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"=
>Hope that clarifies things.<br></div></blockquote></div><br><div>Yep, than=
ks! Hope I’ve added something to the discussion.</div><div><br></div>=
</body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_5E7AB685-8996-4368-AB73-0825047A26B7--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 6 Jul 2014 21:15:02 -0700
Raw View
--047d7b342d301cfae804fd92b8c6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 6, 2014 at 7:17 PM, Faisal Vali <faisalv@gmail.com> wrote:
> On Sun, Jul 6, 2014 at 8:22 PM, David Krauss <potswa@gmail.com> wrote:
> >
> > On 2014=E2=80=9307=E2=80=9307, at 2:36 AM, Faisal Vali <faisalv@gmail.c=
om> wrote:
> >
> > To highlight features of this patch as they might differ from N4035:
> > - auto-aliases only kick in for variable declarations and 'auto'
> > function returns (not during template argument deduction of any other
> > sort, such as generic lambdas etc).
> > - currently allowed in unions
> > - not allowed for decltype(auto)
> > - do not trigger explicit conversions
> >
> > EWG's current stance: http://isocpp.org/files/papers/N4101.html#76
> >
> >
> > Nice work!
> >
> > Your extension provides a member typename called auto, right?
>
> No - I did not interpret N4035 to specify it as such. The extension just
> says:
> - if the type of the initializer being implicitly deduced in an
> 'auto' containing variable initialization
> contains a 'using auto =3D <type-id>' then the 'type-id' is
> substituted into the 'auto' within the decl-specifier
> of the variable being declared - and then the initialization is done.
>
> For e.g in:
> auto *a =3D X{};
>
> The patch checks the type 'X' to see if it is a struct/class/union
> type that contains a
> 'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
> it is using auto =3D double)
> into the declaration:
> double *a =3D X{};
>
This seems quite strange to me, and not at all how I'd expected this to
behave. Instead, what I'd expect is:
When performing 'auto' deduction on an expression E of class type cv C, if
C has a 'using auto =3D <type-id>', then deduce the type from <type-id>
instead of from E.
Then it performs the initialization - and if it is ill-formed (it
> won't be if X has a conversion to double*)
> - then so be it.
>
In this case, I'd expect to get a deduction failure (can't deduce 'T *'
from 'double').
> Perhaps auto alias is not the best way to describe it - especially
> considering Roger Orr pointed out
> the discrepancy between member type aliases and 'auto aliases'.
>
> struct N {
> using auto =3D double*;
> using dptr =3D double*;
> void foo() {
> auto f =3D 0; // 'auto' does not mean 'double*'
> dptr df =3D 0; // dptr does mean 'double*'
> }
> operator double**() const { return 0; }
> }
>
> auto *n =3D N{}; // OK - substitute double* for auto gives us double**,
> which N can convert from.
>
> Hope that clarifies things.
>
> Thanks!
>
> >
> > The conversion-function-id operator auto is already syntactically valid=
,
> its
> > only problem being that auto should be looked up at class scope. It see=
ms
> > that you have defined the result of that lookup.
> >
> > Defining members auto and operator auto() would essentially get back to
> the
> > point of the original proposal, no? I don=E2=80=99t think the change sa=
crifices
> the
> > "running code=E2=80=9D semantic, so much as it reconciles it with the e=
xisting
> core
> > language. Specifying a return type on a conversion function would have
> been
> > irregular.
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google Grou=
ps
> > "ISO C++ Standard - Future Proposals" group.
> > To unsubscribe from this group and stop receiving emails from it, send =
an
> > email to std-proposals+unsubscribe@isocpp.org.
> > To post to this group, send email to std-proposals@isocpp.org.
> > Visit this group at
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--047d7b342d301cfae804fd92b8c6
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 S=
un, Jul 6, 2014 at 7:17 PM, Faisal Vali <span dir=3D"ltr"><<a href=3D"ma=
ilto:faisalv@gmail.com" target=3D"_blank">faisalv@gmail.com</a>></span> =
wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Sun, Jul 6, 2014 at 8:22 =
PM, David Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</=
a>> wrote:<br>
><br>
> On 2014=E2=80=9307=E2=80=9307, at 2:36 AM, Faisal Vali <<a href=3D"=
mailto:faisalv@gmail.com">faisalv@gmail.com</a>> wrote:<br>
><br>
> To highlight features of this patch as they might differ from N4035:<b=
r>
> =C2=A0- auto-aliases only kick in for variable declarations and 'a=
uto'<br>
> function returns (not during template argument deduction of any other<=
br>
> sort, such as generic lambdas etc).<br>
> =C2=A0- currently allowed in unions<br>
> =C2=A0- not allowed for decltype(auto)<br>
> =C2=A0- do not trigger explicit conversions<br>
><br>
> EWG's current stance: =C2=A0<a href=3D"http://isocpp.org/files/pap=
ers/N4101.html#76" target=3D"_blank">http://isocpp.org/files/papers/N4101.h=
tml#76</a><br>
><br>
><br>
> Nice work!<br>
><br>
> Your extension provides a member typename called auto, right?<br>
<br>
</div>No - I did not interpret N4035 to specify it as such. =C2=A0The exten=
sion just says:<br>
=C2=A0 - if the type of the initializer being implicitly deduced in an<br>
'auto' containing variable initialization<br>
=C2=A0 =C2=A0 contains a 'using auto =3D <type-id>' then the =
'type-id' is<br>
substituted into the 'auto' within the decl-specifier<br>
=C2=A0 =C2=A0 of the variable being declared - and then the initialization =
is done.<br>
<br>
For e.g in:<br>
auto *a =3D X{};<br>
<br>
The patch checks the type 'X' to see if it is a struct/class/union<=
br>
type that contains a<br>
'using auto =3D <type-id>' - and if so, substitutes the type-=
id (suppose<br>
it is using auto =3D double)<br>
into the declaration:<br>
double *a =3D X{};<br></blockquote><div><br></div><div>This seems quite str=
ange to me, and not at all how I'd expected this to behave. Instead, wh=
at I'd expect is:</div><div><br></div><div>When performing 'auto=
9; deduction on an expression E of class type cv C, if C has a 'using a=
uto =3D <type-id>', then deduce the type from <type-id> ins=
tead of from E.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex">
Then it performs the initialization - and if it is ill-formed (it<br>
won't be if X has a conversion to double*)<br>
- then so be it.<br></blockquote><div><br></div><div>In this case, I'd =
expect to get a deduction failure (can't deduce 'T *' from '=
;double').</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" styl=
e=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Perhaps auto alias is not the best way to describe it - especially<br>
considering Roger Orr pointed out<br>
the discrepancy between member type aliases and 'auto aliases'.<br>
<br>
struct N {<br>
=C2=A0 using auto =3D double*;<br>
=C2=A0 using dptr =3D double*;<br>
=C2=A0 void foo() {<br>
=C2=A0 =C2=A0 auto f =3D 0; // =C2=A0'auto' does not mean 'doub=
le*'<br>
=C2=A0 =C2=A0 dptr df =3D 0; // dptr =C2=A0does mean 'double*'<br>
=C2=A0 }<br>
=C2=A0 operator double**() const { return 0; }<br>
}<br>
<br>
auto *n =3D N{}; // OK - substitute double* for auto gives us double**,<br>
which N can convert from.<br>
<br>
Hope that clarifies things.<br>
<br>
Thanks!<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
><br>
> The conversion-function-id operator auto is already syntactically vali=
d, its<br>
> only problem being that auto should be looked up at class scope. It se=
ems<br>
> that you have defined the result of that lookup.<br>
><br>
> Defining members auto and operator auto() would essentially get back t=
o the<br>
> point of the original proposal, no? I don=E2=80=99t think the change s=
acrifices the<br>
> "running code=E2=80=9D semantic, so much as it reconciles it with=
the existing core<br>
> language. Specifying a return type on a conversion function would have=
been<br>
> irregular.<br>
><br>
> --<br>
><br>
> ---<br>
> You received this message because you are subscribed to the Google Gro=
ups<br>
> "ISO C++ Standard - Future Proposals" group.<br>
> To unsubscribe from this group and stop receiving emails from it, send=
an<br>
> email to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std=
-proposals+unsubscribe@isocpp.org</a>.<br>
> To post to this group, send email to <a href=3D"mailto:std-proposals@i=
socpp.org">std-proposals@isocpp.org</a>.<br>
> Visit this group at<br>
> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposals/"=
target=3D"_blank">http://groups.google.com/a/isocpp.org/group/std-proposal=
s/</a>.<br>
<br>
--<br>
<br>
---<br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals%2Bunsubscribe@isocpp.org">std-propo=
sals+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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--047d7b342d301cfae804fd92b8c6--
.
Author: Richard Smith <richard@metafoo.co.uk>
Date: Sun, 6 Jul 2014 21:18:37 -0700
Raw View
--089e011618ceec5f2604fd92c4ea
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
On Sun, Jul 6, 2014 at 8:24 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9307, at 10:17 AM, Faisal Vali <faisalv@gmail.co=
m> wrote:
>
> No - I did not interpret N4035 to specify it as such. The extension just
> says:
> - if the type of the initializer being implicitly deduced in an
> 'auto' containing variable initialization
> contains a 'using auto =3D <type-id>' then the 'type-id' is
> substituted into the 'auto' within the decl-specifier
> of the variable being declared - and then the initialization is done.
>
> For e.g in:
> auto *a =3D X{};
>
>
> I don=E2=80=99t see where N4035 mentions anything about compound types fo=
rmed with
> auto. Did I miss something?
>
> The patch checks the type 'X' to see if it is a struct/class/union
> type that contains a
> 'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
> it is using auto =3D double)
> into the declaration:
> double *a =3D X{};
>
> Then it performs the initialization - and if it is ill-formed (it
> won't be if X has a conversion to double*)
> - then so be it.
>
>
> Hmm, is there a use case for the behavior when it's well-formed? This
> seems like a departure from N4035 and it=E2=80=99s a little weird.
>
> Perhaps auto alias is not the best way to describe it - especially
> considering Roger Orr pointed out
> the discrepancy between member type aliases and 'auto aliases'.
>
> struct N {
> using auto =3D double*;
> using dptr =3D double*;
> void foo() {
> auto f =3D 0; // 'auto' does not mean 'double*=E2=80=99
>
>
> My suggestion is that auto be added to the *unqualified-id* production in
> the contexts it makes sense, e.g. in a *qualified-id* or member
> *declarator-id*. Then you could say N::auto f =3D 0;. This replaces N4035=
=E2=80=99s
> auto_result_type<T> builtin alias, which I don=E2=80=99t see in your exam=
ple test
> cases.
>
> Why the =E2=80=9Cauto alias=E2=80=9D discrepancy? Special treatment of au=
to isn=E2=80=99t needed
> for the sake of parsing, since usual typenames are already just regular
> identifiers which may hide preexisting declarations. The special thing
> about *simple-type-specifier* keywords like auto is that they combine to
> form constructs like unsigned long int, but that doesn=E2=80=99t apply to=
auto (unless
> you count decltype(auto), which is does not introduce the same potential
> ambiguity).
>
> TL;DR: auto already behaves syntactically enough like an identifier that
> if we add one case of overlap (for *alias-declarations*) we might as well
> add them all, subject to semantic constraints.
>
FWIW, I disagree. 'using auto =3D <type-id>;' is just a semi-arbitrary
syntactic way to get the particular semantic effect of overriding 'auto'
deduction. It seems like a *major* stretch to say that that 'auto' now
behaves like an identifier. This does make me wonder if a different syntax
would be less confusing. Maybe drop the 'using'; just 'auto =3D <type-id>;'=
?
> Hope that clarifies things.
>
>
> Yep, thanks! Hope I=E2=80=99ve added something to the discussion.
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--089e011618ceec5f2604fd92c4ea
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 S=
un, Jul 6, 2014 at 8:24 PM, David Krauss <span dir=3D"ltr"><<a href=3D"m=
ailto:potswa@gmail.com" target=3D"_blank">potswa@gmail.com</a>></span> w=
rote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><br><div=
><div class=3D""><div>On 2014=E2=80=9307=E2=80=9307, at 10:17 AM, Faisal Va=
li <<a href=3D"mailto:faisalv@gmail.com" target=3D"_blank">faisalv@gmail=
..com</a>> wrote:</div>
<br><blockquote type=3D"cite"><div style=3D"font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px">
No - I did not interpret N4035 to specify it as such. =C2=A0The extension j=
ust says:<br>=C2=A0- if the type of the initializer being implicitly deduce=
d in an<br>'auto' containing variable initialization<br>=C2=A0=C2=
=A0=C2=A0contains a 'using auto =3D <type-id>' then the '=
type-id' is<br>
substituted into the 'auto' within the decl-specifier<br>=C2=A0=C2=
=A0=C2=A0of the variable being declared - and then the initialization is do=
ne.<br><br>For e.g in:<br>auto *a =3D X{};<br></div></blockquote><div><br><=
/div></div><div>
I don=E2=80=99t see where N4035 mentions anything about compound types form=
ed with auto. Did I miss something?</div><div class=3D""><br><blockquote ty=
pe=3D"cite"><div style=3D"font-size:12px;font-style:normal;font-variant:nor=
mal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:=
start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0=
px">
The patch checks the type 'X' to see if it is a struct/class/union<=
br>type that contains a<br>'using auto =3D <type-id>' - and i=
f so, substitutes the type-id (suppose<br>it is using auto =3D double)<br>i=
nto the declaration:<br>
double *a =3D X{};<br><br>Then it performs the initialization - and if it i=
s ill-formed (it<br>won't be if X has a conversion to double*)<br>- the=
n so be it.<br></div></blockquote><div><br></div></div><div>Hmm, is there a=
use case for the behavior when it's well-formed? This seems like a dep=
arture from N4035 and it=E2=80=99s a little weird.</div>
<br><blockquote type=3D"cite"><div style=3D"font-size:12px;font-style:norma=
l;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:=
normal;text-align:start;text-indent:0px;text-transform:none;white-space:nor=
mal;word-spacing:0px">
<div class=3D"">Perhaps auto alias is not the best way to describe it - esp=
ecially<br>considering Roger Orr pointed out<br>the discrepancy between mem=
ber type aliases and 'auto aliases'.<br><br>struct N {<br>=C2=A0usi=
ng auto =3D double*;<br>
=C2=A0using dptr =3D double*;<br>=C2=A0void foo() {<br></div>=C2=A0=C2=A0=
=C2=A0auto f =3D 0; // =C2=A0'auto' does not mean 'double*=E2=
=80=99</div></blockquote><div><br></div><div>My suggestion is that <font fa=
ce=3D"Courier">auto</font> be added to the=C2=A0<i>unqualified-id</i>=C2=A0=
production in the contexts it makes sense, e.g. in a <i>qualified-id</i> or=
member=C2=A0<i>declarator-id</i>. Then you could say <font face=3D"Courier=
">N::auto f =3D 0;</font>. This replaces N4035=E2=80=99s <font face=3D"Cour=
ier">auto_result_type<T></font> builtin alias, which I don=E2=80=99t =
see in your example test cases.</div>
<div><br></div><div>Why the =E2=80=9Cauto alias=E2=80=9D discrepancy? Speci=
al treatment of auto isn=E2=80=99t needed for the sake of parsing, since us=
ual typenames are already just regular identifiers which may hide preexisti=
ng declarations. The special thing about <i>simple-type-specifier</i> keywo=
rds like <font face=3D"Courier">auto</font> is that they combine to form co=
nstructs like <font face=3D"Courier">unsigned long int</font>, but that doe=
sn=E2=80=99t apply to <font face=3D"Courier">auto</font>=C2=A0(unless you c=
ount=C2=A0<font face=3D"Courier">decltype(auto)</font>, which is does not i=
ntroduce the same potential ambiguity).=C2=A0</div>
<div><br></div><div>TL;DR:=C2=A0<font face=3D"Courier">auto</font>=C2=A0alr=
eady behaves syntactically enough like an identifier that if we add one cas=
e of overlap (for <i>alias-declarations</i>) we might as well add them all,=
subject to semantic constraints.</div>
</div></div></blockquote><div><br></div><div>FWIW, I disagree. 'using a=
uto =3D <type-id>;' is just a semi-arbitrary syntactic way to get=
the particular semantic effect of overriding 'auto' deduction. It =
seems like a *major* stretch to say that that 'auto' now behaves li=
ke an identifier. This does make me wonder if a different syntax would be l=
ess confusing. Maybe drop the 'using'; just 'auto =3D <type-=
id>;'?<br>
</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word"><d=
iv><blockquote type=3D"cite"><div style=3D"font-size:12px;font-style:normal=
;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:n=
ormal;text-align:start;text-indent:0px;text-transform:none;white-space:norm=
al;word-spacing:0px">
Hope that clarifies things.<br></div></blockquote></div><br><div>Yep, thank=
s! Hope I=E2=80=99ve added something to the discussion.</div><div><br></div=
></div><div class=3D"HOEnZb"><div class=3D"h5">
<p></p>
-- <br>
<br>
--- <br>
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br>
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org" target=3D"_=
blank">std-proposals+unsubscribe@isocpp.org</a>.<br>
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org" target=3D"_blank">std-proposals@isocpp.org</a>.<br>
Visit this group at <a href=3D"http://groups.google.com/a/isocpp.org/group/=
std-proposals/" target=3D"_blank">http://groups.google.com/a/isocpp.org/gro=
up/std-proposals/</a>.<br>
</div></div></blockquote></div><br></div></div>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--089e011618ceec5f2604fd92c4ea--
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 7 Jul 2014 12:45:18 +0800
Raw View
--Apple-Mail=_5816ABF2-255F-430B-ADA7-90D7EAB58719
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-07, at 12:18 PM, Richard Smith <richard@metafoo.co.uk> wrote:
> FWIW, I disagree. 'using auto =3D <type-id>;' is just a semi-arbitrary sy=
ntactic way to get the particular semantic effect of overriding 'auto' dedu=
ction. It seems like a *major* stretch to say that that 'auto' now behaves =
like an identifier. This does make me wonder if a different syntax would be=
less confusing. Maybe drop the 'using'; just 'auto =3D <type-id>;'?
What about the auto_result_type alias? My thinking is, if X can be defined =
as something, and that definition may be retrieved later, then X might as w=
ell be an identifier. Although interface designers will probably provide so=
me other type-name for whatever "local auto" resolves to, it's better to ha=
ve a uniform query for the sake of generic programming. (Something that doe=
sn't actually involve creating an object.)
I still plan on proposing category-restricted classes, whose instances eith=
er must be named (like scope guards) or temporary (like ET intermediate res=
ults). The only syntax I've supposed so far is ref-qualifiers somewhere in =
the class-head:
class quote_manipulator && { // An instance may not be bound to a name for =
its lifetime.
std::string const & content;
quote_manipulator( std::string const & in_content )
: content( in_content ) {}
};
std::ostream & operator << ( std::ostream & s, quote_manipulator const & o =
)
{ s << '"' << o.content << '"'; }
The associated semantics would make certain declarations ill-formed, but sh=
ould also correspond exactly to what we don't want auto to do. Perhaps auto=
conversion syntax, which provides a way to make such usage well-formed aga=
in, should build on the syntax that specifies the restriction:
class quote_manipulator (&&, else class persistent_quote_manipulator) {
std::string const & content;
public:
quote_manipulator( std::string const & in_content )
: content( in_content ) {}
};
class persistent_quote_manipulator : public quote_manipulator {
std::string const content;
public:
quote_manipulator( std::string in_content )
: quote_manipulator( content )
, content( std::move( in_content ) ) {}
};
The syntax (&&, else X) is supposed to convey "the class must form an rvalu=
e, else the declaration/expression may assume type X." There is probably so=
me more expressive and terser alternative.
The benefit here is generality: authors may specify what's not supposed to =
happen (for a quite broad range of cases) and only later provide the workar=
ound, when feasible.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_5816ABF2-255F-430B-ADA7-90D7EAB58719
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–07, at 12:18 PM, Richard Smith <<a href=3D"mailto:richard=
@metafoo.co.uk">richard@metafoo.co.uk</a>> wrote:</div><br class=3D"Appl=
e-interchange-newline"><blockquote type=3D"cite"><div dir=3D"ltr"><div clas=
s=3D"gmail_extra"><div class=3D"gmail_quote"><div>FWIW, I disagree. 'using =
auto =3D <type-id>;' is just a semi-arbitrary syntactic way to get th=
e particular semantic effect of overriding 'auto' deduction. It seems like =
a *major* stretch to say that that 'auto' now behaves like an identifier. T=
his does make me wonder if a different syntax would be less confusing. Mayb=
e drop the 'using'; just 'auto =3D <type-id>;’?<br>
</div></div></div></div></blockquote><br></div><div>What about the <font fa=
ce=3D"Courier">auto_result_type</font> alias? My thinking is, if X can be d=
efined as something, and that definition may be retrieved later, then X mig=
ht as well be an identifier. Although interface designers will probably pro=
vide some other type-name for whatever “local auto” resolves to=
, it’s better to have a uniform query for the sake of generic program=
ming. (Something that doesn’t actually involve creating an object.)</=
div><div><br></div><div>I still plan on proposing category-restricted class=
es, whose instances either must be named (like scope guards) or temporary (=
like ET intermediate results). The only syntax I’ve supposed so far i=
s ref-qualifiers somewhere in the class-head:</div><div><br></div><div><fon=
t face=3D"Courier">class quote_manipulator && { // An instance may =
not be bound to a name for its lifetime.</font></div><div><font face=3D"Cou=
rier"> std::string const & content;</font></div><div><font=
face=3D"Courier"> quote_manipulator( std::string const & =
in_content )</font></div><div><font face=3D"Courier"> &=
nbsp; : content( in_content ) {}</font></div><div><font face=3D"Couri=
er">};</font></div><div><font face=3D"Courier">std::ostream & operator =
<< ( std::ostream & s, quote_manipulator const & o )</font></=
div><div><font face=3D"Courier"> { s << '"' << o.c=
ontent << </font><span style=3D"font-family: Courier;">'"'</span=
><span style=3D"font-family: Courier;">; }</span></div><div><br></div><div>=
The associated semantics would make certain declarations ill-formed, but sh=
ould also correspond exactly to what we don’t want <font face=3D"Cour=
ier">auto</font> to do. Perhaps auto conversion syntax, which provides a wa=
y to make such usage well-formed again, should build on the syntax that spe=
cifies the restriction:</div><div><br></div><div><div><font face=3D"Courier=
">class quote_manipulator (&&, else class persistent_quote_manipula=
tor) {</font></div><div><span style=3D"font-family: Courier;"> =
std::string const & content;</span></div><div><font face=3D"Courier">p=
ublic:</font></div><div><font face=3D"Courier"> quote_manipula=
tor( std::string const & in_content )</font></div><div><font face=3D"Co=
urier"> : content( in_content ) {}</font><=
/div><div><font face=3D"Courier">};</font></div><div><font face=3D"Courier"=
><br></font></div><div><div><font face=3D"Courier">class </font><span =
style=3D"font-family: Courier;">persistent_quote_manipulator : public quote=
_manipulator</span><font face=3D"Courier"> {</font></div><div><font fa=
ce=3D"Courier"> std::string const content;</font></div><div><f=
ont face=3D"Courier">public:</font></div><div><font face=3D"Courier"> =
quote_manipulator( std::string in_content )</font></div><div><font =
face=3D"Courier"> : quote_manipulator( con=
tent )</font></div><div><font face=3D"Courier"> =
, content( std::move( in_content ) ) {}</font></div><div><font face=
=3D"Courier">};</font></div></div><div><br></div><div>The syntax <span=
style=3D"font-family: Courier;">(&&, else X)</span> is suppos=
ed to convey “the class must form an rvalue, else the declaration/exp=
ression may assume type <font face=3D"Courier">X</font>.” There is pr=
obably some more expressive and terser alternative.</div><div><br></div><di=
v>The benefit here is generality: authors may specify what’s not supp=
osed to happen (for a quite broad range of cases) and only later provide th=
e workaround, when feasible.</div><div><br></div></div></body></html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_5816ABF2-255F-430B-ADA7-90D7EAB58719--
.
Author: Gabriel Dos Reis <gdr@axiomatics.org>
Date: Mon, 07 Jul 2014 01:22:55 -0700
Raw View
Richard Smith <richard@metafoo.co.uk> writes:
[...]
| TL;DR:=C2=A0auto=C2=A0already behaves syntactically enough like an
| identifier that if we add one case of overlap (for
| alias-declarations) we might as well add them all, subject to
| semantic constraints.
|=20
|=20
| FWIW, I disagree. 'using auto =3D <type-id>;' is just a semi-arbitrary
| syntactic way to get the particular semantic effect of overriding
| 'auto' deduction.
Seconded. I have a major concern with the notation=20
using auto =3D <type-id> ;
I am hoping proponent will pick a different, less confusing, notation.
-- Gaby
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Mon, 7 Jul 2014 07:01:19 -0500
Raw View
On Sun, Jul 6, 2014 at 11:15 PM, Richard Smith <richard@metafoo.co.uk> wrot=
e:
> On Sun, Jul 6, 2014 at 7:17 PM, Faisal Vali <faisalv@gmail.com> wrote:
>>
>> On Sun, Jul 6, 2014 at 8:22 PM, David Krauss <potswa@gmail.com> wrote:
>> >
>> > On 2014=E2=80=9307=E2=80=9307, at 2:36 AM, Faisal Vali <faisalv@gmail.=
com> wrote:
>> >
>> > To highlight features of this patch as they might differ from N4035:
>> > - auto-aliases only kick in for variable declarations and 'auto'
>> > function returns (not during template argument deduction of any other
>> > sort, such as generic lambdas etc).
>> > - currently allowed in unions
>> > - not allowed for decltype(auto)
>> > - do not trigger explicit conversions
>> >
>> > EWG's current stance: http://isocpp.org/files/papers/N4101.html#76
>> >
>> >
>> > Nice work!
>> >
>> > Your extension provides a member typename called auto, right?
>>
>> No - I did not interpret N4035 to specify it as such. The extension jus=
t
>> says:
>> - if the type of the initializer being implicitly deduced in an
>> 'auto' containing variable initialization
>> contains a 'using auto =3D <type-id>' then the 'type-id' is
>> substituted into the 'auto' within the decl-specifier
>> of the variable being declared - and then the initialization is done=
..
>>
>> For e.g in:
>> auto *a =3D X{};
>>
>> The patch checks the type 'X' to see if it is a struct/class/union
>> type that contains a
>> 'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
>> it is using auto =3D double)
>> into the declaration:
>> double *a =3D X{};
>
>
> This seems quite strange to me, and not at all how I'd expected this to
> behave. Instead, what I'd expect is:
>
> When performing 'auto' deduction on an expression E of class type cv C, i=
f C
> has a 'using auto =3D <type-id>', then deduce the type from <type-id> ins=
tead
> of from E.
>
So given :
struct X {
using auto =3D double&;
static double gd;
X(double d) { gd =3D d; }
operator double&() const { return gd; }
};
double X::gd;
auto d =3D X{};
You would have expected the following transformation:
auto d =3D (double&)(X{3.14}); // 'd' is of type double
Not:
double &d =3D X{3.14};
That certainly seems like a reasonable interpretation - I initially
thought that the 'replace auto in your variable or function
declaration with the <type-id>' might be an easier thing to teach -
when doing an implicit type deduction (not decltype(auto)) for
variable init or function return - instead of : 'first convert to
<type-id> and then deduce against the auto-laced decl-specifier-seq'.
But I suppose - now that I look at it from your viewpoint - either
one's mechanics seem equally easy (or hard ;) to explain.
>> Then it performs the initialization - and if it is ill-formed (it
>> won't be if X has a conversion to double*)
>> - then so be it.
>
>
> In this case, I'd expect to get a deduction failure (can't deduce 'T *' f=
rom
> 'double').
>
>>
>> Perhaps auto alias is not the best way to describe it - especially
>> considering Roger Orr pointed out
>> the discrepancy between member type aliases and 'auto aliases'.
>>
>> struct N {
>> using auto =3D double*;
>> using dptr =3D double*;
>> void foo() {
>> auto f =3D 0; // 'auto' does not mean 'double*'
>> dptr df =3D 0; // dptr does mean 'double*'
>> }
>> operator double**() const { return 0; }
>> }
>>
>> auto *n =3D N{}; // OK - substitute double* for auto gives us double**,
>> which N can convert from.
>>
>> Hope that clarifies things.
>>
>> Thanks!
>>
>> >
>> > The conversion-function-id operator auto is already syntactically vali=
d,
>> > its
>> > only problem being that auto should be looked up at class scope. It
>> > seems
>> > that you have defined the result of that lookup.
>> >
>> > Defining members auto and operator auto() would essentially get back t=
o
>> > the
>> > point of the original proposal, no? I don=E2=80=99t think the change s=
acrifices
>> > the
>> > "running code=E2=80=9D semantic, so much as it reconciles it with the =
existing
>> > core
>> > language. Specifying a return type on a conversion function would have
>> > been
>> > irregular.
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to the Google
>> > Groups
>> > "ISO C++ Standard - Future Proposals" group.
>> > To unsubscribe from this group and stop receiving emails from it, send
>> > an
>> > email to std-proposals+unsubscribe@isocpp.org.
>> > To post to this group, send email to std-proposals@isocpp.org.
>> > Visit this group at
>> > http://groups.google.com/a/isocpp.org/group/std-proposals/.
>>
>> --
>>
>> ---
>> You received this message because you are subscribed to the Google Group=
s
>> "ISO C++ Standard - Future Proposals" group.
>> To unsubscribe from this group and stop receiving emails from it, send a=
n
>> email to std-proposals+unsubscribe@isocpp.org.
>> To post to this group, send email to std-proposals@isocpp.org.
>> Visit this group at
>> http://groups.google.com/a/isocpp.org/group/std-proposals/.
>
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Mon, 7 Jul 2014 07:09:45 -0500
Raw View
On Sun, Jul 6, 2014 at 10:24 PM, David Krauss <potswa@gmail.com> wrote:
>
> On 2014=E2=80=9307=E2=80=9307, at 10:17 AM, Faisal Vali <faisalv@gmail.co=
m> wrote:
>
> No - I did not interpret N4035 to specify it as such. The extension just
> says:
> - if the type of the initializer being implicitly deduced in an
> 'auto' containing variable initialization
> contains a 'using auto =3D <type-id>' then the 'type-id' is
> substituted into the 'auto' within the decl-specifier
> of the variable being declared - and then the initialization is done.
>
> For e.g in:
> auto *a =3D X{};
>
>
> I don=E2=80=99t see where N4035 mentions anything about compound types fo=
rmed with
> auto. Did I miss something?
>
See the implementation of noeval in the paper.
> The patch checks the type 'X' to see if it is a struct/class/union
> type that contains a
> 'using auto =3D <type-id>' - and if so, substitutes the type-id (suppose
> it is using auto =3D double)
> into the declaration:
> double *a =3D X{};
>
> Then it performs the initialization - and if it is ill-formed (it
> won't be if X has a conversion to double*)
> - then so be it.
>
>
> Hmm, is there a use case for the behavior when it's well-formed? This see=
ms
> like a departure from N4035 and it=E2=80=99s a little weird.
>
> Perhaps auto alias is not the best way to describe it - especially
> considering Roger Orr pointed out
> the discrepancy between member type aliases and 'auto aliases'.
>
> struct N {
> using auto =3D double*;
> using dptr =3D double*;
> void foo() {
> auto f =3D 0; // 'auto' does not mean 'double*=E2=80=99
>
>
> My suggestion is that auto be added to the unqualified-id production in t=
he
> contexts it makes sense, e.g. in a qualified-id or member declarator-id.
> Then you could say N::auto f =3D 0;. This replaces N4035=E2=80=99s auto_r=
esult_type<T>
> builtin alias, which I don=E2=80=99t see in your example test cases.
>
You're right - although you can approximate it with the following code:
template<class T> class art {
static T val();
static auto foo(T t) { return t; } //#0
public:
using type =3D decltype(foo(val()));
};
struct X {
using auto =3D double&;
operator double&(); //#1
};
static_assert(is_same<art<X>::type, double&>::value, "");
The problem with it is that if #1 is commented out, you get a hard
error saying conversion to double& is ill-formed at #0 - so
non-invasive reflection would require compiler support.
> Why the =E2=80=9Cauto alias=E2=80=9D discrepancy? Special treatment of au=
to isn=E2=80=99t needed for
> the sake of parsing, since usual typenames are already just regular
> identifiers which may hide preexisting declarations. The special thing ab=
out
> simple-type-specifier keywords like auto is that they combine to form
> constructs like unsigned long int, but that doesn=E2=80=99t apply to auto=
(unless
> you count decltype(auto), which is does not introduce the same potential
> ambiguity).
>
> TL;DR: auto already behaves syntactically enough like an identifier that =
if
> we add one case of overlap (for alias-declarations) we might as well add
> them all, subject to semantic constraints.
>
> Hope that clarifies things.
>
>
> Yep, thanks! Hope I=E2=80=99ve added something to the discussion.
>
I think you certainly have - thanks!
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ISO C++ Standard - Future Proposals" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to std-proposals+unsubscribe@isocpp.org.
> To post to this group, send email to std-proposals@isocpp.org.
> Visit this group at
> http://groups.google.com/a/isocpp.org/group/std-proposals/.
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
.
Author: Faisal Vali <faisalv@gmail.com>
Date: Mon, 7 Jul 2014 07:16:12 -0500
Raw View
On Mon, Jul 7, 2014 at 3:22 AM, Gabriel Dos Reis <gdr@axiomatics.org> wrote:
> Richard Smith <richard@metafoo.co.uk> writes:
>
> [...]
>
> | TL;DR: auto already behaves syntactically enough like an
> | identifier that if we add one case of overlap (for
> | alias-declarations) we might as well add them all, subject to
> | semantic constraints.
> |
> |
> | FWIW, I disagree. 'using auto = <type-id>;' is just a semi-arbitrary
> | syntactic way to get the particular semantic effect of overriding
> | 'auto' deduction.
>
> Seconded. I have a major concern with the notation
>
> using auto = <type-id> ;
>
> I am hoping proponent will pick a different, less confusing, notation.
>
> -- Gaby
I would tend to agree. Not to speak for the paper-authors - but I
expect suggestions would be appreciated!
--
---
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/.
.
Author: David Krauss <potswa@gmail.com>
Date: Mon, 7 Jul 2014 23:32:34 +0800
Raw View
--Apple-Mail=_905B3774-44BA-4AD2-B1BF-C5E3C571238D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=ISO-8859-1
On 2014-07-07, at 8:09 PM, Faisal Vali <faisalv@gmail.com> wrote:
> On Sun, Jul 6, 2014 at 10:24 PM, David Krauss <potswa@gmail.com> wrote:
>>=20
>> On 2014-07-07, at 10:17 AM, Faisal Vali <faisalv@gmail.com> wrote:
>>=20
>>> For e.g in:
>>> auto *a =3D X{};
>>=20
>> I don't see where N4035 mentions anything about compound types formed wi=
th
>> auto. Did I miss something?
>>=20
>=20
> See the implementation of noeval in the paper.
I mean the construct auto *, which is like a compound type using auto. In t=
hat example, the asterisk is only used for multiplication.
Also, the return statement is missing a template argument list, and the who=
le thing appears to return a dangling reference. It's very unclear how it's=
supposed to work. However, I do think the overall idea is feasible and the=
re's no need to adjust the core language further (and waste the explicit ke=
yword for object declarations) for this corner case.
Back on topic... as for teachability, I think it should suffice for express=
ion template authors/vendors to tell their users that auto now invokes the =
eval() method before deduction. Those users are already suffering enough an=
d the modified behavior should be easily understood in terms of the domain-=
specific language, not C++ deduction. (And, no other behavior should be mod=
ified.)
--=20
---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.
--Apple-Mail=_905B3774-44BA-4AD2-B1BF-C5E3C571238D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset=ISO-8859-1
<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html charset=
=3Dwindows-1252"></head><body style=3D"word-wrap: break-word; -webkit-nbsp-=
mode: space; -webkit-line-break: after-white-space;"><br><div><div>On 2014&=
ndash;07–07, at 8:09 PM, Faisal Vali <<a href=3D"mailto:faisalv@gm=
ail.com">faisalv@gmail.com</a>> wrote:</div><br class=3D"Apple-interchan=
ge-newline"><blockquote type=3D"cite"><div style=3D"font-size: 12px; font-s=
tyle: normal; font-variant: normal; font-weight: normal; letter-spacing: no=
rmal; line-height: normal; orphans: auto; text-align: start; text-indent: 0=
px; text-transform: none; white-space: normal; widows: auto; word-spacing: =
0px; -webkit-text-stroke-width: 0px;">On Sun, Jul 6, 2014 at 10:24 PM, Davi=
d Krauss <<a href=3D"mailto:potswa@gmail.com">potswa@gmail.com</a>> w=
rote:<br><blockquote type=3D"cite"><br>On 2014–07–07, at 10:17 =
AM, Faisal Vali <<a href=3D"mailto:faisalv@gmail.com">faisalv@gmail.com<=
/a>> wrote:<br><br><blockquote type=3D"cite">For e.g in:<br>auto *a =3D =
X{};<br></blockquote><br>I don’t see where N4035 mentions anything ab=
out compound types formed with<br>auto. Did I miss something?<br><br></bloc=
kquote><br>See the implementation of noeval in the paper.<br></div></blockq=
uote><div><br></div><div>I mean the construct <font face=3D"Courier">auto *=
</font>, which is like a compound type using auto. In that example, the ast=
erisk is only used for multiplication.</div></div><br><div>Also, the return=
statement is missing a template argument list, and the whole thing appears=
to return a dangling reference. It’s very unclear how it’s sup=
posed to work. However, I do think the overall idea is feasible and there&r=
squo;s no need to adjust the core language further (and waste the <fon=
t face=3D"Courier">explicit</font> keyword for object declarations) fo=
r this corner case.</div><div><br></div><div>Back on topic… as for t=
eachability, I think it should suffice for expression template authors/vend=
ors to tell their users that <font face=3D"Courier">auto</font> now in=
vokes the <font face=3D"Courier">eval()</font> method before deduction. Tho=
se users are already suffering enough and the modified behavior should be e=
asily understood in terms of the domain-specific language, not C++ deductio=
n. (And, no other behavior should be modified.)</div><div><br></div></body>=
</html>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <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"http://groups.google.com/a/isocpp.org/group/=
std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/<=
/a>.<br />
--Apple-Mail=_905B3774-44BA-4AD2-B1BF-C5E3C571238D--
.