Topic: Overloaded Declarators
Author: andrewtomazos@gmail.com
Date: Thu, 4 Jul 2013 23:32:01 -0700 (PDT)
Raw View
------=_Part_4435_27230862.1373005921884
Content-Type: text/plain; charset=ISO-8859-1
If we view for a moment the various parts of a declarator as operations on
types:
T*: T -> pointer-to-T
T&: T -> lvalue-reference-to-T
T&&: T -> rvalue-reference-to-T
T[]: T -> array-of-T
T(): T -> function-returning-T
and so forth
These operations take one or more types as input and produce a type as
output.
This is not dissimilar to an alias template:
template<class T>
using MakePointer = T*;
template<class T>
using MakeReference = T&;
In fact we could almost say that functions are to the built-in expression
operators, as alias templates are to the built-in declarators.
So the proposed feature "Overloaded Declarators" is to enable a
user-defined alias template to redefine the built-in meaning of a
declarator.
Overloaded Declarators are to the built-in declarators, as Overloaded
Operators are to the built-in expression operators:
struct Foo{}
template<class T>
using operator*<Foo> = shared_ptr<T>;
Foo* p; // p has type shared_ptr<T>
The above shows a key use case, specializing the declarator `T*` to
designate a user-defined smart pointer class instead of pointer-to-T for
some set of types.
Just a random idea.
Enjoy,
Andrew.
--
---
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/.
------=_Part_4435_27230862.1373005921884
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
If we view for a moment the various parts of a declarator as operations on =
types:<br><br> T*: T -> pointer-to-T<br> &n=
bsp; T&: T -> lvalue-reference-to-T<br> T&&=
;: T -> rvalue-reference-to-T<br> T[]: T -> array-o=
f-T<br> T(): T -> function-returning-T<br> =
and so forth<br><br>These operations take one or more types as input=
and produce a type as output.<br><br>This is not dissimilar to an alias te=
mplate:<br><br> template<class T><br> using M=
akePointer =3D T*;<br><br> template<class T><br> &nb=
sp; using MakeReference =3D T&;<br><br>In fact we could almost say that=
functions are to the built-in expression operators, as alias templates are=
to the built-in declarators.<br><br>So the proposed feature "Overloaded De=
clarators" is to enable a user-defined alias template to redefine the built=
-in meaning of a declarator.<br><br>Overloaded Declarators are to the built=
-in declarators, as Overloaded Operators are to the built-in expression ope=
rators:<br><br> struct Foo{}<br><br> template<cl=
ass T><br> using operator*<Foo> =3D shared_ptr<T>=
;;<br><br> Foo* p; // p has type shared_ptr<T><br><=
br>The above shows a key use case, specializing the declarator `T*` to desi=
gnate a user-defined smart pointer class instead of pointer-to-T for some s=
et of types.<br><br>Just a random idea.<br><br>Enjoy,<br>Andrew.<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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_4435_27230862.1373005921884--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Fri, 5 Jul 2013 15:57:23 +0200
Raw View
What if I want an actual pointer now?
Mit freundlichen Gr=FC=DFen,
Martinho
On Fri, Jul 5, 2013 at 8:32 AM, <andrewtomazos@gmail.com> wrote:
> If we view for a moment the various parts of a declarator as operations o=
n
> types:
>
> T*: T -> pointer-to-T
> T&: T -> lvalue-reference-to-T
> T&&: T -> rvalue-reference-to-T
> T[]: T -> array-of-T
> T(): T -> function-returning-T
> and so forth
>
> These operations take one or more types as input and produce a type as
> output.
>
> This is not dissimilar to an alias template:
>
> template<class T>
> using MakePointer =3D T*;
>
> template<class T>
> using MakeReference =3D T&;
>
> In fact we could almost say that functions are to the built-in expression
> operators, as alias templates are to the built-in declarators.
>
> So the proposed feature "Overloaded Declarators" is to enable a user-defi=
ned
> alias template to redefine the built-in meaning of a declarator.
>
> Overloaded Declarators are to the built-in declarators, as Overloaded
> Operators are to the built-in expression operators:
>
> struct Foo{}
>
> template<class T>
> using operator*<Foo> =3D shared_ptr<T>;
>
> Foo* p; // p has type shared_ptr<T>
>
> The above shows a key use case, specializing the declarator `T*` to
> designate a user-defined smart pointer class instead of pointer-to-T for
> some set of types.
>
> Just a random idea.
>
> Enjoy,
> Andrew.
>
> --
>
> ---
> 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: andrewtomazos@gmail.com
Date: Fri, 5 Jul 2013 16:05:18 -0700 (PDT)
Raw View
------=_Part_5125_32488359.1373065518132
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> What if I want an actual pointer now?
Suppose you overload unary operator& on a class:
struct X
{
Y operator&();
}
What if I want the actual address of an object of type X now? You use=20
std::addressof.
In a similar fashion alias templates could be provided in the standard=20
library, for example std::pointerto<T>, such that even if the * declarator=
=20
was overloaded for that class, pointerto<T> would always give you the type=
=20
"pointer to T":
-Andrew.
On Friday, July 5, 2013 3:57:23 PM UTC+2, R. Martinho Fernandes wrote:
>
> What if I want an actual pointer now?=20
> Mit freundlichen Gr=FC=DFen,=20
>
> Martinho=20
>
>
> On Fri, Jul 5, 2013 at 8:32 AM, <andrew...@gmail.com <javascript:>>=20
> wrote:=20
> > If we view for a moment the various parts of a declarator as operations=
=20
> on=20
> > types:=20
> >=20
> > T*: T -> pointer-to-T=20
> > T&: T -> lvalue-reference-to-T=20
> > T&&: T -> rvalue-reference-to-T=20
> > T[]: T -> array-of-T=20
> > T(): T -> function-returning-T=20
> > and so forth=20
> >=20
> > These operations take one or more types as input and produce a type as=
=20
> > output.=20
> >=20
> > This is not dissimilar to an alias template:=20
> >=20
> > template<class T>=20
> > using MakePointer =3D T*;=20
> >=20
> > template<class T>=20
> > using MakeReference =3D T&;=20
> >=20
> > In fact we could almost say that functions are to the built-in=20
> expression=20
> > operators, as alias templates are to the built-in declarators.=20
> >=20
> > So the proposed feature "Overloaded Declarators" is to enable a=20
> user-defined=20
> > alias template to redefine the built-in meaning of a declarator.=20
> >=20
> > Overloaded Declarators are to the built-in declarators, as Overloaded=
=20
> > Operators are to the built-in expression operators:=20
> >=20
> > struct Foo{}=20
> >=20
> > template<class T>=20
> > using operator*<Foo> =3D shared_ptr<T>;=20
> >=20
> > Foo* p; // p has type shared_ptr<T>=20
> >=20
> > The above shows a key use case, specializing the declarator `T*` to=20
> > designate a user-defined smart pointer class instead of pointer-to-T fo=
r=20
> > some set of types.=20
> >=20
> > Just a random idea.=20
> >=20
> > Enjoy,=20
> > Andrew.=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >=20
> >=20
>
--=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/.
------=_Part_5125_32488359.1373065518132
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
> What if I want an actual pointer now?<br><br>Suppose you overload unar=
y operator& on a class:<br><br> struct X<br> &nb=
sp; {<br> Y operator&()=
;<br> }<br><br>What if I want the actual address of an ob=
ject of type X now? You use std::addressof.<br><br>In a similar fashi=
on alias templates could be provided in the standard library, for example s=
td::pointerto<T>, such that even if the * declarator was overloaded f=
or that class, pointerto<T> would always give you the type "pointer t=
o T":<br> -Andrew.<br><br>On Friday, July 5, 2013 3:57:23=
PM UTC+2, R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" st=
yle=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-lef=
t: 1ex;">What if I want an actual pointer now?
<br>Mit freundlichen Gr=FC=DFen,
<br>
<br>Martinho
<br>
<br>
<br>On Fri, Jul 5, 2013 at 8:32 AM, <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"iPeMfqXkGPUJ">andrew...@gmail.com</a>=
> wrote:
<br>> If we view for a moment the various parts of a declarator as opera=
tions on
<br>> types:
<br>>
<br>> T*: T -> pointer-to-T
<br>> T&: T -> lvalue-reference-to-T
<br>> T&&: T -> rvalue-reference-to-T
<br>> T[]: T -> array-of-T
<br>> T(): T -> function-returning-T
<br>> and so forth
<br>>
<br>> These operations take one or more types as input and produce a typ=
e as
<br>> output.
<br>>
<br>> This is not dissimilar to an alias template:
<br>>
<br>> template<class T>
<br>> using MakePointer =3D T*;
<br>>
<br>> template<class T>
<br>> using MakeReference =3D T&;
<br>>
<br>> In fact we could almost say that functions are to the built-in exp=
ression
<br>> operators, as alias templates are to the built-in declarators.
<br>>
<br>> So the proposed feature "Overloaded Declarators" is to enable a us=
er-defined
<br>> alias template to redefine the built-in meaning of a declarator.
<br>>
<br>> Overloaded Declarators are to the built-in declarators, as Overloa=
ded
<br>> Operators are to the built-in expression operators:
<br>>
<br>> struct Foo{}
<br>>
<br>> template<class T>
<br>> using operator*<Foo> =3D shared_ptr<T>;
<br>>
<br>> Foo* p; // p has type shared_ptr<T>
<br>>
<br>> The above shows a key use case, specializing the declarator `T*` t=
o
<br>> designate a user-defined smart pointer class instead of pointer-to=
-T for
<br>> some set of types.
<br>>
<br>> Just a random idea.
<br>>
<br>> Enjoy,
<br>> Andrew.
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<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"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"iPeMfqXkGPUJ">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"iPeMfqXkGPUJ">std-pr...@isocpp.org</a=
>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std=
-<wbr>proposals/</a>.
<br>>
<br>>
<br></blockquote>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_5125_32488359.1373065518132--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Sat, 6 Jul 2013 03:03:37 +0200
Raw View
There is a big problem in that the existing code that wants pointers
uses T*, not std::pointerto<T>. And that's a rather *large* body of
code.
Mit freundlichen Gr=FC=DFen,
Martinho
On Sat, Jul 6, 2013 at 1:05 AM, <andrewtomazos@gmail.com> wrote:
>> What if I want an actual pointer now?
>
> Suppose you overload unary operator& on a class:
>
> struct X
> {
> Y operator&();
> }
>
> What if I want the actual address of an object of type X now? You use
> std::addressof.
>
> In a similar fashion alias templates could be provided in the standard
> library, for example std::pointerto<T>, such that even if the * declarato=
r
> was overloaded for that class, pointerto<T> would always give you the typ=
e
> "pointer to T":
> -Andrew.
>
>
> On Friday, July 5, 2013 3:57:23 PM UTC+2, R. Martinho Fernandes wrote:
>>
>> What if I want an actual pointer now?
>> Mit freundlichen Gr=FC=DFen,
>>
>> Martinho
>>
>>
>> On Fri, Jul 5, 2013 at 8:32 AM, <andrew...@gmail.com> wrote:
>> > If we view for a moment the various parts of a declarator as operation=
s
>> > on
>> > types:
>> >
>> > T*: T -> pointer-to-T
>> > T&: T -> lvalue-reference-to-T
>> > T&&: T -> rvalue-reference-to-T
>> > T[]: T -> array-of-T
>> > T(): T -> function-returning-T
>> > and so forth
>> >
>> > These operations take one or more types as input and produce a type as
>> > output.
>> >
>> > This is not dissimilar to an alias template:
>> >
>> > template<class T>
>> > using MakePointer =3D T*;
>> >
>> > template<class T>
>> > using MakeReference =3D T&;
>> >
>> > In fact we could almost say that functions are to the built-in
>> > expression
>> > operators, as alias templates are to the built-in declarators.
>> >
>> > So the proposed feature "Overloaded Declarators" is to enable a
>> > user-defined
>> > alias template to redefine the built-in meaning of a declarator.
>> >
>> > Overloaded Declarators are to the built-in declarators, as Overloaded
>> > Operators are to the built-in expression operators:
>> >
>> > struct Foo{}
>> >
>> > template<class T>
>> > using operator*<Foo> =3D shared_ptr<T>;
>> >
>> > Foo* p; // p has type shared_ptr<T>
>> >
>> > The above shows a key use case, specializing the declarator `T*` to
>> > designate a user-defined smart pointer class instead of pointer-to-T f=
or
>> > some set of types.
>> >
>> > Just a random idea.
>> >
>> > Enjoy,
>> > Andrew.
>> >
>> > --
>> >
>> > ---
>> > 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-proposal...@isocpp.org.
>> > To post to this group, send email to std-pr...@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: andrewtomazos@gmail.com
Date: Sat, 6 Jul 2013 00:23:02 -0700 (PDT)
Raw View
------=_Part_5183_30927408.1373095382936
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Have you understood that the declarator meaning is only overloaded for the=
=20
user-defined set of types nominated by the declarator overload declaration=
=20
(for example just for one class, or one hierarchy of classes)? The=20
suggestion is not to overload the meaning of the declarator in general.
As such the declarator, so overloaded, would not effect existing code -=20
except where it applies to those user-defined class.
This is the same argument as existing overloaded operators. You wouldn't=
=20
argue that being able to define:
Bar operator+(Foo a, Foo b);
affects existing code that expects the built-in meaning of 3 + 4. Such a=
=20
case still dispatches to built-in addition. Likewise with usages of `T*`,=
=20
for Ts other then the nominated types, still produces "pointer to T". For=
=20
example:
struct Foo{}
template<class T>
using operator*<Foo> =3D shared_ptr<T>;
Foo* p; // p has type shared_ptr<Foo>
int* q; // q still has type "pointer to int" <---- HERE
On Saturday, July 6, 2013 3:03:37 AM UTC+2, R. Martinho Fernandes wrote:
>
> There is a big problem in that the existing code that wants pointers=20
> uses T*, not std::pointerto<T>. And that's a rather *large* body of=20
> code.=20
> Mit freundlichen Gr=FC=DFen,=20
>
> Martinho=20
>
>
> On Sat, Jul 6, 2013 at 1:05 AM, <andrew...@gmail.com <javascript:>>=20
> wrote:=20
> >> What if I want an actual pointer now?=20
> >=20
> > Suppose you overload unary operator& on a class:=20
> >=20
> > struct X=20
> > {=20
> > Y operator&();=20
> > }=20
> >=20
> > What if I want the actual address of an object of type X now? You use=
=20
> > std::addressof.=20
> >=20
> > In a similar fashion alias templates could be provided in the standard=
=20
> > library, for example std::pointerto<T>, such that even if the *=20
> declarator=20
> > was overloaded for that class, pointerto<T> would always give you the=
=20
> type=20
> > "pointer to T":=20
> > -Andrew.=20
> >=20
> >=20
> > On Friday, July 5, 2013 3:57:23 PM UTC+2, R. Martinho Fernandes wrote:=
=20
> >>=20
> >> What if I want an actual pointer now?=20
> >> Mit freundlichen Gr=FC=DFen,=20
> >>=20
> >> Martinho=20
> >>=20
> >>=20
> >> On Fri, Jul 5, 2013 at 8:32 AM, <andrew...@gmail.com> wrote:=20
> >> > If we view for a moment the various parts of a declarator as=20
> operations=20
> >> > on=20
> >> > types:=20
> >> >=20
> >> > T*: T -> pointer-to-T=20
> >> > T&: T -> lvalue-reference-to-T=20
> >> > T&&: T -> rvalue-reference-to-T=20
> >> > T[]: T -> array-of-T=20
> >> > T(): T -> function-returning-T=20
> >> > and so forth=20
> >> >=20
> >> > These operations take one or more types as input and produce a type=
=20
> as=20
> >> > output.=20
> >> >=20
> >> > This is not dissimilar to an alias template:=20
> >> >=20
> >> > template<class T>=20
> >> > using MakePointer =3D T*;=20
> >> >=20
> >> > template<class T>=20
> >> > using MakeReference =3D T&;=20
> >> >=20
> >> > In fact we could almost say that functions are to the built-in=20
> >> > expression=20
> >> > operators, as alias templates are to the built-in declarators.=20
> >> >=20
> >> > So the proposed feature "Overloaded Declarators" is to enable a=20
> >> > user-defined=20
> >> > alias template to redefine the built-in meaning of a declarator.=20
> >> >=20
> >> > Overloaded Declarators are to the built-in declarators, as Overloade=
d=20
> >> > Operators are to the built-in expression operators:=20
> >> >=20
> >> > struct Foo{}=20
> >> >=20
> >> > template<class T>=20
> >> > using operator*<Foo> =3D shared_ptr<T>;=20
> >> >=20
> >> > Foo* p; // p has type shared_ptr<T>=20
> >> >=20
> >> > The above shows a key use case, specializing the declarator `T*` to=
=20
> >> > designate a user-defined smart pointer class instead of pointer-to-T=
=20
> for=20
> >> > some set of types.=20
> >> >=20
> >> > Just a random idea.=20
> >> >=20
> >> > Enjoy,=20
> >> > Andrew.=20
> >> >=20
> >> > --=20
> >> >=20
> >> > ---=20
> >> > You received this message because you are subscribed to the Google=
=20
> >> > Groups=20
> >> > "ISO C++ Standard - Future Proposals" group.=20
> >> > To unsubscribe from this group and stop receiving emails from it,=20
> send=20
> >> > an=20
> >> > email to std-proposal...@isocpp.org.=20
> >> > To post to this group, send email to std-pr...@isocpp.org.=20
> >> > Visit this group at=20
> >> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >> >=20
> >> >=20
> >=20
> > --=20
> >=20
> > ---=20
> > You received this message because you are subscribed to the Google=20
> Groups=20
> > "ISO C++ Standard - Future Proposals" group.=20
> > To unsubscribe from this group and stop receiving emails from it, send=
=20
> an=20
> > email to std-proposal...@isocpp.org <javascript:>.=20
> > To post to this group, send email to std-pr...@isocpp.org <javascript:>=
..=20
>
> > Visit this group at=20
> > http://groups.google.com/a/isocpp.org/group/std-proposals/.=20
> >=20
> >=20
>
--=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/.
------=_Part_5183_30927408.1373095382936
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<br>Have you understood that the declarator meaning is only overloaded for =
the user-defined set of types nominated by the declarator overload declarat=
ion (for example just for one class, or one hierarchy of classes)? Th=
e suggestion is not to overload the meaning of the declarator in general.<b=
r><br>As such the declarator, so overloaded, would not effect existing code=
- except where it applies to those user-defined class.<br><br>This is the =
same argument as existing overloaded operators. You wouldn't argue th=
at being able to define:<br><br> Bar operator+(Foo a, Foo=
b);<br><br>affects existing code that expects the built-in meaning of 3 + =
4. Such a case still dispatches to built-in addition. Likewise =
with usages of `T*`, for Ts other then the nominated types, still produces =
"pointer to T". For example:<br><br> struct Foo{}<br><br>=
template<class T><br> using operator*<Foo=
> =3D shared_ptr<T>;<br><br> Foo* p; // p has ty=
pe shared_ptr<Foo><br><br> int* q; // q still has type "p=
ointer to int" <---- HERE<br><br><br>On Saturday, July 6, 2013 3:03:37 A=
M UTC+2, R. Martinho Fernandes wrote:<blockquote class=3D"gmail_quote" styl=
e=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left:=
1ex;">There is a big problem in that the existing code that wants pointers
<br>uses T*, not std::pointerto<T>. And that's a rather *large* body =
of
<br>code.
<br>Mit freundlichen Gr=FC=DFen,
<br>
<br>Martinho
<br>
<br>
<br>On Sat, Jul 6, 2013 at 1:05 AM, <<a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"5Heb6YLZ61cJ">andrew...@gmail.com</a>=
> wrote:
<br>>> What if I want an actual pointer now?
<br>>
<br>> Suppose you overload unary operator& on a class:
<br>>
<br>> struct X
<br>> {
<br>> Y operator&();
<br>> }
<br>>
<br>> What if I want the actual address of an object of type X now? &nbs=
p;You use
<br>> std::addressof.
<br>>
<br>> In a similar fashion alias templates could be provided in the stan=
dard
<br>> library, for example std::pointerto<T>, such that even if th=
e * declarator
<br>> was overloaded for that class, pointerto<T> would always giv=
e you the type
<br>> "pointer to T":
<br>> -Andrew.
<br>>
<br>>
<br>> On Friday, July 5, 2013 3:57:23 PM UTC+2, R. Martinho Fernandes wr=
ote:
<br>>>
<br>>> What if I want an actual pointer now?
<br>>> Mit freundlichen Gr=FC=DFen,
<br>>>
<br>>> Martinho
<br>>>
<br>>>
<br>>> On Fri, Jul 5, 2013 at 8:32 AM, <<a>andrew...@gmail.c=
om</a>> wrote:
<br>>> > If we view for a moment the various parts of a declarator=
as operations
<br>>> > on
<br>>> > types:
<br>>> >
<br>>> > T*: T -> pointer-to-T
<br>>> > T&: T -> lvalue-reference-to-T
<br>>> > T&&: T -> rvalue-reference-to-T
<br>>> > T[]: T -> array-of-T
<br>>> > T(): T -> function-returning-T
<br>>> > and so forth
<br>>> >
<br>>> > These operations take one or more types as input and prod=
uce a type as
<br>>> > output.
<br>>> >
<br>>> > This is not dissimilar to an alias template:
<br>>> >
<br>>> > template<class T>
<br>>> > using MakePointer =3D T*;
<br>>> >
<br>>> > template<class T>
<br>>> > using MakeReference =3D T&;
<br>>> >
<br>>> > In fact we could almost say that functions are to the bui=
lt-in
<br>>> > expression
<br>>> > operators, as alias templates are to the built-in declara=
tors.
<br>>> >
<br>>> > So the proposed feature "Overloaded Declarators" is to en=
able a
<br>>> > user-defined
<br>>> > alias template to redefine the built-in meaning of a decl=
arator.
<br>>> >
<br>>> > Overloaded Declarators are to the built-in declarators, a=
s Overloaded
<br>>> > Operators are to the built-in expression operators:
<br>>> >
<br>>> > struct Foo{}
<br>>> >
<br>>> > template<class T>
<br>>> > using operator*<Foo> =3D shared_ptr<=
;T>;
<br>>> >
<br>>> > Foo* p; // p has type shared_ptr<T&=
gt;
<br>>> >
<br>>> > The above shows a key use case, specializing the declarat=
or `T*` to
<br>>> > designate a user-defined smart pointer class instead of p=
ointer-to-T for
<br>>> > some set of types.
<br>>> >
<br>>> > Just a random idea.
<br>>> >
<br>>> > Enjoy,
<br>>> > Andrew.
<br>>> >
<br>>> > --
<br>>> >
<br>>> > ---
<br>>> > You received this message because you are subscribed to t=
he Google
<br>>> > Groups
<br>>> > "ISO C++ Standard - Future Proposals" group.
<br>>> > To unsubscribe from this group and stop receiving emails =
from it, send
<br>>> > an
<br>>> > email to <a>std-proposal...@isocpp.org</a>.
<br>>> > To post to this group, send email to <a>std-pr...@isocpp.=
org</a>.
<br>>> > Visit this group at
<br>>> > <a href=3D"http://groups.google.com/a/isocpp.org/group/st=
d-proposals/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/=
group/std-<wbr>proposals/</a>.
<br>>> >
<br>>> >
<br>>
<br>> --
<br>>
<br>> ---
<br>> You received this message because you are subscribed to the Google=
Groups
<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"javascript:" target=3D"_blank" gdf-obfuscated-=
mailto=3D"5Heb6YLZ61cJ">std-proposal...@<wbr>isocpp.org</a>.
<br>> To post to this group, send email to <a href=3D"javascript:" targe=
t=3D"_blank" gdf-obfuscated-mailto=3D"5Heb6YLZ61cJ">std-pr...@isocpp.org</a=
>.
<br>> Visit this group at
<br>> <a href=3D"http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/" target=3D"_blank">http://groups.google.com/a/<wbr>isocpp.org/group/std=
-<wbr>proposals/</a>.
<br>>
<br>>
<br></blockquote>
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_5183_30927408.1373095382936--
.
Author: DeadMG <wolfeinstein@gmail.com>
Date: Sat, 6 Jul 2013 04:07:13 -0700 (PDT)
Raw View
------=_Part_7782_18364204.1373108833296
Content-Type: text/plain; charset=ISO-8859-1
I'mma be a bit more blunt than the robot. This is a terrible idea. You're
changing the fundamental interface of language primitives. This is a
terrible idea. Having T and U behave differently when you define T* and U*
is going to bring about so many errors it's not even funny, and
std::pointerto is terrible. When you say "You can work around it like unary
operator&", this isn't a *good* thing, it's a terrible, terrible thing. The
problems experienced with that operator clearly show how overloading
something like this should never be done.
--
---
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/.
------=_Part_7782_18364204.1373108833296
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I'mma be a bit more blunt than the robot. This is a terrible idea. You're c=
hanging the fundamental interface of language primitives. This is a terribl=
e idea. Having T and U behave differently when you define T* and U* is goin=
g to bring about so many errors it's not even funny, and std::pointerto is =
terrible. When you say "You can work around it like unary operator&", t=
his isn't a <i>good</i> thing, it's a terrible, terrible thing. The pr=
oblems experienced with that operator clearly show how overloading somethin=
g like this should never be done.
<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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_7782_18364204.1373108833296--
.
Author: Thiago Macieira <thiago@macieira.org>
Date: Sat, 06 Jul 2013 09:56:15 -0700
Raw View
--nextPart4809131.u02t0EHU9j
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="iso-8859-1"
On s=E1bado, 6 de julho de 2013 00.23.02, andrewtomazos@gmail.com wrote=
:
> This is the same argument as existing overloaded operators. You woul=
dn't=20
> argue that being able to define:
>=20
> Bar operator+(Foo a, Foo b);
>=20
> affects existing code that expects the built-in meaning of 3 + 4.
That's exactly the point. It doesn't affect built-in meanings.
Without the operator+ definition above, (foo) + (foo) won't compile, so=
there's=20
no problem in adding the overload. You're permitting code to work where=
it=20
otherwise wouldn't. And overloading the unary operator& seems like a mi=
stake=20
to me, so I wouldn't count that as a good example to follow ("two wrong=
s don't=20
make a right").
On the other hand, your proposal does change built-in meaning (of somet=
hing=20
that is not an operator, by the way). The code
=09Foo *ptr;
already compiled and had a specific meaning. You want to change the mea=
ning of=20
what it had.
And, like I said, it's not an operator, it's actually a language constr=
uct.=20
Unless you also want to support this:
=09template <class T>
=09using operator const<Foo> =3D Foo;
--=20
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
--nextPart4809131.u02t0EHU9j
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iD8DBQBR2Ew2M/XwBW70U1gRAlxEAJ98n7Uk6yNT+68D4sEQMY6CnkpszACgkLXF
9cb8WGBScwh1y8s6p/V1AmM=
=KMrA
-----END PGP SIGNATURE-----
--nextPart4809131.u02t0EHU9j--
.
Author: Martinho Fernandes <martinho.fernandes@gmail.com>
Date: Sat, 6 Jul 2013 19:16:52 +0200
Raw View
On Sat, Jul 6, 2013 at 9:23 AM, <andrewtomazos@gmail.com> wrote:
>
> Have you understood that the declarator meaning is only overloaded for the
> user-defined set of types nominated by the declarator overload declaration
> (for example just for one class, or one hierarchy of classes)? The
> suggestion is not to overload the meaning of the declarator in general.
Yes, I have understood that. It changes nothing.
You need to realise that in C++ there is already existing code that
uses *classes that haven't written yet*. That code was written under
the assumption that T* is a pointer and not some other thing that
isn't quite compatible with pointers. That code will break.
The overloadable unary operator& has been there since the beginning.
Existing code that uses &x when it should be using boost::addressof(x)
or any other variant of that *was broken already* before
std::addressof was introduced (exercise for the reader: figure out why
std::addressof was introduced).
Under the light of that, and unless you want to argue that all generic
code that used T*, T(U...), T[N], T&, or T&& anywhere to this day is
broken, this change is a terrible idea that will break a lot existing
code.
--
---
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: Jonathan Wakely <cxx@kayari.org>
Date: Mon, 8 Jul 2013 04:01:07 -0700 (PDT)
Raw View
------=_Part_575_10702131.1373281267856
Content-Type: text/plain; charset=ISO-8859-1
Ignoring the other reasons I think this is a terrible idea, in a declarator
the * is not an operator, so altering the meaning of * as a ptr-declarator
by overloading * as an operator doesn't make much sense.
--
---
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/.
------=_Part_575_10702131.1373281267856
Content-Type: text/html; charset=ISO-8859-1
Ignoring the other reasons I think this is a terrible idea, in a declarator the * is not an operator, so altering the meaning of * as a ptr-declarator by overloading * as an operator doesn't make much sense.<br><br>
<p></p>
-- <br />
<br />
--- <br />
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<br />
Visit this group at <a href="http://groups.google.com/a/isocpp.org/group/std-proposals/">http://groups.google.com/a/isocpp.org/group/std-proposals/</a>.<br />
<br />
<br />
------=_Part_575_10702131.1373281267856--
.
Author: Sean Middleditch <sean.middleditch@gmail.com>
Date: Tue, 16 Jul 2013 19:43:35 -0700 (PDT)
Raw View
------=_Part_8_15727919.1374029015550
Content-Type: text/plain; charset=ISO-8859-1
I've had some desires for a similar feature before, but as others have
pointed out, it's quite bad to overload the existing syntax.
I wouldn't mind seeing something like T^ mapping to a per-type handle type
somehow explored and discussed, with a library defaulting this to
std::unique_ptr<T>, just to avoid the sad sad fact we have now where the
recommended syntax is far longer, more obtuse, and less obvious to newer
coders than the "old way" (compare the ease of banging out
std::unique_ptr<T> over T*).
As a very minor extra benefit, while any such new feature would be
incompatible with Microsoft's crazy .NET/WinRT extensions, the syntax would
be semantically similar.
I can still think of a bazillion counter-arguments to such a feature,
though. Better than a proposal would be a patch to Clang or GCC adding the
feature so we can play around with giving the syntax and semantics a try.
On Thursday, July 4, 2013 11:32:01 PM UTC-7, andrew...@gmail.com wrote:
>
> If we view for a moment the various parts of a declarator as operations on
> types:
>
> T*: T -> pointer-to-T
> T&: T -> lvalue-reference-to-T
> T&&: T -> rvalue-reference-to-T
> T[]: T -> array-of-T
> T(): T -> function-returning-T
> and so forth
>
> These operations take one or more types as input and produce a type as
> output.
>
> This is not dissimilar to an alias template:
>
> template<class T>
> using MakePointer = T*;
>
> template<class T>
> using MakeReference = T&;
>
> In fact we could almost say that functions are to the built-in expression
> operators, as alias templates are to the built-in declarators.
>
> So the proposed feature "Overloaded Declarators" is to enable a
> user-defined alias template to redefine the built-in meaning of a
> declarator.
>
> Overloaded Declarators are to the built-in declarators, as Overloaded
> Operators are to the built-in expression operators:
>
> struct Foo{}
>
> template<class T>
> using operator*<Foo> = shared_ptr<T>;
>
> Foo* p; // p has type shared_ptr<T>
>
> The above shows a key use case, specializing the declarator `T*` to
> designate a user-defined smart pointer class instead of pointer-to-T for
> some set of types.
>
> Just a random idea.
>
> Enjoy,
> Andrew.
>
>
--
---
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/.
------=_Part_8_15727919.1374029015550
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I've had some desires for a similar feature before, but as others have poin=
ted out, it's quite bad to overload the existing syntax.<div><br></div><div=
>I wouldn't mind seeing something like T^ mapping to a per-type handle type=
somehow explored and discussed, with a library defaulting this to std::uni=
que_ptr<T>, just to avoid the sad sad fact we have now where the reco=
mmended syntax is far longer, more obtuse, and less obvious to newer coders=
than the "old way" (compare the ease of banging out std::unique_ptr<T&g=
t; over T*).</div><div><br></div><div>As a very minor extra benefit, while =
any such new feature would be incompatible with Microsoft's crazy .NET/WinR=
T extensions, the syntax would be semantically similar.</div><div><br></div=
><div>I can still think of a bazillion counter-arguments to such a feature,=
though. Better than a proposal would be a patch to Clang or GCC addi=
ng the feature so we can play around with giving the syntax and semantics a=
try.</div><div><div><br>On Thursday, July 4, 2013 11:32:01 PM UTC-7, andre=
w...@gmail.com wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;m=
argin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">If we vie=
w for a moment the various parts of a declarator as operations on types:<br=
><br> T*: T -> pointer-to-T<br> T&am=
p;: T -> lvalue-reference-to-T<br> T&&: T ->=
; rvalue-reference-to-T<br> T[]: T -> array-of-T<br>&n=
bsp; T(): T -> function-returning-T<br> an=
d so forth<br><br>These operations take one or more types as input and prod=
uce a type as output.<br><br>This is not dissimilar to an alias template:<b=
r><br> template<class T><br> using MakePointe=
r =3D T*;<br><br> template<class T><br> using=
MakeReference =3D T&;<br><br>In fact we could almost say that function=
s are to the built-in expression operators, as alias templates are to the b=
uilt-in declarators.<br><br>So the proposed feature "Overloaded Declarators=
" is to enable a user-defined alias template to redefine the built-in meani=
ng of a declarator.<br><br>Overloaded Declarators are to the built-in decla=
rators, as Overloaded Operators are to the built-in expression operators:<b=
r><br> struct Foo{}<br><br> template<class T>=
<br> using operator*<Foo> =3D shared_ptr<T>;<br><br=
> Foo* p; // p has type shared_ptr<T><br><br>The ab=
ove shows a key use case, specializing the declarator `T*` to designate a u=
ser-defined smart pointer class instead of pointer-to-T for some set of typ=
es.<br><br>Just a random idea.<br><br>Enjoy,<br>Andrew.<br><br></blockquote=
></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 std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_8_15727919.1374029015550--
.
Author: stackmachine@hotmail.com
Date: Tue, 16 Jul 2013 23:16:55 -0700 (PDT)
Raw View
------=_Part_372_6843545.1374041815608
Content-Type: text/plain; charset=ISO-8859-1
I think this feature has potential but needs more work. Overloading
existing declarators is dangerous as has already been pointed out.
Instead I would like to see custom declarators. e.g.:
{int, double, std::string} x = {42, 3.14, "foo"}; // {T...} means
std::tuple<T...>
std::string -> int m = {{"foo", 1}, {"bar", 2}}; // K -> V means
std::map<K, V>
[int] x = { 1, 2, 3, 4, 5 }; // [T] means std::vector<T>
I have no idea how you would define these or if that would introduce any
parsing ambiguities though.
I could imagine using a syntax similar to alias templates:
template <typename... T>
using { T... } = std::tuple<T...>;
template <typename T, typename U>
using T -> U = std::map<T, U>;
template <typename T>
using [T] = std::vector<T>;
--
---
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/.
------=_Part_372_6843545.1374041815608
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
I think this feature has potential but needs more work. Overloading existin=
g declarators is dangerous as has already been pointed out.<br>Instead I wo=
uld like to see custom declarators. e.g.:<br><div class=3D"prettyprint" sty=
le=3D"background-color: rgb(250, 250, 250); border-color: rgb(187, 187, 187=
); border-style: solid; border-width: 1px; word-wrap: break-word;"><code cl=
ass=3D"prettyprint"><div class=3D"subprettyprint"><span style=3D"color: #66=
0;" 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"sty=
led-by-prettify">,</span><span style=3D"color: #000;" class=3D"styled-by-pr=
ettify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">d=
ouble</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</sp=
an><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span><sp=
an style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span style=
=3D"color: #008;" class=3D"styled-by-prettify">string</span><span style=3D"=
color: #660;" class=3D"styled-by-prettify">}</span><span style=3D"color: #0=
00;" class=3D"styled-by-prettify"> x </span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">=3D</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">{</span><span style=3D"color: #066;" class=3D"styled-by-prettify=
">42</span><span style=3D"color: #660;" class=3D"styled-by-prettify">,</spa=
n><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><span s=
tyle=3D"color: #066;" class=3D"styled-by-prettify">3.14</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #080;" =
class=3D"styled-by-prettify">"foo"</span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">};</span><span style=3D"color: #000;" class=3D"styl=
ed-by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pre=
ttify">// {T...} means std::tuple<T...></span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"><br>std</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">::</span><span style=3D"color: #008;" class=
=3D"styled-by-prettify">string</span><span style=3D"color: #000;" class=3D"=
styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"styled-by=
-prettify">-></span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #008;" class=3D"styled-by-prettify">int=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> m </span>=
<span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"c=
olor: #660;" class=3D"styled-by-prettify">{{</span><span style=3D"color: #0=
80;" class=3D"styled-by-prettify">"foo"</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"styled-by=
-prettify">1</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: #660;" class=3D"styled-by-prettify">{</span><span s=
tyle=3D"color: #080;" class=3D"styled-by-prettify">"bar"</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"styled-by-prettify">2</span><span style=3D"color: #660;" class=3D"=
styled-by-prettify">}};</span><span style=3D"color: #000;" class=3D"styled-=
by-prettify"> </span><span style=3D"color: #800;" class=3D"styled-by-pretti=
fy">// K -> V means std::map<K, V></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: #008;" class=3D"st=
yled-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=
"> x </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D</=
span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span><spa=
n 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"styled-by-prettify">1</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"styled-by=
-prettify">2</span><span style=3D"color: #660;" class=3D"styled-by-prettify=
">,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span=
><span style=3D"color: #066;" class=3D"styled-by-prettify">3</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #066=
;" class=3D"styled-by-prettify">4</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: #066;" class=3D"styled-by-pret=
tify">5</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </=
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: #800;" class=3D"styled-by-prettify">// [T] means std::vector<=
T></span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br><=
/span></div></code></div>I have no idea how you would define these or if th=
at would introduce any parsing ambiguities though.<br>I could imagine using=
a syntax similar to alias templates:<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">template</span><span style=3D"color: #000;" =
class=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"=
styled-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled=
-by-prettify">typename</span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">...</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify">>=
;</span><span style=3D"color: #000;" class=3D"styled-by-prettify"><br></spa=
n><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: #660;" class=3D"styled-by-prettify">{</span><span style=3D"color=
: #000;" class=3D"styled-by-prettify"> T</span><span style=3D"color: #660;"=
class=3D"styled-by-prettify">...</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"style=
d-by-prettify">}</span><span style=3D"color: #000;" class=3D"styled-by-pret=
tify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=3D=
</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><span s=
tyle=3D"color: #000;" class=3D"styled-by-prettify">tuple</span><span style=
=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D"co=
lor: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #660=
;" class=3D"styled-by-prettify">...>;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br><br></span><span style=3D"color: #008;" c=
lass=3D"styled-by-prettify">template</span><span style=3D"color: #000;" cla=
ss=3D"styled-by-prettify"> </span><span style=3D"color: #660;" class=3D"sty=
led-by-prettify"><</span><span style=3D"color: #008;" class=3D"styled-by=
-prettify">typename</span><span style=3D"color: #000;" class=3D"styled-by-p=
rettify"> T</span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
>,</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> </span>=
<span style=3D"color: #008;" class=3D"styled-by-prettify">typename</span><s=
pan style=3D"color: #000;" class=3D"styled-by-prettify"> U</span><span styl=
e=3D"color: #660;" class=3D"styled-by-prettify">></span><span style=3D"c=
olor: #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"> T </span><span style=3D"color: #660;" class=
=3D"styled-by-prettify">-></span><span style=3D"color: #000;" class=3D"s=
tyled-by-prettify"> U </span><span style=3D"color: #660;" class=3D"styled-b=
y-prettify">=3D</span><span style=3D"color: #000;" class=3D"styled-by-prett=
ify"> std</span><span style=3D"color: #660;" class=3D"styled-by-prettify">:=
:</span><span style=3D"color: #000;" class=3D"styled-by-prettify">map</span=
><span style=3D"color: #660;" class=3D"styled-by-prettify"><</span><span=
style=3D"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D=
"color: #660;" class=3D"styled-by-prettify">,</span><span style=3D"color: #=
000;" class=3D"styled-by-prettify"> U</span><span style=3D"color: #660;" cl=
ass=3D"styled-by-prettify">>;</span><span style=3D"color: #000;" class=
=3D"styled-by-prettify"><br></span><span style=3D"color: #000;" class=3D"st=
yled-by-prettify"><br></span><span style=3D"color: #008;" class=3D"styled-b=
y-prettify">template</span><span style=3D"color: #000;" class=3D"styled-by-=
prettify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify"=
><</span><span style=3D"color: #008;" class=3D"styled-by-prettify">typen=
ame</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> T</spa=
n><span style=3D"color: #660;" class=3D"styled-by-prettify">></span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify"><br></span><span styl=
e=3D"color: #008;" class=3D"styled-by-prettify">using</span><span style=3D"=
color: #000;" class=3D"styled-by-prettify"> </span><span style=3D"color: #6=
60;" class=3D"styled-by-prettify">[</span><span style=3D"color: #000;" clas=
s=3D"styled-by-prettify">T</span><span style=3D"color: #660;" class=3D"styl=
ed-by-prettify">]</span><span style=3D"color: #000;" class=3D"styled-by-pre=
ttify"> </span><span style=3D"color: #660;" class=3D"styled-by-prettify">=
=3D</span><span style=3D"color: #000;" class=3D"styled-by-prettify"> std</s=
pan><span style=3D"color: #660;" class=3D"styled-by-prettify">::</span><spa=
n style=3D"color: #000;" class=3D"styled-by-prettify">vector</span><span st=
yle=3D"color: #660;" class=3D"styled-by-prettify"><</span><span style=3D=
"color: #000;" class=3D"styled-by-prettify">T</span><span style=3D"color: #=
660;" class=3D"styled-by-prettify">>;</span><span style=3D"color: #000;"=
class=3D"styled-by-prettify"><br></span></div></code></div><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" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.<br />
To post to this group, send email to std-proposals@isocpp.org.<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 />
<br />
<br />
------=_Part_372_6843545.1374041815608--
.
Author: Magnus Fromreide <magfr@lysator.liu.se>
Date: Wed, 17 Jul 2013 08:34:57 +0200
Raw View
On Tue, 2013-07-16 at 23:16 -0700, stackmachine@hotmail.com wrote:
> I think this feature has potential but needs more work. Overloading
> existing declarators is dangerous as has already been pointed out.
> Instead I would like to see custom declarators. e.g.:
> {int, double, std::string} x = {42, 3.14, "foo"}; // {T...} means
> std::tuple<T...>
> std::string -> int m = {{"foo", 1}, {"bar", 2}}; // K -> V means
> std::map<K, V>
> [int] x = { 1, 2, 3, 4, 5 }; // [T] means std::vector<T>
I do not think this makes for easier to read C++ code.
The only thing I could imagine as possibly useful would be
std::vector<auto> v = { 1, 2, 3 };
but I think the benefit of that is quite low as well since it is
syntactic sugar for
template <class T> inline std::vector<T>
make_vector(std::initializer_list<T> il) {
return std::vector<T>(il);
}
auto v = make_vector({ 1, 2, 3 });
/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 http://groups.google.com/a/isocpp.org/group/std-proposals/.
.