220 8473 <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@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: Wed, 8 Jan 2014 15:08:46 -0800 (PST) Lines: 302 Approved: news@gmane.org Message-ID: <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@isocpp.org> 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="----=_Part_742_28447818.1389222526249" X-Trace: ger.gmane.org 1389222523 28770 80.91.229.3 (8 Jan 2014 23:08:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 8 Jan 2014 23:08:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCRIRSPDTQIRB75UW6LAKGQEJ6Y2ZXI@isocpp.org Thu Jan 09 00:08:50 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-qa0-f72.google.com ([209.85.216.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W12Ey-0006nY-Vw for gclcip-std-proposals@m.gmane.org; Thu, 09 Jan 2014 00:08:49 +0100 Original-Received: by mail-qa0-f72.google.com with SMTP id f11sf3884107qae.7 for ; Wed, 08 Jan 2014 15:08:48 -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=AYERjtH7pJ+9Tcx3ylpJgUo9S4INmJVkN5nmB7BmSxI=; b=Gh+yq1o+HPCaf6LZrU0EKfYiZ4eyxMYiVvjYYgOBx0IXS4gQcn01hV1wbu039kJw9u mivf17iZ87FG9YjaBm56gUV7JPXPXwTi8EBXq/bZrHQbza2nBUSMTKCL6XYCeW0y9co3 5ThW560CJejmbaJUNi7U/Y8I/NBBhxiXGPDClilVO29X3PfucCwtjKv3+b2s2DL1Ddoh xUs0p2YhPYeGKSnWk1JdxXnyuT4mSkr004cUQ9B8z+fht1felxmYwtsDMkYRf+1dgFq0 DwiebKTc9XTwC47hECX0kcLGuEaCij84dFhNCN/aG42w2J+yv/qProP+aoRkbKL/GdJQ doWg== X-Gm-Message-State: ALoCoQkYMnJBgq1Jw6RsoBXB5bMdFFhCWDKE05Uc+PyyYGWxGeR8+cUNKrVUiOC/UROl5rkNUfm+ X-Received: by 10.59.12.105 with SMTP id ep9mr55801080ved.9.1389222527747; Wed, 08 Jan 2014 15:08:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.59.49 with SMTP id w17ls802759qeq.68.gmail; Wed, 08 Jan 2014 15:08:46 -0800 (PST) X-Received: by 10.49.12.194 with SMTP id a2mr101381qec.26.1389222526944; Wed, 08 Jan 2014 15:08:46 -0800 (PST) In-Reply-To: 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:8473 Archived-At: ------=_Part_742_28447818.1389222526249 Content-Type: text/plain; charset=ISO-8859-1 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. 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? 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. 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/. ------=_Part_742_28447818.1389222526249 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree that something like your ? is needed to be able to= disassemble the list of template arguments.

We would al= so 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 specia= lization 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 n= ot a type we also need to know the type of the value, which I imagine can b= e done with decltype(X) iff X is not a type.

To ma= ke sure that we don't use this decltype erroneously we would have to specia= lize helper templates on is_type<?X>::value in the regular template p= rogramming style unless we get a static if so that a more imperative style = can be used.


Here is a try at imple= menting is_type:

// Base declaration;
te= mplate<?X> struct 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 make any sense? I'm very uncertain about the empty <&g= t; in the first specialization, is it logical at all?

<= div>Whatever solution can be found to this detail it is important that it c= an be done, it is nice if it can be done without introducing any more langu= age features than the ? itself. It is also good if such a trait would be ad= ded to the standard library to avoid having to invent it over and over.






= 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 <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:

   template<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 OK here", exac= tly as the original poster requested. So <? ...> is exactly equivalen= t 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 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:

  template<? ...> struct do_stuff { using ty= pe =3D void; };
  template<? X, ? ...Xs> struct do_stu= ff<X, Xs...> { using type =3D foo<bar<X>, typename do_stuff&= lt;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 "?" syntax because= names at the call site are determined to refer to types or objects indepen= dently 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 stan= dard explicitly mentions that it's impossible to pass a non-type argument a= nd deduce its type, and it makes usage of e.g. std::integral_constant repet= itive.

Yes, there's probably an argument for having both, even= though there's a lot of overlap between them.
 

   template<auto X> void f() {
     int a =3D X; // it's a value by default
   }
   template<auto X> void g() {
     typename X y; // it can be explicitly treated as a type=
   }
   template<auto X> void h() {
     template X<int> z; // or as a template
   }
   template<auto &X> void i(); // not exactly 'auto', a= lways 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 N3405 and t= he resulting N3601. But I agree that separate syntax for the two problems i= s probably the better choice -- I was just pointing out that it's not the o= nly 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>.
------=_Part_742_28447818.1389222526249-- .