220 24344 <56BEF226.2030700@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: [tuple] extracting tuples out of a tuple Date: Sat, 13 Feb 2016 10:06:46 +0100 Lines: 933 Approved: news@gmane.org Message-ID: <56BEF226.2030700@wanadoo.fr> References: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------090706040204090900080905" X-Trace: ger.gmane.org 1455354418 8036 80.91.229.3 (13 Feb 2016 09:06:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 13 Feb 2016 09:06:58 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBKPE7O2QKGQE5BNXSJQ@isocpp.org Sat Feb 13 10:06:51 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f71.google.com ([74.125.82.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aUWAE-0007iw-CO for gclcip-std-proposals@m.gmane.org; Sat, 13 Feb 2016 10:06:50 +0100 Original-Received: by mail-wm0-f71.google.com with SMTP id g62sf16236816wme.1 for ; Sat, 13 Feb 2016 01:06:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type: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=DIiqf+1xR6DGjaZ9/WZz3+NcQS61fffh1s3PcOzlK5c=; b=tC1mvaXPIAmCYv2RSi3XRLIRoF1bFvCR3ZYLrbCz+BV8xAKo4WpjJxykFro7vPRTZO jZFzTM8ZB6hz9fMK9e+JSZo3oQXF79JgYjChBOYntSVgwG9KddGkHETMZgwmgdgXlIvu s2fSghRxKJrDFdeq23XogxXOQtx6Sraan54gqI5qcRw6qC1Nt8AVIG8+BuQoRI5EDXWs knmxSzkk7iuBum6PbLSwyOfY4WROWBE9SrO7rJjMy8jYwx/EVrXksszlrOzMAJJdIOui kNzlph00eRXy+ZozQTRZd4IDS0WJegnsOsVM2r0RInlvZ/XQebtZbbwHIgXoYZZPUIMC eizA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type: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=DIiqf+1xR6DGjaZ9/WZz3+NcQS61fffh1s3PcOzlK5c=; b=cak9YjjXTHzgx8b3F2scZbR8SCjVQ0y+PnxCfbVfvAfp8bCpFNZ30zcTiaXrapeYHx 0TC9zBgTWJKKX/ZqIw/GMazDvuXNNe+2wcc6gAL7gaTQz9nz73u3NtCYieWDqAwEpk4+ 2cQGZ0OAxn7AwxPekxwteFjTDyXN40IYux9ZOsPbCZb/1cVE2s8zYZ/+10jFxOUU6q9s ss4jU0jCZspqm1yXaflZcqMVWRCQJBRp6nfBNmFKTGhTaNDtwaN3KUYxN8Oql9rp6SWW wBzcobf4JfvpjnfBWKV+zwJjnnCeZYJXmFM5GQluRdgYwDxQYsbCfYIER/TBy/FouBKm /s X-Gm-Message-State: AG10YOSBC3agOAzTyI4iGgJxNhs2Be6yYDCSjdebosV9x75NMR73n6Vc2W6X+7/SrAihQw== X-Received: by 10.194.24.233 with SMTP id x9mr541793wjf.0.1455354409828; Sat, 13 Feb 2016 01:06:49 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.3.67 with SMTP id 64ls255179wmd.28.canary; Sat, 13 Feb 2016 01:06:48 -0800 (PST) X-Received: by 10.28.14.4 with SMTP id 4mr2329805wmo.100.1455354408514; Sat, 13 Feb 2016 01:06:48 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr. [80.12.242.123]) by mx.google.com with ESMTPS id n123si9840122wmb.41.2016.02.13.01.06.48 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 13 Feb 2016 01:06:48 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.123; Original-Received: from new-host.home ([86.214.221.89]) by mwinf5d36 with ME id Hl6n1s0081wL8VA03l6nmq; Sat, 13 Feb 2016 10:06:48 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Sat, 13 Feb 2016 10:06:48 +0100 X-ME-IP: 86.214.221.89 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 In-Reply-To: <7e08b6c5-853c-471e-b248-a9df7e8e27be@isocpp.org> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.123 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr 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:24344 Archived-At: This is a multi-part message in MIME format. --------------090706040204090900080905 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 13/02/2016 01:28, Arthur O'Dwyer a =C3=A9crit : > On Friday, February 12, 2016 at 9:11:35 AM UTC-8, Matthew Woehlke wrote: > > On 2016-02-12 11:30, Oliver Kowalke wrote: > > 2016-02-12 16:06 GMT+01:00 Matthew Woehlke >: > >> I'm not a fan of using magical references to do indirect > assignment, > >> i.e. any of your proposals, but especially `split`. All of > these seem > >> backwards, i.e. should be `tpl1 =3D head<3>(tpl);` instead. > > > > I've had std::tie() in mind, > > > > int i...; > > X x...; > > std::tie( i, x) =3D get_tuple(); > > That's also a horribly ugly interface that we shouldn't be > perpetuating; > http://wg21.link/p0144 solves that exact example ever so much > better... > > > I think maybe Oliver was trying to say that > > | > tupletpl {-1,"abc","xyz",.5}; > tupletpl1; > tpl1 =3Dtail(tpl);// Python: tpl1 =3D tpl[1:] > tail(tpl)=3Dtpl1;// Python: tpl[1:] =3D tpl1 > | > > > should both work, because tail() should return a tuple of references=20 > instead of a tuple of values. I definitely support=20 > not-making-unnecessary-copies in general, and particularly in this=20 > case if it lets tail() work like tie(). But it does seem a little bit=20 > non-orthogonal. (Also, I'm assuming that Oliver made some typos in=20 > his original post =E2=80=94 notice I've flipped the "tpl" and "tpl1" in t= he=20 > second line above.) > I don't think Oliver made some typos, but it is up to him to confirm.=20 Anyway the name was not good. std::tuple< int, std::string, std::string, double > tpl{ -1, "abc",=20 "xyz", .5 }; std::tuple< int, std::string, std::string > tpl1; std::tuple< std::string, double > tpl2; head( tpl1) =3D tpl; tail( tpl2) =3D tpl; split( tpl1, tpl2) =3D tpl; head(tpl1) returns a reference to tuple that accepts assignment form=20 tuples having the same types from the front and tail(tpl2) do the opposite, returns a reference to tuple that accepts=20 assignments form tuples having the same types from the back. head->tie_tuple_at_front tail->tie_tuple_at_back It could also be a tie_tuple_at_middle that accepts assignment form=20 tuples having the same types from a unspecified position. My names are not good neither. I believe that his split pretended to be a equivalent to his head( tpl1) =3D tpl; tail( tpl2) =3D tpl; but I don't see the added value. Whether it is worth having this in the standard and looking for a good=20 names is another question. > Also, of course, head(x) should logically return get<0>(x), not some=20 > weird synonym for reverse(tail(reverse(x))). But that's just poor=20 > naming. The underlying operation here is either "splice" (extract a=20 > contiguous range of indices from the input tuple, as in the Python=20 > above) or "select" (extract a noncontiguous set of indices from the=20 > input tuple and compress them, as in various vector instruction sets). I'm not saying that a splice function on tuples is not useful, but IMHO=20 Oliver idea was to determine the splice to do depending on the target=20 tuple not on the source tuple. > > I agree that > > | > std::tupletpl{-1,"abc","xyz",.5}; > std::tupletpl1; > std::tupletpl2; > split(tpl1,tpl2)=3Dtpl; > | > > is just nonsense, as written. See above. > However, under the "unpacking with postfix tilde" not-a-proposal, a=20 > similar operation could be written like this: > > | > tupletpl {-1,"abc","xyz",.5}; > tupletpl1; > tupletpl2; > > std::tie(tpl1~...,tpl2~...)=3Dtpl; > > assert(std::get<0>(tpl1)=3D=3Dstd::get<0>(tpl)); > assert(std::get<1>(tpl1)=3D=3Dstd::get<1>(tpl)); > assert(std::get<0>(tpl2)=3D=3Dstd::get<2>(tpl)); > assert(std::get<1>(tpl2)=3D=3Dstd::get<3>(tpl)); > | > > In general, I think that the C++ standard library is woefully lacking=20 > in tuple manipulators... but rather than proposing new tuple=20 > manipulators (of which there could be a million: zip, fold, map, car,=20 > cdr, reverse,...), we should be trying to give people the ability to=20 > express those manipulators natively in the language, via something=20 > like Matthew's [:] notation or my ~... notation. > > Just wondering how could help the no-yet-proposed operators [:], ~,=20 and ... to implement what I interpreted. Vicente --=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/. --------------090706040204090900080905 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 13/02/2016 01:28, Arthur O'Dwyer a =C3=A9crit=C2=A0:
On Friday, February 12, 2016 at 9:11:35 AM UTC-8, Matthew Woehlke wrote:
On 2016-02-12 11:30, Oliver Kowalke wrote:
> 2016-02-12 16:06 GMT+01:00 Matthew Woehlke <mwoehlk...@g= mail.com>:
>> I'm not a fan of using magical references to do indirect assignment,
>> i.e. any of your proposals, but especially `split`. All of these seem
>> backwards, i.e. should be `tpl1 =3D head<3>(tpl);` instead.
>
> I've had std::tie() in mind,
>
> int i...;
> X x...;
> std::tie( i, x) =3D get_tuple();

That's also a horribly ugly interface that we shouldn't be perpetuating;
http://wg21.link/p0144 solves that exact example ever so much better...

I think maybe Oliver was trying to say that

=C2=A0 =C2=A0 tuple<int, string<= /span>, string<= /span>, double<= /span>> tpl { -1, "abc", "xyz", .5 };
=C2=A0 =C2=A0 tuple<string<= /span>, string<= /span>, double<= /span>> tpl1;
=C2=A0 =C2=A0 tpl1 =3D tail(tpl); =C2=A0= =C2=A0// Python: tpl1 =3D tpl[1:]
=C2=A0 =C2=A0 tail(tpl) =3D tpl1; =C2=A0= =C2=A0// Python: tpl[1:] =3D tpl1


should both work, because tail() should return a tuple of references instead of a tuple of values. I definitely support not-making-unnecessary-copies in general, and particularly in this case if it lets tail() work like tie(). But it does seem a little bit non-orthogonal. =C2=A0(Also, I'm assuming that Olive= r made some typos in his original post =E2=80=94 notice I've flippe= d the "tpl" and "tpl1" in the second line above.)

I don't think Oliver made some typos, but it is up to him to confirm. Anyway the name was not good.

std::tuple< int, std::string, std::string, double > tpl{ -1, "abc", "xyz", .5 = };
std::tuple< int, std::string, std::string > tpl1;
std::tuple< std::string, double > tpl2;

head( tpl1) =3D tpl;
tail( tpl2) =3D tpl;
split( tpl1, tpl2) =3D tpl;

head(tpl1) returns a reference to tuple that accepts assignment form tuples having the same types from the front and
tail(tpl2) do the opposite, returns a reference to tuple that accepts assignments form tuples having the same types from the back.
head->tie_tuple_at_front
tail->tie_tuple_at_back

It could also be a tie_tuple_at_middle that accepts assignment form tuples having the same types from a unspecified position.

My names are not good neither.

I believe that his split pretended to be a equivalent to his

head( tpl1) =3D tpl;
tail( tpl2) =3D tpl;

but I don't see the added value.

Whether it is worth having this in the standard and looking for a good names is another question.



Also, of course, head(x) should logically return get<0>(x), not some weird synonym for reverse(tail(reverse(x))). But that's just poor naming. The underlying operation here is either "splice" (extract a contiguous range of indices from the input tuple, as in the Python above) or "select" (extract a noncontiguous set of indices from the input tuple and compress them, as in various vector instruction sets).
I'm not saying that a splice function on tuples is not useful, but IMHO Oliver idea was to determine the splice to do depending on the target tuple not on the source tuple.


I agree that

=C2=A0 =C2=A0 std::tuple< int, std::string<= /span>, std::string<= /span>, double<= /span> > tpl{ -1, "abc", "xyz", .5 };
=C2=A0 =C2=A0 std::tuple< int, std::string<= /span>, std::string<= /span> > tpl1;
=C2=A0 =C2=A0 std::tuple< std::string<= /span>, double<= /span> > tpl2;
=C2=A0 =C2=A0 split( tpl1, tpl2) =3D tpl;

is just nonsense, as written.
See above.
However, under the "unpacking with postfix tilde" not-a-proposal, a similar operation could be written like this:

=C2=A0 =C2=A0 tuple<int, string<= /span>, string<= /span>, double<= /span>> tpl { -1, "abc", "xyz", .5 };
=C2=A0 =C2=A0 tuple<int, string<= /span>> tpl1;
=C2=A0 =C2=A0 tuple<string<= /span>, double<= /span>> tpl2;

=C2=A0 =C2=A0 std::tie(tpl1~..., tpl2~...) =3D tpl;

=C2=A0 =C2=A0 assert(std::get<0>(tpl1) =3D=3D<= /span> std::get<0>(tpl));
=C2=A0 =C2=A0 assert(std::get<1>(tpl1) =3D=3D<= /span> std::get<1>(tpl));
=C2=A0 =C2=A0 assert(std::get<0>(tpl2) =3D=3D<= /span> std::get<2>(tpl));
=C2=A0 =C2=A0 assert(std::get<1>(tpl2) =3D=3D<= /span> std::get<3>(tpl));

In general, I think that the C++ standard library is woefully lacking in tuple manipulators... but rather than proposing new tuple manipulators (of which there could be a million: zip, fold, map, car, cdr, reverse,...), we should be trying to give people the ability to express those manipulators natively in the language, via something like Matthew's [:] notation or my ~... notation.


Just wondering how could help the no-yet-proposed operators=C2=A0 [:], = ~, and=C2=A0 ... to implement what I interpreted.

Vicente

--

---
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= /.
--------------090706040204090900080905-- .