220 8465 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 13:24:53 -0800 Lines: 227 Approved: news@gmane.org Message-ID: References: <-5123564187529511709@gmail297201516> <52CB7506.1000906@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0160cdf8b80f7f04ef7c1fd8 X-Trace: ger.gmane.org 1389216294 23045 80.91.229.3 (8 Jan 2014 21:24:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 21:24:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBK4EW6LAKGQEMWXM4LI@isocpp.org Wed Jan 08 22:25:02 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f200.google.com ([209.85.223.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W10cW-000197-ON for gclcip-std-proposals@m.gmane.org; Wed, 08 Jan 2014 22:25:01 +0100 Original-Received: by mail-ie0-f200.google.com with SMTP id at1sf9207321iec.3 for ; Wed, 08 Jan 2014 13:24:59 -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=c2JohloNrV/L+o7dgFGSJ5JN0uJPkvZD5flpsaaGsQA=; b=T26fr7JzufcB557kXC56X6EeMGgWB6cyrRE8zWepLinFp4l831yiAC/7sKV9CGjTNu tUgplp4HcLrYrIHXGt4HnNxMjL/8R9peyzmIciE9LLZFdHx032IEueUqf35NbIfQSsyy Ns5Nv7VAxRTH/1oNVsb5kkE3iTIJViSyxExDyLH4CqvqkYo6rDioElBXF2t4nRCQLoAt 2Ft/5cCagQZbrdqj2lo9uqF25DMavyY2+wUxqxRIVh8jFx9LUBR3hDS4WIsFzwzELQvP XJD7R/6QshAtEhbRB3oy2TQSssEpSvpngR2L5lv/XCfHooAQm4Ia//VRe03oOXLojQjv z5ug== X-Gm-Message-State: ALoCoQkNsKSAlGso0cL7zQoXG8LP/Tg3jAft3Uu9PZ6Yegj2ufCBeBfvQOAELe5NcUPWZcwOZb3Y X-Received: by 10.182.88.200 with SMTP id bi8mr21305234obb.43.1389216299822; Wed, 08 Jan 2014 13:24:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.119.196 with SMTP id kw4ls748578qeb.90.gmail; Wed, 08 Jan 2014 13:24:59 -0800 (PST) X-Received: by 10.236.94.67 with SMTP id m43mr7479673yhf.108.1389216299223; Wed, 08 Jan 2014 13:24:59 -0800 (PST) Original-Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [2607:f8b0:400c:c01::22b]) by mx.google.com with ESMTPS id ge8si2554708qab.114.2014.01.08.13.24.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 13:24:57 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c01::22b as permitted sender) client-ip=2607:f8b0:400c:c01::22b; Original-Received: by mail-ve0-f171.google.com with SMTP id pa12so1733076veb.16 for ; Wed, 08 Jan 2014 13:24:54 -0800 (PST) X-Received: by 10.52.171.227 with SMTP id ax3mr9759141vdc.34.1389216293979; Wed, 08 Jan 2014 13:24:53 -0800 (PST) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.136.227 with HTTP; Wed, 8 Jan 2014 13:24:53 -0800 (PST) In-Reply-To: <52CB7506.1000906@gmail.com> 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::22b 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:8465 Archived-At: --089e0160cdf8b80f7f04ef7c1fd8 Content-Type: text/plain; charset=ISO-8859-1 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/. --089e0160cdf8b80f7f04ef7c1fd8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 6, 2014 at 7:31 PM, David Krauss <potswa@gmail.com> w= rote:
On 1/7/14 10:17 AM, Richar= d 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.

--
 
---
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>.
--089e0160cdf8b80f7f04ef7c1fd8-- .