220 24410 <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [tuple] extracting tuples out of a tuple Date: Mon, 15 Feb 2016 18:10:51 -0800 (PST) Lines: 245 Approved: news@gmane.org Message-ID: <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_6261_2015470513.1455588651748" X-Trace: ger.gmane.org 1455588671 13768 80.91.229.3 (16 Feb 2016 02:11:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 16 Feb 2016 02:11:11 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBLMKRK3AKGQE75WJW2I@isocpp.org Tue Feb 16 03:10:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVV6M-0003Rx-PR for gclcip-std-proposals@m.gmane.org; Tue, 16 Feb 2016 03:10:55 +0100 Original-Received: by mail-io0-f197.google.com with SMTP id b188sf230373183iof.0 for ; Mon, 15 Feb 2016 18:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=AU/jhQnnMLg9V7qJnbJg2UX++BjBPotTZbkSAHWKZ2c=; b=GDdWG6LBYQduepR1kaxGH/oTlGYQiOplNVytYBEIwBxSq88aGyeAGn0Yl0Niqo33bW YrojbFcUDcQ3Pqg8jXtjG1aOfHJUbAvW/wbw+iMcGi5Ay4B+/g6xSPVv07JkS2b/C/Qb 3MIiKLnt0sOWV+BHt+TLgN0COJbsB4p2KoTLACC3DsJHiRFJ9BIB8iFxY6QlwdcOoLlW W6DIUq0QQzuSF5I241uaOOIw50YVRsFMck2H1aytb42QuNuQnfVpEtGrNmvhsndO2T09 shO78TAfkKdBG4p+/jnM0mw+dCI73/9quEG2eYDIWYjBhV8hgS0KArqa3S4ZDHc0ZfJ6 jAyw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=AU/jhQnnMLg9V7qJnbJg2UX++BjBPotTZbkSAHWKZ2c=; b=LRyFIC73jUp61KLMbDHZJz53Lbu4eRmPwr1+LbZBqOEE3kn99bTgc75QDatmkvnb0z Mt4HJeRezdSxBg7iSFEyA+ba9TMU5QihoJCFRCwd9vHs9sjNKLrhQwAT5bwiJttklh+9 QHTzj838hXHjR12C8d7hNzHDPzSEAezzYvl4G2z+Ltk5eJhggJHGnlq+6pFGwrJzPd8k wZt3bhZpay9ZVVY0wkFB683geeEuBdXU/SOyda9A4DU0XGYO5kDSfWGvEPs4iAZjypEE IenRf2mKFLu1anWvie0CeeeyUR6y4HJ8TyHz6Peo5OpPy6Mxt6kwXJook4+TEAhwGl1B 8MWw== 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:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=AU/jhQnnMLg9V7qJnbJg2UX++BjBPotTZbkSAHWKZ2c=; b=KGUBiaCPqUr02YfwD4hDN2aNXZ/XWHbnlEliUYyzBDDY62KFlBkYXcLK5K7KRY0R7U kZZxwqL7vZFy0no+pQUQ4tLHp+PQr1d2VhO5IPL1o68qdcnAa56cGHVqgbED24KkLnlU fHbDuW4Rqu4hHX5ZpduDu9DISPhAMq6H4yCt7hQsYHQlHb53cER3LxYHFAnCO2vVCN94 xYb2osQyqBIJBtjY/IIjde6Snlfz52ze6TSiJ5vBAcL1euuel+3qIuiDZPMqg64s/qze +Rjol34v4J4IYSvF2eXtvze3iqx0DTncLmnqq6gcMQQHKxhHYaDhgCyqouadGyLaHqHR 9+Lw== X-Gm-Message-State: AG10YOTW4RvKXZRiA/2CLl6JpKm0DsvNwnleQD2B91oQOuuiuvZrfCTahEm0Pe/7aNm52A== X-Received: by 10.50.87.7 with SMTP id t7mr15452045igz.11.1455588653894; Mon, 15 Feb 2016 18:10:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.133.205 with SMTP id p74ls1605350ioi.11.gmail; Mon, 15 Feb 2016 18:10:52 -0800 (PST) X-Received: by 10.50.155.65 with SMTP id vu1mr215946igb.0.1455588652901; Mon, 15 Feb 2016 18:10:52 -0800 (PST) In-Reply-To: <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> X-Original-Sender: jmckesson@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:24410 Archived-At: ------=_Part_6261_2015470513.1455588651748 Content-Type: multipart/alternative; boundary="----=_Part_6262_334406376.1455588651749" ------=_Part_6262_334406376.1455588651749 Content-Type: text/plain; charset=UTF-8 On Monday, February 15, 2016 at 6:22:24 PM UTC-5, Louis Dionne wrote: > > Hi, > > I'd like to quickly chime in to drop a link to Boost.Hana [1] (which I'm > the > author of, for full disclosure). There seems to be quite a bit of > discussion > about adding language features to manipulate packs and tuples, when a lot > of > this could be done in a library. Hana's purpose is specifically to > manipulate > tuples (and more generally heterogeneous containers) by providing std-like > algorithms to operate on them. > > Reading the comments here, I just don't see the need for a new language > feature for manipulating parameter packs. Instead, I think we need proper > standard library features to manipulate tuples with a high level of > abstraction. > That's like saying, "Why do we need lambdas in the language? We have Boost.Lambda!" Indeed, I seem to recall Boost.Lambda being one of the impetuses for getting language-based lambdas. BLL was basically *proof* that you couldn't do lambdas as a library. It said, "Look, this is the best the language can do as is: here's what you get, here's what you have to do to implement it, here's how ugly user-code looks, and here are all of the places where it breaks down". In that regard, libraries like Fusion and Hana are perfect examples of why tuple unpacking needs to be a *language* feature. Show me the Hana code for this: outer(inner([:]tpl)...) This calls `inner` on each element of the tuple, then pipes the result into the call to `outer`. It works exactly like parameter packs too, so if `tpl` were a pack, you just drop the `[:]` syntax and it works. Show me the Hana code for this: auto x = inner([:]tpl) + ...; This simply calls a function on each element of the tuple and takes the sum of the results. Again, it works like parameter packs, so it reuses existing knowledge. Oh, and show me the Hana code for this: struct Data { int i; float f; double d; }; Data d = ...; outer(inner([:]d)...); It's the same as the first example, only using an aggregate. It should also be noted that having compiler support for unpacking tuples does not mean you can't also have additional library functions for help in other cases. Sorting, reversing, etc could be library stuff, while the most common cases are handled by the direct language feature. > If properly designed, that could be much more flexible than > a language feature in the long term, when we realize that we're missing > something else. Just to give you a glimpse: how would you reverse a > parameter > pack? How would you sort a parameter pack based on a compile-time > predicate? > I don't see how these slicing proposals are of any help, yet this is a > very > real use case for metaprogramming. > > Instead, I think we need to carefully design a STL for metaprogramming > (with > customization points where it makes sense), and then let users build on > top > of that. And if you're worried about compile-times being too long with a > library-based approach, this can be tackled with a few well-chosen > compiler > intrinsics (see this article [2]). > So instead of having language support for unpacking tuples, you want language support for... some low-level stuff that can be used to build a library? No thanks; I'll take the simple and easy-to-use feature over the huge and complex STL-like thing. -- --- 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 https://groups.google.com/a/isocpp.org/group/std-proposals/. ------=_Part_6262_334406376.1455588651749 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Monday, February 15, 2016 at 6:22:24 PM UTC-5, Louis Di= onne wrote:
Hi,

I'd like to quickly chime in to dr= op a link to Boost.Hana [1] (which I'm the=C2=A0
author of, f= or full disclosure). There seems to be quite a bit of discussion=C2=A0
about adding language features to manipulate packs and tuples, when a= lot of=C2=A0
this could be done in a library. Hana's purpose= is specifically to manipulate=C2=A0
tuples (and more generally h= eterogeneous containers) by providing std-like=C2=A0
algorithms t= o operate on them.=C2=A0

Reading the comments here= , I just don't see the need for a new language=C2=A0
feature = for manipulating parameter packs. Instead, I think we need proper=C2=A0
standard library features to manipulate tuples with a high level of= =C2=A0
abstraction.

That&#= 39;s like saying, "Why do we need lambdas in the language? We have Boo= st.Lambda!"

Indeed, I seem to recall Boost.Lambda being one of = the impetuses for getting language-based lambdas. BLL was basically proo= f that you couldn't do lambdas as a library. It said, "Look, t= his is the best the language can do as is: here's what you get, here= 9;s what you have to do to implement it, here's how ugly user-code look= s, and here are all of the places where it breaks down".

In tha= t regard, libraries like Fusion and Hana are perfect examples of why tuple = unpacking needs to be a language feature.

Show me the Hana co= de for this:

outer(inner<= /span>([:]= tpl)...)

This calls `inner` on each element of the tuple, then pipes the = result into the call to `outer`. It works exactly like parameter packs too,= so if `tpl` were a pack, you just drop the `[:]` syntax and it works.
<= br>Show me the Hana code for this:

auto x =3D inner([:]tpl) + ...;

This sim= ply calls a function on each element of the tuple and takes the sum of the = results. Again, it works like parameter packs, so it reuses existing knowle= dge.

Oh, and show me the Hana code for this:

struct Data
{
=C2=A0 int i;
=C2= =A0 float<= /span> f;
=C2=A0 double d;
};

Data d = =3D ...;
outer(inner([:]d)...);

It's the sa= me as the first example, only using an aggregate.

It should also be = noted that having compiler support for unpacking tuples does not mean you c= an't also have additional library functions for help in other cases. So= rting, reversing, etc could be library stuff, while the most common cases a= re handled by the direct language feature.
=C2=A0
If properly designed= , that could be much more flexible than=C2=A0
a language feature = in the long term, when we realize that we're missing=C2=A0
so= mething else. Just to give you a glimpse: how would you reverse a parameter= =C2=A0
pack? How would you sort a parameter pack based on a compi= le-time predicate?=C2=A0
I don't see how these slicing propos= als are of any help, yet this is a very=C2=A0
real use case for m= etaprogramming.=C2=A0

Instead, I think we need to = carefully design a STL for metaprogramming (with=C2=A0
customizat= ion points where it makes sense), and then let users build on top=C2=A0
of that. And if you're worried about compile-times being too lon= g with a=C2=A0
library-based approach, this can be tackled with a= few well-chosen compiler=C2=A0
intrinsics (see this article [2])= ..

So instead of having language supp= ort for unpacking tuples, you want language support for... some low-level s= tuff that can be used to build a library?

No thanks; I'll take t= he simple and easy-to-use feature over the huge and complex STL-like thing.=

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
------=_Part_6262_334406376.1455588651749-- ------=_Part_6261_2015470513.1455588651748-- .