220 24184 article Path: news.gmane.org!not-for-mail From: "Arthur O'Dwyer" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: RFC: Unpacking tuples to value sequences Date: Wed, 3 Feb 2016 16:28:17 -0800 Lines: 171 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: multipart/alternative; boundary=001a1145392ca0fafc052ae6cf6c X-Trace: ger.gmane.org 1454545705 27317 80.91.229.3 (4 Feb 2016 00:28:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Feb 2016 00:28:25 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIKFNWKWUCRUBAEP5GMQ@isocpp.org Thu Feb 04 01:28:21 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aR7mW-0005ZK-9d for gclcip-std-proposals@m.gmane.org; Thu, 04 Feb 2016 01:28:20 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id h66sf14626371lfb.0 for ; Wed, 03 Feb 2016 16:28:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type: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=Sw1GtMfjh4PApGVcs27KVUm4c4Olpu/T0skC8bJsRRo=; b=sU6Afbm/Xru5NZ0THOjPIotbEVPog+3TkpAuQG1auBPR8DY7ZU/Hhs3QsawpxPEwNq cUUJP8CKO/+E8h/978R11pPDI8gMZD9mzYeXVT8JjsfgzODTts/KoA9+Md1+Xs+jIdp3 cIWBo8xMbEPY+hVVoFIs1JzN0u3m7QGE7mMrw1Gs3yMklR7Ibaxp55kOX1my/YUrSPJf 627l+wCne+IvFbcn5As3ca1yJElxnwZ6ln3m7gamRaHdM2d7ww+M+cTU9C+GlUtnlQwK WwLAizeu7eGIKhrYyVZMRE6SQnuFik5aHBfEts3X2lTHN1zuYWRaJGTQto4RX9q46CRL vNXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type: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=Sw1GtMfjh4PApGVcs27KVUm4c4Olpu/T0skC8bJsRRo=; b=j2JxbghCOwOej7O+Fse/4084Ya59Kqw6MFrAranZKJquag+4a+GQov63+bgvPdT1F6 wRKIKPrVACggFKHL0ka//nVmbomNEnE7NYskFC9j2zDP0oYHoYnKNb/G08CKe+Mq5zOd /ApNYe7P5K7OsAKLAUmZsrIAqp+SDm23WIi9v0RnO0DZdlyUvms1/gVBm0G8kyd/14se YQQBmFyfcaA21AToyjJvz0LRE/eWYzOTRRMsuGw3ny8GPzmVyD5Jde4HcdrLLYVbhNj7 QO1PF6umnxwC1kf63W6skvIETyJSuYYZ2ecy/Xg6Qs5eLmOcgRqRrx6lYRarelmn9n54 itAQ== X-Gm-Message-State: AG10YOSOeTFJwW1edCQDL8Mr4/XjxcjlkKxg2HsurwIJp5IZAbg4QZO8els2DCpRlIeg3Q== X-Received: by 10.25.213.65 with SMTP id m62mr708888lfg.2.1454545699572; Wed, 03 Feb 2016 16:28:19 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.14.85 with SMTP id 82ls487077wmo.38.gmail; Wed, 03 Feb 2016 16:28:18 -0800 (PST) X-Received: by 10.195.11.226 with SMTP id el2mr5712977wjd.112.1454545698008; Wed, 03 Feb 2016 16:28:18 -0800 (PST) Original-Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com. [2a00:1450:400c:c09::230]) by mx.google.com with ESMTPS id e63si34374410wme.95.2016.02.03.16.28.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Feb 2016 16:28:17 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) client-ip=2a00:1450:400c:c09::230; Original-Received: by mail-wm0-x230.google.com with SMTP id l66so94761110wml.0 for ; Wed, 03 Feb 2016 16:28:17 -0800 (PST) X-Received: by 10.28.179.84 with SMTP id c81mr27533775wmf.30.1454545697829; Wed, 03 Feb 2016 16:28:17 -0800 (PST) Original-Received: by 10.27.49.8 with HTTP; Wed, 3 Feb 2016 16:28:17 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::230 as permitted sender) smtp.mailfrom=arthur.j.odwyer@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (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:24184 Archived-At: --001a1145392ca0fafc052ae6cf6c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 3, 2016 at 8:03 AM, Matthew Woehlke wrote: > 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 > >> "packful" version of std::get, so the user wouldn't have to actually > >> write out the implementation of getp in practice. > >> I agree that the syntax inside this version of dotproduct is much more > >> off-putting than the postfix-twiddle syntax. *It is uglier.* However, = it > >> is *conceptually cleaner*, because it doesn't introduce any > significantly > >> new grammar (no postfix-twiddle operator) > > > > It does introduce new grammar; just not at the cite of *use*. You have = to > > 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, [...] > all sorts of interesting implications... Right. Adding "first-class parameter packs" would definitely open many cans of worms, which is why the Committee hasn't done it yet. It adds many interesting *language* issues (as opposed to *library* issues). However, I stand by my assertion that it doesn't add any new *grammar* issues. > what is `decltype(x)`? Well, since x is a *pattern*, decltype(x) would also be a *pattern*. You could turn it into a *pack expansion* by adding ... on the end. > 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)? > There's no existing grammar to allow that, so I guess not. >> and it doesn't introduce any new "magic names" (no hard-coding of the > names > >> 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 id= iocy. > You're right. If P0144 is adopted, it will show that the Committee is friendly to the idea of hard-coding the name "std::get" into the compiler. If that happens, then my objection to "magic names" will clearly have been overruled, and I'll happily shut up about it. The reason I'm harping on it right now is that I'm not aware that the Committee *has* shown significant friendliness toward P0144 yet. In other words: Ranged for-loop syntax is a minor, but IMHO inconclusive, precedent in favor of hard-coding magic names. Adoption of P0144 would be a *major* precedent in favor =E2=80=94 I'm just not aware that P0144 has in f= act *been* adopted. :) =E2=80=93Arthur --=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/. --001a1145392ca0fafc052ae6cf6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 3, 2016 at 8:03 AM, Matthew Woehlke <= mwoehlke.floss@gmail.com> wrote:
On 2016-01-30 11:33, Nicol Bolas wrote:
> On Friday, January 29, 2016 at 8:59:22 PM UTC-5, Arthur O'Dwyer wr= ote:
>> My idea was that std::getp would probably = be standardized as the
>> "packful" version of std::get, so the user wouldn't = have to actually
>> write out the implementation of getp in practice.
>> I agree that the syntax inside this version of dotproduct is much = more
>> off-putting than the postfix-twiddle syntax. *It is uglier.= * However, it
>> is *conceptually cleaner*, because it doesn't introduce any si= gnificantly
>> new grammar (no postfix-twiddle operator)
>
> It does introduce new grammar; just not at the cite of *use*. Y= ou have to
> have new grammar to have multiple return values.

Not only that, but you're no longer returning a tuple-like, you&= #39;re
returning *an actual parameter pack*. This implies, by extension, [...]
= all sorts of interesting implications...

Ri= ght. Adding "first-class parameter packs" would definitely open m= any cans of worms, which is why the Committee hasn't done it yet. It ad= ds many interesting language issues (as opposed to library is= sues). However, I stand by my assertion that it doesn't add any new=C2= =A0grammar issues.
=C2=A0
what is=C2=A0`decltype(x)`?

Well, sinc= e x is a pattern, decltype(x) would also be a pattern<= /i>. You could turn it into a pack expansion by adding ... on the end.
=C2=A0
Can I pass `x` as a "single" parameter t= o a function? Can
I pass multiple packs as distinct entities (i.e. and still know on the
other side what belongs to which pack)?

There's no existing grammar to allow that, so I guess not.
<= br>
>> and it do= esn't introduce any new "magic names" (no hard-coding of the = names
>> get and tuple_element_t into the compiler).

...which is completely irrelevant. In light of P0144, we *already ha= ve
that*. Inventing a new mechanism to do *the exact same thing*=C2=B9 is idio= cy.

You're right. If P0144 is adopt= ed, it will show that the Committee is friendly to the idea of hard-coding = the name "std::get" into the compiler. If that happens, then my o= bjection to "magic names" will clearly have been overruled, and I= 'll happily shut up about it. The reason I'm harping on it right no= w is that I'm not aware that the Committee has shown significant= friendliness toward P0144 yet.
In other words: Ranged for-loop s= yntax is a minor, but IMHO inconclusive, precedent in favor of hard-coding = magic names. Adoption of P0144 would be a major precedent in favor = =E2=80=94 I'm just not aware that P0144 has in fact been adopted= .. :)

=E2=80=93Arthur

--

---
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= /.
--001a1145392ca0fafc052ae6cf6c-- .