220 29671 <b6286db3-251a-d59e-acf7-f5b1daa624bd@wanadoo.fr> article
Path: news.gmane.org!.POSTED!not-for-mail
From: "Vicente J. Botet Escriba" <vicente.botet@wanadoo.fr>
Newsgroups: gmane.comp.lang.c++.isocpp.proposals
Subject: Re: Re: Add a "tuple_slice" function in <tuple>
Date: Mon, 5 Dec 2016 22:21:42 +0100
Lines: 167
Approved: news@gmane.org
Message-ID: <b6286db3-251a-d59e-acf7-f5b1daa624bd@wanadoo.fr>
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>
 <58419917.8000105@gmail.com>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Trace: blaine.gmane.org 1480972907 4175 195.159.176.226 (5 Dec 2016 21:21:47 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Mon, 5 Dec 2016 21:21:47 +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+bncBDH67CONY4PBB2NUS7BAKGQENDKW5RI@isocpp.org Mon Dec 05 22:21:42 2016
Return-path: <std-proposals+bncBDH67CONY4PBB2NUS7BAKGQENDKW5RI@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-lf0-f71.google.com ([209.85.215.71])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <std-proposals+bncBDH67CONY4PBB2NUS7BAKGQENDKW5RI@isocpp.org>)
	id 1cE0hh-0000UG-Fl
	for gclcip-std-proposals@m.gmane.org; Mon, 05 Dec 2016 22:21:41 +0100
Original-Received: by mail-lf0-f71.google.com with SMTP id 98sf129527831lfs.0
        for <gclcip-std-proposals@m.gmane.org>; Mon, 05 Dec 2016 13:21:45 -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=nrL0O3yh0nIqGLbj+jxuywzT+Woi1F8/IAIIa1dagsU=;
        b=U+NwgiKtpp19HvMtQPYoAGdlJsCwygqRUPy6Daqzamh2Q/0i9dLJH+jkECxg54CGEy
         cpXZeEvKaJg0W8yJBtNv3PUN7H+R6V5osyYd3Awbkwzx9fHj4uG4CUBEtt12PfVPtMtn
         dpQhkW1F0TeKAkq/Dm/OHPXdSHGSucXNoWALXf2WZSOAsYuRurU4h8AWszY6ohUTQgE5
         66Ysor9oI3A0c4fOexa2FtuVm6DGaR6Q7S7t+Z4CjNn/hMLLVBtBHPnBYeyfgKJYR2zw
         R1MU3jm1tY1WuVUXwSiCa3YCAwAVvUI/b9PKqO3YhAmzB2SD0qSa/7rl5WAMan98cnDe
      
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=nrL0O3yh0nIqGLbj+jxuywzT+Woi1F8/IAIIa1dagsU=;
        b=FavDQLdVI0pqp1tWME3eBr+SmVcNwGiwYDBZwuNjuuJRlqLY1g6GTxg1MuULLcgX2d
         uNe0E1hP8Lj9yBrBlGdVPBji+4x455QqMBbm7AZ9x5l/AzUnjokl6R6ZfXZ62ffqdZRg
         pUH9MNM/HNq1a9C6OfTco1tgNjqRr1h7QJEIfdqb+uA4lW4Qd2JefBNb8Y7TgX69lmsX
         2VedFPzALZQklGiOOCtZ1lAmA+K5y13ufLhEl8pY0boY2/a7YDOEFU2sz1aM7WVcQBio
         36+Z7QTY4NdxSdEtuW761UZsUAWOKfWvCpSH99sUwvOXekGmdVotELMqtnL61je6IFl8
  
X-Gm-Message-State: AKaTC01H2ekfKOIgBmw17yTY/JQq1L1P4a9t4yrcytFTGXirUxLYyC//hxp2wP7wL/A+2Q==
X-Received: by 10.25.157.71 with SMTP id g68mr4970635lfe.8.1480972905707;
        Mon, 05 Dec 2016 13:21:45 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.28.29.68 with SMTP id d65ls1432707wmd.18.canary-gmail; Mon, 05
 Dec 2016 13:21:44 -0800 (PST)
X-Received: by 10.28.91.143 with SMTP id p137mr11635183wmb.51.1480972904639;
        Mon, 05 Dec 2016 13:21:44 -0800 (PST)
Original-Received: from smtp.smtpout.orange.fr (smtp08.smtpout.orange.fr. [80.12.242.130])
        by mx.google.com with ESMTPS id h17si16484029wjq.274.2016.12.05.13.21.44
        for <std-proposals@isocpp.org>
        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Mon, 05 Dec 2016 13:21:44 -0800 (PST)
Received-SPF: neutral (google.com: 80.12.242.130 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.130;
Original-Received: from imac-de-vicente-botet-escriba.home ([2.13.32.114])
	by mwinf5d43 with ME
	id GMMj1u00a2TkMyS03MMkub; Mon, 05 Dec 2016 22:21:44 +0100
X-ME-Helo: imac-de-vicente-botet-escriba.home
X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy
X-ME-Date: Mon, 05 Dec 2016 22:21:44 +0100
X-ME-IP: 2.13.32.114
In-Reply-To: <58419917.8000105@gmail.com>
X-Original-Sender: vicente.botet@wanadoo.fr
X-Original-Authentication-Results: mx.google.com;       spf=neutral
 (google.com: 80.12.242.130 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: <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:29671
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/29671>

Le 02/12/2016 =C3=A0 16:53, Matthew Woehlke a =C3=A9crit :
> 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); }
You need an additional indirection as slice has no template parameter T,=20
but yes we can define them using a language feature, but this is an=20
implementation detail.
Note that the result of slice could be view on a product type and so=20
there is no need to copy on another product type as std::tuple.
I don't think we want each user to define them as it is not so simple.=20
See range-v3.
>> 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  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.
It could be an optional parameter(see below) :)
> 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...
I see now where it was done the expansion.
> 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
>    }
  v | stride<I1,I2> | accumulate

The goal been that the previous expression is as efficient as if it was=20
hand written using whatever feature in the language.
I we cannot do that, there is something wrong on the ability to make=20
high abstractions.
>
>> 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.)
I'll need to check once we have a compiler providing the feature ;-)
>> 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`?
Compile error.

   auto bar =3D make_slice<1,3, std::tuple>(Foo{...});

The result is a tuple here.

The same applies to transform a product type

   auto bar =3D pt::transform<std::tuple>(Foo{...}, NFct);

When the product type is a template as tuple, pair

   auto bar =3D transform(aTuple, NFct);

the result is a tuple, pair.

The same could apply to std::array.


> 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.
Maybe you are right. The problem I see is that functions cannot return=20
parameter packs as them are no types and so this makes composition more=20
difficult.
>
>> 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.)
>
I like P0341 mainly on how it transforms a parameter pack on a pack type=20
that we can return from a function. I believe it is essential to have a=20
type associated to an aggregate expression.

There are parts that are yet on a draft more in this proposal so I can=20
not comment yet.

Up to you to elaborate on a comparison of both proposals.


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/b6286db3-251a-d59e-acf7-f5b1daa624bd%40wanadoo.f=
r.

.