220 30699 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 15:22:53 -0500 Lines: 161 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=94eb2c096f3e8a45c90547559442 X-Trace: blaine.gmane.org 1485807778 5157 195.159.176.226 (30 Jan 2017 20:22:58 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Jan 2017 20:22:58 +0000 (UTC) To: "ISO C++ Standard - Future Proposals" Original-X-From: std-proposals+bncBCGNLO5F34OBBH6BX3CAKGQEVOUZC3Y@isocpp.org Mon Jan 30 21:22:54 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pf0-f197.google.com ([209.85.192.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cYITU-00012W-Np for gclcip-std-proposals@m.gmane.org; Mon, 30 Jan 2017 21:22:53 +0100 Original-Received: by mail-pf0-f197.google.com with SMTP id f144sf466105227pfa.3 for ; Mon, 30 Jan 2017 12:22:58 -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=E5FC/o3bnEKpMQreOySJL2OCYyB9SwD/cKvu6ZAY9X4=; b=PAaAdhqXUsQJsMWn4G0AnC8a6RgefEkYuoya0dKl6qqWK/RuVJpomlwuBAWvgT0QX/ pVVpmbdXO9WlHQiS1YHeJsyJjPeDdB1fW0NOqdzyrJI3OVBcOGnYHmboxRvqrDQWfumK osfbwuCi+NJYXdYQaB8Y6dm58hrheIMas/pB1QS2o16htqiYugMlEF7rbld6Fg0HSquM wI+Jh96FvGEBGFxD3zLnMgNRTKgCJgFJNYvpHP40Sl0IkpZDg8hlvpHfOlCgCa5BYdPe 2MTAZtZLVcSi83IWUaC2ugdooikTsaQjIFv8F1lI8AEWWidr3CboS7z8orVzjeTZDC8x GjIQ== 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=E5FC/o3bnEKpMQreOySJL2OCYyB9SwD/cKvu6ZAY9X4=; b=k4dzUqfznMEEhYvTZ8byFR1ZZDF38+c/hPbnCsImZ6/iF5NBMjqaYzf7k1EWus55IS +CMlo13Zh7lRTFw7PkMJIRve+YkoOD1P5R6iS59FfJTc4P+uyJLY71Z0Xiw81WHn5pMw YZLUlZ5ANl9lZtDn+ycPLwioQg559o7OptXd+3lyGoJ/Mb6XRJaUCgtffOEV7U/Mpz93 gvyHEkOEh4OYR+yXxAVZnV0U0/ONbsXWqJ+1u/SeuHnf0Cy3TuWSUKVaJ4dQb4t0AbVf lV+9EzlGq88Fj9tXQBGpc8+R8weVJ8LZ2uOhBWqQzY4xRtu8HAJdG1EvVStadGJZ2mFB 9lfQ== X-Gm-Message-State: AIkVDXLYfZ6OB715/v987M6IaECQHPmNW5vfQl8dO+JrjpRApZGv6B1FzuaWKrpCHZAO6Q== X-Received: by 10.99.130.199 with SMTP id w190mr6840229pgd.158.1485807777205; Mon, 30 Jan 2017 12:22:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.157.29.8 with SMTP id m8ls7875401otm.43.gmail; Mon, 30 Jan 2017 12:22:55 -0800 (PST) X-Received: by 10.202.172.195 with SMTP id v186mr11567259oie.8.1485807773826; Mon, 30 Jan 2017 12:22:53 -0800 (PST) Original-Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com. [2607:f8b0:4003:c06::22f]) by mx.google.com with ESMTPS id p14si5886431otd.8.2017.01.30.12.22.53 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jan 2017 12:22:53 -0800 (PST) Received-SPF: pass (google.com: domain of calabrese@google.com designates 2607:f8b0:4003:c06::22f as permitted sender) client-ip=2607:f8b0:4003:c06::22f; Original-Received: by mail-oi0-x22f.google.com with SMTP id w204so202344301oiw.0 for ; Mon, 30 Jan 2017 12:22:53 -0800 (PST) X-Received: by 10.202.240.11 with SMTP id o11mr12073417oih.198.1485807773421; Mon, 30 Jan 2017 12:22:53 -0800 (PST) Original-Received: by 10.74.31.152 with HTTP; Mon, 30 Jan 2017 12:22:53 -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:c06::22f 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:30699 Archived-At: --94eb2c096f3e8a45c90547559442 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 30, 2017 at 2:47 PM, Richard Smith wrote: > Another way to get a similar effect would be to allow partial application > of templates at the point of use instead of allowing currying in the > definition. So (strawman syntax): > > static_assert(all_of, int, short, float>); > > where std::is_convertible is a type lambda, with the above being > shorthand for > > template using X = std::is_convertible; > static_assert(all_of); > > (In fact, I think you can implement an _1 and an all_of sufficient to > support the above as a library, but it would have a lot of limitations.) > That's not exactly a strawman -- Boost.MPL has had such lambdas since it was introduced in the early 2000s. The equivalent lambda in MPL-land would be std::is_convertible. In current MPL, you can apply an MPL lambda or a "normal" metafunction class with boost::mpl::apply (in some ways akin to a std::invoke of the metafunction world). I don't believe MPL has an all_of algorithm, but it does have other algorithms. FWIW, despite the magic involved, I've always found MPL's lambda facilities better than the runtime Boost.Lambda facilties (partly because the problem is in some ways simpler -- no value/reference binding specification, etc.). 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). During composition, you can also run into the subtleties that require an equivalent of boost::protect (mpl has a corresponding boost::mpl::protect). I'd rather we not continue down the library route for this stuff. On Mon, Jan 30, 2017 at 2:47 PM, Richard Smith wrote: > Or we could support type lambdas directly (again, strawman syntax): > > static_assert(all_of<[] -> std::is_convertible, > int, short, float>); > This seems much more reasonable to me, though I suspect that, due to its dealing with metaprogramming, it would see push-back from some people. On Mon, Jan 30, 2017 at 2:47 PM, Richard Smith wrote: > ... since the above alternatives don't provide a way to specify where the > end of the first pack is. We could perhaps get that effect with another > extension: > > template using X = pair, > tuple>; > X pt; // pair, tuple> > Interesting idea. -- 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/CANh8DEnSUxxC2BojM%2BB8qpiOvrOo0qsA8stn_Yz3CMOUKD6b%2BQ%40mail.gmail.com. --94eb2c096f3e8a45c90547559442 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Jan 30, 2017 at 2:47 PM, Richard Smith <richard@metafoo.co.uk&= gt; wrote:
Another way t= o get a similar effect would be to allow partial application of templates a= t the point of use instead of allowing currying in the definition. So (stra= wman syntax):

=C2=A0 stat= ic_assert(all_of<std::is_convertible<bool, _1>, int, short, f= loat>);

where std::is_convertible<bool, = _1> is a type lambda, with the above being shorthand for

<= /div>
=C2=A0 template<typename T> using X =3D std::is_convertible= <bool, T>;
=C2=A0 static_assert(all_of<X, int, short, fl= oat>);

(In fact, I think you can implement = an _1 and an all_of sufficient to support the above as a library, but it wo= uld have a lot of limitations.)
That's not exactly a strawman -- Boost.MPL has had such la= mbdas since it was introduced in the early 2000s. The equivalent lambda in = MPL-land would be std::is_convertible<bool, boost::mpl::_1>. In curre= nt MPL, you can apply an MPL lambda or a "normal" metafunction cl= ass with boost::mpl::apply (in some ways akin to a std::invoke of the metaf= unction world). I don't believe MPL has an all_of algorithm, but it doe= s have other algorithms. FWIW, despite the magic involved, I've always = found MPL's lambda facilities better than the runtime Boost.Lambda faci= lties (partly because the problem is in some ways simpler -- no value/refer= ence binding specification, etc.).

Anyway, as some= one who's done a decent amount of C++98/03 metaprogramming, it's un= fortunately 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). Du= ring composition, you can also run into the subtleties that require an equi= valent of boost::protect (mpl has a corresponding boost::mpl::protect).
=
I'd rather we not continue down the library route for th= is stuff.

On Mon, Jan 30, 2017 at 2:47 PM, Richard= Smith=C2=A0<richard@metafoo.co.uk>=C2=A0wrote:
Or we could support type l= ambdas directly (again, strawman syntax):

=C2= =A0 static_assert(all_of<[]<typename T> -> std::is_convert= ible<bool, T>, int, short, float>);
<= /blockquote>

This seems much more reasonable to me, thou= gh I suspect that, due to its dealing with metaprogramming, it would see pu= sh-back from some people.

On Mon, Jan 30, 2017 at = 2:47 PM, Richard Smith=C2=A0<richard@metafoo.co.uk>=C2= =A0wrote:=C2=A0
... since the above alternatives don't provide a way to sp= ecify where the end of the first pack is. We could perhaps get that effect = with another extension:

=C2=A0 template<t= ypename ...A, typename ...B> using X =3D pair<tuple<A...>, tupl= e<B...>>;
=C2=A0 X<int, char; float> pt; // pair&l= t;tuple<int, char>, tuple<float>>

Interesting idea.

--
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/CANh8DEnSUxxC= 2BojM%2BB8qpiOvrOo0qsA8stn_Yz3CMOUKD6b%2BQ%40mail.gmail.com.
--94eb2c096f3e8a45c90547559442-- .