220 24471 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [tuple] extracting tuples out of a tuple Date: Thu, 18 Feb 2016 11:18:53 -0500 Lines: 129 Approved: news@gmane.org Message-ID: References: <6e35f24a-f728-4ac2-b329-1894206f59cc@isocpp.org> <56C5048D.5020304@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1455812358 7732 80.91.229.3 (18 Feb 2016 16:19:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 16:19:18 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBB6W5S63AKGQE2W6D3VY@isocpp.org Thu Feb 18 17:19:09 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lb0-f197.google.com ([209.85.217.197]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aWRIL-0000uo-8W for gclcip-std-proposals@m.gmane.org; Thu, 18 Feb 2016 17:19:09 +0100 Original-Received: by mail-lb0-f197.google.com with SMTP id p10sf20169922lbo.0 for ; Thu, 18 Feb 2016 08:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=to:from:subject:date:lines:message-id:references:mime-version :content-transfer-encoding:user-agent:in-reply-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=at2CdIu01U8GHqiVleB0/EUhy2o5IFaz652pAfkOm6c=; b=JiKS0A+awzBaD2mhTiW6C/6JLuGNPPXMvuDvDJRREHdAhQC9sagETETzkleo7Kqcun un8+EIu/X8tm8cxMqeLy7gkL9F47HY3uZdo/cvM/OPqvKHtcrgJxSTBy9ZggHPIjd/FY k/HA7BnkYwTPlLDS50GthMaVw6ESKHjAoocEidKl2SgkGOjn9KUWxGJgxnMKKb6Dyvgw s6dLqydgDsTlZqIbL9FLINepDdSEx6oMlBpz4lr9lESqMdxtwNi4qlMHyHr6FVHQeEed v1bNPowDHqU1kR0lmImDEn0SBANxVo3XTWLLCXwN/x8HJPTdIZ+K5s/SjH/Ox10SEbbG X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:to:from:subject:date:lines:message-id:references :mime-version:content-transfer-encoding:user-agent:in-reply-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=at2CdIu01U8GHqiVleB0/EUhy2o5IFaz652pAfkOm6c=; b=lB1hQ1FT5gPRjvkoAi+VQXfCdybBOB5H2ZE4lKSYc035Lv+LZTnYBDd9LMbv9Lnjcg oNWfAheFPxaJj0bQ82Hl12NZAcsSh9EHrOL8ZqTXsLdKJEoWF1Qk0HAOquLXNzdTa4Lk 0ExGU3uWVlfOEY827YeVfGJlO9NRoGE0PECy6/kRH5M1BaqSci4H9IqblYlqbzSO/9/g NYuZi3CH0/Ika0de3nQYR3uP+lgV8ubcNfCnmruDtxd8LPcJirOhAs062nyYL4qfBto4 IL3OCozmbRRuL/cA5TioHySWzZ132Xv6WrN9DePcxbV6mUc61Vor9zXexdYuN7Ee X-Gm-Message-State: AG10YOT/B5yUwgiCUdpUcrEVz12dz1TIqxNq7IiI0IfhdSK2kTY9Pwot6kRonlK8F/2k+w== X-Received: by 10.28.172.194 with SMTP id v185mr559159wme.5.1455812348704; Thu, 18 Feb 2016 08:19:08 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.156.81 with SMTP id f78ls1132595lfe.9.gmail; Thu, 18 Feb 2016 08:19:05 -0800 (PST) X-Received: by 10.25.167.18 with SMTP id q18mr3038863lfe.27.1455812345579; Thu, 18 Feb 2016 08:19:05 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id rr3si4357348lbb.49.2016.02.18.08.19.05 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 18 Feb 2016 08:19:05 -0800 (PST) Received-SPF: pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) client-ip=80.91.229.3; Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1aWRIF-0000sA-IX for std-proposals@isocpp.org; Thu, 18 Feb 2016 17:19:03 +0100 Original-Received: from tripoint.kitware.com ([66.194.253.20]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Feb 2016 17:19:03 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 18 Feb 2016 17:19:03 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 115 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: tripoint.kitware.com User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 In-Reply-To: <56C5048D.5020304@gmail.com> X-Original-Sender: mwoehlke.floss@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gclcip-std-proposals@m.gmane.org designates 80.91.229.3 as permitted sender) smtp.mailfrom=gclcip-std-proposals@m.gmane.org; dmarc=fail (p=NONE dis=NONE) header.from=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:24471 Archived-At: On 2016-02-17 18:38, Miro Knejp wrote: > Am 17.02.2016 um 23:22 schrieb Matthew Woehlke: >> On 2016-02-17 16:30, Miro Knejp wrote: >>> I somehow can't shed the feeling that what we really need here is >>> support for multiple return values. >>>=20 >>> having this ability makes writing tuple unpacking trivial: >>> >>> template auto... unpack(tuple x); >> >> First off, you meant: >> >> template auto... unpack(T); > > No, I didn't. The example I provided was for std::tuple explicitly to > demonstrate how MRVs come into the picture. People can obviously > customize unpack() in addition to get<>() using ADL as necessary. Does assignment unpacking use std::unpack, then? If so, then you've just changed the customization point. (If not, I object to requiring different customization points for such similar operations.) That said, I'm not convinced that std::get isn't the superior customization point. (Keep in mind I also objected to having to specialize std::tuple_size, always.) >> TBH, as much as I argued this previously, I have to say that at this >> point I'm inclined to see U2PP=C2=B9, and possibly P0222, as the best >> solution to MRV's. > > (do you have a link to P0222? I couldn't find anything with that number) It hasn't been published yet AFAICT, but should be in the Feb 2016 mailing whenever that does get published. Meanwhile: https://github.com/mwoehlke/cpp-proposals/blob/master/p0222r0-anonymous-str= uct-return.rst (be aware that github strips the markup for standardese edits; check the raw reST for these, though in this case the edit may be obvious). > In my head MRVs are a transient construct only existent as the type of a > call expression. If you need to capture it assign the values to > varaiables (like in P0144R1) or forward as parameters to another call > expression (like make_tuple). Under this assumption, that MRVs are their > own kind of entity, folding becomes possible as (0 + ... + foo()) if > their special nature is considered. Therefore folding a tuple becomes (0 > + ... + unpack(tpl)). So... basically, an MRV *is* a parameter pack? In that case, I don't see much difference between "true MRV's" and U2PP. >>> Given the proper handling of lvalue-refs, rvalue-refs, reference_wrappe= r >>> etc, this should also make the example tail(ref(tpl1)) =3D tpl2 work. >> >> How would this be different from / better than: >> >> std::tie([1:]tpl1...) =3D tpl2; >> >> ...? > > It uses words that actually describe what it does. >=20 > Without MRVs you cannot hide "[1:]tpl1..." effortlessly behind a named > function. You can't? auto tail(auto tuple) { return make_tuple([1:]tuple...); } (Simplified for illustrative purposes; usual caveats about proper reference handling, forwarding, etc.) > *Every single time* someone needs to unpack the tail of a > tuple they have to write out the same sequence of punctuation. DRY > anyone? That's like saying "every time someone needs to add two numbers they have to write '+'". Yes, every time you do something you have to write something. DRY is when you are writing the same *non-trivial* code repeatedly. Seven characters (`[1:]...`) is not non-trivial, especially as your example uses a minimum of six (`tail()`, assuming that you are `using namespace std;`, which not everyone wants to do!). > Even languages with this kind of syntax come shipped with > utility functions like tail() because they're more descriptive. I could argue that. If I'm not familiar with it, I need to check the documentation to know if 'tail' means `[1:]` or `[-1]`, because it could mean either one. With U2PP slicing, there is no such ambiguity. (And anyway, as shown above, there is nothing stopping us having a `std::tail()` with U2PP.) > In order to hide it inside a function you have to return a tuple > (maybe containing references) and then use the awkward inversion of > "apply(f, something(x))" when using the result. Ah... no? Why? Huh? U2PP makes std::apply superfluous. > Compare that to "f(something(x))" and tell me which one you'd prefer > to write and read. I'm not thrilled that I can't tell there that `something(x)` is a parameter pack. In that sense, I prefer the clarity of `f([:]something(x)...)`. (Note that this is also how e.g. Python works. Despite often being used as the poster child for MRV's, Python actually has no such thing... just lots of syntax sugar a la P0144 and U2PP that makes it seem as if it does.) Oh! Here's a fun point... if we *did* have true MRV's, how long until people start writing unary operator* as a synonym for unpack? Would that be a good thing? --=20 Matthew --=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/. .