220 5409 <8bcba044-b27b-48a0-b3a1-ffd59302d57d@isocpp.org> article Path: news.gmane.org!not-for-mail From: Sean Middleditch Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Overloaded Declarators Date: Tue, 16 Jul 2013 19:43:35 -0700 (PDT) Lines: 143 Approved: news@gmane.org Message-ID: <8bcba044-b27b-48a0-b3a1-ffd59302d57d@isocpp.org> References: <82b89c5e-ce4e-49c0-82b2-d6032631e3e3@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_8_15727919.1374029015550" X-Trace: ger.gmane.org 1374029016 5736 80.91.229.3 (17 Jul 2013 02:43:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Jul 2013 02:43:36 +0000 (UTC) Cc: andrewtomazos@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCDODCNR2QPRBWEJTCHQKGQEEH3QQDI@isocpp.org Wed Jul 17 04:43:38 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f200.google.com ([209.85.216.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UzHiM-0008Lw-Av for gclcip-std-proposals@m.gmane.org; Wed, 17 Jul 2013 04:43:38 +0200 Original-Received: by mail-qc0-f200.google.com with SMTP id n1sf2023579qcx.7 for ; Tue, 16 Jul 2013 19:43:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-beenthere:date:from:to:cc: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=1qrsJdYcob/tCFG+3fCQlN+pL1XtC7fnHfZN84+ofFM=; b=jNBfQMQrhBei3+DMW+POpjnl72ZTeSgXm9nzegukvXjMZkw7tJMuPlFRnBlG2EwLTy Q+dhEJHk9hzvUHeFsGo3dPjoffRtsHb6whEKe9MR/gVRT8jVr2qnllCamcNzUrrKowRw p14yIukUIF/UMf2XaKu76Yg2h01HqxB/ZNvtE3xRcd8WahvN+5WioX5HqoEpZAspbeqz qwI/NsPahwrHGtRgHeB4oMLlgE2rNSOGT7Z55uKq2zAQVLsf+nb5n3kevBqY+ZzEA6ZB bUqI4qWlEgRN2tFjwPVbqJyTmGIGpx6S+m89KAvu53jw+SEZhwx1F8KidFKSyp01t2ui F2JA== X-Received: by 10.236.51.225 with SMTP id b61mr2524634yhc.4.1374029017537; Tue, 16 Jul 2013 19:43:37 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.117.231 with SMTP id kh7ls666163qeb.26.gmail; Tue, 16 Jul 2013 19:43:36 -0700 (PDT) X-Received: by 10.49.71.173 with SMTP id w13mr233289qeu.21.1374029016524; Tue, 16 Jul 2013 19:43:36 -0700 (PDT) In-Reply-To: <82b89c5e-ce4e-49c0-82b2-d6032631e3e3@isocpp.org> X-Original-Sender: sean.middleditch@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:5409 Archived-At: ------=_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, 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 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 > using MakePointer = T*; > > template > 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 > using operator* = shared_ptr; > > Foo* p; // p has type shared_ptr > > 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.

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*).

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.

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.

On Thursday, July 4, 2013 11:32:01 PM UTC-7, andre= w...@gmail.com wrote:
If we vie= w for a moment the various parts of a declarator as operations on types:
    T*: T -> pointer-to-T
    T&am= p;: T -> lvalue-reference-to-T
    T&&: T ->= ; rvalue-reference-to-T
    T[]: T -> array-of-T
&n= bsp;   T(): T -> function-returning-T
    an= d 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 MakePointe= r =3D T*;

   template<class T>
   using= MakeReference =3D T&;

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.

So the proposed feature "Overloaded Declarators= " is to enable a user-defined alias template to redefine the built-in meani= ng of a declarator.

Overloaded Declarators are to the built-in decla= rators, 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 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.

Just a random idea.

Enjoy,
Andrew.

--
 
---
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_8_15727919.1374029015550-- .