220 24483 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 13:14:21 -0500 Lines: 100 Approved: news@gmane.org Message-ID: References: <6e35f24a-f728-4ac2-b329-1894206f59cc@isocpp.org> <56C5048D.5020304@gmail.com> <56C6036D.4000406@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 X-Trace: ger.gmane.org 1455819283 2534 80.91.229.3 (18 Feb 2016 18:14:43 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 18 Feb 2016 18:14:43 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBBMUTC3AKGQEGCDEK4Q@isocpp.org Thu Feb 18 19:14:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f72.google.com ([74.125.82.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aWT5y-0004MA-VI for gclcip-std-proposals@m.gmane.org; Thu, 18 Feb 2016 19:14:31 +0100 Original-Received: by mail-wm0-f72.google.com with SMTP id c200sf11437974wme.0 for ; Thu, 18 Feb 2016 10:14:30 -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=vUKFp0LPolHKzgihy7vNsu1hbcUXHY1PhCMFNAkqVMI=; b=V1p0ORwsAoOuGsJUxtx8dzl3czVMsRxQXAlcJHG018DmzkmLgJvjHNl1NPfHx6wUT8 YjARYlvaL9Mp9WDGRp0S/j6vrizLX16oFdH2aVfrDeGDPUYBM7AWFllm6XNRAP65IpnF TYRZ0fhCpqw3gl+Osg5vuRaZ7S64G6X57s9yBjhWbq5uFZa5amPQj93xeF0x3xJz6woH N8UTjTdtVt43Hd6Zqc6Zh5ZbKYcUEMdVgPgmlfnmPzB3fWyzdhNYIHACD71noUGFKG0c 8QAHVArkFrui4INaN7KR1aBOvlD1dPbtKnX4eoCjz704UWo3Oh4KB5FCjjecnW1n5LBH 1B5 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=vUKFp0LPolHKzgihy7vNsu1hbcUXHY1PhCMFNAkqVMI=; b=lYIVazU7wnc6iS8zbvUlro5oY8Ncot1qZATxnXdk9q7L0pez43dx5wO3/W01pfR1Ig 7pGyb1PMG8UodRs+C8xWw8FRCB1MOETy+kUTLA+vmujZw1s4ZL2SPtlsWtEZY5ejOUyP y82NWJ5J4efUnoVXAJFIsykdm9HUIIoz3860f+InukbqZFwFaWX8+glYNPdAV4bd5NhR dCm7YQx+PE6y8Fu0rWhdhNP0SZR3aiKyymtxUUuUUIHcOyJjNM0qU8luTncVw4I7y/oC FczNF61NCU5Ak9q7TSKmP8S2tW6bWRzFzGe+l92Frr4FQyekQgb2o4Mbq84d8hMZAX9O X-Gm-Message-State: AG10YOQu22hRLUJB1d4sp4sfgS0Ph+OpS0/qwDVf4r6yXdXJUkTwdtbriVU09MNKIL/Qew== X-Received: by 10.112.156.33 with SMTP id wb1mr1311195lbb.7.1455819270501; Thu, 18 Feb 2016 10:14:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.7.2 with SMTP id 2ls1198712lfh.89.gmail; Thu, 18 Feb 2016 10:14:29 -0800 (PST) X-Received: by 10.25.167.18 with SMTP id q18mr3220765lfe.27.1455819269137; Thu, 18 Feb 2016 10:14:29 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id eg2si4596025lbb.87.2016.02.18.10.14.29 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 18 Feb 2016 10:14:29 -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 1aWT5v-0004GL-E6 for std-proposals@isocpp.org; Thu, 18 Feb 2016 19:14:27 +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 19:14:27 +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 19:14:27 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 91 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: <56C6036D.4000406@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:24483 Archived-At: On 2016-02-18 12:46, Miro Knejp wrote: > Am 18.02.2016 um 17:18 schrieb Matthew Woehlke: >> So... basically, an MRV *is* a parameter pack? In that case, I don't see >> much difference between "true MRV's" and U2PP. > > Call it whatever you want, I don't care. At this stage I'm interested in > the functionality not bikeshedding of syntax or classification. That's not a bikeshedding question. A parameter pack is an existing entity with known functionality. If TMRV's are also parameter packs (and my impression is that we generally agree the should be), that gives specific, detailed information about how they function and what they can do. >> On 2016-02-17 18:38, Miro Knejp wrote: >>> Without MRVs you cannot hide "[1:]tpl1..." effortlessly behind a named >>> function. >> >> You can't? >> >> auto tail(auto tuple) { return make_tuple([1:]tuple...); } > > Yes, that is how I would implement `tail()` even with MRVs because > `tail()` has the signature `(a_0, a_1, ..., a_n) -> (a_1, ..., a_n)`. A > better name for the example would have been `unpack_tail(tpl)` or > similar, my bad. Basically it needs the signature `(a_0, a_1, ..., a_n) > -> a_1, ..., a_n`. > > But yet, those two are not equivalent. I cannot substitute the > expression `[1:]tpl...` with the expression `unpack_tail(tpl)` using > only the tools given in this thread and get the same semantics. Or am I > wrong? That's what I mean with you can't `hide` it. A full substitution > is `[:]unpack_tail(tpl)...` but that is a leaky abstraction because in > order to get the same semantics you have to apply additional operators. Well... yes, except a more accurate comparison would be: unpack_tail(tpl) // vs. [:]tail(tpl) ....because the non-MRV version isn't unpacked. (If you actually *want* a tuple, it's also more efficient, but that's bordering on a strawman argument...) It's not exactly a leaky abstraction; more of an inexact equivalence. That is, you can't exactly implement `unpack_tail` with U2PP. What you *can* implement is something that returns a tuple that can be unpacked to obtain the same parameter pack. Is that a problem? Well... maybe. I'm not sure. > `tail()` is a ubiquitous operation in basically every language that has > some form of builtin list or tuple type. It's also the accessor of the last item in a queue or linked list. :-) >> 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.) > > I call that paranoia, as is the case with every new language feature. > Soon we won't be able to tell whether `void foo(X x)` is the definition > of a function template or not. Are you also not going to avoid that? Well... yeah, I'm not crazy about that either :-). >> 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? > > People define their own operators for DSLs or convenience all the time. > If it gets established as common practice then there's no point in > trying to stop it. But you know how it goes: new language features are > always heavily abused until people shoot themselves in the foot enough > times and figure out what the "good" versus the "bad" abuses are :) I should clarify that the above was *not* meant as a rhetorical question :-). One possibly "good" think about TMRV's as you propose, including omission of `...`, is that I can write: void dot(double, double, double); vector_3d p = ...; dot(*p); ....just as in Python. I suspect some people will love this while others will be passionately opposed to it... -- 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/. .