220 8501 <031149b3-1c5b-4c6d-a827-82d29bc73d6f@isocpp.org> article Path: news.gmane.org!not-for-mail From: Bengt Gustafsson Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: A new keyword for either a type or a variable (typical use case for variadic template template)? Date: Fri, 10 Jan 2014 02:01:31 -0800 (PST) Lines: 254 Approved: news@gmane.org Message-ID: <031149b3-1c5b-4c6d-a827-82d29bc73d6f@isocpp.org> References: <-5123564187529511709@gmail297201516> <52CB7506.1000906@gmail.com> <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@isocpp.org> <52CDFB2D.4050703@gmail.com> <-9126987679220332623@gmail297201516> <52CE0F54.5020800@gmail.com> <52CF3AB0.7090102@gmail.com> <52CF3D80.9090702@gmail.com> <52CF4DC0.20100@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_148_30962611.1389348092038" X-Trace: ger.gmane.org 1389348089 8426 80.91.229.3 (10 Jan 2014 10:01:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 10:01:29 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRB7MJX6LAKGQEKNEHN4I@isocpp.org Fri Jan 10 11:01:37 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qc0-f197.google.com ([209.85.216.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1YuE-0008Tq-Dr for gclcip-std-proposals@m.gmane.org; Fri, 10 Jan 2014 11:01:34 +0100 Original-Received: by mail-qc0-f197.google.com with SMTP id r5sf6789575qcx.4 for ; Fri, 10 Jan 2014 02:01:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:list-post:list-help:list-archive :list-subscribe:list-unsubscribe:content-type; bh=P3Rv/Toyw6krw5vSVRrtZjAGxqQoP0TKqE0mEQQPOqg=; b=HMGRSFR9aWMXFn0MvPqLn6YGGksLORQUowDs+15zcYUrYhRvFPRBCK/TnRPpoaqvMi /pSftQNT8NdDhmlT4j7C+kzbSCK3B2KBvfhVbXK6P7GBgAK301tFBK0fbIdvv2avV14/ 2xtYtSIuuTCtF67sYnleByfNxosDItyY20no27ZDPi3OOXVoGskm41/eURFQyCvbwZtX MfFVneZt0bdc7B/NH1QH3NlF00b2iHcbVNloYbzoG4tROzjI2X34px+Su6LZMNpInJ8x nZj4dep+w/ZoNJ4pXmFKb+2phNwL/IHCEleA6I3OQg/E08IF7HX0yH2uNxcho1fwBToS g1yA== X-Gm-Message-State: ALoCoQkikzuYc4BBDfLuhP6ng5ROGLIeruY6Ktg4YzaqAEy41tbuJrBdhjdIUttkHi3VhR7FxwpC X-Received: by 10.58.100.99 with SMTP id ex3mr3217278veb.1.1389348093468; Fri, 10 Jan 2014 02:01:33 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.24.174 with SMTP id v14ls1343635qef.74.gmail; Fri, 10 Jan 2014 02:01:32 -0800 (PST) X-Received: by 10.49.85.2 with SMTP id d2mr30655qez.9.1389348092856; Fri, 10 Jan 2014 02:01:32 -0800 (PST) In-Reply-To: <52CF4DC0.20100@gmail.com> X-Original-Sender: bengt.gustafsson@beamways.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:8501 Archived-At: ------=_Part_148_30962611.1389348092038 Content-Type: text/plain; charset=ISO-8859-1 Except that it is error prone I like your idea: template< ... > struct is_type : std::false_type {}; // primary template struct is_type : std::true_type {}; // partial specialization (error prone in the sense that if you call it with more than one type it tells you it isn't a type). But in our use case we would first have to split the incoming generic pack into its individual elements to be able to test them for type/non-type. Can this be done with only the ... feature. I think it can, but only given the other "auto" feature. I exemplify by a simple function to get info about the first element of a generic pack: template<...> struct HeadInfo; template struct HeadInfo { static const bool is_type = true; typedef T type; }; template struct HeadInfo { static const bool is_type = false; typedef decltype(V) type; static const auto value = V; }; Well, now that I wrote the code I noticed that the same "default based" technique used for is_type is usable here too, except of course that you would not get the type and value members for the non typename case. Also, it seems that it gets hard to work with the "always variadic" nature of the resulting templates, for instance we could not write static const bool is_type = std::is_type<...> here as it would be exposed to the error-proneness I described at the top of this post. My conclusion for now is that if we have 'auto' as I used it above we only need the ... notation for variadic generic parameters, as auto and typename can be used to differentiate the members of the generic pack as shown in the HeadInfo example. Thus a new implementation of is_type is like this: template< ... > struct is_type; // primary, not implemented. This prevents using is_type with more than one element packs. template : struct is_type : std::false_type {}; template struct is_type : std::true_type {}; // partial specialization The only problem I see with this is that it is kind of weird to define the primary template with ... which denotes any number of anything. At least error messages when you instantiate with more than one parameter will be misleading, as it will complain about the class being incomplete rather than the template parameters being too many. This argument alone seems however to be too weak to motivate a ? feature. Den fredagen den 10:e januari 2014 kl. 02:32:48 UTC+1 skrev David Krauss: > > On 1/10/14 9:07 AM, Richard Smith wrote: > > On Thu, Jan 9, 2014 at 4:23 PM, David Krauss > > wrote: > > > >> On 1/10/14 8:11 AM, David Krauss wrote: > >> > >> Given "?", you can peel off a fully-generic argument from a pack, and > >> pass it to another template. But the other template must be either > >> fully-generic, or overloaded/partially specialized. So you might as > >> well peel the pack in the target overloaded/partially specialized > >> template. All "?" buys you is the freedom to add a dispatcher between > >> components which are actually necessary. > > It allows more code reuse, by allowing handling of individual elements > of > > such a pack to be factored out. That is a valuable property, even if it > > only helps those people who are writing template metaprograms. > > I'm still skeptical that real factoring is ever possible, i.e. that a > template with a fully generic non-pack parameter, and doing more than > forward it (which could be done by a tuple-like, pack-based utility), > can ever usefully be more than a simple dispatcher. This refers to the > primary template, not the specializations. Your previous example use > case did not actually use the fully-generic single argument at all, and > might as well have taken a pack: > > template< ... > struct is_type : std::false_type {}; // primary > template struct is_type : std::true_type {}; // partial > specialization > > > This is assuming, as the previous example already did, that "typename" > is more specialized than fully-generic. Presumably "" is still > never more specialized than "". We can remove that > assumption, and contain the pattern making it scalable by adding that > tuple-like utility: > > template< ... > struct generic_tuple; // library utility > > template< typename > struct is_type : std::false_type {}; // primary > template struct is_type< generic_tuple< T > > : > std::true_type {}; // partial specialization > > > The user would have no need for an is_type facility, though, because > peeling a tuple element would always require type/value resolution. > > Prototyping and practice will tell. But, let's keep an eye out for > unnecessary complexity masquerading as factoring. > > -- --- 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_148_30962611.1389348092038 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Except that it is error prone I like your idea:

   template< ... > struct is_type : std::false_typ= e {}; // primary 
   template<typename T> struct is= _type<T> : std::true_type {}; // partial specialization 

= (error prone in the sense that if you call it with more than one type it te= lls you it isn't a type).

But in our use case we w= ould first have to split the incoming generic pack into its individual elem= ents to be able to test them for type/non-type. Can this be done with only = the ... feature. I think it can, but only given the other "auto" feature. I= exemplify by a simple function to get info about the first element of a ge= neric pack:

   template<...> struc= t HeadInfo;
   template<typename T, ...> struct H= eadInfo<T, ...> {
       static const b= ool is_type =3D true;
       typedef T type;<= /div>
   };
   template<auto V, ...>= ; struct HeadInfo<V, ...> {
       stat= ic const bool is_type =3D false;
       typed= ef decltype(V) type;
       static const auto= value =3D V;
   };

Well, now = that I wrote the code I noticed that the same "default based" technique use= d for is_type is usable here too, except of course that you would not get t= he type and value members for the non typename case. Also, it seems that it= gets hard to work with the "always variadic" nature of the resulting templ= ates, for instance we could not write static const bool is_type =3D std::is= _type<...> here as it would be exposed to the error-proneness I descr= ibed at the top of this post.

My conclusion for no= w is that if we have 'auto' as I used it above we only need the ... notatio= n for variadic generic parameters, as auto and typename can be used to diff= erentiate the members of the generic pack as shown in the HeadInfo example.= Thus a new implementation of is_type is like this:

 template< ... > struct is_type; // primary, not implemen= ted. This prevents using is_type with more than one element packs.
 template<auto V> : struct is_type<V> : std::false_type = {};
 template<typename T> struct is_type<T> : std::true= _type {}; // partial specialization 

The = only problem I see with this is that it is kind of weird to define the prim= ary template with ... which denotes any number of anything. At least error = messages when you instantiate with more than one parameter will be misleadi= ng, as it will complain about the class being incomplete rather than the te= mplate parameters being too many. This argument alone seems however to be t= oo weak to motivate a ? feature.



Den fredagen den 10:e januari 2014 kl. 02:32:48 UTC+1 skre= v David Krauss:
On 1/10/14 9:07= AM, Richard Smith wrote:
> On Thu, Jan 9, 2014 at 4:23 PM, David Krauss <pot...@gmail.com> wrote:
>
>> On 1/10/14 8:11 AM, David Krauss wrote:
>>
>> Given "?", you can peel off a fully-generic argument from a pa= ck, and=20
>> pass it to another template. But the other template must be ei= ther=20
>> fully-generic, or overloaded/partially specialized. So you mig= ht as=20
>> well peel the pack in the target overloaded/partially speciali= zed=20
>> template. All "?" buys you is the freedom to add a dispatcher = between=20
>> components which are actually necessary.=20
> It allows more code reuse, by allowing handling of individual elem= ents of
> such a pack to be factored out. That is a valuable property, even = if it
> only helps those people who are writing template metaprograms.

I'm still skeptical that real factoring is ever possible, i.e. that a= =20
template with a fully generic non-pack parameter, and doing more than= =20
forward it (which could be done by a tuple-like, pack-based utility),= =20
can ever usefully be more than a simple dispatcher. This refers to the= =20
primary template, not the specializations. Your previous example use=20
case did not actually use the fully-generic single argument at all, and= =20
might as well have taken a pack:

   template< ... > struct is_type : std::false_type {};= // primary
   template<typename T> struct is_type<T> : std::= true_type {}; // partial specialization


This is assuming, as the previous example already did, that "typename"= =20
is more specialized than fully-generic. Presumably "<typename>" i= s still=20
never more specialized than "<typename ...>". We can remove that= =20
assumption, and contain the pattern making it scalable by adding that= =20
tuple-like utility:

   template< ... > struct generic_tuple; // library uti= lity

   template< typename > struct is_type : std::false_typ= e {}; // primary
   template<typename T> struct is_type< generic_tupl= e< T > > : std::true_type {}; // partial specialization


The user would have no need for an is_type facility, though, because=20
peeling a tuple element would always require type/value resolution.

Prototyping and practice will tell. But, let's keep an eye out for=20
unnecessary complexity masquerading as factoring.

--
 
---
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_148_30962611.1389348092038-- .