220 28825 <4ecaea2b-35d0-4c1b-706c-9f1d668b112d@wanadoo.fr> article Path: news.gmane.org!.POSTED!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Structured Bindings for all the Aggregates Date: Fri, 14 Oct 2016 08:57:42 +0200 Lines: 343 Approved: news@gmane.org Message-ID: <4ecaea2b-35d0-4c1b-706c-9f1d668b112d@wanadoo.fr> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------EF0EE0983CFA271E9ECB133F" X-Trace: blaine.gmane.org 1476428286 19128 195.159.176.226 (14 Oct 2016 06:58:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 14 Oct 2016 06:58:06 +0000 (UTC) User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBB2EDQLAAKGQEAYFG77I@isocpp.org Fri Oct 14 08:58:01 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f70.google.com ([209.85.215.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1buwR5-000214-0h for gclcip-std-proposals@m.gmane.org; Fri, 14 Oct 2016 08:57:43 +0200 Original-Received: by mail-lf0-f70.google.com with SMTP id b81sf64197407lfe.1 for ; Thu, 13 Oct 2016 23:57:45 -0700 (PDT) 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=LgVtUhgnh6God1wukfl79KUH4nFN3Ib5Kh2HdSLvFqw=; b=njHHz1APmM4H4hKcKUFw1MACOAUEvT+bjLQdsXr1OcrARuddB8U6/JsXn59LHeOSmX GceNzQfzGY5IOmdtt5eJdYPEJJIvaFYqgbdoMtH1kGD63+L/ENrade4zqeEtao2bJf6u mcVYLCTvTSNX6LIJn0qDQHs74XRULeL3qpoyIgRFIQFTHHQzQIdO7y1r9JV18z0rvxQp +UYkle0nhXJK/tIUmUTbgmkpYtZr5aq7Np/YiCRrnrdHjrYc6i28dqj0r8cdJkqJz473 g7I/2dOMqHexXinZQ9Vkz6sVp0cOBQNmb+kGwBajgFHZQH3oe5PW87SP5BGz73YBiobQ +vKw== 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=LgVtUhgnh6God1wukfl79KUH4nFN3Ib5Kh2HdSLvFqw=; b=kbzAzWmxiW+JKD4jLcwmmnv8vPW4OZzWmFUIFx31WQvJlCvHqHdX3ZTYEUlLXl7KZ3 xIqOlrk+cRl0P0fhTg13JBaVN/FzIiUH072+roHT1MgyPRxx6R253DGoOQCGzG1E4P5N f0pB9bzx25H7KtnaBbuU9zU8QMPU5Po6VKEjaU4vGt3+GtXldXgEI2Gt8ZJMa+V55/c3 Bbicm+YPbMB1g1JzfnJ7G+nu6zjBezDIN8LB0LUI9EYz+O1jyjG+AD7XsSTTO/Bk2vGt TdnDHmTgogvcBSFHK+hRQ7EeVjNdF0uRvsHpVPruUX+IfigBZeI9Jr/yBm6ie6qLubc7 V8BQ== X-Gm-Message-State: AA6/9RkHI06uF3ifkf26Wu6VeNlNtSwABfudDYQXnRBfmATErllkVEeA0fAz2FbigAVyVQ== X-Received: by 10.25.138.11 with SMTP id m11mr93369lfd.15.1476428265371; Thu, 13 Oct 2016 23:57:45 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.25.193.195 with SMTP id r186ls429813lff.22.gmail; Thu, 13 Oct 2016 23:57:43 -0700 (PDT) X-Received: by 10.28.94.139 with SMTP id s133mr572431wmb.1.1476428263879; Thu, 13 Oct 2016 23:57:43 -0700 (PDT) Original-Received: from smtp.smtpout.orange.fr (smtp09.smtpout.orange.fr. [80.12.242.131]) by mx.google.com with ESMTPS id bg10si23268163wjb.57.2016.10.13.23.57.43 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 13 Oct 2016 23:57:43 -0700 (PDT) Received-SPF: neutral (google.com: 80.12.242.131 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.131; Original-Received: from pc29.home ([2.11.66.154]) by mwinf5d32 with ME id vJxi1t00d3KhaHe03JxjYN; Fri, 14 Oct 2016 08:57:43 +0200 X-ME-Helo: pc29.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Fri, 14 Oct 2016 08:57:43 +0200 X-ME-IP: 2.11.66.154 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.131 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: 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:28825 Archived-At: This is a multi-part message in MIME format. --------------EF0EE0983CFA271E9ECB133F Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Le 14/10/2016 =C3=A0 01:43, Barry Revzin a =C3=A9crit : > > > And you're explaining exactly why SB doesn't do this. > > You believe that a base class member should be treated as if it > were a direct member of the derived class. I believe otherwise. > The standard's aggregate rules don't agree with you either. As > such, one user will expect SB to unpack the "underlying values", > while another user will expect SB to unpack the /subobjects/ in > the type. > > By forbidding this case entirely, the standard ensures that there > is no confusion. > > > But SB already does unpack the members, not the subobjects. Consider: > > | > structempty {}; > structA {intx;}; > structB :A {}; > > A makeA(); > B makeB(); > > auto[v1]=3DmakeA(); > auto[v2]=3DmakeB(); > | > > Based on the definitions in the standard, A has two elements (an empty=20 > and an int) and B has one element (an A), but when we use structured=20 > bindings, in both cases we only need one single name in the identifier=20 > list and both v1 and v2 are ints. > Good point. C++17 is not finished yet, and if we consider that this is=20 not what we wanted, we should fix it now. IMHO we wanted to delay the=20 decision otherwise it would had been proposed. For what I know, this was not the intention. May be I'm wrong. > We've already taken the step of enumerating members non-static data=20 > members in declaration order for structured bindings. As I see it: empty base classes and derived classes without NSDM don't=20 play in structure binding C++17. This is almost in line with aggregate initialization See http://melpon.org/wandbox/permlink/xakhsxNTIRcjiWJg Note that aggregate initialization doesn't allows neither to initialize=20 an empty base class using {}. and that it allows to initialize D d1 =3D {1, 2}; D d2 =3D {{1, 2}}; D d3 =3D {c1}; D d4 =3D {{{1}, 2}}; D d5 =3D {{a1, 2}}; The question is what we would like for structured binding if applied=20 when more than one class of the hierarchy has NSDM public members What do we want a) auto [b, j] =3D makeC(); // b is B i is int or b) auto [i, j] =3D makeC(); // i and j are int If a) we would need to support auto [[i], j] =3D makeC(); // i and j are int ? > All I want to do is apply that same logic to more kinds of types and=20 > have that enumeration available in a metaprogramming context. I agree. I would like also we apply the same logic for aggregate=20 initialization, structure binding if it was yet possible. I believe that flat aggregate initialization was syntactic sugar error.=20 Too late to change this. Now we have the option to choose flat or nested structure binding in C++20. If C++17 wording doesn't implies flat structure binding we will see what=20 we do for calss C for C++20. If C++17 wording implies flat structure binding we should decide if we=20 want it and if so we should have also flat structure binding for=20 classes C and D. 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/4ecaea2b-35d0-4c1b-706c-9f1d668b112d%40wanadoo.f= r. --------------EF0EE0983CFA271E9ECB133F Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Le 14/10/2016 =C3=A0 01:43, Barry Revzin= a =C3=A9crit=C2=A0:

And you're explaining exactly why SB doesn't do this.

You believe that a base class member should be treated as if it were a direct member of the derived class. I believe otherwise. The standard's aggregate rules don't agree with you either. As such, one user will expect SB to unpack the "underlying values", while another user will expect SB to unpack the subobjects in the type.

By forbidding this case entirely, the standard ensures that there is no confusion.

But SB already does unpack the members, not the subobjects. Consider:

struct empt= y { };
struct A { int x; };
struct B : A { };

A makeA();
B makeB();

auto [v1] =3D make= A();
auto [v2] =3D= makeB();

Based on the definitions in the standard, A has two elements (an empty and an int) and B has one element (an A), but when we use structured bindings, in both cases we only need one single name in the identifier list and both v1 and v2 are ints.=C2=A0

Good point. C++17 is not finished yet, and if we consider that this is not what we wanted, we should fix it now. IMHO we wanted to delay the decision otherwise it would had been proposed.
For what I know, this was not the intention. May be I'm wrong.

We've already taken the step of enumerating members non-static data members in declaration order for structured bindings.
As I see it: empty base classes and derived classes without NSDM don't play in structure binding C++17.
This is almost in line with aggregate initialization

See http://melpon.org/wandbox/permlink/xakhsxNTIRc= jiWJg

Note that aggregate initialization doesn't allows neither to initialize an empty base class using {}. and that it allows to initialize

=C2=A0=C2=A0=C2=A0 D d1 =3D {1, 2};
=C2=A0=C2=A0=C2=A0 D d2 =3D {{1, 2}};
=C2=A0=C2=A0=C2=A0 D d3 =3D {c1};
=C2=A0=C2=A0=C2=A0 D d4 =3D {{{1}, 2}};
=C2=A0=C2=A0=C2=A0 D d5 =3D {{a1, 2}};

The question is what we would like for=C2=A0 structured binding if applied when more than one class of the hierarchy has NSDM public members

What do we=C2=A0 want
a) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto [b, j] =3D makeC(); // b i= s B=C2=A0 i is int
or
b) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto [i, j] =3D makeC(); // i a= nd j are int

If a) we would need to support
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 auto [[i], j] =3D makeC(); /= / i and j are int
?

All I want to do is apply that same logic to more kinds of types and have that enumeration available in a metaprogramming context.=C2=A0
I agree. I would like also we apply the same logic for aggregate initialization, structure binding if it was yet possible.
I believe that flat aggregate initialization was syntactic sugar error. Too late to change this.
Now we have the option to choose flat or nested structure binding in C++20.

If C++17 wording doesn't implies flat structure binding we will see what we do for calss C for C++20.
If C++17 wording implies flat structure binding we should decide if we want it and if so we should=C2=A0 have also flat structure binding f= or classes C and D.

Vicente

--
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/4ecaea2b-35d0-4c1b-706c-9f1d668b112d= %40wanadoo.fr.
--------------EF0EE0983CFA271E9ECB133F-- .