220 24163 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RFC: Unpacking tuples to value sequences Date: Wed, 03 Feb 2016 11:03:04 -0500 Lines: 71 Approved: news@gmane.org Message-ID: References: <6ad65a24-8a2e-4053-b9c9-80d296d98e7d@isocpp.org> <72de7daf-93af-4e55-95ea-67898bd2a5f6@isocpp.org> <29e7b2a0-05fb-46e2-92bc-2a83f8a1e53c@isocpp.org> <93bbc0ca-e986-45a3-b86e-9aa4f38feb2e@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 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1454515418 6883 80.91.229.3 (3 Feb 2016 16:03:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Feb 2016 16:03:38 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBUGJZC2QKGQEY7ZB7UA@isocpp.org Wed Feb 03 17:03:31 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f69.google.com ([209.85.215.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aQztz-0005qF-B4 for gclcip-std-proposals@m.gmane.org; Wed, 03 Feb 2016 17:03:31 +0100 Original-Received: by mail-lf0-f69.google.com with SMTP id e36sf10035057lfi.3 for ; Wed, 03 Feb 2016 08:03: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: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=bjDmWIl3OH2uLvAxKvbjMmIPDTOXS1KbRzzaUZMWEqY=; b=playHJyu/i14t72fuJTWxriDayFvxEwo7b1p9MzkRLRBQDZdqLv9uMHsX2xijzJ+f0 0wQwoxllQYKavyrj0ZxEO7jgNE/GJ+VEoDfLnbVISqg0LuRnXBvd50KEHC5SJExSvR1V gkuayUgcZtlHjs0ZvFEZm+EGeuRkUoavFzhE5XuCCDxLZgtxkEnWBGKPSuggHbBCutqR W1lfnqwhkUiTSaK9nDG8+nd00iYcsOZorRfWYA8T3X0W+c4AM+spS45xyFIM2mfnZabh W5lkJobJY/GhdNwDBJ3cCIZ38WtB+pMFj+CofOy+DHzPnL22Sz/hUS6 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: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=bjDmWIl3OH2uLvAxKvbjMmIPDTOXS1KbRzzaUZMWEqY=; b=jzBEihaq2TmyFXfYxVTUOMjKDaWaZuiC76WOoqZKLzz/+bYo6uN+rOKClfWPcxh6/6 zz1Z2837qWpp+InQYUfUfWhhsyYgc2DsV+QA/o3t8FqIRgepXsvhuy/WsnP5jQogcWS9 2+2FeYTQBzAceucvM6gMK9HKnsBW0+TvQVeJR3Z0vaK5/dBVkYTmj7qpQIwN5qZywqp8 7N6BFcvSSMQ2oeDlArJbmtSkVnS/ZQLOcEHtWf0cxMdq46FNrrcjgn3k2nqmSG2Pa5G2 fZB3YDgOCqAox8l6yW3MUP4rEuz6T6rJ4wQ8E2NCoJCnjmXXdU/ X-Gm-Message-State: AG10YOTp6x2UqDoCviN5L6cjUn+YGR3siPwP5M7c0/9YbBtr9lur/J6qgTt72608jCwNhg== X-Received: by 10.28.47.211 with SMTP id v202mr495438wmv.3.1454515410498; Wed, 03 Feb 2016 08:03:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.38.67 with SMTP id m64ls142089lfm.49.gmail; Wed, 03 Feb 2016 08:03:28 -0800 (PST) X-Received: by 10.112.13.8 with SMTP id d8mr1176394lbc.110.1454515408086; Wed, 03 Feb 2016 08:03:28 -0800 (PST) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id mm9si4428106lbb.44.2016.02.03.08.03.27 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 03 Feb 2016 08:03:27 -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 1aQzts-0005ec-Ib for std-proposals@isocpp.org; Wed, 03 Feb 2016 17:03:24 +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 ; Wed, 03 Feb 2016 17:03:24 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 03 Feb 2016 17:03:24 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 53 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:24163 Archived-At: On 2016-01-30 11:33, Nicol Bolas wrote: > On Friday, January 29, 2016 at 8:59:22 PM UTC-5, Arthur O'Dwyer wrote: >> My idea was that std::getp would probably be standardized as the=20 >> "packful" version of std::get, so the user wouldn't have to actually=20 >> write out the implementation of getp in practice. >> I agree that the syntax inside this version of dotproduct is much more= =20 >> off-putting than the postfix-twiddle syntax. *It is uglier.* However, it= =20 >> is *conceptually cleaner*, because it doesn't introduce any significantl= y=20 >> new grammar (no postfix-twiddle operator) >=20 > It does introduce new grammar; just not at the cite of *use*. You have to= =20 > have new grammar to have multiple return values. Not only that, but you're no longer returning a tuple-like, you're returning *an actual parameter pack*. This implies, by extension, that you can do things like assign that pack to a variable: auto p =3D getp(t); ....which in turn implies: template foo(Ts const&... args) { auto x =3D args; bar(x...); } This of course has all sorts of interesting implications... what is `decltype(x)`? Can I pass `x` as a "single" parameter to a function? Can I pass multiple packs as distinct entities (i.e. and still know on the other side what belongs to which pack)? You can weasel out of this by claiming that getp only works in certain contexts, but then... you've invented a grammar disguised as a function. In any case, I don't see an improvement over something that's a grammar and not trying to pretend otherwise. Also, I still want slicing. >> and it doesn't introduce any new "magic names" (no hard-coding of the na= mes=20 >> get and tuple_element_t into the compiler). ....which is completely irrelevant. In light of P0144, we *already have that*. Inventing a new mechanism to do *the exact same thing*=C2=B9 is idio= cy. (=C2=B9 Both P0144 and this are value unpacking. This unpacks into a parameter pack, P0144 into a variable assignment, but before those happen, both involve the same conceptual decomposition of a tuple-like into a sequence of values.) --=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/. .