220 24083 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: Fri, 29 Jan 2016 17:59:19 -0800 Lines: 367 Approved: news@gmane.org Message-ID: References: <6f3ece34-e302-4d95-afd0-4c1924e8a780@isocpp.org> <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=001a1145b8d8f94465052a837f23 X-Trace: ger.gmane.org 1454119163 31782 80.91.229.3 (30 Jan 2016 01:59:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2016 01:59:23 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDLZJYWNDQIPRMNQWUCRUBEFAWWJK@isocpp.org Sat Jan 30 02:59:23 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 1aPKos-00043u-BX for gclcip-std-proposals@m.gmane.org; Sat, 30 Jan 2016 02:59:22 +0100 Original-Received: by mail-wm0-f69.google.com with SMTP id 128sf879707wmz.0 for ; Fri, 29 Jan 2016 17:59:22 -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=lp9IzITsD9981oBZBbhWHMS39uX2phH8Jh7UME6sJug=; b=IOvdtsUjSUREUMmPPi/vXYH12yxUWrhrJLeHNw5MGVOqz+ATo42bvcMGHYM8DUY4zy MFR8ZWP865WGvTwp53FPokzZHaWAQEjdrF06utVaCw7nfPSuFrpOg1Npwk8T5AyAChU3 CufASxfzrmABwhiKSkfh8zkKRzYPd/00C0Nx81Mqpz4v84crr0RwwrqArNSyYiEZahpP +uO3rJ0ThKFu9Fln/oJzGqzwxbTzbeOpdVLu9K5Sx/A+CwTMvAqtHYN9jSgI5Zn0onJM ZmqIE7ucyoGqzSxi99yXJcOXHjFp2oAyAuZfeo7a8fe0ir3m464JXb9uzbe6GkUdTDOL +5NQ== 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=lp9IzITsD9981oBZBbhWHMS39uX2phH8Jh7UME6sJug=; b=OzEFvj6DXeVxw/NXBxVf+DPQgfgMt7zsBKBhSqD1FUls6AnB0r5mKTH1tST+meg7SB vks02VHxYc7ksu59CjLSSM7q7U88lor3km3E39xDpEpqhx6TbA9Sp3fvtHShBvAuCIJZ qsnEHA4ndM3dy+aRd7T0yAEsB2vIoe2nxIS5DSaduEUdlkEuk1ffOR93KvhHDDaJ71ni SkjUXxaLMpDoJJx0wgtJQFnkTnN6DgMHL+DT0otkL1TBSho9C8yu5A/dLMVM5wgjnb2g nSBgoSeGNQX1BCD6YprQHCHwn9nEmLRFvoclo9fA98qOc8cALTCGG1x5oHEImhwVo5NI Vb2w== X-Gm-Message-State: AG10YOS0wsIIows6oB1DyPNVuhLpoKyB+B6AD8v6TGu8930wVgs8JeRmrDocZjw4w2Ohyw== X-Received: by 10.28.129.210 with SMTP id c201mr32754wmd.1.1454119161784; Fri, 29 Jan 2016 17:59:21 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.129.6 with SMTP id c6ls159887wmd.4.gmail; Fri, 29 Jan 2016 17:59:19 -0800 (PST) X-Received: by 10.28.186.87 with SMTP id k84mr424748wmf.13.1454119159912; Fri, 29 Jan 2016 17:59:19 -0800 (PST) Original-Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com. [2a00:1450:400c:c09::229]) by mx.google.com with ESMTPS id mn4si25541922wjc.49.2016.01.29.17.59.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Jan 2016 17:59:19 -0800 (PST) Received-SPF: pass (google.com: domain of arthur.j.odwyer@gmail.com designates 2a00:1450:400c:c09::229 as permitted sender) client-ip=2a00:1450:400c:c09::229; Original-Received: by mail-wm0-x229.google.com with SMTP id p63so2761501wmp.1 for ; Fri, 29 Jan 2016 17:59:19 -0800 (PST) X-Received: by 10.28.19.76 with SMTP id 73mr481707wmt.24.1454119159675; Fri, 29 Jan 2016 17:59:19 -0800 (PST) Original-Received: by 10.27.19.201 with HTTP; Fri, 29 Jan 2016 17:59:19 -0800 (PST) In-Reply-To: <93bbc0ca-e986-45a3-b86e-9aa4f38feb2e@isocpp.org> 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::229 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:24083 Archived-At: --001a1145b8d8f94465052a837f23 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 29, 2016 at 1:08 PM, Nicol Bolas wrote: > On Friday, January 29, 2016 at 2:21:00 PM UTC-5, Arthur O'Dwyer wrote: >> >> >> As of C++11, we have decltype(E) =E2=80=94 which takes the value E and p= roduces >> its type =E2=80=94 and we have std::declval() =E2=80=94 which takes a= type T and >> produces a value of that type. And they compose, so I can do a bunch of >> "value-space" computations and then take the decltype of the resulting >> expression. Any construct that gets in the way of my doing that is >> objectionable. >> In other words, rather than saying that mpl::vector doesn't have >> a value and so std::get(mplvec) should be ill-formed, I would prefer >> we simply say that std::get(mplvec) doesn't have a *value* =E2=80=94 = but it >> should still have a *type*! >> > > You can want whatever you want, but the fact is that in C++, types and > values are different things. And we have different mechanisms for dealing > with each. > > Functions take values and return them. Template metafunctions take types > and can evaluate to types. `declval` doesn't really generate a value in a= ny > meaningful way, since it can only exist in a non-evaluated context. And > while `decltype` does evaluate to a type, that type is not based on a > value, since the expression itself is never actually evaluated. > > Maybe sometimes these things will be equivalent someday. But until then, > C++ is what it is. Values and types are different, and we shouldn't prete= nd > that they're not. > That's one point of view, but I tend to think that it's outdated (as of C++11). We don't need template metafunctions anymore (well, not so many of them), now that we have constexpr and heterogeneous function templates at our disposal. For example, where in C++03 we *did* often have to write template metafunctions such as *template* *struct result_of_plus {* * typedef __typeof(T()+U()) type;* *};* struct plus { template *typename result_of_plus::type* operator(T t, U u) { return t + u; } }; as of C++14 we no longer need to write any of that metafunction machinery; we can use decltype to get the compiler to do the meta-lifting on our behalf, and all we need to worry about are *expressions*, which generally have both a type and a value. struct plus { template *auto* operator(T t, U u) *-> decltype(t + u)* { return t + u; } }; (and we don't even need the -> decltype stuff unless we want SFINAE!) Values and types *are* different, but they are still intimately related (for example, every value has a type), and while we *can* use different mechanisms to deal with each, we no longer *need* to. Having said all that, this "postfix twiddle means std::get<> (and/or >> std::tuple_element_t<>)" thing still feels too ad-hoc to me. >> > > It's no more ad-hoc than range-based for using `std::begin` and > `std::end`. You have to have some customization point for user-defined > types. > Agreed, I think, grudgingly, reluctantly, in practice. In other words, I agree that's the current state of the world, but I don't *like* it. It feels much too ad-hoc. begin and end "work" as well as they do because they had a couple of decades of implementation experience behind them before people started making up syntactic sugar for them. Right now we have maybe 5 years of experience using std::get and probably even less with std::tuple_element_t. Are those *exactly* the primitives we want to syntactic-sugar up, or will we regret the decision in another 5 years when we realize "how tuples *should* have been done"? I mean, imagine if instead of iostreams using operator overloading, we had gotten a syntactic sugar where << in certain contexts expanded to a call to std::printf(). Makes sense, right? But it would have been horrible for the flexibility and symmetry of the language as a whole. *And even iostreams-as-is suck!* Basically I'm worried that postfix-twiddle and tuples-as-is are in an analogous situation right now. We might not *want* to immortalize std::get in language syntax. > If we could come up with a nice syntax for it, I'd prefer to have the >> std::get<> written out and just build a simple syntax for getting a >> parameter-pack of *integer indices*. I have no idea what that syntax >> would look like, though, or how it would end up remotely as clean as thi= s >> seductive example: >> >> template >> auto dotproduct(const Vec& a, const Vec& b) >> { >> return (... + (a~ * b~)); // this is a C++17 fold-expression >> } >> >> > That example seems to be missing what the return value is supposed to be. > Presumably it's some `Vec` object, but you don't use the typename anywher= e. > The return type is exactly decltype((... + (a~ * b~))). Starting in C++14, we don't have to write it out; auto suffices for return type deduction. For example, if Vec is std::tuple, then decltype((... + (a~ * b~))) is double. The only thing I can think to do is to introduce first-class parameter >> packs, and write >> >> template >> auto getp(const std::tuple&) -> Ts...; // "return a pack" >> >> template >> auto dotproduct(const Vec& a, const Vec& b) >> { >> return (... + (getp(a) * getp(b))); >> } >> >> But first-class parameter packs seem like a nightmare to specify, don't >> they? >> > > Um, how exactly is that easier than the user implementing the appropriate > interfaces? It certainly isn't easier for the reader to understand. > 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) and it doesn't introduce any new "magic names" (no hard-coding of the names get and tuple_element_t into the compiler). This is a trade-off, and I'm honestly not sure which way would be better for the language. It's quite possible (IMHO) that the best course of action for now would be *not doing either one*. =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/. --001a1145b8d8f94465052a837f23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Jan 29, 2016 at 1:08 PM, Nicol Bolas <jmckesson= @gmail.com> wrote:
On Friday, January 29, 2= 016 at 2:21:00 PM UTC-5, Arthur O'Dwyer wrote:

As of C++11, we hav= e decltype(E) =E2=80=94 which takes the value E and produces its type =E2= =80=94 and we have std::declval<T>() =E2=80=94 which takes a type T a= nd produces a value of that type. And they compose, so I can do a bunch of = "value-space" computations and then take the decltype of the resu= lting expression. Any construct that gets in the way of my doing that is ob= jectionable.
In other words, rather than saying that mpl::vector<Ts...> doesn't have = a value and so std::get<I>(mplvec= ) should be ill-formed, I would prefer we simply say that std::get<I>(mplvec) doesn't have= a value =E2=80=94 but it should still have a type!

You can want whatever you want, = but the fact is that in C++, types and=20 values are different things. And we have different mechanisms for=20 dealing with each.

Functions take values and return them.=20 Template metafunctions take types and can evaluate to types. `declval`=20 doesn't really generate a value in any meaningful way, since it can onl= y exist in a non-evaluated context. And while `decltype` does evaluate to a type, that type is not based on a value, since the expression itself=20 is never actually evaluated.

Maybe sometimes these things will be equivalent someday. But until then, C++ is what it is. Values and types ar= e=20 different, and we shouldn't pretend that they're not.

That's one point of view, but I tend= to think that it's outdated (as of C++11). We don't need template = metafunctions anymore (well, not so many of them), now that we have constex= pr and heterogeneous function templates at our disposal. For example, where= in C++03 we did=C2=A0often have to write template metafunctions suc= h as

templa= te<class T, class U>
struct result_of_plus {
=C2=A0 =C2=A0 typedef __typeof(T()+U()) type;
};

struct plus {
=C2=A0 =C2=A0 template<class T, class U>
=C2=A0 =C2=A0 typename result_of_pl= us<T,U>::type operator(T t, U u) { return t + u; }
};

a= s of C++14 we no longer need to write any of that metafunction machinery; w= e can use decltype=C2=A0to get t= he compiler to do the meta-lifting on our behalf, and all we need to worry = about are expressions, which generally have both a type and a value.=

struct p= lus {
=C2=A0 =C2=A0 te= mplate<class T, class U>
=C2=A0 =C2=A0=C2=A0auto=C2=A0operator(T t, U u) -> de= cltype(t + u) { return t + u; }
};

(and we don't even need the -> decltype stuff unless we want SFINAE!)
Values and types are different, but they are still intimately rel= ated (for example, every value has a type), and while we can use dif= ferent mechanisms to deal with each, we no longer need to.

Ha= ving said all that, this "postfix twiddle means std::get<> (and/= or std::tuple_element_t<>)" thing still feels too ad-hoc to me.<= /div>

It's no more ad-hoc= than range-based for using `std::begin` and `std::end`. You have to have s= ome customization point for user-defined types.

Agreed, I think, grudgingly, reluctantly, in practice.= =C2=A0 In other words, I agree that's the current state of the world, b= ut I don't like it. It feels much too ad-hoc. begin and end &quo= t;work" as well as they do because they had a couple of decades of imp= lementation experience behind them before people started making up syntacti= c sugar for them. Right now we have maybe 5 years of experience using std::= get and probably even less with std::tuple_element_t. Are those exactly<= /i> the primitives we want to syntactic-sugar up, or will we regret the dec= ision in another 5 years when we realize "how tuples should hav= e been done"?

I mean, imagine if instead of i= ostreams using operator overloading, we had gotten a syntactic sugar where = << in certain contexts exp= anded to a call to std::printf()= .. Makes sense, right? But it would have been horrible for the flexibility a= nd symmetry of the language as a whole. And even iostreams-as-is suck! =C2=A0Basically I'm worried that postfix-twiddle and tuples-as-is ar= e in an analogous situation right now. We might not want to immortal= ize std::get<I> in languag= e syntax.

=C2=A0
If we could come up with a nice syntax for it, I'd p= refer to have the std::get<> written out and just build a simple synt= ax for getting a parameter-pack of integer indices.=C2=A0 I have no = idea what that syntax would look like, though, or how it would end up remot= ely as clean as this seductive example:

=C2=A0 = =C2=A0 template<class Vec>
=C2=A0 =C2=A0 auto dotproduct(const= Vec& a, const Vec& b)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 return (... + (a~ * b~)); =C2=A0// this is a C++17 fold-expression
decltype= ((... + (a~ * b~))). Starting in C++14, we don't have to write i= t out; auto suffices for return = type deduction.
For example, if Vec is std::tuple<int, dou= ble, char>, then=C2=A0decltype((... + (a~ * b~)))=C2=A0is double.


=
The only thing I can think to do is to intr= oduce first-class parameter packs, and write

=
=C2=A0 =C2=A0 template<size_t I, class... Ts>
=C2=A0 =C2=A0= auto getp(const std::tuple<Ts...>&) -> Ts...; =C2=A0// "= return a pack"

=C2=A0 =C2=A0 temp= late<class Vec>
=C2=A0 =C2=A0 auto dotproduct(const Vec& a= , const Vec& b)
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 retur= n (... + (getp(a) * getp(b)));
=C2=A0 =C2=A0 }
<= div>
But first-class parameter packs seem like a nightmare to= specify, don't they?
<= br>Um, how exactly is that easier than the user implementing the appropriat= e interfaces? It certainly isn't easier for the reader to understand.

My idea was that std::getp would probably be standardized as the= "packful" version of std::ge= t, so the user wouldn't have to actually write out the implement= ation of getp in practice.
=
I agree that the syntax inside this version of dotproduct is much more off-putting than the postfix-tw= iddle syntax. It is uglier. However, it is conceptually cleaner, because it doesn't introduce any significantly new grammar (no post= fix-twiddle operator) and it doesn't introduce any new "magic name= s"=C2=A0(no hard-coding of the names=C2=A0get=C2=A0and=C2=A0tuple_= element_t=C2=A0into the compiler).=C2=A0 This is a trade-off, and I&= #39;m honestly not sure which way would be better for the language.=C2=A0 I= t's quite possible (IMHO) that the best course of action for now would = be=C2=A0not doing either one.

=E2=80=93Arth= ur

--

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