220 29608 article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Add a "tuple_slice" function in Date: Fri, 2 Dec 2016 00:00:01 +0100 Lines: 266 Approved: news@gmane.org Message-ID: References: <490cad18-4302-4350-976f-2bc394a1a350@isocpp.org> <583F4A4F.7020708@gmail.com> <945de37f-352d-008f-a29b-d354999c6c4c@wanadoo.fr> <5840659B.7050003@gmail.com> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------AB37B4E37810C129C83207E8" X-Trace: blaine.gmane.org 1480633211 30853 195.159.176.226 (1 Dec 2016 23:00:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 1 Dec 2016 23:00:11 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB4WWQLBAKGQECG2FFJQ@isocpp.org Fri Dec 02 00:00:06 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cCaKf-0006LU-RD for gclcip-std-proposals@m.gmane.org; Fri, 02 Dec 2016 00:00:01 +0100 Original-Received: by mail-lf0-f70.google.com with SMTP id l68sf102269088lfb.1 for ; Thu, 01 Dec 2016 15:00:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :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=LWikcesKwQRmDkF43TF19b+yDTpFCNzyj9xtwDHXBTk=; b=k8/MCQfz10VCj7FnRSggiuux3emBzDeLi3xV/u71NtiC4+ZWWwuYZjSDk4BAmyeFb6 EDfJVCq+02jvqt58kXeN5cYLjcZvaXf1Q+luaoyxoeNavC0CnkavpqdPYajpr4LThlaN NXzjjJWL0qX1uiK6tKzmlF4wFOo9HvP77+vsfrV6mZevhQAFByO5rzCUzp+kkAj/gClz X4httxjBxTp9lfYflVcZewSzn5abIPf2b1c+LyjteAPrFRrGev6AJYLPL3QkcGLWUkNh N4hZpU2+H67GxMILfsvVT3NZs6iicKEgmWan8GkT1AqKMkotCDtksTw4DE3AZW2IbfJk 5W0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version: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=LWikcesKwQRmDkF43TF19b+yDTpFCNzyj9xtwDHXBTk=; b=Hkib/Po9iyQ7RBY0c7scbK78OgrBYpsVMSFhEj/7Vf5H3TSdWrXXl8tZqpBc3kXdBd MdkcfmgV6eX0VdK3zXY1ep6AQk6htvWzyejsq/0feBx4hRp8idWGJKPdG2WlP4oVv8WY PVmzbisaj+i0aWvDOZp7XgW3tWn7tq1mZNrAmuGZ1+CYVvF9OpQ52F5aWwF6H5+u4rV/ v2OeHiwUkhaZlwWPyvziNN/QlrJsNQ7D2kHMYbcm+C8zq+91ZxeqoObWxSE7wjsgB5qU 8CXPiEp0OCUwBucpk9CcJUD0Com0tluX5t9y/yYVb/X2X4U2VGPXC9rfFe4cOH5ye9N2 xULQ== X-Gm-Message-State: AKaTC03NkKLF7NLEiK/qmTfMJfDi9GniPFv/ylmLPNqXEAu7jfidxmerlKnj7ykOZ5RpjA== X-Received: by 10.46.33.154 with SMTP id h26mr5950332lji.2.1480633203353; Thu, 01 Dec 2016 15:00:03 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.197.14 with SMTP id v14ls14259wmf.19.gmail; Thu, 01 Dec 2016 15:00:02 -0800 (PST) X-Received: by 10.194.97.8 with SMTP id dw8mr10151694wjb.84.1480633202075; Thu, 01 Dec 2016 15:00:02 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126]) by mx.google.com with ESMTPS id qc15si2327386wjb.233.2016.12.01.15.00.01 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 01 Dec 2016 15:00:02 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.126; Original-Received: from imac-de-vicente-botet-escriba.home ([86.214.78.47]) by mwinf5d80 with ME id En011u00411EX3q03n01Qe; Fri, 02 Dec 2016 00:00:01 +0100 X-ME-Helo: imac-de-vicente-botet-escriba.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 02 Dec 2016 00:00:01 +0100 X-ME-IP: 86.214.78.47 In-Reply-To: <5840659B.7050003@gmail.com> X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.126 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) smtp.mailfrom=vicente.botet@wanadoo.fr Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:29608 Archived-At: This is a multi-part message in MIME format. --------------AB37B4E37810C129C83207E8 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 01/12/2016 =C3=A0 19:02, Matthew Woehlke a =C3=A9crit : > On 2016-11-30 17:41, Vicente J. Botet Escriba wrote: >> I agree that new algorithms should work on ProductTypes [P0327R1]. It is >> not yet clear to me how we would have the same syntax for ProductTypes >> and parameter packs. > As a language feature, I don't see the difficulty. The proposed syntax > is a unary operator, thus the generalized form is ` ` > (more specifically, `[]`, though that may be > subject to bikeshedding). There should be no problem for the compiler to > determine whether or not the operand is a parameter pack, and act > accordingly. See my other post. There are several proposal (P0341R0=20 ). > >> While this could be user friendly, it doesn't compose well in generic >> code. > Can you elaborate? What I meant is that some times we need HOF (e.g. pipe composition), and=20 the friendly [I:J] syntax wouldn't provide it, isn't it? auto x =3D pt | slice | filter(cnd) | transform(fct); > >> BTW, would slicing [I1,I2]pt... return a pack or a product type? Or a vi= ew? > Neither. See Nicol's reply for longer explanation. > > If you want that as a product type, you could write e.g. > `make_tuple([I1:I2]pt...)`. Now that I'm re-reading myself, my question was more on what is the type=20 of [I1,I2]pt. But you have already responded to this question now. Then I would prefer make_slice(pt) in my production code and let=20 the implementation to provide the best implementation. > You can also write things like: > > template > auto partial_manhattan_distance(VectorType const& v) > { > using std::abs; > return decltype(vec){} + ... + abs([I1:I2]v); > } Could you expand? What will be the result of this expression with a=20 concrete example? Is abs variadic? What are we expanding on the fold expression? > This is one area where a language feature is superior. The other, of > course, is that it works on parameter packs also. So you are saying that an slice on a product type is a parameter pack=20 and a slice of a parameter pack is also a parameter pack, isn't it? I would find more logical that an slice on a ProductType is a=20 ProductType whenever possible. > > In my proposal (which I should probably post :-)), I present this as two > separate features that logically combine. First, I present *parameter > pack* slicing. A language feature is much more desirable for parameter > packs, because there are drawbacks to trying to do slicing as a library > feature (creation of temporary objects being the big one; some cases, > especially involving move-only types, can get *really* awkward trying to > use pure library features vs. a language feature). I'm all for this feature. > Second, I present > generalized unpacking, which turns a product type into a parameter pack > (without slicing), which is much more powerful than std::apply (e.g. > above example). However, I use the same syntax for both, such that > combining the two becomes "obvious"; it makes both features more > powerful and is less to learn (two features, only one syntax between them= ). > I'm all for unpacking a product type. An even unpacking and then slicing. What the OP was proposing was to slice a product type and get another=20 product type, not a parameter pack. As I said the implementation is not important. What is important is the=20 function specification, and the function can not return a parameter=20 pack, at least I have not seen any proposal that will allow to return=20 parameter packs. P0341R0=20 =20 talks about literal pack types, but they are IMO closer to product types=20 than to parameter packs. Vicente --=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/fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0%40wanadoo.f= r. --------------AB37B4E37810C129C83207E8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Le 01/12/2016 =C3=A0 19:02, Matthew Woeh= lke a =C3=A9crit=C2=A0:

On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:

I agree that new algorithms should work on ProductTy=
pes [P0327R1]. It is
not yet clear  to me how we would have the same syntax for ProductTypes
and parameter packs.

As a language feature, I don't see the difficulty. The proposed syntax
is a unary operator, thus the generalized form is `<operator> <ope=
rand>`
(more specifically, `[<index-expression>]<operand>`, though tha=
t may be
subject to bikeshedding). There should be no problem for the compiler to
determine whether or not the operand is a parameter pack, and act
accordingly.

See my other post. There are several proposal (P0341R0).

While this could be user friendly, it doesn't compos=
e well in generic
code.

Can you elaborate?

What I meant is that some times we need HOF (e.g. pipe composition), and the friendly [I:J] syntax wouldn't provide it, isn't it?

auto x =3D pt | slice<I,J> | filter(cnd) | transform(fct);

BTW, would slicing [I1,I2]pt... return a pack or a p=
roduct type? Or a view?

Neither. See Nicol's reply for longer explanation.

If you want that as a product type, you could write e.g.
`make_tuple([I1:I2]pt...)`.

Now that I'm re-reading myself, my question was more on what is the type of [I1,I2]pt. But you have already responded to this question now.

Then I would prefer make_slice<I1,I2>(pt) in my production code=C2=A0 and let the implementation to provide the best implementatio= n.

You can also write things like:

  template <int I1, int I2, typename VectorType>
  auto partial_manhattan_distance(VectorType const& v)
  {
    using std::abs;
    return decltype(vec){} + ... + abs([I1:I2]v);
  }

Could you expand? What will be the result of this expression with a concrete example?
Is abs variadic? What are we expanding on the fold expression?

This is one area where a language feature is superior. The other, of
course, is that it works on parameter packs also.

So you are saying that an slice on a product type is a parameter pack and a slice of a parameter pack is also a parameter pack, isn't it?

I would find more logical that an slice on a ProductType is a ProductType whenever possible.


In my proposal (which I should probably post :-)), I present this as two
separate features that logically combine. First, I present *parameter
pack* slicing. A language feature is much more desirable for parameter
packs, because there are drawbacks to trying to do slicing as a library
feature (creation of temporary objects being the big one; some cases,
especially involving move-only types, can get *really* awkward trying to
use pure library features vs. a language feature).

I'm all for this feature.

Second, I present
generalized unpacking, which turns a product type into a parameter pack
(without slicing), which is much more powerful than std::apply (e.g.
above example). However, I use the same syntax for both, such that
combining the two becomes "obvious"; it makes both features more
powerful and is less to learn (two features, only one syntax between them).

I'm all for unpacking a product type. An even unpacking and then slicing.

What the OP was proposing was to slice a product type and get another product type, not a parameter pack.

As I said the implementation is not important. What is important is the function specification, and the function can not return a parameter pack, at least I have not seen any proposal that will allow to return parameter packs. P0341R0=C2=A0 talks about literal pack types, but they are IMO closer to product types than to parameter packs.

Vicente

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0= %40wanadoo.fr.
--------------AB37B4E37810C129C83207E8-- .