220 29607 <db477ff7-beb6-e2de-d4ca-6a3c6a313da5@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: Thu, 1 Dec 2016 23:25:06 +0100
Lines: 282
Approved: news@gmane.org
Message-ID: <db477ff7-beb6-e2de-d4ca-6a3c6a313da5@wanadoo.fr>
References: <490cad18-4302-4350-976f-2bc394a1a350@isocpp.org>
 <583F4A4F.7020708@gmail.com>
 <945de37f-352d-008f-a29b-d354999c6c4c@wanadoo.fr>
 <e3a2acfe-dbb6-4f8f-84da-8debda38a4fc@isocpp.org>
Reply-To: std-proposals@isocpp.org
NNTP-Posting-Host: blaine.gmane.org
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="------------E96931727EE18E9157AA2AE1"
X-Trace: blaine.gmane.org 1480631121 18050 195.159.176.226 (1 Dec 2016 22:25:21 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Thu, 1 Dec 2016 22:25:21 +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+bncBDH67CONY4PBBRWGQLBAKGQEL2ZCZCA@isocpp.org Thu Dec 01 23:25:14 2016
Return-path: <std-proposals+bncBDH67CONY4PBBRWGQLBAKGQEL2ZCZCA@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+bncBDH67CONY4PBBRWGQLBAKGQEL2ZCZCA@isocpp.org>)
	id 1cCZmt-00032I-Bs
	for gclcip-std-proposals@m.gmane.org; Thu, 01 Dec 2016 23:25:07 +0100
Original-Received: by mail-lf0-f71.google.com with SMTP id 98sf101000129lfs.0
        for <gclcip-std-proposals@m.gmane.org>; Thu, 01 Dec 2016 14:25:11 -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=W+wT5EwdnjAgWfw5KsL42p5JY8k34hfOx7FiMpFEgLI=;
        b=SvElATN4Y2GIjBt+kMYR0VQYFMIBsv10GRT8i9GrcSN39xIn1o/MVPFGrP2PFTpKcA
         y3Ba+B40B3cdZ8KrCIgZEOAPjBm4nrcv/q9IzEMduE5CtOKbzpR6XktJ18F98UFoYjjl
         htN6xQW1eu/18CT0hOr0BQROIqo6HrXT2HDOI2F6xH6Gr4cbGxoe93229dBx+8VpeYHX
         IudfNOHqv3cDlwFsgfP/QdO5Y944CsLYgcv4RXProP+PT6wnp7plx2S+Y75tUYyTsana
         dgolfSLDPAFTWFECgma610RWTIdb8OKLoBIbfpmc8eic566Y171+Q8qDk8TEBQuLcOK5
         yaBg==
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=W+wT5EwdnjAgWfw5KsL42p5JY8k34hfOx7FiMpFEgLI=;
        b=KriEnK4zzBDUyUvJUeltml2Enot+w977UWIIx+TAuDfYv+fHTQqfiyYWOvfcYXrkpE
         WDt6lJwvvtbIBFWqZHjqTNwQTCcmDZ2SnfVHIx/bMA2bi3VGS5GlA4lV21Lo+UBwlfSP
         nSjO0wUcTiw/h3gZBjLkj/RHSLDw3rOOWLYNtUnC4e89ydLbWydziDyGbAi3Vkby+e9d
         Efj401uHOfOCoP+E5MIR1MJpjAaIrBd0EM0xLYkY0vBDEQDV5SNGEFAtl81AopEweXcR
         P9hCOIa/ZqTyA8UVHaGctfBtqvDuN+YcFN7y8gPSAeXnkISsE+eglBxQAYS9AuKvGb3a
         3Ahw==
X-Gm-Message-State: AKaTC00w24OHQe8qsIFUa7e61o2mfUij6WbqeapT/104uajTwHuGAk9WADYOyPNrDWI3qQ==
X-Received: by 10.46.33.154 with SMTP id h26mr5933424lji.2.1480631111426;
        Thu, 01 Dec 2016 14:25:11 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.28.37.4 with SMTP id l4ls6427wml.19.canary-gmail; Thu, 01 Dec
 2016 14:25:10 -0800 (PST)
X-Received: by 10.28.19.67 with SMTP id 64mr11736wmt.111.1480631107558;
        Thu, 01 Dec 2016 14:25:07 -0800 (PST)
Original-Received: from smtp.smtpout.orange.fr (smtp04.smtpout.orange.fr. [80.12.242.126])
        by mx.google.com with ESMTPS id jd4si2181269wjb.273.2016.12.01.14.25.07
        for <std-proposals@isocpp.org>
        (version=TLS1 cipher=AES128-SHA bits=128/128);
        Thu, 01 Dec 2016 14:25:07 -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 EmR61u00C11EX3q03mR6Al; Thu, 01 Dec 2016 23:25:07 +0100
X-ME-Helo: imac-de-vicente-botet-escriba.home
X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy
X-ME-Date: Thu, 01 Dec 2016 23:25:07 +0100
X-ME-IP: 86.214.78.47
In-Reply-To: <e3a2acfe-dbb6-4f8f-84da-8debda38a4fc@isocpp.org>
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: <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:29607
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/29607>

This is a multi-part message in MIME format.
--------------E96931727EE18E9157AA2AE1
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

Le 01/12/2016 =C3=A0 01:23, Nicol Bolas a =C3=A9crit :
>
>
> On Wednesday, November 30, 2016 at 5:41:18 PM UTC-5, Vicente J. Botet=20
> Escriba wrote:
>
>     Le 30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :
>     > On 2016-11-30 16:04, =CE=9D=CE=B9=CE=BA=CF=8C=CE=BB=CE=B1=CE=BF=CF=
=82 =CE=91=CE=B8=CE=B1=CE=BD=CE=B1=CF=83=CE=AF=CE=BF=CF=85 wrote:
>     >> Just floating the idea before composing the complete text. I
>     recently *blogged
>     >>
>     <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/
>     <https://ngathanasiou.wordpress.com/2016/11/28/want-a-std-slice/>>*ab=
out
>     a
>     >> hypothetical tuple slice functionality (and related design
>     considerations)
>     >> and it seems useful & simple enough (conceptually and
>     implementation wise)
>     >> to be added in isolation to the Standard library (it may just
>     have been
>     >> overlooked in previous versions, I couldn't find related
>     proposals).
>     > If we had generalized slicing, would the proposed library
>     function offer
>     > anything superior to `std::make_tuple([I1:I2]product_type...)`?
>     >
>     > (Generalized slicing would work both on *any* product type, as
>     well as
>     > on parameter packs, so in at least that sense, it is superior to a
>     > library function that operates only on std::tuple.)
>     >
>     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. I'm not saying that I'm against, just that we
>     don't
>     have yet a clear proposal for this common access. While this could be
>     user friendly, it doesn't compose well in generic code.
>
>     I believe it is worth defining algorithms that do whatever we want
>     independently of the precise implementation and the possible language
>     evolution.
>
>     I'm considering defining some kind of ProductType views as we
>     could have
>     Range views. product_type::slice<I1,I2>(pt) could return a lazy
>     product_type::slice_view<I1,I2, PT>. This should be more efficient,
>     needs to store a reference to the ProductType instead to a
>     reference to
>     each one of the elements of the product type. Sorry, but I don't have
>     neither a draft paper nor an implementation to show yet.
>
>     What do you think of this suggested product type views?
>
>     BTW, would slicing [I1,I2]pt... return a pack or a product type?
>     Or a view?
>
>
> It is none of those:
>
> * `pt` is an expression that results in a "product type".
>
> * `[:]pt` is a product type pack, which is behaviorally identical to a=20
> parameter pack, save the fact that it unpacks into a sequence of=20
> `get<i>(pt)` calls.
>
> * `[I1:I2]pt` is a product type pack that goes from `get<I1>` to=20
> `get<I2>`, rather than across the entire range of `pt`.
>
> * `[I1:I2]pt...` unpacks the pack, which works exactly like unpacking=20
> a parameter pack.

Sorry, I was thinking on
P0341R0=20
<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.html>=20
parameter packs outside of templates


where the operator ... can be overloaded for UDT.

And then [I1:I2] taken a slice of  the pack expansion, possibly=20
resulting in a product-type again ;-)

I was surely mixing conflicting 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/db477ff7-beb6-e2de-d4ca-6a3c6a313da5%40wanadoo.f=
r.

--------------E96931727EE18E9157AA2AE1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>
    <meta content=3D"text/html; charset=3Dutf-8" http-equiv=3D"Content-Type=
">
  </head>
  <body bgcolor=3D"#FFFFFF" text=3D"#000000">
    <div class=3D"moz-cite-prefix">Le 01/12/2016 =C3=A0 01:23, Nicol Bolas =
a
      =C3=A9crit=C2=A0:<br>
    </div>
    <blockquote
      cite=3D"mid:e3a2acfe-dbb6-4f8f-84da-8debda38a4fc@isocpp.org"
      type=3D"cite">
      <div dir=3D"ltr"><br>
        <br>
        On Wednesday, November 30, 2016 at 5:41:18 PM UTC-5, Vicente J.
        Botet Escriba wrote:
        <blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:
          0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">Le
          30/11/2016 =C3=A0 22:53, Matthew Woehlke a =C3=A9crit :
          <br>
          &gt; On 2016-11-30 16:04, =CE=9D=CE=B9=CE=BA=CF=8C=CE=BB=CE=B1=CE=
=BF=CF=82 =CE=91=CE=B8=CE=B1=CE=BD=CE=B1=CF=83=CE=AF=CE=BF=CF=85 wrote:
          <br>
          &gt;&gt; Just floating the idea before composing the complete
          text. I recently *blogged
          <br>
          &gt;&gt; &lt;<a moz-do-not-send=3D"true"
            href=3D"https://ngathanasiou.wordpress.com/2016/11/28/want-a-st=
d-slice/"
            target=3D"_blank" rel=3D"nofollow"
onmousedown=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fn=
gathanasiou.wordpress.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD=
\x26sntz\x3d1\x26usg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return
            true;"
onclick=3D"this.href=3D'https://www.google.com/url?q\x3dhttps%3A%2F%2Fngath=
anasiou.wordpress.com%2F2016%2F11%2F28%2Fwant-a-std-slice%2F\x26sa\x3dD\x26=
sntz\x3d1\x26usg\x3dAFQjCNHKdHZP3i-sb9B8mj2zsgcFU8wugA';return
            true;">https://ngathanasiou.<wbr>wordpress.com/2016/11/28/want-=
<wbr>a-std-slice/</a>&gt;*about
          a
          <br>
          &gt;&gt; hypothetical tuple slice functionality (and related
          design considerations)
          <br>
          &gt;&gt; and it seems useful &amp; simple enough (conceptually
          and implementation wise)
          <br>
          &gt;&gt; to be added in isolation to the Standard library (it
          may just have been
          <br>
          &gt;&gt; overlooked in previous versions, I couldn't find
          related proposals).
          <br>
          &gt; If we had generalized slicing, would the proposed library
          function offer
          <br>
          &gt; anything superior to `std::make_tuple([I1:I2]<wbr>product_ty=
pe...)`?
          <br>
          &gt;
          <br>
          &gt; (Generalized slicing would work both on *any* product
          type, as well as
          <br>
          &gt; on parameter packs, so in at least that sense, it is
          superior to a
          <br>
          &gt; library function that operates only on std::tuple.)
          <br>
          &gt;
          <br>
          I agree that new algorithms should work on ProductTypes
          [P0327R1]. It is <br>
          not yet clear =C2=A0to me how we would have the same syntax for
          ProductTypes <br>
          and parameter packs. I'm not saying that I'm against, just
          that we don't <br>
          have yet a clear proposal for this common access. While this
          could be <br>
          user friendly, it doesn't compose well in generic code.
          <br>
          <br>
          I believe it is worth defining algorithms that do whatever we
          want <br>
          independently of the precise implementation and the possible
          language <br>
          evolution.
          <br>
          <br>
          I'm considering defining some kind of ProductType views as we
          could have <br>
          Range views. product_type::slice&lt;I1,I2&gt;(pt) could return
          a lazy <br>
          product_type::slice_view&lt;I1,<wbr>I2, PT&gt;. This should be
          more efficient, <br>
          needs to store a reference to the ProductType instead to a
          reference to <br>
          each one of the elements of the product type. Sorry, but I
          don't have <br>
          neither a draft paper nor an implementation to show yet.
          <br>
          <br>
          What do you think of this suggested product type views?
          <br>
          <br>
          BTW, would slicing [I1,I2]pt... return a pack or a product
          type? Or a view?
          <br>
        </blockquote>
        <div><br>
          It is none of those:<br>
          <br>
          * `pt` is an expression that results in a "product type".<br>
          <br>
          * `[:]pt` is a product type pack, which is behaviorally
          identical to a parameter pack, save the fact that it unpacks
          into a sequence of `get&lt;i&gt;(pt)` calls.<br>
          <br>
          * `[I1:I2]pt` is a product type pack that goes from
          `get&lt;I1&gt;` to `get&lt;I2&gt;`, rather than across the
          entire range of `pt`.<br>
          <br>
          * `[I1:I2]pt...` unpacks the pack, which works exactly like
          unpacking a parameter pack.</div>
      </div>
    </blockquote>
    <br>
    Sorry, I was thinking on
    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf-8=
">
    <table border=3D"1">
      <tbody>
        <tr>
          <td><a
href=3D"http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0341r0.htm=
l">P0341R0</a>
          </td>
          <td> parameter packs outside of templates</td>
        </tr>
      </tbody>
    </table>
    <br>
    where the operator ... can be overloaded for UDT.<br>
    <br>
    And then [I1:I2] taken a slice of=C2=A0 the pack expansion, possibly
    resulting in a product-type again ;-)<br>
    <br>
    I was surely mixing conflicting proposals.<br>
    <br>
    Vicente<br>
    <br>
  </body>
</html>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/db477ff7-beb6-e2de-d4ca-6a3c6a313da5%=
40wanadoo.fr?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.=
com/a/isocpp.org/d/msgid/std-proposals/db477ff7-beb6-e2de-d4ca-6a3c6a313da5=
%40wanadoo.fr</a>.<br />

--------------E96931727EE18E9157AA2AE1--

.
