220 24403 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: Mon, 15 Feb 2016 16:40:34 -0500 Lines: 129 Approved: news@gmane.org Message-ID: 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: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1455572476 1777 80.91.229.3 (15 Feb 2016 21:41:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 15 Feb 2016 21:41:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBY4LRG3AKGQEB7QM5PA@isocpp.org Mon Feb 15 22:41:01 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f69.google.com ([74.125.82.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aVQt3-0000TA-VU for gclcip-std-proposals@m.gmane.org; Mon, 15 Feb 2016 22:40:54 +0100 Original-Received: by mail-wm0-f69.google.com with SMTP id c200sf25190828wme.0 for ; Mon, 15 Feb 2016 13:40:53 -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-type: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=9acfZjcch5TEIk6nDrjS8ZPsE8jDPkMgRdsEG7DeaaU=; b=WguCKzIR2IDuYaXNQ6cd167bKVu3yVzs443D+vwIGz1EwLrRMuJ9zHpWo5ADfUGl/y PKJUVSYtcR/gd395tC5OCd7474pm7mwCUOc6wT93Hgq2H4UXDQuIjQS8cgTFhtx5oVoo jwRbWK4r1J1Q44F4zMdaWcJ+RdGCJBW07QzrJZGb3U9wcFQgk/DRCffFxJFQQZorjY53 stPrJalul0wzm9j3Yez2Mc+iUHzpSATfKcUwziTQw/Rsxc1PYNCoRsc+9LOAYMxh/WrD dQIr/8boHgQf0O7WgiNxNK8NVSsb3KFuO1UTRflCXWX/cr2styvdzmXF5JxUYN77ZBkL Dbk 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-type: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=9acfZjcch5TEIk6nDrjS8ZPsE8jDPkMgRdsEG7DeaaU=; b=WI3DHmDFK6PA6ENFer7dbPxDARAqRAYfk7i+tluLMwM83MdOYK+xTIrJSSGakZJEk3 ml5iCd3AP5wJEKArgFo8zZp/ZLfarpBG5CgqMoj/iIT1T61O8tB6I1Si2M/WtE6RbVjZ 0fhbEaeB9zmF03mTgdV8ZzJCk5SAZq7VEB9soe6APTvNZmsqj/hCWgNTja0rA6hU2XSX eBkrSp6DsoU//Ak5auh60xHiPlpvnT5JC6zUoR2XnsbzU9qWvkmuiYEiT1OZXvUnh8Qg Jg5MjEr4gzoYUA4o+yB5i5aYpTBjnNT2Ps4mpivg7HT4MQPxiUwhc75BC5o+dtnM163R X-Gm-Message-State: AG10YOTi1OmxxXlwXVmT9niMBv7aO5Vdo/Kj8ZJNzV0Ti+4t763KZn6q+YykvusXhAmm+Q== X-Received: by 10.112.162.101 with SMTP id xz5mr2149640lbb.20.1455572453425; Mon, 15 Feb 2016 13:40:53 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.88.82 with SMTP id m79ls591088lfb.78.gmail; Mon, 15 Feb 2016 13:40:51 -0800 (PST) X-Received: by 10.25.29.8 with SMTP id d8mr3597714lfd.92.1455572451342; Mon, 15 Feb 2016 13:40:51 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id gh9si12783067lbc.11.2016.02.15.13.40.51 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 15 Feb 2016 13:40:51 -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 1aVQsv-0000Lu-6l for std-proposals@isocpp.org; Mon, 15 Feb 2016 22:40:45 +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 ; Mon, 15 Feb 2016 22:40:45 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 15 Feb 2016 22:40:45 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 120 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: 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:24403 Archived-At: On 2016-02-15 15:54, Arthur O'Dwyer wrote: > On Mon, Feb 15, 2016 at 7:54 AM, Matthew Woehlke wrote: >> On 2016-02-12 19:28, Arthur O'Dwyer wrote: >>> I think maybe Oliver was trying to say that >>> >>> tuple tpl { -1, "abc", "xyz", .5 }; >>> tuple tpl1; >>> tpl1 = tail(tpl); // Python: tpl1 = tpl[1:] >>> tail(tpl) = tpl1; // Python: tpl[1:] = tpl1 >>> >>> should both work, because tail() should return a tuple of references >>> instead of a tuple of values. >> >> No, that's definitely *not* how I understood it. See Vicente's reply. > > Yep, I was definitely wrong in my interpretation of what Oliver meant. My > standard for "no way, he couldn't possibly mean..." was set too high. ;) :-D >> Actually, thinking about it, `splice` *might* be useful enough to keep >> as a function in its own right: >> >> template >> splice(Tuples&... tuples) >> { >> return std::tie(([:]tuples...)...); >> } > > Isn't this (concatenation of a list of tuples) just tuple_cat? > http://en.cppreference.com/w/cpp/utility/tuple/tuple_cat If that is extended to take *tuple-likes*, then sure :-). (It isn't clear from the link, but I assume currently it only takes `std::tuple`s. I don't see why extending it would be a problem.) >> (Bonus points: would the above syntax actually work? What syntax *would* >> work? The goal is: `get<0>(a), ... get(a), get<0>(b), ... get(b), >> ...`.) > > Yes, I think the syntax above would work (modulo [...] the trivial > missing auto). Oops :-). > However, oh god, let's not encourage such brain-twisting code. Well, it would be in the standard library, at least :-) (i.e. as opposed to user code). > Assuming I'm understanding correctly, the weirdness here is that > packness "nests" or "stacks", and therefore pattern expressions in the new > regime have to be evaluated "on a stack", kind of like type definitions. > > [snip detailed explanation] Yes, exactly. >> ...and this thread is a great example of the superiority of `[:]` ;-). >> (Because it's not *just* `[:]`, it's `[A:B]` where both of `A` and `B` >> are optional. That's harder to do with `~`... I suppose you could write >> something like `tpl~{0:2}`, but that's getting a little ugly.) > > Personally I'd just do it with > > std::tuple_slice<0,2>(tpl)~ > > :) Keep in mind that I don't see "slicing" as a primitive operation; I > think slicing can be done efficiently with a library solution (which is to > say, it doesn't add any new expressiveness to the language). What happens when you want to do this? auto {x, y} = some_3d_point; // don't care about z With tuple_slice: auto {x, y} = tuple_slice<0,2>(make_tuple(some_3d_point~...)); With my `[:]`: auto {x, y} = {[:2]some_3d_point...}; (Possibly the `{}`s and `...` could be optional in the above.) That involves a temporary. (Now, obviously there are totally different ways to accomplish the same thing that may be better, but I feel like `[:2]` is the most terse. Also, it means we don't need to bother with assignment-unpacking syntax for that case.) Oh! Another reason why we might want slicing: template auto sum(Arg arg) { return arg; } template auto sum(Args... args) { return sum([0]{args...}) + sum([1:]{args...}...); } (Ignore that a fold expression would do this better. The point is that this allows writing recursive variadic-template functions without the ugly 'Head head, Tail... tail' style parameter lists.) For bonus points, if we allow `[:]` to directly slice parameter packs, we can simplify: return sum([0]args) + sum(([1:]args)...); // Notes: [0]args; // single value, not a parameter pack sizeof...([0]args); // illegal; not a parameter pack [:]args; // same as 'args' [:1]args; // still a parameter pack [0:1]args; // also still a parameter pack ([0:1]args...); // same as '[0]args' (or error if sizeof...(args)==0) sizeof...([:1]args); // == max(0, sizeof...(args) - 1) -- Matthew -- --- 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/. .