220 5310 <3ab6aadf-3c8b-4054-87bb-9db8a786f847@isocpp.org> article Path: news.gmane.org!not-for-mail From: andrewtomazos@gmail.com Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Overloaded Declarators Date: Sat, 6 Jul 2013 00:23:02 -0700 (PDT) Lines: 377 Approved: news@gmane.org Message-ID: <3ab6aadf-3c8b-4054-87bb-9db8a786f847@isocpp.org> References: <82b89c5e-ce4e-49c0-82b2-d6032631e3e3@isocpp.org> <6ed86280-bff9-4dc5-bef3-28be8981770b@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_5183_30927408.1373095382936" X-Trace: ger.gmane.org 1373095387 13159 80.91.229.3 (6 Jul 2013 07:23:07 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Jul 2013 07:23:07 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBD5KHQXXWYPRBV4L36HAKGQEX6KPBOY@isocpp.org Sat Jul 06 09:23:07 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qe0-f72.google.com ([209.85.128.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UvMpl-0003wE-QK for gclcip-std-proposals@m.gmane.org; Sat, 06 Jul 2013 09:23:06 +0200 Original-Received: by mail-qe0-f72.google.com with SMTP id 1sf3622320qec.3 for ; Sat, 06 Jul 2013 00:23:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:x-google-group-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=TTticQNxHIHk1a0WXVG7RmIqEHD9lit82XMmLFMClvU=; b=ehFauL3Fx/njx+LH4jYQqxrkblLR8P4OIIDtS0OFEPv+1GPW4foVidTHpV0XdEyAwG 8W4+EPz9gG1UCRTUQI/0P2pzAdoBXiZ3s0shEi6BdG7rjRo92O0IYc2UUof7qb0Xq1lu oQbkRspw1bG4TM1Zv67fzYq2L1VRcPybM7nosapvqTy6+xrFYyNCMCvbKkaJ3BaMWqTM b2acC5QhusUitusnFgeF5DDfK5gUJCpwPPUrnUjHMglu6ENSYbqH7Vuy3D4VaT87U7Rs zObGpR0R5yu/A3xOzvaSAH/I4QxDMvvlnbdq/aGUzU9f0O0NjmDf2CM0DvbhpkovQrRn ODiQ== X-Received: by 10.224.37.3 with SMTP id v3mr8631054qad.2.1373095384980; Sat, 06 Jul 2013 00:23:04 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.26.70 with SMTP id j6ls1271336qeg.94.gmail; Sat, 06 Jul 2013 00:23:03 -0700 (PDT) X-Received: by 10.49.47.10 with SMTP id z10mr292946qem.7.1373095383313; Sat, 06 Jul 2013 00:23:03 -0700 (PDT) In-Reply-To: X-Original-Sender: andrewtomazos@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:5310 Archived-At: ------=_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 using operator* =3D shared_ptr; Foo* p; // p has type shared_ptr 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. 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, >=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, such that even if the *=20 > declarator=20 > > was overloaded for that class, pointerto 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, 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=20 > >> > using MakePointer =3D T*;=20 > >> >=20 > >> > template=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=20 > >> > using operator* =3D shared_ptr;=20 > >> >=20 > >> > Foo* p; // p has type shared_ptr=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 .=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 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
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.
As such the declarator, so overloaded, would not effect existing code= - except where it applies to those user-defined class.

This is the = same argument as existing overloaded operators.  You wouldn't argue th= at being able to define:

    Bar operator+(Foo a, Foo= b);

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:

   struct Foo{}

=    template<class T>
   using operator*<Foo= > =3D shared_ptr<T>;

   Foo* p;  // p has ty= pe shared_ptr<Foo>

   int* q; // q still has type "p= ointer to int" <---- HERE


On Saturday, July 6, 2013 3:03:37 A= M UTC+2, R. Martinho Fernandes wrote:
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,  <andrew...@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? &nbs= p;You use
> std::addressof.
>
> In a similar fashion alias templates could be provided in the stan= dard
> library, for example std::pointerto<T>, such that even if th= e * declarator
> was overloaded for that class, pointerto<T> would always giv= e you the type
> "pointer to T":
>     -Andrew.
>
>
> On Friday, July 5, 2013 3:57:23 PM UTC+2, R. Martinho Fernandes wr= ote:
>>
>> 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.c= om> 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 prod= uce 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 bui= lt-in
>> > expression
>> > operators, as alias templates are to the built-in declara= tors.
>> >
>> > So the proposed feature "Overloaded Declarators" is to en= able a
>> > user-defined
>> > alias template to redefine the built-in meaning of a decl= arator.
>> >
>> > Overloaded Declarators are to the built-in declarators, a= s 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&= gt;
>> >
>> > The above shows a key use case, specializing the declarat= or `T*` to
>> > designate a user-defined smart pointer class instead of p= ointer-to-T for
>> > some set of types.
>> >
>> > Just a random idea.
>> >
>> > Enjoy,
>> > Andrew.
>> >
>> > --
>> >
>> > ---
>> > You received this message because you are subscribed to t= he 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-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 &= quot;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-proposals/<= /a>.
 
 
------=_Part_5183_30927408.1373095382936-- .