220 8479 <-9126987679220332623@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: Thu, 09 Jan 2014 02:41:54 +0000 Lines: 193 Approved: news@gmane.org Message-ID: <-9126987679220332623@gmail297201516> References: <-5123564187529511709@gmail297201516> <52CB7506.1000906@gmail.com> <62bda680-3dd7-4be8-8ac5-0d2e08bf6d99@isocpp.org> <52CDFB2D.4050703@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0160cc307a360e04ef808d5c X-Trace: ger.gmane.org 1389235311 30654 80.91.229.3 (9 Jan 2014 02:41:51 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 9 Jan 2014 02:41:51 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDI4T64VSQPRB44YXCLAKGQEV24ZCJY@isocpp.org Thu Jan 09 03:41:58 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W15ZF-0007X8-FE for gclcip-std-proposals@m.gmane.org; Thu, 09 Jan 2014 03:41:57 +0100 Original-Received: by mail-oa0-f71.google.com with SMTP id i4sf322986oah.2 for ; Wed, 08 Jan 2014 18:41:56 -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=f0jp1PTXfqbo5A3UnRMphcfnGybxav1LdW+R9zM59sc=; b=RwPPoNKeM0hsvSA6xWCbBOrgK20QP/b6pNe47PO8/f7tDYu0hmXSLwVpxE08nnZaP3 A3TkTvbvw0UFqi1zWAPoks1XHwa9bsp6EiMsN3JGIjlJYgNmOffUTWtx6UGSPux5cIoD bd7V7FwmkDXnz90uKfS0bqfraPudf1P4BFdL17iJZKmid88Rhve4CEro2XajQZNYqpmU zqgjCUvLTXkWauiD6EEat9Fpz9rNCUYts4kHti9f464EpovNaw/Laag1Tz75pKUaYP7O Z+akzujPvyW3LgJicoR3T5x7EJSbKFsiEKv5+FlHZZJLDhMyVO0C/XaTPkge7B1N6g2M HKOQ== X-Gm-Message-State: ALoCoQnUpTf7G+qDGwmLk80yAA3ek8pPRV/Jn2LhB3kzwRPAR9oei7VBfjxin/vCBckJiKEx7aot X-Received: by 10.42.122.140 with SMTP id n12mr215868icr.25.1389235316496; Wed, 08 Jan 2014 18:41:56 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.48.105 with SMTP id k9ls756662qen.96.gmail; Wed, 08 Jan 2014 18:41:55 -0800 (PST) X-Received: by 10.49.17.232 with SMTP id r8mr1506685qed.74.1389235315596; Wed, 08 Jan 2014 18:41:55 -0800 (PST) Original-Received: from mail-vb0-x236.google.com (mail-vb0-x236.google.com [2607:f8b0:400c:c02::236]) by mx.google.com with ESMTPS id l8si3527705qey.28.2014.01.08.18.41.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 08 Jan 2014 18:41:55 -0800 (PST) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c02::236 as permitted sender) client-ip=2607:f8b0:400c:c02::236; Original-Received: by mail-vb0-f54.google.com with SMTP id g10so1800004vbg.13 for ; Wed, 08 Jan 2014 18:41:55 -0800 (PST) X-Received: by 10.52.160.38 with SMTP id xh6mr55251vdb.39.1389235315286; Wed, 08 Jan 2014 18:41:55 -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:c02::236 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:8479 Archived-At: --089e0160cc307a360e04ef808d5c Content-Type: text/plain; charset=ISO-8859-1 On Wed Jan 08 2014 at 5:28:21 PM, David Krauss wrote: > On 1/9/14 8:44 AM, Richard Smith wrote: > > Here's an implementation: > > > > template struct is_type : std::false_type {}; > > template struct is_type : std::true_type {}; > > This appears to be using ? like auto, not to mean "type or object." > No, it's using it to mean "type or object". > Also, as you know, class templates cannot currently be overloaded like > this. It's not an overload, it's a partial specialization. > Functions can be, so: > > template< typename > > std::true_type is_type(); > > template< int > // Insufficient generality, to be fixed by "auto"-like > type deduction. > std::false_type is_type(); > > template< template< typename ... > class > // Insufficient generality, > to be fixed by "?"-like kind deduction. > std::false_type is_type(); > > bool three_is_type = decltype( is_type< 3 >() )::value, > double_is_type = decltype( is_type< double >() )::value, > vector_is_type = decltype( is_type< std::vector >() )::value; > > > 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). > > I still don't see the value of an identifier, as opposed to a pack > expansion element, that can be either a type or a value. And such a name > would throw a wrench into template parsing. They could *only* be used as > explicit template arguments to functions as in my example above, or to > template template parameters with "?"-like parameter lists. > > If you end up needing to use is_type, you're already in deep shit. > > On the other hand, parameter lists are already unpacked using > overloading, or partial specialization which works the same way. This > gives you a branching point to different code paths for type, value, or > template, which can already be written and parsed without redesigning > dependent name lookup. > > This is why I think "..." is sufficient with no motivation for "?" or > any provision for a single argument. > > -- > > --- > 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/. --089e0160cc307a360e04ef808d5c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed Jan 08 2014 at 5:28:21 PM, David Krauss <potswa@gmail.com> wrote:
On 1/9/14 8:44 AM, Richard Smith wrote:
> Here's an implementation:
>
> =A0 =A0template<? X> struct is_type : std::false_type {};
> =A0 =A0template<typename T> struct is_type<T> : std::true_= type {};

This appears to be using ? like auto, not to mean "type or object.&quo= t;

No, it's using it to mean "= type or object".
=A0
Also, as you know, class templates cannot currently be overloaded like
this.

It's not an overload, it's a = partial specialization.
=A0
= Functions can be, so:

template< typename >
std::true_type is_type();

template< int > // Insufficient generality, to be fixed by "auto= "-like
type deduction.
std::false_type is_type();

template< template< typename ... > class > // Insufficient gene= rality,
to be fixed by "?"-like kind deduction.
std::false_type is_type();

bool three_is_type =3D decltype( is_type< 3 >() )::value,
=A0 =A0 =A0double_is_type =3D decltype( is_type< double >() )::value,=
=A0 =A0 =A0vector_is_type =3D decltype( is_type< std::vector >() )::v= alue;

> Yes, I think the ? extension alone is sufficient for this.
>
> With the addition of some motivating examples, this seems ready to be<= br> > written up as a paper to me. I'm somewhat optimistic that the most=
> contentious part of this will be the syntax ('?' or 'auto&= #39; or a new keyword
> or something else).

I still don't see the value of an identifier, as opposed to a pack
expansion element, that can be either a type or a value. And such a name would throw a wrench into template parsing. They could *only* be used as explicit template arguments to functions as in my example above, or to
template template parameters with "?"-like parameter lists.

If you end up needing to use is_type, you're already in deep shit.

On the other hand, parameter lists are already unpacked using
overloading, or partial specialization which works the same way. This
gives you a branching point to different code paths for type, value, or
template, which can already be written and parsed without redesigning
dependent name lookup.

This is why I think "..." is sufficient with no motivation for &q= uot;?" or
any provision for a single argument.

--

---
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/.

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