220 24459 <6e35f24a-f728-4ac2-b329-1894206f59cc@isocpp.org> article Path: news.gmane.org!not-for-mail From: Miro Knejp Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [tuple] extracting tuples out of a tuple Date: Wed, 17 Feb 2016 13:30:28 -0800 (PST) Lines: 181 Approved: news@gmane.org Message-ID: <6e35f24a-f728-4ac2-b329-1894206f59cc@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_901_1882132413.1455744628399" X-Trace: ger.gmane.org 1455744633 23121 80.91.229.3 (17 Feb 2016 21:30:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 17 Feb 2016 21:30:33 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBC6ONSXJ54LBB5OMSO3AKGQEH3EZNSI@isocpp.org Wed Feb 17 22:30:33 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 1aW9g7-0006uO-ON for gclcip-std-proposals@m.gmane.org; Wed, 17 Feb 2016 22:30:32 +0100 Original-Received: by mail-io0-f197.google.com with SMTP id t64sf79852043ioe.0 for ; Wed, 17 Feb 2016 13:30:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to: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=EuLLqoLR++GSBsPTM+8dsnyU0jfpdQhWRZOpOEJRJRk=; b=CtBMghinLD8VC1+yAYaOijY1f7oshi4zB90125Q5e6TlIyixRSRxiWG+lPa13LZaqD 5rcqXBoPOROA+l8SM9B1pXuNcavFUJCUVd3wpj++a0dj738gVnO0/2fp7tXv9Bn4KYUR s3BxWmh72gGj1i9+zZ+yZll6mLUUvn5RzWZJo/VCO4ExPvUk8XuBPYiDTJoXWoiBmyIU mTYMlpQNnuZ51/sxZ1bhcmvf6s4HfBsJmsKv6VuismJncHqVqm/RUU/vKbXUEinO1Ds0 gjSuwplPS7RnXzfGeG2byS7llny32L6vFqKszIqmMmEuSQmank/3V4NCoY/aDYBrOJxv VRLg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=EuLLqoLR++GSBsPTM+8dsnyU0jfpdQhWRZOpOEJRJRk=; b=jwqpnpJbx4YdFfclJ5ZAWqJD9T3DCHlpsPLi399TJgPVCj1HZBrme377Il2BuBXNum HHbbUVts9IPfOcUfTocQmRdFz6XSscUFVPUbpRgeM0an1hEgwycHahREfvoWRd2rTDK7 zlSrRsEUDPvT9Lo3AK/Tf0D6OSieNskBaaAGhIEExM5f7EgRI9pad6A5ELkU37xs36uG TvvkdoZNaKI0jwVWpBwV78uCYvXWRWg4IfHAprt1bkdoM9P4U/KqimYrEj/jIFExnowQ mqSyY3/rvY13rGVXJoM4Cb+Nf+9OvsRBLTebFcU4ROm9Rcx5gUrG8XH+aVgyxVY8QiAz 6qoA== 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: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=EuLLqoLR++GSBsPTM+8dsnyU0jfpdQhWRZOpOEJRJRk=; b=AZC05E5cGI2pCbhrc26d7GG7K2u7oWlwKyfxs38a4/2X6oXL+CTzv5728AgaEHBttX sBOsB8BXmAZe6VrFvMKCnaCt6VQEn1il5eKe9s+2xF59kCydxoK7CmUcAOo/YXqTcv0Y ve5Ra08IZeDibDn+pr4D/PCUiL47Ce6shm1aDOQZ1QLWC6vpbsGo7LIH72uEuh2S7BaP xtfjddGd/9y8YbAaG14G34/4cX7g2D4XWPNO9ZXvge2lSM0OpbEcX49hWIY8xr1/3ab/ /IADCzREBEWvlVYrW0RMCdtbOezLB55+EJLSkSIZJS/pGNWuse7OBO4oF+iODFd2ER9u baOQ== X-Gm-Message-State: AG10YOT25XngPLRso5RjJzoJA1IIiMBbMhFf2OdyyOxydgix7woYK5JdVEn96i6QXgygUg== X-Received: by 10.50.13.101 with SMTP id g5mr25548486igc.6.1455744630493; Wed, 17 Feb 2016 13:30:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.35.213 with SMTP id j204ls2188998ioj.42.gmail; Wed, 17 Feb 2016 13:30:29 -0800 (PST) X-Received: by 10.50.79.136 with SMTP id j8mr148925igx.6.1455744629495; Wed, 17 Feb 2016 13:30:29 -0800 (PST) In-Reply-To: X-Original-Sender: miro.knejp@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:24459 Archived-At: ------=_Part_901_1882132413.1455744628399 Content-Type: multipart/alternative; boundary="----=_Part_902_332764873.1455744628400" ------=_Part_902_332764873.1455744628400 Content-Type: text/plain; charset=UTF-8 I somehow can't shed the feeling that what we really need here is support for multiple return values. Just imagine for a moment that the following is valid: int, float, double foo(); void bar(int, float, double); bar(foo()); auto {a, b, c} = foo(); // borrowed from P0144R1 having this ability makes writing tuple unpacking trivial auto tpl = make_tuple(1, 2.f, 3.0); bar(unpack(tpl)); bar(unpack<2, 1, 0>(tpl)); template auto... unpack(tuple x) { return unpack_impl<0>(x, index_sequence_for()); } template auto... unpack(tuple x) { return unpack_impl<0>(x, make_index_sequence()); } template auto... unpack_range(tuple x) { return unpack_impl(x, make_index_sequence); } template auto... unpack_impl(tuple x, index_sequence()) { return get(x)...; } (and yes, I did omit stuff like rvalue-refs, forward() etc. as they are only distracting and I am sure everyone here can fill in the details themselves) I feel like this opens up the doors to many more possibilities than just the unpacking syntax alone as discussed in this thread. The syntax may not be as terse, but to me "unpack(x)" feels easier to understand and teach than "[:]x". One might consider changing "unpack_range(x)" into "unpack>(x)", making "unpack" even more potent as a commonly understood tool (and allows things like unpack, 4>(x) getting the indices 0, 1, 4). Other examples: template auto tail(tpl x) { return make_tuple(unpack_range<1, sizeof...(Ts)>(x)); } template auto... split(tpl x) { return make_tuple(unpack>(x)), make_tuple(unpack>(x)); } Given the proper handling of lvalue-refs, rvalue-refs, reference_wrapper etc, this should also make the example tail(ref(tpl1)) = tpl2 work. I know multiple return values come with their own set of problems and since this thread isn't about multiple return values I am not going to address them here. I guess it comes down to which of the two is more general purpose and/or has the lesser impact on the language. I just felt like mentioning this and maybe get more support for multiple return values if people are interested as the rest emerges naturally from it and the topic of multiple return values resurfaces regularly. -- --- 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_902_332764873.1455744628400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I somehow can't shed the feeling that what we really n= eed here is support for multiple return values.

Just ima= gine for a moment that the following is valid:
int, float, double = foo();
void bar(int, float, double);
bar(foo());
auto {a, b, c} =3D foo(); // borrowed from P0144R1

having this ability makes writing tuple unpacking trivial
auto tpl =3D make_tuple(1, 2.f, 3.0);
bar(unpack(tpl));
bar(unpack&= lt;2, 1, 0>(tpl));

template<class... Ts>
auto... unpack(tuple<Ts...> x)
= {
return unpack_impl<0>(x, index_sequence_= for<Ts...>());
}
template<size_t... Is, class... Ts>
auto... unpack(tuple<Ts...> x)
{
return unpack_impl<0>(= x, make_index_sequence<Is...>());
= }
template<size_t From, size_t To, cl= ass... Ts>
auto... unpack_range(tuple= <Ts...> x)
{
return unpack_impl<From>(x, make_index_sequence<To - From>)= ;
}
t= emplate<size_t Offset, class... Ts, size_t... Is>
auto... unpack_impl(tuple<Ts...> x, index_sequence<= ;Is...>())
{
return get<Is + Offset>(x)...;
}<= /div>
(and yes, I did omit stuff like rvalue-refs, = forward() etc. as they are only distracting and I am sure everyone here can= fill in the details themselves)

I feel like this opens u= p the doors to many more possibilities than just the unpacking syntax alone= as discussed in this thread. The syntax may not be as terse, but to me &qu= ot;unpack(x)" feels easier to understand and teach than "[:]x&quo= t;. One might consider changing "unpack_range<a, b>(x)" int= o "unpack<range<a, b>>(x)", making "unpack"= even more potent as a commonly understood tool (and allows things like unp= ack<range<0, 2>, 4>(x) getting the indices 0, 1, 4).
=
Other examples:
template<class Ts...>
=
auto tail(tpl<Ts...> x)
{
return make_tuple(unpack_ran= ge<1, sizeof...(Ts)>(x));
}
<= div class=3D"subprettyprint">template<size_t Index, class Ts...>
auto... split(tpl<Ts...> x)
{
return make_tuple(unp= ack<range<0, Index>>(x)), make_tuple(unpack<range<Index, = sizeof...(Ts)>>(x));
}
=
Given the proper handling of lvalue-refs, rvalue-refs, re= ference_wrapper etc, this should also make the example tail(ref(tpl1)) =3D = tpl2 work.

I know multiple return values come with = their own set of problems and since this thread isn't about multiple re= turn values I am not going to address them here. I guess it comes down to w= hich of the two is more general purpose and/or has the lesser impact on the= language. I just felt like mentioning this and maybe get more support for = multiple return values if people are interested as the rest emerges natural= ly from it and the topic of multiple return values resurfaces regularly.

--

---
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_902_332764873.1455744628400-- ------=_Part_901_1882132413.1455744628399-- .