220 8516 <-2066463899325499340@gmail297201516> article Path: news.gmane.org!not-for-mail From: Richard Smith 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: Sat, 11 Jan 2014 00:43:25 +0000 Lines: 340 Approved: news@gmane.org Message-ID: <-2066463899325499340@gmail297201516> 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> <031149b3-1c5b-4c6d-a827-82d29bc73d6f@isocpp.org> <628bba42-9a56-42d7-8182-0de7c10c437b@isocpp.org> <5f8d31ad-a264-4389-976d-840a71d07f2e@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec5485ad06dfd2e04efa7211e X-Trace: ger.gmane.org 1389401000 10135 80.91.229.3 (11 Jan 2014 00:43:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 11 Jan 2014 00:43:20 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDI4T64VSQPRBLVHYKLAKGQELV3PFVI@isocpp.org Sat Jan 11 01:43:28 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-gg0-f198.google.com ([209.85.161.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1mfg-0000rY-9e for gclcip-std-proposals@m.gmane.org; Sat, 11 Jan 2014 01:43:28 +0100 Original-Received: by mail-gg0-f198.google.com with SMTP id x14sf25596ggx.5 for ; Fri, 10 Jan 2014 16:43:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=Ujlpti99pwaqa5aoCpWSiVXDUBeR/9g2kSAt6m9qBsc=; b=IRWyYHuguB+UckvxjD0AjfhOVLp6RIqkten8300YuI+QE817jIjfimyVXl10OJo/g0 b2vDCcv0Nom61PpclJ8POyvNXyxOF/L/PjbJ3nudcZZ2MuNPQ1VsoN45yFBcAIcEfjzo yuGmzMSivS9SJ3bP3T7SPmlBsCepDFqjGXPYlzslVzS/bKlvFKhK243Sn22/jDJ68sZP CJQjcfidvyavg1TMdDKoU6NjsXs4cpKjShZb+QAmeQRO+2ZnJsHM3Vm4GHbL78cK1ptL SsLSBJvg6gM5WpLXP7I150hrM0VxuDkfYS5bqo/jfOI4icsxch/uEVEUOukeKYr2cy1B AnpA== X-Gm-Message-State: ALoCoQmNWrMTEG7YiFMBMHPDjPx3seV+y8zsOMbrlx7yKBYf8et4XS5ZqJ83WY85tpDlx+LiTiRt X-Received: by 10.52.167.129 with SMTP id zo1mr4107411vdb.5.1389401007379; Fri, 10 Jan 2014 16:43:27 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.26.72 with SMTP id j8ls1618205qeg.62.gmail; Fri, 10 Jan 2014 16:43:26 -0800 (PST) X-Received: by 10.49.110.134 with SMTP id ia6mr10623602qeb.78.1389401006582; Fri, 10 Jan 2014 16:43:26 -0800 (PST) Original-Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [2607:f8b0:400c:c01::230]) by mx.google.com with ESMTPS id r5si12541693qat.112.2014.01.10.16.43.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 10 Jan 2014 16:43:26 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::230 as permitted sender) client-ip=2607:f8b0:400c:c01::230; Original-Received: by mail-ve0-f176.google.com with SMTP id oz11so3920713veb.7 for ; Fri, 10 Jan 2014 16:43:26 -0800 (PST) X-Received: by 10.52.116.200 with SMTP id jy8mr8533370vdb.15.1389401006274; Fri, 10 Jan 2014 16:43:26 -0800 (PST) X-Original-Sender: metafoo@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::230 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:8516 Archived-At: --bcaec5485ad06dfd2e04efa7211e Content-Type: text/plain; charset=ISO-8859-1 On Fri Jan 10 2014 at 3:41:44 PM, Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > Yes, you are absolutely right, the "Tail" should have been there in my > example just as you wrote it. > > So it seems right now that we can make do with the ... "generic pack" type > and auto, but it bugs me a bit that we now have all of these forms of a > template parameter type (where int is of course just an example): > > int One template parameter of type int > int... Any number of int template parameters > auto One non-type template parameter of any type > auto... Any number of non-type template parameters of mixed > types* > typename One type template parameter > typename... Any number of type template parameters > Also: template class template class... > ... Any number of type or non-type template parameters > > But not: > ? One type or auto tempalte parameter (apart from the > bikeshed issue of ?) > > > At least from an educational standpoint it could be wise to be more > orthogonal, which would also mean to reintroduce ?... instead of just ... > > Another risk I see with using ... is that people will start to over-use it > because it looks nice, i.e. writing template<...> for a variadic template > template parameter even when the code only handles that the actuals are > types. > > In the back of my head I also feel that sooner of later we will find > something that can't be done due to the omission of the lonely ? feature. > > Entering the bikeshed I toyed with the use of . instead of ? It kind of > goes nicely with ... as it would be interpreted as "many dots". The main > problem could be that it is almost invisible on the screen especially as a > typical usage would be template<. H,... T>. The * suggested in this thread > is a bit scary as you can also write for instance template which > as another traditional meaning... I also scanned the keyword list but > didn't find any real candidates. > Yes, I also scanned the keyword list before suggesting '?'. The only plausible candidate there was 'auto', but that makes more sense as a generic non-type template parameter. '?' doesn't seem like a great name to me, but it at least gives us something to talk about for now. Hopefully someone can find something better. '.' versus '...' seems cute, but perhaps it's too cute, and as you say, the dot is easily missed. BTW: I can't seem to find any wording in the standard document (C++14) that > allows for instance a function taking any number of ints, although I have > seen uses of it in this list (and which I assumed was available in my list > above): > > template class Matrix; > > VS2012 also does not allow this. What is the status? > This is valid in C++11. We have: 14.1/1: template-parameter: type-parameter parameter-declaration Per 8.3.5, 'int... dims' is a parameter-declaration. Per 14.1/15, such a template-parameter declares a parameter pack. > * The reason for assuming that auto... would refer to any number of > parameters of different types is that otherwise reursive decomposition like > this would be strange: > > template class Foo; > > as now H is "another auto" than Ts which can bind to another type, while > the Ts must still be the same, untill next recursion step. > > Is there a paper or thread for auto template parameters? > No, it came up during discussion of N3601 at the Bristol WG21 meeting, but I don't believe there's any paper on it. (And at Bristol, EWG was pretty evenly divided between wanting N3601's syntax and wanting 'auto'.) > Den fredagen den 10:e januari 2014 kl. 16:35:15 UTC+1 skrev Alex B: > > On Friday, January 10, 2014 5:01:31 AM UTC-5, Bengt Gustafsson wrote: > > > 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; > }; > > > > That syntax without ? would still require being able to name the generic > pack. Your example should be: > > > template struct HeadInfo { > static const bool is_type = true; > typedef T type; > }; > > > > Giving a name would be required to disambiguate cases where there is more > than one generic pack: > > > template <...> struct A {}; > > template > struct B; > > template <...ElemsT, ...ElemsU> > struct B, A> > { > }; > > > As for actual use cases (with or without ?), there is more > than metaprogramming refactoring sugar. I can see at least one case that it > would allow to fix which is boost recursive variants: > > *http://www.boost.org/doc/libs/1_55_0/doc/html/boost/make_recursive_variant.html* > Unless I'm wrong, recursive variants currently cannot contain a template > type with non-type parameters, which is a bit annoying. This feature would > make it possible. > > -- > > --- > 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 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/. --bcaec5485ad06dfd2e04efa7211e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri Jan 10 2014 at 3:41:44 PM, Bengt Gustafsson <bengt.gustafsson@beamways.com> wro= te:
Yes, you are absolutely right, the "Tail" should= have been there in my example just as you wrote it.

So = it seems right now that we can make do with the ... "generic pack"= ; type and auto, but it bugs me a bit that we now have all of these forms o= f a template parameter type (where int is of course just an example):

int =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0One template par= ameter of type int
int... =A0 =A0 =A0 =A0 =A0 =A0 =A0 Any number = of int template parameters
auto =A0 =A0 =A0 =A0 =A0 =A0 =A0 One n= on-type template parameter of any type
auto... =A0 =A0 =A0 =A0 =A0 =A0Any number of non-type template paramet= ers of mixed types*
typename =A0 =A0 =A0 One type template parame= ter
typename... =A0 =A0Any number of type template parameters

Also:

template<template-par= ameter-list> class
template<template-parameter-list>= class...
=A0
... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Any number of = type or non-type template parameters

But not:
? =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 One type or auto tempalte param= eter =A0(apart from the bikeshed issue of ?)


At least from an educational standpoint = it could be wise to be more orthogonal, which would also mean to reintroduc= e ?... instead of just ...

Another risk I see with= using ... is that people will start to over-use it because it looks nice, = i.e. writing template<...> for a variadic template template parameter= even when the code only handles that the actuals are types.

In the back of my head I also feel that sooner of later= we will find something that can't be done due to the omission of the l= onely ? feature.

Entering the bikeshed I toyed wit= h the use of . instead of ? It kind of goes nicely with ... as it would be = interpreted as "many dots". The main problem could be that it is = almost invisible on the screen especially as a typical usage would be templ= ate<. H,... T>. The * suggested in this thread is a bit scary as you = can also write for instance template<int*...> which as another tradit= ional meaning... =A0I also scanned the keyword list but didn't find any= real candidates.

Yes, I also scanned the keyword list= before suggesting '?'. The only plausible candidate there was '= ;auto', but that makes more sense as a generic non-type template parame= ter. '?' doesn't seem like a great name to me, but it at least = gives us something to talk about for now. Hopefully someone can find someth= ing better. '.' versus '...' seems cute, but perhaps it'= ;s too cute, and as you say, the dot is easily missed.

BTW: I = can't seem to find any wording in the standard document (C++14) that al= lows for instance a function taking any number of ints, although I have see= n uses of it in this list (and which I assumed was available in my list abo= ve):

template<int... dims> class Matrix;=A0
=
VS2012 also does not allow this. What is the status?=A0

This is valid in C++11. We have:

14.1/1:
=A0 template-parameter:
=A0= =A0 type-parameter
=A0 =A0 parameter-declaration

<= /div>
Per 8.3.5, 'int... dims' is a parameter-declaration. Per = 14.1/15, such a template-parameter declares a parameter pack.
=A0
* The re= ason for assuming that auto... would refer to any number of parameters of d= ifferent types is that otherwise reursive decomposition like this would be = strange:

template<auto H, auto... Ts> class Foo;

as now H is "another auto" than Ts which can bind= to another type, while the Ts must still be the same, untill next recursio= n step.

Is there a paper or thread for auto template parameters= ?

No, it came up during discuss= ion of N3601 at the Bristol WG21 meeting, but I don't believe there'= ;s any paper on it. (And at Bristol, EWG was pretty evenly divided between = wanting N3601's syntax and wanting 'auto'.)
=A0
Den fred= agen den 10:e januari 2014 kl. 16:35:15 UTC+1 skrev Alex B:
On Friday, January 10, 2014 5:= 01:31 AM UTC-5, Bengt Gustafsson wrote:
=A0
=A0 =A0template<...> struct HeadI= nfo;
=A0 =A0template<typename T, ...> struct HeadInfo<T,= ...> {
=A0 =A0 =A0 =A0static const bool is_type =3D true;
=A0 =A0 =A0 =A0typedef T type;
=A0 =A0};
=A0 =A0template<auto V, ...> struct HeadInfo= <V, ...> {
=A0 =A0 =A0 =A0static const bool is_type =3D fal= se;
=A0 =A0 =A0 =A0typedef decltype(V) type;
=A0 =A0 = =A0 =A0static const auto value =3D V;
=A0 =A0};
=A0
=A0
Tha= t syntax without ? would still require being able to name the generic pack.= Your example should be:
=A0
template<typename T, ...Tail> struct HeadInfo<T, Tail...> {
static const bool is_type =3D t= rue;
typedef T= type;
};
=A0
=A0
Giving a name would be requir= ed to disambiguate cases where there is more than one generic pack:
=A0
template <...> struct A {};
=A0
template <class T, class U>
struct B;
=A0
template <...ElemsT, ...ElemsU= >
struct B<A<= ;ElemsT...>, A<ElemsU...>>
{
};
= =A0
As for actual use cases (with or without ?),=A0there is more = than=A0metaprogramming refactoring sugar.=A0I can see at least one case=A0t= hat it would allow to fix which is boost recursive variants:
Unless I'm wrong, recursive variants currently cannot contain a te= mplate type with non-type parameters, which is a bit annoying.=A0This featu= re would make it possible.

--
=A0
---
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/gro= up/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>.
--bcaec5485ad06dfd2e04efa7211e-- .