220 8499 <52CF4DC0.20100@gmail.com> article Path: news.gmane.org!not-for-mail From: David Krauss 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: Fri, 10 Jan 2014 09:32:48 +0800 Lines: 53 Approved: news@gmane.org Message-ID: <52CF4DC0.20100@gmail.com> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Trace: ger.gmane.org 1389317574 28375 80.91.229.3 (10 Jan 2014 01:32:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 01:32:54 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBSE3XWLAKGQEIOUYNZI@isocpp.org Fri Jan 10 02:32:59 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f199.google.com ([209.85.214.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W1Qy2-0003uf-3K for gclcip-std-proposals@m.gmane.org; Fri, 10 Jan 2014 02:32:58 +0100 Original-Received: by mail-ob0-f199.google.com with SMTP id gq1sf13805650obb.6 for ; Thu, 09 Jan 2014 17:32:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-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=XlTEbbN0feX73PfnuE0t9Pkg5NCvseMLCijNWe/thnk=; b=PhfYGKriUFWtkQ+AicHNFNR4dXIVuHqbtcB1STzsuuFm1fMci9ipQtDbS1ErxW5275 630OcnGXq1PKY2Rs9fXuGSIwsIWOGz03DCZ5oI73yLQVrnQNCqyIw3Hwh5fQk7J3di2c dWxGJd/ws1qEuidazXHxAGkqvjDQN3576hwAwpcjCttl7PxxaSEkvFxcOdkiHyOy7Hm/ XlMvkJrRYY2/LJ0mqj+DpdPkidXK5ZgJP0/zW0IkZ8omQxa3j0G2yJDZhbbt1p18UDdg 9P0WztqD2FB/7rWUugamvlmXatr/A10X5MHkctiGFuBdqsW7eSOx11/L77bORNnnBrsZ RANA== X-Gm-Message-State: ALoCoQkt4zzdf0+DjIlxJYA2DZuZa3m88u9Qw2ubrDfbxn/xEyH0DZwXRyrU+sG4RwNjzV6hXEqt X-Received: by 10.182.74.226 with SMTP id x2mr2477344obv.1.1389317577120; Thu, 09 Jan 2014 17:32:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.17.137 with SMTP id o9ls385107qed.88.gmail; Thu, 09 Jan 2014 17:32:56 -0800 (PST) X-Received: by 10.236.105.236 with SMTP id k72mr8590737yhg.30.1389317576100; Thu, 09 Jan 2014 17:32:56 -0800 (PST) Original-Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [2607:f8b0:400e:c03::234]) by mx.google.com with ESMTPS id s23si6878651yhf.103.2014.01.09.17.32.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jan 2014 17:32:56 -0800 (PST) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::234 as permitted sender) client-ip=2607:f8b0:400e:c03::234; Original-Received: by mail-pa0-f52.google.com with SMTP id kx10so203293pab.11 for ; Thu, 09 Jan 2014 17:32:55 -0800 (PST) X-Received: by 10.68.129.99 with SMTP id nv3mr7535107pbb.40.1389317575215; Thu, 09 Jan 2014 17:32:55 -0800 (PST) Original-Received: from Davids-MacBook-Pro.local ([121.54.44.154]) by mx.google.com with ESMTPSA id e6sm13065706pbg.4.2014.01.09.17.32.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 09 Jan 2014 17:32:54 -0800 (PST) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::234 as permitted sender) smtp.mail=potswa@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:8499 Archived-At: On 1/10/14 9:07 AM, Richard Smith wrote: > On Thu, Jan 9, 2014 at 4:23 PM, David Krauss wrote: > >> On 1/10/14 8:11 AM, David Krauss wrote: >> >> Given "?", you can peel off a fully-generic argument from a pack, and >> pass it to another template. But the other template must be either >> fully-generic, or overloaded/partially specialized. So you might as >> well peel the pack in the target overloaded/partially specialized >> template. All "?" buys you is the freedom to add a dispatcher between >> components which are actually necessary. > It allows more code reuse, by allowing handling of individual elements of > such a pack to be factored out. That is a valuable property, even if it > only helps those people who are writing template metaprograms. I'm still skeptical that real factoring is ever possible, i.e. that a template with a fully generic non-pack parameter, and doing more than forward it (which could be done by a tuple-like, pack-based utility), can ever usefully be more than a simple dispatcher. This refers to the primary template, not the specializations. Your previous example use case did not actually use the fully-generic single argument at all, and might as well have taken a pack: template< ... > struct is_type : std::false_type {}; // primary template struct is_type : std::true_type {}; // partial specialization This is assuming, as the previous example already did, that "typename" is more specialized than fully-generic. Presumably "" is still never more specialized than "". We can remove that assumption, and contain the pattern making it scalable by adding that tuple-like utility: template< ... > struct generic_tuple; // library utility template< typename > struct is_type : std::false_type {}; // primary template struct is_type< generic_tuple< T > > : std::true_type {}; // partial specialization The user would have no need for an is_type facility, though, because peeling a tuple element would always require type/value resolution. Prototyping and practice will tell. But, let's keep an eye out for unnecessary complexity masquerading as factoring. -- --- 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/. .