220 8477 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: Wed, 8 Jan 2014 16:44:43 -0800 Lines: 389 Approved: news@gmane.org Message-ID: References: <-5123564187529511709@gmail297201516> <52CB7506.1000906@gmail.com> <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b86e48259903004ef7eea51 X-Trace: ger.gmane.org 1389228278 24048 80.91.229.3 (9 Jan 2014 00:44:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 00:44:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBB67BW6LAKGQEGI5L77Y@isocpp.org Thu Jan 09 01:44:45 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W13jp-0000pM-95 for gclcip-std-proposals@m.gmane.org; Thu, 09 Jan 2014 01:44:45 +0100 Original-Received: by mail-ie0-f197.google.com with SMTP id e14sf9880961iej.0 for ; Wed, 08 Jan 2014 16:44:44 -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:sender:in-reply-to:references:date :message-id:subject:from: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=2mSq/efmRuK/FRX3sNlMzxf75n5PvMNEQd26RAvHOwc=; b=d8+kxX1567DRgxCSJRPJCgu809sSkBmcawfus+oKRq80B7S6lO6p97JVcazWcTxfcX d7kRU5zYQWepWvj9HH1iqnsnZ/OXrlKWlCuxIYjob4rORmYjLRcQDu9E+kYfH7N+AYpN ppAujthxm6e3T0Gn1zxdy2IdxX0DSsF4OFh5Dc7Y4q1REMvhnvVhiFitqN8/RkJMd93J j/8JNOHmQvsFLrnAewjdPETljoKImfLAXMgY9yVTIcXAfgC0vKQYaryXorhRaoAleMID +p2+OFUnCJrt9iMYzFstZpuYFzKeIQsbZXxLEvgcg60IiVcQEZ5U4nCKV9kogXwHPO7w UZKw== X-Gm-Message-State: ALoCoQn8nDagI+YwIJ9ny0am1Vj6h67vUE91KoxPFCCW2bCz0iR4ozNn6WjqOhc3chLIBP9PVMtk X-Received: by 10.182.213.5 with SMTP id no5mr61975obc.15.1389228284410; Wed, 08 Jan 2014 16:44:44 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.61.229 with SMTP id t5ls865223qer.53.gmail; Wed, 08 Jan 2014 16:44:43 -0800 (PST) X-Received: by 10.49.52.34 with SMTP id q2mr678958qeo.10.1389228283777; Wed, 08 Jan 2014 16:44:43 -0800 (PST) Original-Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [2607:f8b0:400c:c01::235]) by mx.google.com with ESMTPS id v10si1377042qat.6.2014.01.08.16.44.43 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 16:44:43 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::235 as permitted sender) client-ip=2607:f8b0:400c:c01::235; Original-Received: by mail-ve0-f181.google.com with SMTP id oy12so1858914veb.26 for ; Wed, 08 Jan 2014 16:44:43 -0800 (PST) X-Received: by 10.58.216.133 with SMTP id oq5mr68675vec.80.1389228283496; Wed, 08 Jan 2014 16:44:43 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.136.227 with HTTP; Wed, 8 Jan 2014 16:44:43 -0800 (PST) In-Reply-To: <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@isocpp.org> X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::235 as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@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:8477 Archived-At: --047d7b86e48259903004ef7eea51 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Jan 8, 2014 at 3:08 PM, Bengt Gustafsson < bengt.gustafsson@beamways.com> wrote: > I agree that something like your ? is needed to be able to disassemble the > list of template arguments. > > We would also need some way to overload based on whether the "head", i.e. > your ?X is a type or a value. Maybe this can be done with partial class > template specialization already with the aid of SFINAE but what we need to > boil it down to is: > > is_type::value to be true or false depending on if X is a type or a > value. > > If it is not a type we also need to know the type of the value, which I > imagine can be done with decltype(X) iff X is not a type. > Here's an implementation: template struct is_type : std::false_type {}; template struct is_type : std::true_type {}; (and likewise we can implement is_template and is_nontype). To make sure that we don't use this decltype erroneously we would have to > specialize helper templates on is_type::value in the regular template > programming style unless we get a static if so that a more imperative style > can be used. > > > Here is a try at implementing is_type: > > // Base declaration; > template struct is_type; > > // Specialization for typename: > template<> struct is_type { static const bool value = true; } > template is_type { static const bool value = false; } > > Does this make any sense? I'm very uncertain about the empty <> in the > first specialization, is it logical at all? > The <> doesn't make sense here; that'd be the syntax for an explicit specialization, which is not what you want here. > Whatever solution can be found to this detail it is important that it can > be done, it is nice if it can be done without introducing any more language > features than the ? itself. It is also good if such a trait would be added > to the standard library to avoid having to invent it over and over. > Yes, I think the ? extension alone is sufficient for this. With the addition of some motivating examples, this seems ready to be written up as a paper to me. I'm somewhat optimistic that the most contentious part of this will be the syntax ('?' or 'auto' or a new keyword or something else). > Den onsdagen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith: > >> On Mon, Jan 6, 2014 at 7:31 PM, David Krauss wrote: >> >>> On 1/7/14 10:17 AM, Richard Smith wrote: >>> >>>> Rather than introducing a new keyword, you could use a '?' token: >>>> >>>> template class A, ? ... Ts> void f(A); >>>> >>>> (or a '*' token, or something similar). >>>> >>> >>> This idea is unscalable if the ? represents a particular template >>> parameter list. If there were two template template parameters with >>> different lists, you would end up attempting to assign both to ? . >>> >> >> That's not the idea. ? doesn't get assigned a value, it just means "any >> type, non-type, or template template argument is OK here", exactly as the >> original poster requested. So is exactly equivalent to your >> suggested <...>. >> >> >>> I'm pretty sure I wrote something about the issue on this board a while >>> ago, but can't recall the details. >>> >>> A bare ellipsis seems to make it clearer that there is no underlying >>> storage or meta-variable. >>> >>> template class A, ... Ts> void f(A); >>> >> >> This does not seem like a complete solution, because it does not provide >> a way to have a *single* template parameter of any kind. That in turn can >> be useful if generic code wants to process an arbitrary list of template >> arguments in some way: >> >> template struct do_stuff { using type = void; }; >> template struct do_stuff { using type = >> foo, typename do_stuff::type>; }; >> >> In this case, the template parameter list of A and the argument >>> types/kinds of Ts are deduced separately, and conversion potentially occurs >>> when forming A . No expressiveness is lost versus the "?" syntax >>> because names at the call site are determined to refer to types or objects >>> independently of the template parameter list, so ? would not pass any >>> information back to the user anyway. >>> >>> >>> The 'auto' keyword would make sense here, but it might make more sense >>>> being restricted to a non-type template parameter (with its type deduced >>>> from the template argument). Perhaps it could be made to fill both >>>> roles: >>>> >>> >>> As for the non-type role, that sounds nice as a separate proposal. The >>> standard explicitly mentions that it's impossible to pass a non-type >>> argument and deduce its type, and it makes usage of e.g. >>> std::integral_constant repetitive. >> >> >> Yes, there's probably an argument for having both, even though there's a >> lot of overlap between them. >> >> >>> >>>> template void f() { >>>> int a = X; // it's a value by default >>>> } >>>> template void g() { >>>> typename X y; // it can be explicitly treated as a type >>>> } >>>> template void h() { >>>> template X z; // or as a template >>>> } >>>> template void i(); // not exactly 'auto', always a non-type >>>> template parameter >>>> >>>> ... though this would require a lot of hacking with the grammar, to >>>> allow >>>> 'template' and 'typename' in these new places. >>>> >>> >>> Looks like a solution in search of a problem. Every use of the parameter >>> would have to be disambiguated, and since the parameter can only refer to >>> the typename or object passed by the caller, each disambiguation would have >>> to go the same way. Might as well keep the status quo. >> >> >> Uses as a non-type parameter would not need disambiguation, and it solves >> both the problem originally raised in this thread and the more-constrained >> problem raised in the "T for two" section of N3405 and the resulting N3601. >> But I agree that separate syntax for the two problems is probably the >> better choice -- I was just pointing out that it's not the only option. >> > -- > > --- > 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/. --047d7b86e48259903004ef7eea51 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Jan 8, 2014 at 3:08 PM, Bengt Gustafsson <bengt.gustafsso= n@beamways.com> wrote:
I agree that something like= your ? is needed to be able to disassemble the list of template arguments.=

We would also need some way to overload based on whether the= "head", i.e. your ?X is a type or a value. Maybe this can be don= e with partial class template specialization already with the aid of SFINAE= but what we need to boil it down to is:

is_type<?X>::value to be true or false depending = on if X is a type or a value.

If it is not a type = we also need to know the type of the value, which I imagine can be done wit= h decltype(X) iff X is not a type.

Here's an implementation:
<= div>
=A0 template<? X> struct is_type : std::false_type= {};
=A0 template<typename T> struct is_type<T> : std= ::true_type {};

(and likewise we can implement is_template and is_nonty= pe).

To make sure that we don't use this decltype erroneously we would have = to specialize helper templates on is_type<?X>::value in the regular t= emplate programming style unless we get a static if so that a more imperati= ve style can be used.


Here is a try at implementing is_type:

// Base declaration;
template<?X> s= truct is_type;

// Specialization for typename:
template<> struct is_type<typename X> { static const bool = value =3D true; }
template<typename T> is_type<T X> {= static const bool value =3D false; }

Does this ma= ke any sense? I'm very uncertain about the empty <> in the first = specialization, is it logical at all?

The <> doesn't make sense = here; that'd be the syntax for an explicit specialization, which is not= what you want here.
=A0
Whatever solution can be found to this detail it is i= mportant that it can be done, it is nice if it can be done without introduc= ing any more language features than the ? itself. It is also good if such a= trait would be added to the standard library to avoid having to invent it = over and over.

Yes, I think the ? extension alone i= s sufficient for this.

With the addition of some m= otivating examples, this seems ready to be written up as a paper to me. I&#= 39;m somewhat optimistic that the most contentious part of this will be the= syntax ('?' or 'auto' or a new keyword or something else).=
=A0
Den onsd= agen den 8:e januari 2014 kl. 22:24:53 UTC+1 skrev Richard Smith:
On Mon, Jan 6, 2014 at 7:31 PM, David Krauss <pot...@gmail.com> wrote:
On 1/7/14 10:17 AM, Richard Smith wrote= :
Rather than introducing a new keyword, you could use a '?' token:
=A0 =A0template<template<? ...> class A, ? ... Ts> void f(A<= Ts...>);

(or a '*' token, or something similar).

This idea is unscalable if the ? represents a particular template parameter= list. If there were two template template parameters with different lists,= you would end up attempting to assign both to ? .

That's not the idea. ? doesn't get assigned a value,= it just means "any type, non-type, or template template argument is O= K here", exactly as the original poster requested. So <? ...> is= exactly equivalent to your suggested <...>.
=A0
I'm pretty sure I wrote something about the issue on this board a while= ago, but can't recall the details.

A bare ellipsis seems to make it clearer that there is no underlying storag= e or meta-variable.

template<template<...> class A, ... Ts> void f(A<Ts...>);=

This does not seem like a complete sol= ution, because it does not provide a way to have a *single* template parame= ter of any kind. That in turn can be useful if generic code wants to proces= s an arbitrary list of template arguments in some way:

=A0 template<? ...> struct do_stuff { using type = =3D void; };
=A0 template<? X, ? ...Xs> struct do_stuff<= X, Xs...> { using type =3D foo<bar<X>, typename do_stuff<Xs.= ...>::type>; };

In this case, the template parameter list of A and the argument types/kinds= of Ts are deduced separately, and conversion potentially occurs when formi= ng A<Ts...> . No expressiveness is lost versus the "?" synt= ax because names at the call site are determined to refer to types or objec= ts independently of the template parameter list, so ? would not pass any in= formation back to the user anyway.


The 'auto' keyword would make sense here, but it might make more se= nse
being restricted to a non-type template parameter (with its type deduced from the template argument). Perhaps it could be made to fill both roles:

As for the non-type role, that sounds nice as a separate proposal. The stan= dard explicitly mentions that it's impossible to pass a non-type argume= nt and deduce its type, and it makes usage of e.g. std::integral_constant r= epetitive.

Yes, there's probably an argument for having both, = even though there's a lot of overlap between them.
=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=A0 =A0template<auto X> void f() {
=A0 =A0 =A0int a =3D X; // it's a value by default
=A0 =A0}
=A0 =A0template<auto X> void g() {
=A0 =A0 =A0typename X y; // it can be explicitly treated as a type
=A0 =A0}
=A0 =A0template<auto X> void h() {
=A0 =A0 =A0template X<int> z; // or as a template
=A0 =A0}
=A0 =A0template<auto &X> void i(); // not exactly 'auto',= always a non-type
template parameter

.... though this would require a lot of hacking with the grammar, to allow 'template' and 'typename' in these new places.

Looks like a solution in search of a problem. Every use of the parameter wo= uld have to be disambiguated, and since the parameter can only refer to the= typename or object passed by the caller, each disambiguation would have to= go the same way. Might as well keep the status quo.

Uses as a non-type parameter would not need disambiguat= ion, and it solves both the problem originally raised in this thread and th= e more-constrained problem raised in the "T for two" section of N= 3405 and the resulting N3601. But I agree that separate syntax for the two = problems is probably the better choice -- I was just pointing out that it&#= 39;s not the only option.

--
=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>.
--047d7b86e48259903004ef7eea51-- .