220 29615 <58419917.8000105@gmail.com> article
Path: news.gmane.org!.POSTED!not-for-mail
From: Matthew Woehlke <mwoehlke.floss@gmail.com>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Add a "tuple_slice" function in <tuple>
Date: Fri, 2 Dec 2016 10:53:59 -0500
Lines: 156
Approved: news@gmane.org
Message-ID: <58419917.8000105@gmail.com>
References: <490cad18-4302-4350-976f-2bc394a1a350@isocpp.org>
 <583F4A4F.7020708@gmail.com>
 <945de37f-352d-008f-a29b-d354999c6c4c@wanadoo.fr>
 <5840659B.7050003@gmail.com>
 <fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0@wanadoo.fr>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Trace: blaine.gmane.org 1480694045 20490 195.159.176.226 (2 Dec 2016 15:54:05 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Fri, 2 Dec 2016 15:54:05 +0000 (UTC)
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.1.0
To: std-proposals@isocpp.org
Original-X-From: std-proposals+bncBC37LBFWUIFBBGNSQ3BAKGQEPGD2TZI@isocpp.org Fri Dec 02 16:54:00 2016
Return-path: <std-proposals+bncBC37LBFWUIFBBGNSQ3BAKGQEPGD2TZI@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-pg0-f71.google.com ([74.125.83.71])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <std-proposals+bncBC37LBFWUIFBBGNSQ3BAKGQEPGD2TZI@isocpp.org>)
	id 1cCq9u-0004au-VJ
	for gclcip-std-proposals@m.gmane.org; Fri, 02 Dec 2016 16:53:59 +0100
Original-Received: by mail-pg0-f71.google.com with SMTP id e9sf174899760pgc.5
        for <gclcip-std-proposals@m.gmane.org>; Fri, 02 Dec 2016 07:54: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:content-transfer-encoding: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=jvjJ+goBdinWeTB4r5oEhEfAsInBciZAkj/rC6BZQxw=;
        b=iA3MvzSH1+J6Qh8Qy3wxrF4WtBmTfZ8JkskqxXE2QSqxaEREuq2qsvdUKd+Puzpjs5
         HPoDqRmrnJLlR4FgH451nTgKk37GqRcPyEEtUwhJo5617cVQpV3jCX2fq3V5uxf4EV2Z
         AoVR/PKZxHXBTTXimsC5k7JeMaGelgvCeJQqhgDrGRYEQha9Fe8Tn9nbYa1g1lFXsYHb
         iUL2i/ycVWPO3l1r9Q7HewC2eQClV1wOTvzBoh96gFwKWGt6hC18uMQ4JMEIrXRtURPD
         S0kGE9tzqqx/ltLWZjJd1yGF6m7/Ou3JLGh3OTdlQmOKf58AKc81+d6SgErHdsAZ865x
      
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:content-transfer-encoding
         :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=jvjJ+goBdinWeTB4r5oEhEfAsInBciZAkj/rC6BZQxw=;
        b=XcBwVAJh1aZRfzFro5wfODWkO3+p8HvjB2J07T3hJKOOQpdjtsgpvpDSCLXSuXqfuP
         RWPYPQEum209kq4rcyYApmQMHbIpgmCCvX4QilqeLXTdMRXtXsr6Rg6YlDC2Y7Yd8wt/
         NBACmvMsAj2RWbV+DC3nNgBMqfjR9lLB2FpFEzVdmus70Ll7V2d7BykskQRQeuDB3Rki
         JMMeBxcqMt2uExew1p9T/AJcgDKFMLyI8SaMCc4zOUnn5h2/vkNFs3adLPxvfjFC5NbK
         OI0qaU4HWeHDslMb00lCxlfILmeQQf7rmSge7SYJi6EJKWQsOdl2Qyh86Y4mjqxka9Fw
  
X-Gm-Message-State: AKaTC014ZmFsZJ9EeVifea+hSmXvJFqVJqYm7YLAXBZKM36wI8t7PQJMvw5CS3LfGpjc6w==
X-Received: by 10.99.113.75 with SMTP id b11mr21591303pgn.162.1480694042205;
        Fri, 02 Dec 2016 07:54:02 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.157.13.110 with SMTP id 101ls20118113oti.25.gmail; Fri, 02 Dec
 2016 07:54:01 -0800 (PST)
X-Received: by 10.237.53.168 with SMTP id c37mr39389909qte.48.1480694041286;
        Fri, 02 Dec 2016 07:54:01 -0800 (PST)
Original-Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com. [2607:f8b0:400d:c09::234])
        by mx.google.com with ESMTPS id a134si3263509qkb.306.2016.12.02.07.54.01
        for <std-proposals@isocpp.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 02 Dec 2016 07:54:01 -0800 (PST)
Received-SPF: pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c09::234 as permitted sender) client-ip=2607:f8b0:400d:c09::234;
Original-Received: by mail-qk0-x234.google.com with SMTP id n204so282872655qke.2
        for <std-proposals@isocpp.org>; Fri, 02 Dec 2016 07:54:01 -0800 (PST)
X-Received: by 10.55.98.73 with SMTP id w70mr42238962qkb.91.1480694040789;
        Fri, 02 Dec 2016 07:54:00 -0800 (PST)
Original-Received: from [192.168.1.173] (tripoint.kitware.com. [66.194.253.20])
        by smtp.googlemail.com with ESMTPSA id a69sm2827870qkj.38.2016.12.02.07.53.59
        for <std-proposals@isocpp.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Fri, 02 Dec 2016 07:54:00 -0800 (PST)
In-Reply-To: <fbfba60b-f7a7-2a41-6e09-0cbe7e6378c0@wanadoo.fr>
X-Original-Sender: mwoehlke.floss@gmail.com
X-Original-Authentication-Results: mx.google.com;       dkim=pass
 header.i=@gmail.com;       spf=pass (google.com: domain of
 mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c09::234 as permitted
 sender) smtp.mailfrom=mwoehlke.floss@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: <std-proposals.isocpp.org>
X-Google-Group-Id: 399137483710
List-Post: <https://groups.google.com/a/isocpp.org/group/std-proposals/post>, <mailto:std-proposals@isocpp.org>
List-Help: <https://support.google.com/a/isocpp.org/bin/topic.py?topic=25838>, <mailto:std-proposals+help@isocpp.org>
List-Archive: <https://groups.google.com/a/isocpp.org/group/std-proposals/>
List-Subscribe: <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>,
 <mailto:std-proposals+subscribe@isocpp.org>
List-Unsubscribe: <mailto:googlegroups-manage+399137483710+unsubscribe@googlegroups.com>,
 <https://groups.google.com/a/isocpp.org/group/std-proposals/subscribe>
Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:29615
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/29615>

On 2016-12-01 18:00, Vicente J. Botet Escriba wrote:
> Le 01/12/2016 =C3=A0 19:02, Matthew Woehlke a =C3=A9crit :
>> On 2016-11-30 17:41, Vicente J. Botet Escriba wrote:
>>> 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
> the friendly [I:J] syntax wouldn't provide it, isn't it?

Sorry, what is "HOF"?

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

Ah... I guess you could do this with a library function. It would be
trivial to write your own with the proposed language feature, though:

  template <int I1, int I2, typename T>
  auto slice(T const& t) { return std::make_tuple([I1:I2]t); }

> 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.
>=20
> Then I would prefer make_slice<I1,I2>(pt) in my production code  and let
> the implementation to provide the best implementation.

How would that work?

The "type" of `[l:u]pt` is a parameter pack. If you need it as a
concrete type, you can wrap a constructor for *whatever* concrete type
is desired around it. A library function would necessarily dictate the
type, e.g. std::tuple. The language feature is strictly *more* powerful,
even ignoring the ability to employ *arbitrary* fold expressions.

The implementation is not free to make an optimal choice in this matter;
it is constrained by the API.

>> 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);
>>    }

Arf... just realized, the `decltype(vec){}` is nonsense (intended to be
a zero-element, but obtaining that is actually rather convoluted and
subject to some icky corner cases...). Ignoring that for the remainder
of my reply...

In fact, a better expression is:

  template <int I1, int I2, typename VectorType>
  auto partial_manhattan_distance(VectorType const& v)
  {
    using std::abs;
    if constexpr (sizeof...([I1:I2]v))
      return abs([I1:I2]v) + ...;
    else
      // here be dragons
  }

> Could you expand? What will be the result of this expression with a
> concrete example?

The result type depends on the inputs, as it should. To employ a
particularly esoteric - but still valid - example, consider:

  auto t =3D tuple<double, int, complex<int>, double, char>{
             1.5, -3, {3, -4}, 2.0, 'a' };
  auto d =3D partial_manhattan_distance<1,99>(t);
  // d has type double, value 107

(Normally you would use such a function on a product type of homogeneous
types, e.g. an array, but so long as the addition operations and calls
to `abs` are well formed...)

> Is abs variadic? What are we expanding on the fold expression?

No; in the above example, the expression expands to (types elided):

  abs(-3) + abs({3, 4}) + abs(2.0) + abs('a');

....as it would for any parameter pack.

> 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?

Exactly.

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

No. First, because you then run afoul of trying to solve *what* product
type it should be (very hard), and second because it defeats the entire
purpose, which is *generalized unpacking*.

Again, the intent is a) to unpack product types into a parameter packs,
and b) to be able to slice *parameter packs*. They are combined because
IMO it makes more sense than to combine them than to not combine them.

IOW:

  [:]pt -> unpack product type
  [l:u]([:]pt) -> slice product type
  [l:u]pt -> combine redundant syntax

(Also, the latter may be slightly more optimization friendly, since it's
obvious that the compiler never needs to generate get<> for the
untouched elements.)

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

....and you can do that by wrapping the slice in a product type ctor,
which avoids the hard problem of solving (or enforcing) *what* product
type is returned.

Consider:

  struct Foo { int a; int b; string c; double d; };
  auto bar =3D make_slice<1,3>(Foo{...});

....what is the type of `bar`? It can't be a Foo, for obvious reasons,
and it can't be e.g. a std::array... but if we slice a std::array, we
would want a std::array back, wouldn't we? What about slicing an
Eigen::Vector4d; will make_slice give back an Eigen::Vector#d of
appropriate `#`? The OP's proposal either has to always return e.g.
std::tuple, or solve the complicated problem of picking an "appropriate"
type based on the input. In either case, it is likely that the decision
will be wrong for someone, somewhere. Producing a parameter pack avoids
this by deferring the problem to the user at point of use, where likely
the user *knows* what type is desired.

> P0341R0
> <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>
> talks about literal pack types, but they are IMO closer to product types
> than to parameter packs.

Somewhat off topic, but P0341R0 seems like a worse version of P0222R0
:-). (Well, the relevant part of it, anyway.)

--=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/58419917.8000105%40gmail.com.

.