220 25304 article Path: news.gmane.org!not-for-mail From: Matthew Woehlke Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: [RFC] Call for considering "the big picture" re: tuples and parameter packs Date: Mon, 21 Mar 2016 12:15:14 -0400 Lines: 213 Approved: news@gmane.org Message-ID: References: <7a6256c3-9a42-4788-a8ac-ffdd5d95db6d@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 1458576948 2867 80.91.229.3 (21 Mar 2016 16:15:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Mar 2016 16:15:48 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBC37LBFWUIFBBIV4YC3QKGQE2EMENFY@isocpp.org Mon Mar 21 17:15:34 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-wm0-f70.google.com ([74.125.82.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ai2UP-000868-7L for gclcip-std-proposals@m.gmane.org; Mon, 21 Mar 2016 17:15:33 +0100 Original-Received: by mail-wm0-f70.google.com with SMTP id r129sf16279222wmr.2 for ; Mon, 21 Mar 2016 09:15:31 -0700 (PDT) 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-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=a/Kl4sN8OZlR6uVSRpFQhmLjHeQGE1UubOnZZQQOz/w=; b=tcBcKE5nxOAmjY1GBAVN83qEJtIpZDpjIJeucWpRY4+4tELFZaz4+gZ5UMvXepYpow QPxqMM1Ss4xhTK626NiRgZWtD9/lVMwFkZu7KyoQVO0zgRLI3bQ5CGBSoVvPXvr2L5co dQn14qi54C2yTUDoVhsXugFMWiDJ5y1BLb2X9EyoHmsGvGSO4L49YE3PZrfUp+jAGC2O K654TFkDy2Otr4wK2+R8G0E3/UhJUOoLPxFuFwU6Mhexq5HnohQg3LlCnh1tVmKDotgb CmLg+SpgaYZKY0lD/sw4PDo4V1EgsXMs3x+XLdMdyt1Su3MFOwKp0Jyb0HkbIj+xP0RR 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-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=a/Kl4sN8OZlR6uVSRpFQhmLjHeQGE1UubOnZZQQOz/w=; b=KklXnE7cpBREQ/Ep9Tf4x1FxgGINx3gRbgMlrrS0C7o+Ld68dd5n7+8Fzml+4cFxpU RWwFVysYcL1J/uF4R1WfXDYpbGtuLlWazomGjrhRUT0TVOFgdIUyXM2fuj7qM3ZP7nLv 7JhI9mpM4NEfs8OvbF1puSWotT5v08Xn4xIJcYB/Y7767m6py3N22UtV7cj3gjJLMK44 7ShR2WsUr9ay+TbwNWQFbk2sxweIopnFK5Dlu1zIK0HwXNkAJIEZvi3yLam1ALij/G2e cxt2dVkeuXpzeN8Io28e6wIl3pHK7oGqK890abM5WZLnhnk1fP4sHyk4rZxLwms0 X-Gm-Message-State: AD7BkJIFuWBa+xAlZqPG7nm7TbiXVolxbKcaGisW8POUVd8R8HZlnROusyM6JWLWoY9XpA== X-Received: by 10.194.121.197 with SMTP id lm5mr2719148wjb.2.1458576931293; Mon, 21 Mar 2016 09:15:31 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.206.66 with SMTP id e63ls639030lfg.28.gmail; Mon, 21 Mar 2016 09:15:29 -0700 (PDT) X-Received: by 10.25.136.84 with SMTP id k81mr11970164lfd.78.1458576929572; Mon, 21 Mar 2016 09:15:29 -0700 (PDT) Original-Received: from plane.gmane.org (plane.gmane.org. [80.91.229.3]) by mx.google.com with ESMTPS id m16si13592431lfb.34.2016.03.21.09.15.29 for (version=TLS1 cipher=AES128-SHA bits=128/128); Mon, 21 Mar 2016 09:15:29 -0700 (PDT) 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 1ai2UH-00081w-QE for std-proposals@isocpp.org; Mon, 21 Mar 2016 17:15:26 +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 ; Mon, 21 Mar 2016 17:15:25 +0100 Original-Received: from mwoehlke.floss by tripoint.kitware.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 21 Mar 2016 17:15:25 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 184 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: <7a6256c3-9a42-4788-a8ac-ffdd5d95db6d@isocpp.org> 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:25304 Archived-At: On 2016-03-20 15:42, Nicol Bolas wrote: > I'm not suggesting that you separate anything. I'm suggesting that you=20 > *never* propose slicing at all. Don't even talk about it. >=20 > The feature is "turn a tuple into a parameter pack". Full Stop. Anything= =20 > more than that is something more than that. That's how you justify your= =20 > design: the feature is X. That way lies... postfix `~`. Ick. Which... is the entire point=C2=B9 of P0311 and the reason I've been debating syntax with Daniel; to *avoid* having 2-3 new syntaxes where one would suffice. (=C2=B9 Secondary point, anyway.) > On Sunday, March 20, 2016 at 2:15:23 PM UTC-4, Matthew Woehlke wrote: >> [...] I think it's important to emphasize first that we *need* >> parameter pack indexing, >=20 > I don't agree that we need that. And your insistence on emphasizing that= =20 > will only lead to bad things. I'd like to see you convince Daniel and/or Daveed of this. >> and that short-form common case tuple-like unpacking is important, >=20 > To me, the biggest justification for tuple-to-parameter-pack conversion i= s=20 > how dysfunctional the library solutions are. Hana, and Boost.Fusion befor= e=20 > it, are perfect examples of the nightmare of code you have to write to do= =20 > simple things. The existence of two such libraries proves that there is a= =20 > genuine need, but the fact that the libraries create unreadable code prov= es=20 > that there needs to be a language feature to simplify it. Again, my *main* use case (i.e. the one where I would use this feature most) is where spelling out each element is annoyingly repetitive. If we have some solution to this that takes half again as much typing as *just writing the darn thing out the old way*, that makes the feature useless. I can't and won't advocate that. >> On 2016-03-19 15:58, Nicol Bolas wrote:=20 >>> So your alternative has to build up a bunch of language sub-features=20 >>> to make it work, a whole different way of doing such computations.=20 >> >> I think we're either not on the same page, or you seriously overestimate= =20 >> the complexity. Default-indexed unpacking already needs to build a pack= =20 >> of index access operations. >=20 > No, it doesn't. It will do whatever it is that it does to accomplish that= ..=20 > You're specifying behavior, not *implementation*. Yes, and the *behavior* is that it constructs the parameter pack which looks like `get<0>(__t), get<1>(__t), ...`. At least for some types. (And even that's not true; considering P0197, this *is* how I would specify the behavior, *full stop*. Doing otherwise just overcomplicates things.) > And since this is a language feature, the compiler should be allowed > to do whatever it wants. It doesn't actually have to call > `std::get<#>` for aggregates that don't have user-defined overloads. > In those case, the compiler can generate far more optimal code, since > it knows exactly where the data members are. See previous comment. It can do this *under as-if*. I have no desire or intention to *specify* the behavior this way. > With whole tuple-to-pack, the unpack expression `[:]agg + ...` can be=20 > turned into `agg.x + agg.y + agg.z`, assuming `agg` has x, y, and z membe= rs. Yes... *after optimization*. > Slicing needlessly complicates such simple code-generation functionality. It doesn't. It *modifies the bounds* used to generate the pack. (Even without going through indexed access, I would be surprised if this is as hard for the compiler to accomplish as you are insinuating!) >> Here is what code would have to look like to select every odd numbered= =20 >>> element from a tuple, under your method:=20 >>> >>> [std::odd_elements(tpl):]tpl...=20 >> >> Ah... no. That's not legal (in fact, it's syntactic garbage); the=20 >> initial-index in that example is not an integer value. The indices=20 >> *must* be constexpr integer values. The compiler already knows how to=20 >> evaluate constexpr functions, so nothing new is added there. >=20 > You said: >> Moreover, the syntax can be readily extended to accept multiple values,= =20 >> perhaps even :cpp:`constexpr` parameter packs, which would permit=20 >> discarding of specific elements, or even more complicated operations suc= h=20 >> as selecting every other element in reverse order. I said "can", *not "should"*. I also said (re-adding the part where you take that out of context) "this may be an area that parameter pack generators would serve better", and "there are complications with how to implement expansion if a parameter pack is allowed as an index". As in *I don't intend to propose this*. (on top of all that... this text isn't in the final version of P0311. It's not even in the updated draft I posted *prior* to your previous message.) At best, `std::odd_elements` is a pack generator, and fold expressions on CTI=C2=B2 are allowed. In that case... your example *might* be legal, bu= t it's almost certainly not what you intended: [1:]tpl, [3:]tpl, [5:]tpl, ... (...which is a list of parameter packs that still need to be expanded. Which... I'm not actually sure is legal, or if it is, how you would use it... At best, you're running afoul of the packs-of-packs problems.) (=C2=B2 Compile-Time Indexing) > There is no such thing as "`constexpr` parameter packs". Parameter packs whose values are constexpr. If they aren't, you can't use them for compile-time indexing. >>> Note that you have to pass the `tpl` twice, since `count_odd_elements`= =20 >>> needs to know how many are in the tuple. Or worse, `tuple_count(tpl)`.= =20 >> >> I can't think of a practical example where you wouldn't just use a=20 >> negative index. >=20 > How would using a negative index equate to slicing a tuple of the odd=20 > elements from another tuple? Because that doesn't work the way you think it does. I strongly question the value of using packs as indices (see also following comment), and if you aren't doing that, that leaves expressions like: [3:tuple_size(t)]t; [3:tuple_size(t) - 2]t; ....which are better written: [3:]t; [3:-2]t; If you can show an example that *isn't* better written as a tail-relative index or as a pure pack generator, that would be interesting. So far, I haven't seen one. >> And all of this stuff is purely at compile time, so who=20 >> cares anyway?=20 >=20 > I care about having to write the same variable name twice. So... don't: // ugly, maybe even illegal [std::odd_indices(tpl)]tpl... // better std::odd_elements(tpl)... >>> Here is what it would look like with a library solution, one that is=20 >>> coupled with tuple pack expansion:=20 >>> >>> [:](std::forward_odd_elements(tpl))...=20 >> >> *That* would be legal :-). Daveed's proposal can possibly do this more= =20 >> efficiently, however. Note that I *like* Daveed's proposal. >=20 > What is "Daveed's proposal"? Your proposal doesn't mention it, - "A third is to create a parameter pack 'generator'." - "various possible solutions have been suggested, including pack generators" - The entire "Pack Generation, Revisited" section. - Many posts in this thread and Daniel's proposal thread. > and there is nothing from this year or last year from anyone named > Daveed with regard to tuples and pack expansions. If we're talking > about Daveed Vandevoorde, Yes, *that* Daveed. ("The" Daveed, AFAICT; see e.g. Tony's reply in this thread :-).) Unless it's in the upcoming mailing, I don't believe he's published it yet. I encouraged him to share with std-proposals, but so far he hasn't commented on those requests. --=20 Matthew --=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. To view this discussion on the web visit https://groups.google.com/a/isocpp= ..org/d/msgid/std-proposals/ncp6mo%24258%241%40ger.gmane.org. .