220 24435 <586249ad-b4ae-4e40-bdf7-344a641ad4c9@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: Tue, 16 Feb 2016 19:28:32 -0800 (PST) Lines: 567 Approved: news@gmane.org Message-ID: <586249ad-b4ae-4e40-bdf7-344a641ad4c9@isocpp.org> References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> <67c3c86d-3089-4f07-878a-3f3e706744df@isocpp.org> <42a29c5b-07e4-4e36-bab4-03a7e86ff905@isocpp.org> <6e02dbfe-01f3-4840-92ab-bcc8f7824348@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7760_750743506.1455679712664" X-Trace: ger.gmane.org 1455679721 32743 80.91.229.3 (17 Feb 2016 03:28:41 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 03:28:41 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBYWRR63AKGQEAZLHS3A@isocpp.org Wed Feb 17 04:28:36 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVsn5-0004t3-Sx for gclcip-std-proposals@m.gmane.org; Wed, 17 Feb 2016 04:28:36 +0100 Original-Received: by mail-ig0-f198.google.com with SMTP id rx16sf20940471igc.3 for ; Tue, 16 Feb 2016 19:28:35 -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=fOS1J2x3GBFLrQxceI40M5wVUS5urkJb1GJXTRLnBCo=; b=hwHZZEAZhfJQVXfQ6MZmzHePuht7r38M6UXuHuhJVpU0pLejkugFb8pNn3hnAfEjOl IUF2g3qbde5rxHjqSJBGXK4jKuGvSfg1hcGHR0WJ4e1OzT1XRqjA4jU7yeBoYBudFgRJ HOBpSpaj694TdFkrHMTO8lhtHgwbCpFFpKjbomLPkjSopzfLFJzyP+4weDEGE5bE9PkK ml9AiW2muhqeoeRVzGpOEAogXI6fo66TGqB0cgeiZ3VNxEzYg+UrnUTtJ2uBvl4aDzdO yUD8bUS1/kOpVAp2Wj94SCs2F6vaaXJN5OkkQy6zGDm6QJLTdcu7/sM2WXiJgNWX4HS8 7LJQ== 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=fOS1J2x3GBFLrQxceI40M5wVUS5urkJb1GJXTRLnBCo=; b=rzC+Eu11ESwbOhaUYFrdzEU6cXKaNST8dVo91E/DpCBytUVs3/yWl3rnElbAx8Y5oY WxZxcp0ysxu5S+uTXhf611schKqno1BNaoxI7cOxyYLKWklhdC8yLXDx/NDtna3Kp+fg nDnkOraxS/3o8RvhS67tfuBtN3Xzzyd3dyxcxaD8abXiVvxSjpStq8PCNWbqs6s9QZpy t2JiGcq0RFF+gMpFe+I6ygEf0wWbcO48DqVFXFMHMhotW6uTp3bNXbAI19YCjclwthmO h3Ao+fE5lYPmgzfI5OJJ/2W5lFLUCXYkQ7Lz9hYSLzq08eEP/nTuLkdqxd99/N0tcfQ8 GBww== 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=fOS1J2x3GBFLrQxceI40M5wVUS5urkJb1GJXTRLnBCo=; b=nHN9O4lsK6UheNPT/0kP4Dbpci01nMqOcbRRuTdy+ky1RwmxbtM3DQfLbxLH4w52ZQ 88oYckfHvK66RMHbaicATMdFLjmifZyWCgAXnOJx8vVsNH6TAvJPVAvWOsPTc47nifAg 6NovmAezGP33BraXZsa67/VmtlIwvXOsKwd4NF3hYaLga7WfjCQYyaNWQQg1cQvqLlLE 4VYqW+mzpxfC8frnUZqXe4VWwuZYPbr2mX4Jt+zlaQwvQdhZiLxwJ4aElS3jkNMdJw9H MX+9r9J5Hb13EuTmB48kK23zfdgY0PdXE5SPaSqBnmBIs24he/dvpkR3Ac2IJ4OI/afW E35Q== X-Gm-Message-State: AG10YOQmxtUwETShjq3ZxqKbQ3ErbxBz/6eZ9Hte2g/HsOCY1YM40OXj4puQmFzRfq9nEw== X-Received: by 10.107.157.9 with SMTP id g9mr833591ioe.26.1455679714904; Tue, 16 Feb 2016 19:28:34 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.47.25 with SMTP id j25ls1386034ioo.59.gmail; Tue, 16 Feb 2016 19:28:34 -0800 (PST) X-Received: by 10.50.66.236 with SMTP id i12mr5294igt.7.1455679714075; Tue, 16 Feb 2016 19:28:34 -0800 (PST) In-Reply-To: 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:24435 Archived-At: ------=_Part_7760_750743506.1455679712664 Content-Type: multipart/alternative; boundary="----=_Part_7761_1482735312.1455679712665" ------=_Part_7761_1482735312.1455679712665 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, February 16, 2016 at 6:57:59 PM UTC-5, Louis Dionne wrote: > > On Tuesday, 16 February 2016 18:19:00 UTC-5, Nicol Bolas wrote: >> >> On Tuesday, February 16, 2016 at 3:21:29 PM UTC-5, Louis Dionne wrote: >>> >>> or you could also write >>> >>> hana::unpack(tpl, [](auto ...x) { return outer(inner(x)...); }); >>> >> >> Whenever your library equivalent to a 1-liner language feature includes= =20 >> "introduce a Lambda", you have *lost* in terms of code=20 >> comprehensibility. On the other hand, it does fix (most) of the=20 >> functionality problems outlined above. >> > > You're drawing an arbitrary line without any argument for this. > .... yes. Code quality is always arbitrary. Some people claim that this is a= =20 good, easy-to-understand piece of code: char * strcpy(char *strDest, const char *strSrc) { assert(strDest!=3DNULL && strSrc!=3DNULL); char *temp =3D strDest; while(*strDest++ =3D *strSrc++); return temp; } Everyone has their own tastes. But... Concepts TS has 3 different and=20 increasingly brief syntaxes for declaring a constrained template for a=20 reason. In N3701, Stroustrup et. al. defended this by saying: > Do not confuse the familiar with the simple. The proposed syntax is=20 readable and parsable. We considered =E2=80=9Clouder=E2=80=9D, more verbose= notations, but=20 did not find them consistently better than what is described here. Brevity has value. Actually, > I tend to prefer writing things more explicitly like above than using > nested ... expansions when things get complex, for I think the different > rules for ... expansion can be confusing. > Welcome to the point of the whole idea. In this example, what we're trying to do is to call `inner` for each=20 element of the tuple, then pass the results as parameters to `outer`. To=20 you, this is something that "gets complex". The purpose of the language feature is so that it *isn't complex* anymore.= =20 By making it a language feature, we take something that was "complex" and= =20 make it simple. That's the point. Your library solution is much like `std::enable_if`. Yes, it gives you a=20 consistent tool for invoking SFINAE. But I *bet* you'd rather be using=20 Concepts. `enable_if` makes SFINAE doable, but it requires that you express your=20 condition in an unnatural way. Concepts makes SFINAE *trivial*. Same here:= =20 Hana makes tuple manipulation doable, but requires that you write your code= =20 in unnatural ways. The principle difference is that there's nothing `enable_if` can do that=20 concepts can't. Whereas there's a lot that Hana can do which tuple=20 expansion can't. But that alone doesn't mean that it isn't worth being a=20 language feature. Lambdas were supposed to obsolete std::bind too. Yet there are still some= =20 valid uses for it. But here's the #1 reason why the library solution is the wrong solution:=20 >> you *wrote it wrong*. You forgot to `std::forward` your arguments. And= =20 >> you forgot to use `decltype(auto)` for the return value. Both of which a= re=20 >> needed to be exactly equivalent to the above code. Without the=20 >> `decltype(auto)`, if `outer` returned a reference of some kind, it could= =20 >> provoke an unwanted copy. >> >> So it really needed to be: >> >> hana::unpack(tpl, [](auto ...x) -> decltype(auto) { return outer(inner( >> std::forward(x)...)); }); >> >> I fail to see how this could be considered anywhere nearly as easy to=20 >> understand. >> > > Fair enough. But if we're going to be pedantic, let's be pedantic for=20 > real. What you wanted > to write is > hana::unpack(tpl, [](auto&& ...x) -> decltype(auto) { return outer(inner( > std::forward(x))...); }); > > With this out of the way, I will argue that you actually don't need to=20 > write the above, except > in rare cases where the tuple is potentially a rvalue. Instead, in most= =20 > cases, you'd just > have to write > > hana::unpack(tpl, [](auto& ...x) -> decltype(auto) { return outer(inner(x > )...); }); > > which is slightly less verbose. > My point was not just that it was verbose. My point is that it is both=20 verbose *and* easy to get wrong, which we both demonstrated (though at=20 least my error would have shown up in the compiler ;) ). Basically, `unpack` is just `std::apply` but with the arguments reversed. >>> >>> >>> > Show me the Hana code for this: >>> > >>> > auto x =3D inner([:]tpl) + ...; >>> > >>> > This simply calls a function on each element of the tuple and takes= =20 >>> the sum >>> > of the results. Again, it works like parameter packs, so it reuses=20 >>> existing >>> > knowledge. >>> >>> You could write >>> >>> auto x =3D hana::fold_left(hana::transform(tpl, inner), std::plus<>= {}); >>> >> >> And for people who natively read right to left, this would probably be= =20 >> decent. But that's not how the rest of C++ works. >> > > Wtf? How is this different from writing=20 > > auto x =3D ranges::accumulate(ranges::transformed(...), std::plus<>{}); > > You will never catch me writing *that* either. or equivalently >>> >>> auto x =3D hana::fold_left(tpl, [](auto a, auto b) { >>> return a + inner(b); >>> }); >>> >> >> Again you forgot to forward the arguments and return values properly. No= t=20 >> to mention, you turn a simple one-liner into a multi-line statement. >> > > Same argument as above. And the fact that I broke the statements into=20 > multiple > lines to make it more readable is a feature. Honestly, I think this (and= =20 > especially > the transform/fold_left variant) is more readable than the variant with= =20 > ... expansions. > Of course, your version is more terse, but too terse is not good either. > It's not really that it's terse; that's not what attracts me to tuple=20 expansion. What matters most to me is that the code looks as much like=20 normal code ought to look. This is also what repels me from your ranges example. Most programmers know what `outer(inner(value))` does. They can understand= =20 that by inspection, and its meaning is clear. Most programmers understand= =20 what `inner(value) + inner(value2)` means. Hana code is not obvious, not to someone who isn't familiar with template= =20 metaprogramming and such techniques. While an unsuspecting programmer may not understand exactly what the `...`= =20 and `[:]` parts mean, they can still look at `outer(inner([:]value)...)`=20 and see that `inner` will be called, followed by `outer`. It carries the=20 same physical structure and code layout of the simple and obvious case. It= =20 may be more complex under the hood, but the user is not exposed to it. When looking at `hana::on(inner, outer)`, they have absolutely no idea what= =20 that means. Not without looking up the docs. There is no intuitive grasp of= =20 what's going on. So the value is more than "just" terseness. The value is that the code's=20 structure remains intact. You're not exchanging a call to `+` with=20 `std::plus<>`. You're not altering the overall order and nature of the code= .. Let's stop arguing over petty details. You want to hear it? Of course your= =20 > solution > is better for those use cases, because it was designed with those in mind= ! > But it is also much more limited, and the point I'm trying to make is tha= t=20 > from > the point of view of a metaprogramming library writer, this proposal, in= =20 > its > current form, misses the goal just like fold expressions did. > And my overall point is that what you want was *never* the goal to begin=20 with. You are denigrating a proposal for not solving a problem that it was= =20 never intended to solve. The problem it is solving is making tuples work=20 like parameter pack expansion, so as to be able to more effectively access= =20 data out of tuples in useful ways. Arbitrary tuple transformations was never the goal. That's a legitimate and= =20 useful problem domain. But that's not what this is intended to handle. The= =20 fact that this syntax can indeed handle some of that via clever usage of=20 the syntax is merely a fortunate coincidence. C++11 already has a construct that is tuple-like in its nature: parameter= =20 packs. We're just expanding it to work with actual tuples. --=20 ---=20 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 e= mail 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-propos= als/. ------=_Part_7761_1482735312.1455679712665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, February 16, 2016 at 6:57:59 PM UTC-5, Louis D= ionne wrote:
O= n Tuesday, 16 February 2016 18:19:00 UTC-5, Nicol Bolas wrote:
On Tuesday, February 16, 2016 = at 3:21:29 PM UTC-5, Louis Dionne wrote:
or you could also write

=C2=A0 =C2=A0 hana::unpack(tpl, [](auto ...x) { return outer(inner(= x)...); });

Whenever your library equivale= nt to a 1-liner language feature includes "introduce a Lambda", y= ou have lost in terms of code comprehensibility. On the other hand, = it does fix (most) of the functionality problems outlined above.
<= /div>

You're drawing an arbitrary line = without any argument for this.

... yes. Co= de quality is always arbitrary. Some people claim that this is a good, easy= -to-understand piece of code:

char * strcpy(<= /span>char= *strDest, const char = *strSrc)
{
=C2=A0 =C2=A0 assert(strDest!=3DNULL && strSrc!=3DNULL);
=C2=A0 = =C2=A0 cha= r <= span style=3D"color: #660;" class=3D"styled-by-prettify">*temp =3D strDest;
=C2=A0 =C2=A0 while(*strDest++ = =3D *strSrc++);
=C2=A0 =C2=A0 return temp;
}

Everyone has their own = tastes. But... Concepts TS has 3 different and increasingly brief syntaxes = for declaring a constrained template for a reason. In N3701, Stroustrup et.= al. defended this by saying:

> Do not confuse the familiar with = the simple. The proposed syntax is readable and parsable. We considered =E2= =80=9Clouder=E2=80=9D, more verbose notations, but did not find them consis= tently better than what is described here.

Brevity has value.
A= ctually,
I tend to prefer writing things more explicitly like abo= ve than using
nested ... expansions when things get complex, for = I think the different
rules for ... expansion can be confusing.

Welcome to the point of the whole idea.
=
In this example, what we're trying to do is to call `inner` for eac= h element of the tuple, then pass the results as parameters to `outer`. To = you, this is something that "gets complex".

The purpose of= the language feature is so that it isn't complex anymore. By ma= king it a language feature, we take something that was "complex" = and make it simple. That's the point.

Your library solution is m= uch like `std::enable_if`. Yes, it gives you a consistent tool for invoking= SFINAE. But I bet you'd rather be using Concepts.

`enabl= e_if` makes SFINAE doable, but it requires that you express your condition = in an unnatural way. Concepts makes SFINAE trivial. Same here: Hana = makes tuple manipulation doable, but requires that you write your code in u= nnatural ways.

The principle difference is that there's nothing = `enable_if` can do that concepts can't. Whereas there's a lot that = Hana can do which tuple expansion can't. But that alone doesn't mea= n that it isn't worth being a language feature.

Lambdas were sup= posed to obsolete std::bind too. Yet there are still some valid uses for it= ..

But here= 9;s the #1 reason why the library solution is the wrong solution: you wr= ote it wrong. You forgot to `std::forward` your arguments. And you forg= ot to use `decltype(auto)` for the return value. Both of which are needed t= o be exactly equivalent to the above code. Without the `decltype(auto)`, if= `outer` returned a reference of some kind, it could provoke an unwanted co= py.

So it really needed to be:

hana::unpack<= /span>(tpl, [](auto ...x) -> decltype(auto) { return outer(inner(std::forward<decltype(auto)>(x)...)); });

I fail to see how this c= ould be considered anywhere nearly as easy to understand.

Fair enough. But if we're going to be pe= dantic, let's be pedantic for real. What you wanted
to write = is
hana::unpack(tpl, [](au= to&& ...x) -> decltype(auto) { return outer(inner(std::forward<decltype<= span style=3D"color:#660">(x)>(x))...); });

With this out of the way, I will argue that you actually don't need = to write the above, except
in rare cases where the tuple is poten= tially a rvalue. Instead, in most cases, you'd just
have to w= rite

hana::unpack(tpl, [](auto& ...x)<= /span> -> decltype= (auto) = { return outer= (inner<= span style=3D"color:#660">(x)...); });

whi= ch is slightly less verbose.

My poin= t was not just that it was verbose. My point is that it is both verbose = and easy to get wrong, which we both demonstrated (though at least my e= rror would have shown up in the compiler ;) ).

Basically, `unp= ack` is just `std::apply` but with the arguments reversed.


> Show me the Hana code for this:
>=
> auto x =3D inner([:]tpl) + ...;
>
&g= t; 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.

You = could write

=C2=A0 =C2=A0 auto x =3D hana::fold_le= ft(hana::transform(tpl, inner), std::plus<>{});

And for people who natively read right to left, this would= probably be decent. But that's not how the rest of C++ works.

Wtf? How is this different from wri= ting=C2=A0

auto x =3D ranges::accumulate(ranges::transformed(...), std::plus<>{});

=

You will never catch me writing = that either.

=
or equivalently

=C2=A0 =C2=A0 auto x =3D hana::fold_left(tpl, [](auto a, auto b) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 return a + inner(b);
=C2=A0 = =C2=A0 });

Again you forgot to forward the= arguments and return values properly. Not to mention, you turn a simple on= e-liner into a multi-line statement.

<= /div>
Same argument as above. And the fact that I broke the statements = into multiple
lines to make it more readable is a feature. Honest= ly, I think this (and especially
the transform/fold_left variant)= is more readable than the variant with ... expansions.
Of course= , your version is more terse, but too terse is not good either.
=

It's not really that it's terse; that's n= ot what attracts me to tuple expansion. What matters most to me is that the= code looks as much like normal code ought to look.

This is also wha= t repels me from your ranges example.

Most programmers know what `ou= ter(inner(value))` does. They can understand that by inspection, and its me= aning is clear. Most programmers understand what `inner(value) + inner(valu= e2)` means.

Hana code is not obvious, not to someone who isn't f= amiliar with template metaprogramming and such techniques.

While an = unsuspecting programmer may not understand exactly what the `...` and `[:]`= parts mean, they can still look at `outer(inner([:]value)...)` and see tha= t `inner` will be called, followed by `outer`. It carries the same physical= structure and code layout of the simple and obvious case. It may be more c= omplex under the hood, but the user is not exposed to it.

When looki= ng at `hana::on(inner, outer)`, they have absolutely no idea what that mean= s. Not without looking up the docs. There is no intuitive grasp of what'= ;s going on.

So the value is more than "just" terseness. T= he value is that the code's structure remains intact. You're not ex= changing a call to `+` with `std::plus<>`. You're not altering th= e overall order and nature of the code.

Let's stop argu= ing over petty details. You want to hear it? Of course your solution
<= div>is better for those use cases, because it was designed with those in mi= nd!
But it is also much more limited, and the point I'm tryin= g to make is that from
the point of view of a metaprogramming lib= rary writer, this proposal, in its
current form, misses the goal = just like fold expressions did.

And my ove= rall point is that what you want was never the goal to begin with. Y= ou are denigrating a proposal for not solving a problem that it was never i= ntended to solve. The problem it is solving is making tuples work like para= meter pack expansion, so as to be able to more effectively access data out = of tuples in useful ways.

Arbitrary tuple transformations was never = the goal. That's a legitimate and useful problem domain. But that's= not what this is intended to handle. The fact that this syntax can indeed = handle some of that via clever usage of the syntax is merely a fortunate co= incidence.

C++11 already has a construct that is tuple-like in its n= ature: parameter packs. We're just expanding it to work with actual tup= les.

--

---
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_7761_1482735312.1455679712665-- ------=_Part_7760_750743506.1455679712664-- .