220 29606 <5840659B.7050003@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: Thu, 1 Dec 2016 13:02:03 -0500
Lines: 56
Approved: news@gmane.org
Message-ID: <5840659B.7050003@gmail.com>
References: <490cad18-4302-4350-976f-2bc394a1a350@isocpp.org>
 <583F4A4F.7020708@gmail.com>
 <945de37f-352d-008f-a29b-d354999c6c4c@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
X-Trace: blaine.gmane.org 1480615329 17011 195.159.176.226 (1 Dec 2016 18:02:09 GMT)
X-Complaints-To: usenet@blaine.gmane.org
NNTP-Posting-Date: Thu, 1 Dec 2016 18:02:09 +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+bncBC37LBFWUIFBBHWLQHBAKGQEOQRZDKI@isocpp.org Thu Dec 01 19:02:04 2016
Return-path: <std-proposals+bncBC37LBFWUIFBBHWLQHBAKGQEOQRZDKI@isocpp.org>
Envelope-to: gclcip-std-proposals@m.gmane.org
Original-Received: from mail-qk0-f197.google.com ([209.85.220.197])
	by blaine.gmane.org with esmtp (Exim 4.84_2)
	(envelope-from <std-proposals+bncBC37LBFWUIFBBHWLQHBAKGQEOQRZDKI@isocpp.org>)
	id 1cCVgJ-0003H9-Gy
	for gclcip-std-proposals@m.gmane.org; Thu, 01 Dec 2016 19:02:03 +0100
Original-Received: by mail-qk0-f197.google.com with SMTP id y205sf185699081qkb.4
        for <gclcip-std-proposals@m.gmane.org>; Thu, 01 Dec 2016 10:02:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=isocpp-org.20150623.gappssmtp.com; s=20150623;
        h=subject:to:references:newsgroups: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=W1yPrc+nVULyOUWKkAqFM9UtSULydSDo0g/kTjwSoQQ=;
        b=wGg/AuFQlmy9s+xpr+0lrBYF/gS2D9I+RW66N++wIQM5iTmO9Aa493VNU9wnM3pDgG
         etC4LmONVNt0w2J6DtytrYxF7356Yh/G/s2laPQ4zgosFUCMuQMYHbCpsIBZUJygqsSr
         y5S4rQU5ZFLTn6/FCH0MU32bGbhgqWVLCRvciSAnXBGzE50+UmDQxBQSCsWrm7C2NXmj
         2QDeh+ITsXCkumjci4kWyxF2CbfIuVGkcrgHWJ8ibTYQ+ksVcjxRx8mqkhRw3tMAjnpr
         fRnxdaWDPKzgMKoCNa/mlAjm2PVr+utZL/zf8iKmspDQ0KmBi6Udcod8r2FqsapTmnDJ
         nVqw==
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:newsgroups: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=W1yPrc+nVULyOUWKkAqFM9UtSULydSDo0g/kTjwSoQQ=;
        b=gxC6iC02ZQOinQ0mTUhXaWN1PMz2wiGb2hrel9PZHX99N23vzosh2psembO3KC9D/E
         fRZ8lBA0HSXyW8RCJTlrXQj0TRjy5NgnvPhrFZzmZODhDACfBP49Bw7m1iMC0gZoUXA7
         /yBOIL5tVncnioVpIbEi0wUGhm5FM5ubPQNNQAsG1FzvJRRfZq78wqEW7sqORNh8AgeF
         KEfAX1ukRmxDA38kJQVgdYH7ofqrRUMLBm+5a+ZzNsy9fa+VWerOeKcuVYxMqGxCZq/N
         Pw6XiSG2GD05AUX0xE4gAP4X+uDOUFJmhQNmWyP47fiFzbC8PzMD2BrmaCek2NaANu6Z
         MLEQ==
X-Gm-Message-State: AKaTC00rS7nQS693+v6Q/eJgqwIzDs7SewQmHwP6u1+sqtqg/SPPqxFw3zWoCcDK19+Pxg==
X-Received: by 10.157.20.236 with SMTP id r41mr8588636otr.29.1480615327165;
        Thu, 01 Dec 2016 10:02:07 -0800 (PST)
X-BeenThere: std-proposals@isocpp.org
Original-Received: by 10.157.43.24 with SMTP id o24ls17753012otb.41.gmail; Thu, 01 Dec
 2016 10:02:06 -0800 (PST)
X-Received: by 10.55.20.164 with SMTP id 36mr33301197qku.86.1480615326385;
        Thu, 01 Dec 2016 10:02:06 -0800 (PST)
Original-Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com. [2607:f8b0:400d:c0d::22b])
        by mx.google.com with ESMTPS id t7si742475qtc.66.2016.12.01.10.02.06
        for <std-proposals@isocpp.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 01 Dec 2016 10:02:06 -0800 (PST)
Received-SPF: pass (google.com: domain of mwoehlke.floss@gmail.com designates 2607:f8b0:400d:c0d::22b as permitted sender) client-ip=2607:f8b0:400d:c0d::22b;
Original-Received: by mail-qt0-x22b.google.com with SMTP id p16so227782586qta.0
        for <std-proposals@isocpp.org>; Thu, 01 Dec 2016 10:02:06 -0800 (PST)
X-Received: by 10.200.45.6 with SMTP id n6mr35193079qta.220.1480615325822;
        Thu, 01 Dec 2016 10:02:05 -0800 (PST)
Original-Received: from [192.168.1.173] (tripoint.kitware.com. [66.194.253.20])
        by smtp.googlemail.com with ESMTPSA id d15sm665881qkb.10.2016.12.01.10.02.05
        for <std-proposals@isocpp.org>
        (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
        Thu, 01 Dec 2016 10:02:05 -0800 (PST)
Original-Newsgroups: gmane.comp.lang.c++.isocpp.proposals
In-Reply-To: <945de37f-352d-008f-a29b-d354999c6c4c@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:c0d::22b 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:29606
Archived-At: <http://permalink.gmane.org/gmane.comp.lang.c++.isocpp.proposals/29606>

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 `<operator> <operand>`
(more specifically, `[<index-expression>]<operand>`, 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.

> While this could be user friendly, it doesn't compose well in generic
> code.

Can you elaborate?

> BTW, would slicing [I1,I2]pt... return a pack or a product 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...)`. 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);
  }

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

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). 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).

-- 
Matthew

-- 
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 email 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/5840659B.7050003%40gmail.com.

.