220 23555 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: n4428 and Tuple-like access interface reflection Date: Wed, 6 Jan 2016 10:40:56 -0800 (PST) Lines: 341 Approved: news@gmane.org Message-ID: References: <56770133.7070701@wanadoo.fr> <5681D877.3010101@wanadoo.fr> <43daa6cd-e152-43c1-ab51-0661779d344b@isocpp.org> <568942A9.80700@wanadoo.fr> <568B0DA1.3080704@wanadoo.fr> <7d4bd204-e4c3-4f60-8be5-63d8127daf74@isocpp.org> <487ea013-6fcb-4d2e-8bc7-8fe96cdbf0a9@isocpp.org> <568C3EC7.8070900@wanadoo.fr> <568D5959.9000501@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_53_583534280.1452105657053" X-Trace: ger.gmane.org 1452105663 23710 80.91.229.3 (6 Jan 2016 18:41:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2016 18:41:03 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBOV7WW2AKGQE6KEN2XI@isocpp.org Wed Jan 06 19:41:02 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oi0-f69.google.com ([209.85.218.69]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGt11-0003bu-Ui for gclcip-std-proposals@m.gmane.org; Wed, 06 Jan 2016 19:41:00 +0100 Original-Received: by mail-oi0-f69.google.com with SMTP id y66sf943831454oig.0 for ; Wed, 06 Jan 2016 10:40:59 -0800 (PST) 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:content-type: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=zYdyUBltKQnAXRAsYN1S6zTUB2/lazxZKY2xBSATwn8=; b=px0hpaAL9L9FrWaXTh7Lt7DgzMsSc3aUdcdz0ZYpE23oE4tGScMXnqOKt9uRm08sfm EupdjjrzoHrlqk7NT74C1IH71MY8/M7SMeVpi/DgE1yLxH7yrRtr/d/zt7CphdCnnkrG Xv7lI1tXAd5kOd7tvbLxvwqBPFIgfpGEE8rDW+h0z/PQ4LbfhDX2QuBAOHnTe+9FKwga gpyzaJ5ebc/ON5xFzTPtJOnyHauHznXdvq/Sap2DR6/5KsLQpgPRLpSGZYFTu7NHp6N3 jeoSZWYiS14Jxt+zBSWfrRTIClqXReEu4rjP1yC31YSqlx1RbidR55OWlC+2zKfwOWnU DLeg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version:content-type: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=zYdyUBltKQnAXRAsYN1S6zTUB2/lazxZKY2xBSATwn8=; b=Av5VnkqWVexi6ILHxDvm4kQvx7MwPa68uce0V++zMjhZ2EdbsB2b/clSwaShrvQAM6 VrpFRw424vPL8PpHt/9CcPNkRi2G+eq1T2g2li2kcNgKVlWLVM+HciadmAHbSYXMbmbP T5pRoeLmWwgjWDv97jbB/2iN8PNKrvrurSdE14Jx9wy+hE1DCAnGu3fbtSJGQz5GBam4 gu+Vsl93AONQ/768cOsxeCVhyJtocqpMZvFpSpJVFW1OA3sATZ+sWv6ucOtBt/TLuVC7 cxgEWMOT0CuSLfAiXKqcv5zgPKobPvqDgDC19YhrGGZ94R/N0D+C7rbZ8owYRT1L6TXw FI6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version:content-type: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=zYdyUBltKQnAXRAsYN1S6zTUB2/lazxZKY2xBSATwn8=; b=CU90WHwc4m3quV+24TeE9hi3PBgq1hHqdliMwdcMY30P0N9GWTX8KFYJ/mCeNinovI dmQpFYHXM1PfmhA/p40rwYpVSDdN/jVGfBF/HO7R+/MWuY/SiwG0QATqJGmF+dt/yVKO ltPmuttQChB3I9ilMKjJ3xhi2/tnMbOK5UT96T6NW21ezc/rYdBZZ0SBx71S3JWAhLKP T1q8v/RV6I2v7Azty7UvwTiRZOQ/x2I41J1/+S7LKL4pdTjTUaazsa4b+3dT9ycUABe1 tm0mqXTOgN1i9erFacOKuUUR1Zreix5e7qu2O8+bVgWwHNhd1PsIe5g0YCckZrtoNjGG V4eg== X-Gm-Message-State: ALoCoQnXVrmh0fYuyaXG8SnLgqmeuJ+oWefLcsJnC9Yz1g5jwJr3OzQoSBt4TaGZecbScfG6stXPNQ8l7zLjKNCGBTdmCv+FLQ== X-Received: by 10.182.33.74 with SMTP id p10mr89503783obi.34.1452105659165; Wed, 06 Jan 2016 10:40:59 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.107.165.19 with SMTP id o19ls1085868ioe.53.gmail; Wed, 06 Jan 2016 10:40:57 -0800 (PST) X-Received: by 10.50.138.138 with SMTP id qq10mr359295igb.10.1452105657905; Wed, 06 Jan 2016 10:40:57 -0800 (PST) In-Reply-To: <568D5959.9000501@wanadoo.fr> X-Original-Sender: jmckesson@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:23555 Archived-At: ------=_Part_53_583534280.1452105657053 Content-Type: multipart/alternative; boundary="----=_Part_54_1247374328.1452105657053" ------=_Part_54_1247374328.1452105657053 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 6, 2016 at 1:13:48 PM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 06/01/2016 18:49, Nicol Bolas a =C3=A9crit : > > On Tuesday, January 5, 2016 at 5:08:09 PM UTC-5, Vicente J. Botet Escriba= =20 > wrote:=20 >> >> Le 05/01/2016 19:20, Nicol Bolas a =C3=A9crit : >> >> On Tuesday, January 5, 2016 at 11:38:11 AM UTC-5, Matthew Woehlke wrote:= =20 >>> >>> On 2016-01-05 11:00, Nicol Bolas wrote:=20 >>> > On 2016-01-04 22:08, Ville Voutilainen wrote:=20 >>> >>> The question is why would you check for an aggregate?=20 >>> >>=20 >>> >> The goal is that get would be implicitly defined for any=20 >>> "aggregate".=20 >>> >> It should *not* be defined however for types that have non-public=20 >>> >> NSDM's. The question is how to achieve this.=20 >>> >>=20 >>> >> I should note that one answer is "compiler magic". If a standard=20 >>> trait=20 >>> >> is going to be a problem, that may be a strong argument to use=20 >>> compiler=20 >>> >> magic rather than a portable library solution.=20 >>> >=20 >>> > Well, reflection of any kind, which this whole idea relies on, is=20 >>> going to=20 >>> > require compiler magic.=20 >>> >>> True. The question could be better expressed as whether the compiler=20 >>> magic provides get *directly* (as in, there may be no visible=20 >>> declaration of the generic form of such), or whether get is (visibly= ,=20 >>> in the standard library) implemented with the help of traits (which=20 >>> themselves are compiler magic, but have broader applicability).=20 >>> >> >> I say let the whole thing be compiler magic. It'd probably be faster to= =20 >> compile that way if the compiler can just use intrinsics or whatever to= =20 >> enumerate the members of the struct. >> >> Thanks to all for your help. Could we conclude then that the generation= =20 >> should be done when >> >> - (1) no private or protected non-static data members and >> - (2) no base classes=20 >> ? >> >> Do you see a better characterization? >> >> We can let the answer to whether it is the compiler that generates them = or if they are generated using some missing type trait or reflection traits= as an open question. =20 >> >> >> >> I realized while reading your post that the structured bindings proposal= =20 > also keys off of being an aggregate when it is not, strictly speaking,=20 > necessary. > > That's when I started to think about what these limitations exist. > > Aggregate initialization is all about the compiler generating constructio= n=20 > code on the fly. Looked at from that perspective, the reasoning for the= =20 > exclusions can be understood as follows: > > 1) *Types with constructors*: You're not supposed to be able to=20 > initialize a type that has a user-provided constructor with anything=20 > *except* a call to one of those constructors. That's how they maintain=20 > invariants. > 2) *Public-only members*: Access classes exist so that only designated=20 > code can access that value. So you can't initialize such values directly;= =20 > only designated code (ie: user-provided constructors) may do so. > 3) *Virtual types*: Generating the construction code would require=20 > dealing with filling in virtual stuff. That's more complex code which wou= ld=20 > best be expressed with a constructor. Also, virtual stuff alters the layo= ut=20 > of the type. > 4) *Types with base classes*: The layout of base classes is not=20 > well-defined, which makes the initialization code more complex. > > Notice that C++17 will dispense with #4, presumably because, well, what= =20 > does it matter? Yes, the layout is not defined by the standard, but every= =20 > class *has* a layout. The compiler knows what that layout is, so the=20 > compiler can figure out how to put each item in the aggregate list in the= =20 > right place. > > When initializing a type, restriction #3 matters, since you have to fill= =20 > out the appropriate information. But that information is irrelevant when= =20 > *accessing* NSDMs, either for these auto-tuplizing functions or for=20 > structured binding. > > (note: as I think more on this, it may be problematic with virtual=20 > *inheritance*. But virtual functions themselves ought to be fine,=20 > implementation-wise.) > > So when doing structured binding or tuplized access, we should only=20 > require restrictions #1 and #2 (and possibly no virtual inheritance). > > I missed why you want to maintain #1. This will eliminate std::tuple and= =20 > std::pair :( > They already have tuple-like interfaces. And structured binding will=20 already need an extensibility mechanism for types that don't fit this=20 criteria. So just apply those to `tuple` and `pair`. =20 > I wonder about multiple inheritance. if=20 > > struct A: A1, A2 {...}; > > Is everyone comfortable with=20 > > get<0>(a) !=3D get<0>(static_cast(a) > Yes. It matches with aggregate initialization in C++17. =20 > BTW, what would get<0>(a) be? static_cast(a) or=20 > get<0>(static_cast(a))? > The same thing it is in aggregate initialization in C++17. --=20 ---=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. Visit this group at https://groups.google.com/a/isocpp.org/group/std-propos= als/. ------=_Part_54_1247374328.1452105657053 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 6, 2016 at 1:13:48 PM UTC-5, Vicente J. Botet Escriba= wrote:
=20 =20 =20
Le 06/01/2016 18:49, Nicol Bolas a =C3=A9crit=C2=A0:
On Tuesday, January 5, 2016 at 5:08:09 PM UTC= -5, Vicente J. Botet Escriba wrote:
Le 05/01/2016 19:20, Nicol Bolas a =C3=A9crit=C2=A0:
On Tuesday, January 5, 2016 at 11:38:11 AM UTC-5, Matthew Woehlke wrote:
On 2016-01-05 11:00, Ni= col Bolas wrote:
> On 2016-01-04 22:08, Ville Voutilainen wrote:
>>> The question is why would you check for an aggregate?
>>
>> The goal is that get<N> would be implicitly defined for any "aggregate".
>> It should *not* be defined however for types that have non-public
>> NSDM's. The question is how to achieve this. >>
>> I should note that one answer is "compiler magic". If a standard trait
>> is going to be a problem, that may be a strong argument to use compiler
>> magic rather than a portable library solution.
>
> Well, reflection of any kind, which this whole idea relies on, is going to
> require compiler magic.

True. The question could be better expressed as whether the compiler
magic provides get<N> *directly* (as in, there may be no visible
declaration of the generic form of such), or whether get<N> is (visibly,
in the standard library) implemented with the help of traits (which
themselves are compiler magic, but have broader applicability).

I say let the whole thing be compiler magic. It'd probabl= y be faster to compile that way if the compiler can just use intrinsics or whatever to enumerate the members of the struct.

Thanks to all for your help. Could we conclude then that the generation should be done when
   - (1) no private or protected non-static data members and
   - (2) no base classes=20
?

Do you see a better characterization?

We can let the answer to whether it is the compiler that generates them or =
if they are generated using some missing type trait or reflection traits as=
 an open question. =20
I realized while reading your post that the structured bindings proposal also keys off of being an aggregate when it is not, strictly speaking, necessary.

That's when I started to think about what these limitations exist.

Aggregate initialization is all about the compiler generating construction code on the fly. Looked at from that perspective, the reasoning for the exclusions can be understood as follows:

1) Types with constructors: You're not supposed to be able to initialize a type that has a user-provided constructor with anything except a call to one of those constructors. That's how they maintain invariants.
2) Public-only members: Access classes exist so that only designated code can access that value. So you can't initialize such values directly; only designated code (ie: user-provided constructors) may do so.
3) Virtual types: Generating the construction code would require dealing with filling in virtual stuff. That's more complex code which would best be expressed with a constructor. Also, virtual stuff alters the layout of the type.
4) Types with base classes: The layout of base classes is not well-defined, which makes the initialization code more complex.

Notice that C++17 will dispense with #4, presumably because, well, what does it matter? Yes, the layout is not defined by the standard, but every class has a layout. The compiler knows what that layout is, so the compiler can figure out how to put each item in the aggregate list in the right place.

When initializing a type, restriction #3 matters, since you have to fill out the appropriate information. But that information is irrelevant when accessing NSDMs, either for these auto-tuplizing functions or for structured binding.

(note: as I think more on this, it may be problematic with virtual inheritance. But virtual functions themselves ought to be fine, implementation-wise.)

So when doing structured binding or tuplized access, we should only require restrictions #1 and #2 (and possibly no virtual inheritance).
I missed why you want to maintain #1. This will eliminate std::tuple and std::pair :(

They already have tuple= -like interfaces. And structured binding will already need an extensibility= mechanism for types that don't fit this criteria.

So just apply= those to `tuple` and `pair`.
=C2=A0
=20 I wonder about multiple inheritance. if

=C2=A0=C2=A0=C2=A0 struct A: A1, A2 {...};

Is everyone comfortable with

=C2=A0=C2=A0=C2=A0 get<0>(a) !=3D get<0>(static_cast<A2&= amp;>(a)

Yes. It matches with aggregate i= nitialization in C++17.
=C2=A0
=20 BTW, what would get<0>(a) be? static_cast<A1&>(a) or get<0>(static_cast<A1&>(a))?

The same thing it is in aggregate initialization in C++17.

--

---
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= /.
------=_Part_54_1247374328.1452105657053-- ------=_Part_53_583534280.1452105657053-- .