220 23877 <72de7daf-93af-4e55-95ea-67898bd2a5f6@isocpp.org> article Path: news.gmane.org!not-for-mail From: Arthur O'Dwyer Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: RFC: Unpacking tuples to value sequences Date: Tue, 19 Jan 2016 22:50:34 -0800 (PST) Lines: 303 Approved: news@gmane.org Message-ID: <72de7daf-93af-4e55-95ea-67898bd2a5f6@isocpp.org> References: <6f3ece34-e302-4d95-afd0-4c1924e8a780@isocpp.org> <6ad65a24-8a2e-4053-b9c9-80d296d98e7d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_627_2046547581.1453272634390" X-Trace: ger.gmane.org 1453272639 11252 80.91.229.3 (20 Jan 2016 06:50:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 20 Jan 2016 06:50:39 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDLZJYWNDQILXXH4WQCRUBDIOSHZY@isocpp.org Wed Jan 20 07:50:39 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ig0-f198.google.com ([209.85.213.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aLmbF-0008Sz-5x for gclcip-std-proposals@m.gmane.org; Wed, 20 Jan 2016 07:50:37 +0100 Original-Received: by mail-ig0-f198.google.com with SMTP id ik10sf18399566igb.2 for ; Tue, 19 Jan 2016 22:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=pJVqwjppHEzvuPvTxbMff4dN6GgUZAKsbdqJhiAvizQ=; b=QJzg7ilISyrok1V4bvXAyDR2qfjNEBqWvimU5q5uJf5dEH885X7pzbQpco/EG2pW35 kBJ+e7/8qVTou3woVSUlchJV+yyHcNwbdZiTkA1VUPkGrs7CDoZNLQxHUmUnBKuvbXqd 6nYoxIpIWQKtCFC2f6FEvR6RgCmNn7OI+ex9tIsGIH8p1NLVfXx8PEF4kxrmya/J/zXq lLRAD4QInj9TtvXtNN0/PtrzWc0YIHYlat/raNgzQgSp9Eq3TpnGA+u99O6K2inrewUQ 5ot8vNAjl8cCFpjzxbr0BzP5UCWHmOdUluqOkwy+ulegnGyjFvxEq7Mci7brv0zwcQ41 U+8w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=pJVqwjppHEzvuPvTxbMff4dN6GgUZAKsbdqJhiAvizQ=; b=WMi3Sx4tayP/jbuNgCGMgBA/vsFw7x36SBCvkkpMMFymzc7qUhswpvVXshB64int/6 Tr+6msg/Fi2pvR4rLBcDKbvW6n6v0QSBwJ27wr21S0LAzXmIxSnPP0uMdAZAFqtCPDVd P15jmcFFwNJLv6QnG7hXzcj+mNOh/o4vtzIxIS3GeP+jTi8yeOgQejSh4Pf0kGqJlzfq NMj9F+juu7245JhpG04KDrPYcV4bartZBWwht4QqjxaFRzyhSmfKzQIRiF0CwSUc0WLi godlJVGWph8g6CmFgMuBkieQ7sJ+LpVUU2geiKlfU/pmOYMPj7RImTGOw35nDxJGs1+8 TB/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type:x-original-sender :reply-to:precedence:mailing-list:list-id:x-spam-checked-in-group :list-post:list-help:list-archive:list-subscribe:list-unsubscribe; bh=pJVqwjppHEzvuPvTxbMff4dN6GgUZAKsbdqJhiAvizQ=; b=TnO2dnM8KT105h1Ett1WQR7OqUYq4S/ON6DgCq2HbWOXTjPjBpsSsffjlIfVbiD7+h cc8oETmUfdzYgpGMppQ5LH6mstXeeU0sgifH9P8vJXUd9OMBEczjgyZ4qsGuZxTGd4Ut 1uMbQiB8LTBQTv4pubex/8AlIi98VAswIA41Vv9ESoPDx8bvzJDS/eZPlM7IF0mMbyVP Be7roGCqv552VLvlzZ8srPAAXKQzBUea+JWLVwt539CwafZY/ERaQeci09CTGU31/Po/ 2mH8nABLsEaT7eZs+wr7DP6tseYMeOrTTwve7MyetjoxMzl8XmekqskAT2QpGqkUlE/b rvZg== X-Gm-Message-State: ALoCoQkAK5cbzVSqisP+NeFijJd7Ed5ecjsYeF+gKox0fyD9yWGX6fnItZ7LJbqf1r2dTK3e6sKSKRfDhC9BSgsZysEtt8PPoQ== X-Received: by 10.182.24.41 with SMTP id r9mr31200028obf.25.1453272636335; Tue, 19 Jan 2016 22:50:36 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.18.137 with SMTP id 9ls94085ios.106.gmail; Tue, 19 Jan 2016 22:50:35 -0800 (PST) X-Received: by 10.50.73.200 with SMTP id n8mr47672igv.6.1453272635266; Tue, 19 Jan 2016 22:50:35 -0800 (PST) In-Reply-To: X-Original-Sender: arthur.j.odwyer@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:23877 Archived-At: ------=_Part_627_2046547581.1453272634390 Content-Type: multipart/alternative; boundary="----=_Part_628_1113157909.1453272634391" ------=_Part_628_1113157909.1453272634391 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tuesday, January 19, 2016 at 12:23:25 PM UTC-8, Matthew Woehlke wrote: > > On 2016-01-19 14:15, Nicol Bolas wrote:=20 > > Your mechanism is too simplified to be of *general* use.=20 > > I disagree. I can think of immediate examples of unpacking in place (and= =20 > some have been given). I would like to see a reasonable example for:=20 > > auto result =3D make_tuple(func([*]f..., [*]g)...);=20 > > ...along with a rationale why this merits a language feature.=20 > Aren't you both (Nicol and Matthew) proposing language features? Matthew is= =20 proposing `[*]`, and Nicol is proposing `[*]...`. I don't see how either= =20 of those can be implemented as a library-only feature. The only difference between Nicol's proposal and Matthew's (AFAICT) is=20 whether [*]x "expands in place" into a comma-separated sequence of gets=20 (Matthew's), or whether it evaluates to a parameter pack at the AST level= =20 (Nicol's). If that is in fact the only difference, then *of course* Nicol's proposal= =20 is better. Parameter packs are well-understood, are composable in=20 interesting ways (e.g. `f(g(x)...)` versus `f(g(x...))`), and are going to= =20 become even more composable in C++17 (e.g. fold-expressions). A=20 comma-separated sequence is *just one possible result* of expanding a=20 parameter pack. Plus, parameter packs have Standard wording already, so you wouldn't need= =20 to write any new wording to describe what you (Matthew) mean by *"any=20 context where a ``,``-separated sequence of expressions is accepted"*.=20 (Matthew doesn't really mean that literally anyway, unless he's proposing= =20 to allow [*]x; as an expression statement containing std::tuple_size_v=20 - 1 instances of the comma operator.) Notice that in the previous parenthetical I had to write std::tuple_size_v<= decltype(std::tie([*]x))>=20 - 1 to express the size of the "comma-separated sequence" [*]x under=20 Matthew's proposal. I think that's really the simplest thing that would=20 compile! Under Nicol's proposal, the same notion would be expressed as=20 sizeof...([*]x). This illustrates what I mean by the statement "Parameter= =20 packs are well-understood." We know how to work with them; we have language= =20 tools that have been carefully designed to work with them. Whereas, IMO,=20 "comma-separated sequences" are weird and un-C++thonic. p.s. If we have genuine promotion of value sequences to parameter packs,=20 > why can't we do this?=20 > > auto&&... g_unpacked =3D g;=20 > auto result =3D make_tuple(func([*]f, g_unpacked)...);=20 > Because you can't have variables of parameter-pack type. Parameter packs=20 aren't first-class citizens in C++. Maybe they should be; but that seems=20 like a distraction from the issue at hand, which is - should tuples be convertible back into packs, or into some other kind of= =20 entity? and - what should the syntax for that look like? The questions of "why can't I declare a pack on the stack", or "why can't I= =20 init-capture a pack", or "why can't I declare a class A that has=20 members of types T..." are all good questions, but are completely=20 orthogonal to the two questions above. And they'll still be there for the= =20 solving later. =20 > > ... The *only part* of your proposal that absolutely needs to be a=20 > > *language* feature is the ability to unpack a tuple into a=20 > > braced-init-list.=20 > > I think you're severely understating the usefulness of this case. I=20 > don't feel that being able to unpack into e.g. constructor calls is so=20 > rare as to be so lightly glossed over.=20 > I suspect Nicol was implying that "unpacking into the arguments of a=20 constructor call" can be simulated by "unpacking into the arguments of a=20 function call": new (addr) T(pack...) is exactly equivalent to std::experimental::apply(std::allocator::construct,=20 std::allocator{}, addr, pack...); and creating temporary objects of type T can also be done with constructs= =20 such as my::make(pack...), as long as T is moveable. Richard Smith's=20 P0135 "Guaranteed copy elision through simplified value categories" removes= =20 even that "moveable" requirement. Whereas, there is no library solution for "creating a braced-init-list".=20 Braced-init-lists are special in that they force left-to-right (LTR)=20 evaluation of their contents. You can't do that with a function call.=20 (Although, as previously noted on this list, I wish you could. ;)) > Oh, and the temporary in this case must be named. Weren't you one of=20 > those=20 > > who were saying that naming things is hard=20 > > Naming *API* is hard :-). I dub the temporary 't'. Or 't0'. Or whatever;= =20 > the names of temporar^Wlocal scratch variables don't matter the way the= =20 > names of API types do.=20 > Depends on your domain, as always. If your codebase has a lot of deeply=20 nested constructs and compiles with -Wshadow, naming local variables *can*= =20 be challenging. If you're working on a code-generator that generates C++=20 code, the first time you run into some construct that *requires* you to=20 implement a std::string get_temp_variable_name() { static int x =3D 0; return "t"+std::to_string(x++); } if you're like me you're going to spend at least half an hour tearing your= =20 hair out to find any workaround for this *$*#$% stupid language feature*=20 that *requires* making up ad-hoc names. Naming things sucks; IMHO half the= =20 attraction of "point-free style=20 " is that it eliminates=20 most of the bikeshedding over naming! :) =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/. ------=_Part_628_1113157909.1453272634391 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tuesday, January 19, 2016 at 12:23:25 PM UTC-8, Matthew= Woehlke wrote:
On 2016-01-19 1= 4:15, Nicol Bolas wrote:
> Your mechanism is too simplified to be of *general* use.

I disagree. I can think of immediate examples of unpacking in place (an= d
some have been given). I would like to see a reasonable example for:

=C2=A0 auto result =3D make_tuple(func([*]f..., [*]g)...);

...along with a rationale why this merits a language feature.

Aren't you both (Nicol and Matthew= ) proposing language features? Matthew is proposing `[*]`, and Nicol is pro= posing `[*]...`. =C2=A0I don't see how either of those can be implement= ed as a library-only feature.

The only difference = between Nicol's proposal and Matthew's (AFAICT) is whether [*]x &qu= ot;expands in place" into a comma-separated sequence of gets (Matthew&= #39;s), or whether it evaluates to a parameter pack at the AST level (Nicol= 's).

If that is in fact the only difference, t= hen of course Nicol's proposal is better. Parameter packs are we= ll-understood, are composable in interesting ways (e.g. `f(g(x)...)` versus= `f(g(x...))`), and are going to become even more composable in C++17 (e.g.= fold-expressions). A comma-separated sequence is just one possible resu= lt of expanding a parameter pack.
Plus, parameter packs have = Standard wording already, so you wouldn't need to write any new wording= to describe what you (Matthew) mean by "any context where a ``,``-separated seque= nce of expressions is accepted". (Matthew doesn't reall= y mean that literally anyway, unless he's proposing to allow
=
=C2=A0 =C2=A0 [*]x;

as an expressio= n statement containing std::tuple_siz= e_v<decltype(std::tie([*]x))> - 1 instances of the comma opera= tor.)

Notice that in the previous parenthetical I = had to write std::tuple_size_v<dec= ltype(std::tie([*]x))> - 1 to express the size of the "comma= -separated sequence" [*]x= under Matthew's proposal. I think that's really the simplest thing= that would compile! Under Nicol's proposal, the same notion would be e= xpressed as sizeof...([*]x). T= his illustrates what I mean by the statement "Parameter packs are well= -understood." We know how to work with them; we have language tools th= at have been carefully designed to work with them. Whereas, IMO, "comm= a-separated sequences" are weird and un-C++thonic.


p.s. If we hav= e genuine promotion of value sequences to parameter packs,
why can't we do this?

=C2=A0 auto&&... g_unpacked =3D g;
=C2=A0 auto result =3D make_tuple(func([*]f, g_unpacked)...);

Because you can't have variables o= f parameter-pack type. Parameter packs aren't first-class citizens in C= ++. Maybe they should be; but that seems like a distraction from the issue = at hand, which is
- should tuples be convertible back into packs,= or into some other kind of entity? and
- what should the syntax = for that look like?
The questions of "why can't I declar= e a pack on the stack", or "why can't I init-capture a pack&q= uot;, or "why can't I declare a class A<T...> that has membe= rs of types T..." are all good questions, but are completely orthogona= l to the two questions above. And they'll still be there for the solvin= g later.

=C2=A0
> ... The *only part* of your proposal that absolutely n= eeds to be a=20
> *language* feature is the ability to unpack a tuple into a=20
> braced-init-list.

I think you're severely understating the usefulness of this case. I
don't feel that being able to unpack into e.g. constructor calls is= so
rare as to be so lightly glossed over.

I suspect Nicol was implying that &quo= t;unpacking into the arguments of a constructor call" can be simulated= by "unpacking into the arguments of a function call":
= =C2=A0 =C2=A0 new (addr) T(pack...)
is exactly equivalent to<= /div>
=C2=A0 =C2=A0 std::experimental::apply(std::allocator<T>::c= onstruct, std::allocator<T>{}, addr, pack...);
and creating= temporary objects of type T can also be done with constructs such as my::m= ake<T>(pack...), as long as T is moveable. =C2=A0Richard Smith's = P0135=C2=A0"Guaranteed copy elision through simplified value categorie= s" removes even that "moveable" requirement.
Where= as, there is no library solution for "creating a braced-init-list"= ;. Braced-init-lists are special in that they force left-to-right (LTR) eva= luation of their contents. You can't do that with a function call. (Alt= hough, as previously noted on this list, I wish you could. ;))
> Oh, and the tempo= rary in this case must be named. Weren't you one of those=20
> who were saying that naming things is hard

Naming *API* is hard :-). I dub the temporary 't'. Or 't0&#= 39;. Or whatever;
the names of temporar^Wlocal scratch variables don't matter the way= the
names of API types do.

Depends on your domain, as always. If = your codebase has a lot of deeply nested constructs and compiles with -Wsha= dow, naming local variables can be challenging. If you're workin= g on a code-generator that generates C++ code, the first time you run into = some construct that requires you to implement a

=
std::string get_temp_variable_na= me() {
=C2=A0 =C2=A0= static int x =3D 0;
=C2=A0 =C2=A0 return "t"+std::to_string(x++);
<= font face=3D"courier new, monospace">}

if y= ou're like me you're going to spend at least half an hour tearing y= our hair out to find any workaround for this $*#$% stupid language featu= re that requires making up ad-hoc names. Naming things sucks; IM= HO half the attraction of "point-free style" is that it eliminates most of t= he bikeshedding over naming! :)

=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= /.
------=_Part_628_1113157909.1453272634391-- ------=_Part_627_2046547581.1453272634390-- .