220 24089 <20160130173553.4898897.39320.4122@gmail.com> article Path: news.gmane.org!not-for-mail From: Tony V E Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: RFC: Unpacking tuples to value sequences Date: Sat, 30 Jan 2016 12:35:53 -0500 Lines: 385 Approved: news@gmane.org Message-ID: <20160130173553.4898897.39320.4122@gmail.com> References: <29e7b2a0-05fb-46e2-92bc-2a83f8a1e53c@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1454175379 21592 80.91.229.3 (30 Jan 2016 17:36:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Jan 2016 17:36:19 +0000 (UTC) To: Arthur O'Dwyer , std-proposals@isocpp.org Original-X-From: std-proposals+bncBCUZ5QWKNQIPZ2FTWUCRUBDVMQ5UO@isocpp.org Sat Jan 30 18:36:02 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f72.google.com ([209.85.218.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aPZRG-0005dK-Qy for gclcip-std-proposals@m.gmane.org; Sat, 30 Jan 2016 18:35:59 +0100 Original-Received: by mail-oi0-f72.google.com with SMTP id i14sf136050405oig.2 for ; Sat, 30 Jan 2016 09:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references: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=Zo6uS5smKQ4dHKBqQ0N6rFHLs2Jilf3K0BtYEKZAqpE=; b=fBHH0XA6UMJe4GcKHshIw5o+zpprIZmnoh4Npo+zDYA60MsHNVd41y1/UHB80REDMv l0nYIIvDj7gMIWfCLycADeEpoXK+DBW/84PjWfiJYpdvzBK/1F8a1P+5LKCuMBz432yN yI70gljfuZsBcHaofuEMiaYm6kAfWHTUJsrMVpXVb6FzBK/jSNj+3QObH68ZwDyxNz9L Nip7RR0XgjDiJJeeYBkQpaeVTQIKUH7VArdy+LZ8YiHurOnz1MDvX9GFPJwmCW75p/HE nXDhmsXFu5YLkOJUQsDN8R6Dkjv5YEfK8Csti5dBSiDo8J/Fv2dbHq4cBsWkgHeyYl8Z X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:message-id:date:subject:from:in-reply-to :references: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=Zo6uS5smKQ4dHKBqQ0N6rFHLs2Jilf3K0BtYEKZAqpE=; b=MzpJBeS412IQAZRrlAx6WCnC4/lhDzmRx4/2DKdSMGhN2VacI6N+usJvhN8CntFkpi t7c4G4q8VRQ9xEa7C16P5FWZle0u10jMnVAVn+H7VRz2QQcjnyPi528BRiVwUwxBD9P1 LOlJaZHJ2iGt2VYOZ7WMr7HwXpzWI3X/KFsSF+Yf0m7xtTSwUs9P3+1cVOZnHwRVu/6S TprjWO6DbVO+83LLgU4gs7vINFizKHcc/Ockm7detkDZp/KQRDReCmk5oY2g7uVP7mTf o+5K+Md4CePWFZjY0mp2rRJUbA/X5U8V2YjPc8P5dQs/oXcqXWd6ktq4yAjDtZObXIEs X-Gm-Message-State: AG10YOSLX3nGkReChltnkSJO9GA09wrh+itvi5yq/P9jI5llfkd6lW30SsdKKmcziBtWjg== X-Received: by 10.107.14.141 with SMTP id 135mr15447790ioo.22.1454175357830; Sat, 30 Jan 2016 09:35:57 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.40.164 with SMTP id x33ls3045406qgx.8.gmail; Sat, 30 Jan 2016 09:35:56 -0800 (PST) X-Received: by 10.140.166.198 with SMTP id m189mr18719824qhm.35.1454175356464; Sat, 30 Jan 2016 09:35:56 -0800 (PST) Original-Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com. [2607:f8b0:400d:c09::22e]) by mx.google.com with ESMTPS id e5si23206465qga.29.2016.01.30.09.35.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 Jan 2016 09:35:56 -0800 (PST) Received-SPF: pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:400d:c09::22e as permitted sender) client-ip=2607:f8b0:400d:c09::22e; Original-Received: by mail-qk0-x22e.google.com with SMTP id x1so36388194qkc.1 for ; Sat, 30 Jan 2016 09:35:56 -0800 (PST) X-Received: by 10.55.82.137 with SMTP id g131mr18468592qkb.66.1454175356273; Sat, 30 Jan 2016 09:35:56 -0800 (PST) Original-Received: from [127.0.0.1] ([24.114.52.72]) by smtp.gmail.com with ESMTPSA id 63sm9631304qgy.45.2016.01.30.09.35.54 for (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jan 2016 09:35:54 -0800 (PST) X-Mailer: BlackBerry Email (10.3.2.2876) In-Reply-To: X-Original-Sender: tvaneerd@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of tvaneerd@gmail.com designates 2607:f8b0:400d:c09::22e as permitted sender) smtp.mailfrom=tvaneerd@gmail.com; dkim=pass header.i=@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: X-Spam-Checked-In-Group: std-proposals@isocpp.org 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:24089 Archived-At: =
IMO

mpl::vector is a "type-list"std::tuple is a "tuple-like"=E2=80=8E= (and also a type-list) - a typelist with values

Can = we use those terms going forward?


Any place you are doing meta-programming an= d need a type-list you _could_ use std::tuple, and the value part of tuple = is ignored without penalty, as you are just doing compile-time type stuff. =

HOWEVER, it is confusing to the reader. We need an a= ctual std::typelist

At which point mpl::vector become= s "typelist-like" :-(
(ie we = need to be careful about naming our types and our concepts the same thing o= r not)

And I hate std::get. I wish it was called tu= ple_get. Particularly if we start to use it as a syntax-sugar extension poi= nt (like range-for and begin/end)

=E2=80=8EJust my tw= o cents. Carry on. 
Tony=

= =

= = =
Sent from my BlackBe= rry portable Babbage Device
= = =
From: Arthur O'Dw= yer
Sent: Monday, January 25, 2016 2:37 PM
To= : std-proposals@isocpp.org
Reply To: std-proposals@iso= cpp.org
Subject: Re: [std-proposals] Re: RFC: Unpacking tu= ples to value sequences

On Mon, Jan 25, 2016 at 9:20 AM, Matthew Woehlke <mwo= ehlke.floss@gmail.com> wrote:
<= div class=3D"gmail_quote">
On 2016-01-25 1= 1:25, Ville Voutilainen wrote:
> On 25 January 2016 at 17:32, Matthew Woehlke <mwoehlke.floss@gmail.com> wrote:
>> = On 2016-01-20 18:13, Arthur O'Dwyer wrote:
>>> would [mpl::vector] *not* be "tuple-like" because you couldn't= use
>>> std::get<I> on it at runtime?
>>
>> ...but then, I don't understand why that would be true?
>>
>> Back to that question, yes, the idea as I understand it is that >> "tuple-like" <=3D> "can use get<N>". Why is that an is= sue?
>
> mpl::vector is a container of types, not values. get<N> is a val= ue-getter.

Ah. Um... how would you then *use* an mpl::vector in any context tha= t
you would use a tuple-like? A std::tuple is certainly a value
collection. By extension, a tuple-like is also a value collection.

As I explained in my original post, it seems ob= vious that we'd define

template< class... Types >

class tupl= e_size< mp= l::vector<Types...> >

 : public std::integral_constant<std::size_t, sizeof...(Types)<= span class=3D"" style=3D"line-height:1.1em;margin:0px;padding:0px;color:rgb= (0,0,128);font-family:DejaVuSansMono,'DejaVu Sans Mono',courier,monospace;f= ont-size:13px;white-space:nowrap">> {=  };

and also

// = recursive case template< std::size_t I, class= Head, class... Tail > struct tuple_element<I, mpl::vector<Head, Tail...>> : std::tuple_elemen= t<I-1, mpl::vector&= lt;Tail...>> { }; // base case template< class Head, class... Tail > struct tuple_element<0, mpl::vector<Head, Tail...>> { typedef Head type; 
};

=
The "Sprout" C++14 library includes these definitions today.
https://github.com/bolero-MURAKAMI/Sprout/blob/mas= ter/sprout/type/boost/mpl/vector.hpp

Howev= er, there's no such "obvious" definition for std::get.
The most p= lausible one would be

// please stifle all irreleva=
nt comments re: overload sets and CV-qualifiers
template< std::size_t I, class... = Types >

auto ge= t(const = mpl::vector<Types...>&)<= /span>

   -> std::add_rvalue_reference_t<tuple_element_t<I,mpl::vector<= Types...>>>;

// deliberately left with no impl=
ementation, a la std::declval
So what we're left with is: mpl::vector is "not tuple-like", but it does impleme= nt tuple_size_v and tuple_element_t.
The only part o= f the "tuple-like" contract that it fails to have an obvious implementation= for is the one part of the "tuple-like" contract whose name doesn't inv= olve the word "tuple".
That is why the concept of "tup= le-like" bothers me.

=E2=80=93Arthur

--

---
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-proposa= ls+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.

--

---
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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
.