220 34159 article Path: news.gmane.org!.POSTED!not-for-mail From: Curious Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Structured bindings with polymorphic lambdas Date: Sat, 26 Aug 2017 14:54:48 -0700 (PDT) Lines: 138 Approved: news@gmane.org Message-ID: References: <8497b31b-7c9d-4334-ac22-0809c958cb93@isocpp.org> <15a70d94-e039-4f82-ba01-bde9d3fbacbd@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_4823_1053186380.1503784489073" X-Trace: blaine.gmane.org 1503784493 13331 195.159.176.226 (26 Aug 2017 21:54:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 26 Aug 2017 21:54:53 +0000 (UTC) Cc: rmn100@gmail.com, zy@miator.net To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCNP5RVE2QIBBKO4Q7GQKGQE5YQ7SQI@isocpp.org Sat Aug 26 23:54:49 2017 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f197.google.com ([209.85.223.197]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dlj2S-0002xw-JS for gclcip-std-proposals@m.gmane.org; Sat, 26 Aug 2017 23:54:44 +0200 Original-Received: by mail-io0-f197.google.com with SMTP id c18sf26765602ioj.3 for ; Sat, 26 Aug 2017 14:54:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=zMZoaPF9eYG2Ef4Eg8zhdm+3bqAM0z89ueAfG2+VQQo=; b=z1wnfxdi1kFCldrz65IwiKwiWqfzFZQzyPpgbd7Q/+xvR/pbgT96yz9dceJRjpzrpJ HjoJapgKlAGBnyJ7VwCXmayw598kKhgk4Ju21lOeAA5bHEB4GXoG6LVRjhbUv+wTlXHX kECRuir3pPXhGm95l3j7oddadUkFCLkBTajRASq8P1Z01q5+cA6QfFUMtrNx1h+4hI5z zXTV4f0LJ03Eayx49MWHnpocgfhwVvqc7xm2BZ3CqPFFUQ70l3cb7AEmHl/U65qrvvoq 5dIgRjOra3qLb6GNHWzjmP7lw/dXc7yDbQ4qEDB6Dmi8+rLdlfWjRLM34vKvIYXY7HRw NgAg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:x-original-sender:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe; bh=zMZoaPF9eYG2Ef4Eg8zhdm+3bqAM0z89ueAfG2+VQQo=; b=Av0FVUikcsXySVWlrHol/oKTkS33JZJcKWFxoPWFor+CiqjXsJfxkRWGDElcWo+Q/L Z8XmwRtqL+8g4IYiRLS7xlq/WoovRAF+NKgm1b2Od0Tqvstk5xiKbVTsOBeeX+m146Zl ++AuVoDhuzy4Pfkqxs7Z62bc2QjlVJorT+wmme3hQjSHjTjSVS/17ddpyjlm3LbEAa/h mHJCYQUyPwvyES4x/QFhX8HFkXJ69XuUQ3T7nb8e1GicdkhIvU1JifH8Oa9uHajr4kNN wYDAoFXkySXfE7atjCrwwUnAC6uze96ORDjHao7LYwrx29P3QoU2VdeesWslheJCbpol 22yA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:x-original-sender:reply-to :precedence:mailing-list:list-id:x-spam-checked-in-group:list-post :list-help:list-archive:list-subscribe:list-unsubscribe; bh=zMZoaPF9eYG2Ef4Eg8zhdm+3bqAM0z89ueAfG2+VQQo=; b=S38u+vvSbsZYEJUUzMzwzNFBhDjmbogad2AUX5fJ1ETp+w3kh+ccp/ozopf1U1XmTT nvWI6eK8nLOvlpDMeTTOjxnDTJmdNy/76GbGw+VMLmTaK0+Dr5bwKSBshhubCiv04eZY X9gDoUeEc6a4PJNTT2kminawk1zDzhZmigpyEQIP6nOmTXKSYm8w3ELlTYM+s4doO/wc 4gPeHkx+PhFI0N3ht7+j1sNXepAzCO22i52XVsc+699TO9LRK6N2FkzML8iUXGAUcz4d ff3x6Qd6f6DbLGOw+N+WOSq2jS0lH2AymsApyJbAHM+AAbZEXsPTONt287MVtm8UuUkE XsjA== X-Gm-Message-State: AHYfb5jf4GPprSTqn5Pz2lNjjky43JFN6R5ColM4Y+xet1cIORprrRof 37P8p2t9eAEclqg/ X-Received: by 10.107.16.77 with SMTP id y74mr1981917ioi.126.1503784490804; Sat, 26 Aug 2017 14:54:50 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.142.67 with SMTP id q64ls7633299iod.47.gmail; Sat, 26 Aug 2017 14:54:49 -0700 (PDT) X-Received: by 10.31.160.13 with SMTP id j13mr29148vke.25.1503784489541; Sat, 26 Aug 2017 14:54:49 -0700 (PDT) In-Reply-To: X-Original-Sender: rmn100@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:34159 Archived-At: ------=_Part_4823_1053186380.1503784489073 Content-Type: multipart/alternative; boundary="----=_Part_4824_639189993.1503784489073" ------=_Part_4824_639189993.1503784489073 Content-Type: text/plain; charset="UTF-8" Yeah I intentionally defined it like that. In the expansion of the lambda the copy-init (if any) happens before the decomposition; the actual decomposition step happens inside the body of the function. This also fits the scope visibility issue that I mentioned. Did I leave something specified ambiguously? On Saturday, 26 August 2017 14:07:31 UTC-7, Zhihao Yuan wrote: > > On Fri, Aug 25, 2017 at 2:19 PM, Curious > > wrote: > > > >> Also, now you need to explicitly specify the order in which these > >> decompositions happen. That is, if you have two structured binding > >> parameters, which one gets decomposed first? At the very least, you > should > >> explicitly state that there is no order. > > > > In my mind they should follow the same order as for a regular function, > > with the decompositions happening in the same order as constructions of > the > > parameters. > > > > In your latest draft, you choose to decompose inside > function body, so I have a further suggestion: entirely > split the decomposition step from the parameter > copy-init step and define the decomposition order > to be left-to-right. > > [] (auto [a, b] /* underlying object x */, > auto [c, d] /* underlying object y */) {...} > > When invoking this function, copy-init x and y in > unspecific order, then decompose x into a and b, > then decompose y into c and d. This can further > simplify the model, because that will be no difference > from > > [] (auto x, auto y) {...} > > from the caller's point of view. > > -- > Zhihao Yuan, ID lichray > The best way to predict the future is to invent it. > _______________________________________________ > -- 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/f0a5b11a-7fb8-4243-a8c2-51a6aaaaf1d5%40isocpp.org. ------=_Part_4824_639189993.1503784489073 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yeah I intentionally defined it like that. =C2=A0In the ex= pansion of the lambda the copy-init (if any) happens before the decompositi= on; the actual decomposition step happens inside the body of the function. = =C2=A0This also fits the scope visibility issue that I mentioned. =C2=A0Did= I leave something specified ambiguously?

On Saturday, 26 August 20= 17 14:07:31 UTC-7, Zhihao Yuan wrote:
On Fri, Aug 25, 2017 at 2:19 PM, Curious <rmn...@gmail.com> wr= ote:
>
>> Also, now you need to explicitly specify the order in which th= ese
>> decompositions happen. That is, if you have two structured bin= ding
>> parameters, which one gets decomposed first? At the very least= , you should
>> explicitly state that there is no order.
>
> =C2=A0In my mind they should follow the same order as for a regula= r function,
> with the decompositions happening in the same order as constructio= ns of the
> parameters.
>

In your latest draft, you choose to decompose inside
function body, so I have a further suggestion: entirely
split the decomposition step from the parameter
copy-init step and define the decomposition order
to be left-to-right.

=C2=A0 [] (auto [a, b] /* underlying object x */,
=C2=A0 =C2=A0 =C2=A0 auto [c, d] /* underlying object y */) {...}

When invoking this function, copy-init x and y in
unspecific order, then decompose x into a and b,
then decompose y into c and d. =C2=A0This can further
simplify the model, because that will be no difference
from

=C2=A0 [] (auto x, auto y) {...}

from the caller's point of view.

--=20
Zhihao Yuan, ID lichray
The best way to predict the future is to invent it.
_______________________________________________

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/f0a5b11a-7fb8-4243-a8c2-51a6aaaaf1d5= %40isocpp.org.
------=_Part_4824_639189993.1503784489073-- ------=_Part_4823_1053186380.1503784489073-- .