220 30706 article Path: news.gmane.org!.POSTED!not-for-mail From: "'Matt Calabrese' via ISO C++ Standard - Future Proposals" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: template template aliases? Date: Mon, 30 Jan 2017 16:48:36 -0500 Lines: 113 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a114088501e189f054756c7b0 X-Trace: blaine.gmane.org 1485812923 6018 195.159.176.226 (30 Jan 2017 21:48:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 21:48:43 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBNPJX3CAKGQE4C2X75Y@isocpp.org Mon Jan 30 22:48:38 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f198.google.com ([209.85.192.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYJoU-000195-FN for gclcip-std-proposals@m.gmane.org; Mon, 30 Jan 2017 22:48:38 +0100 Original-Received: by mail-pf0-f198.google.com with SMTP id c73sf471484300pfb.7 for ; Mon, 30 Jan 2017 13:48:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :x-original-sender:x-original-authentication-results:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=+544F6NMNOIEUloMM4HVQ/nFzJzrtAJ54gDqGcspRgE=; b=H5Xnjul9nafoi91iX3qdZvzxO8ItYmd30QEDisLwAFqjCi3PhxW4p99neSHnF//2qx tNBN5+rz+DqciL4/hxS/eKOrH751YtDrLUkDJN0FjR8TPNvxq4UktJAlaj238Qnx6rgr ILHyPO3BWzmzXzIK2QGtkiRa37kIDip8MK12eTS+NdVF3krNBJLl5m3beAUdPt8UR1So fMj0fiojqidf+DChHzgj8/zvqJo0D/3z8AOXlbh/7548/Mzt2Vd3ovrfTZsEXNjcx1QA DwHqNvyv5gMXr+OZGVLwXjejpD2p5u2q2+ZtSf7XSVO/EC0w8AZD1cUHsaAyoz3Wnb5r NjKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:x-spam-checked-in-group:list-post:list-help:list-archive :list-subscribe:list-unsubscribe; bh=+544F6NMNOIEUloMM4HVQ/nFzJzrtAJ54gDqGcspRgE=; b=DGkSKRcOWNbKe5Y+2b5wVPQjFPz4chlZ3XnNfbt9YcRBBfaNTg/IXeZc1FRJcbY/o0 luADYioBTL16QEgynIYPo5IMg4Q4zzTpqADipox3ZaICa/7yf3A0itNpuLTF6iav13BQ j6SE1TS7WcHteqgJZ92x25mswJJ+QW+PYow+GBRebpDb9fCUdE3XM/YnDz/kEdDM2dcd UzY7u0J/nGQYbEgF3ou61leWpDh67xqgJIRDuuEKicoqvaqk+RjsW/9JyzjM+etslQSk uaLmx2BE5bS1/ToXSnYVmRl+/SzW2kwXZ/4zhDHwq7zsmv6DRLStQDA3Rx6JyJDLhP// U3ww== X-Gm-Message-State: AIkVDXLBTYgmd4ruKMpeeDTIKKbGdNDy5tGEUtA1caaH6OMrI4VD5JMnUr4Fqogx7cgPcw== X-Received: by 10.99.104.9 with SMTP id d9mr6794116pgc.103.1485812918155; Mon, 30 Jan 2017 13:48:38 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.11.115 with SMTP id p48ls7596194otd.19.gmail; Mon, 30 Jan 2017 13:48:37 -0800 (PST) X-Received: by 10.157.26.19 with SMTP id a19mr10458461ote.216.1485812917441; Mon, 30 Jan 2017 13:48:37 -0800 (PST) Original-Received: from mail-ot0-x233.google.com (mail-ot0-x233.google.com. [2607:f8b0:4003:c0f::233]) by mx.google.com with ESMTPS id w54si5957277otw.219.2017.01.30.13.48.37 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 13:48:37 -0800 (PST) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c0f::233 as permitted sender) client-ip=2607:f8b0:4003:c0f::233; Original-Received: by mail-ot0-x233.google.com with SMTP id 65so252696703otq.2 for ; Mon, 30 Jan 2017 13:48:37 -0800 (PST) X-Received: by 10.157.54.98 with SMTP id w89mr11503876otb.123.1485812916923; Mon, 30 Jan 2017 13:48:36 -0800 (PST) Original-Received: by 10.74.31.152 with HTTP; Mon, 30 Jan 2017 13:48:36 -0800 (PST) In-Reply-To: X-Original-Sender: calabrese@google.com X-Original-Authentication-Results: mx.google.com; dkim=pass header.i=@google.com; spf=pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c0f::233 as permitted sender) smtp.mailfrom=calabrese@google.com; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com X-Original-From: Matt Calabrese 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:30706 Archived-At: --001a114088501e189f054756c7b0 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 30, 2017 at 3:58 PM, Richard Smith wrote: > On 30 January 2017 at 12:47, 'Matt Calabrese' via ISO C++ Standard - > Future Proposals wrote: > >> On Mon, Jan 30, 2017 at 3:22 PM, Matt Calabrese >> wrote: >> >>> Anyway, as someone who's done a decent amount of C++98/03 >>> metaprogramming, it's unfortunately no replacement for a language feature. >>> If the complexity of the tricks involved wasn't already enough, it's >>> impossible to make it work consistently with arbitrary template parameter >>> kinds (MPL lambdas live in a world of templates whose only template >>> parameter kinds are types). >>> >> >> On that note, though, I recall that James Touton has voiced a desire for >> an "any-template-parameter-kind" kind (sort of like the new "auto" template >> parameters, but would match *any* template parameter kind). He may even be >> actively working on such a proposal. That would at least make a >> library-level MPL-style lambda facility more capable, but still no >> replacement for something in the language. >> > > Even with such a facility (which I think we sorely need), you still > presumably couldn't fully support non-type template arguments nor packs > with a library-only approach: given > > template struct A {}; > > there's no way that A<_1> can mean anything other than A for some > specific integer N. > Right, *this* syntax wouldn't be usable in that case. In those specific kinds of cases you would use some explicit binding syntax, like bind. Perhaps a more concrete example would be bind. I *think* that should be easily implementable. -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DN%2BWkrGmBET0kbRtZZxAE7fWHOsRcU%3DpDHuSx0zsxCmg%40mail.gmail.com. --001a114088501e189f054756c7b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 30, 2017 at 3:58 PM, Richard Smith <richard@metafoo.co.uk&= gt; wrote:
On 30 January 2017 at 12:47, 'Matt Calabrese' via= ISO C++ Standard - Future Proposals <std-proposals@isocpp.org&= gt; wrote:
On Mon, Jan 30, = 2017 at 3:22 PM, Matt Calabrese <calabrese@google.com> wr= ote:
=
Anyway, as someo= ne who's done a decent amount of C++98/03 metaprogramming, it's unf= ortunately no replacement for a language feature. If the complexity of the = tricks involved wasn't already enough, it's impossible to make it w= ork consistently with arbitrary template parameter kinds (MPL lambdas live = in a world of templates whose only template parameter kinds are types).
=

On that not= e, though, I recall that James Touton has voiced a desire for an "any-= template-parameter-kind" kind (sort of like the new "auto" t= emplate parameters, but would match *any* template parameter kind). He may = even=C2=A0be actively working on such a proposal. That would at least make = a library-level MPL-style lambda facility more capable, but still no replac= ement for something in the language.

Even with such a facility (which I think we s= orely need), you still presumably couldn't fully support non-type templ= ate arguments nor packs with a library-only approach: given

<= /div>
=C2=A0 template<int N> struct A {};=C2=A0

there's no way that A<_1> can mean anything other th= an A<N> for some specific integer N.

Right, *this* syntax wouldn't be usable i= n that case. In those specific kinds of cases you would use some explicit b= inding syntax, like bind<A, _1>. Perhaps a more concrete example woul= d be bind<std::array, int, _1>. I *think* that should be easily imple= mentable.

--
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CANh8DE%3DN= %2BWkrGmBET0kbRtZZxAE7fWHOsRcU%3DpDHuSx0zsxCmg%40mail.gmail.com.
--001a114088501e189f054756c7b0-- .