220 23585 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: Thu, 7 Jan 2016 11:24:20 -0800 (PST) Lines: 610 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> <568D8DD7.30303@wanadoo.fr> <568E0C83.7030609@wanadoo.fr> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_7648_334481014.1452194660536" X-Trace: ger.gmane.org 1452194682 3027 80.91.229.3 (7 Jan 2016 19:24:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 19:24:42 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBZXWXK2AKGQE4ZVNUTI@isocpp.org Thu Jan 07 20:24:26 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-io0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aHGAZ-0001Zo-Ly for gclcip-std-proposals@m.gmane.org; Thu, 07 Jan 2016 20:24:24 +0100 Original-Received: by mail-io0-f198.google.com with SMTP id s102sf117033141ioi.0 for ; Thu, 07 Jan 2016 11:24:23 -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=8TIChtyzrhbrzjSeamv3Wy/KlyOxlGhTOr6oK5+bmL0=; b=V0gU5vC7PIkg1TLKmheY157hiabMUIW5tUT4ZytO1OmyCrNfJ2QtunoOxOkJWCGygA t2L788wsESDNqlspbeIPBTkiaPG2C9q6BhSNyGp6/Wa5ZXs8PHwGlvluqWQ845kjaomq b0XunVHlf+AEiQmAB8/EHROIElB7wp5G4uFTTO109U7y60QpDfUQKFdeBgTAIkZe1CCb azwNE2kaM3NEzcf1hxeWyoHb54q1sIArPH1Yi62rpOWLDPkgTUF1ywpHKltB9lPEcfLp 7nTnL1G7UaZRlbNEULiLyarKqENYpA2R+J2JMNUWI6LVC/b/opIMKAQr+fDBlXfF6AbA Q7yA== 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=8TIChtyzrhbrzjSeamv3Wy/KlyOxlGhTOr6oK5+bmL0=; b=XNkPa3Da1h8GVbeWetWwyQs72+sOlCHlKM8vkTyhhrhOF7a/WftRPSDS0MdpnmtxwE EBFsm2YV4on/MhVIVP4rbIX+h+XSZ/dTHqzGMnkjDGltGfpLdiG4a52e5FiSeQO6hnYR 7VsectEPd/BipisjG81eXK84gKu7En3rc7yz9EJa//HRrAZQuJlgeLJZRvPz9zmcrMZz psiUrkApNV9tur/Awtq2rvTuJWUeK5+4tiQO8phYpwd6et3IlJNI90iAnpr2W0LMlZ6W iBTwJq+r7lytgdBozVQPHxqD0XAPPpq8y/hPkpkzlBvAA6BFf1vvPrkBpsms/CxTzTiv H6HQ== 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=8TIChtyzrhbrzjSeamv3Wy/KlyOxlGhTOr6oK5+bmL0=; b=jqaCi5YCza7HnElSFERWgRszzFlisnbAboE3INip3Unsq21wn29RcF2D4e5MNIcjCd 2aPa3fvThu2UOAbd+SXJc6D8rYPn9Z0lbzC8dGxy5pi5Cvuh5mvNKMp8QI4k99JhHhPb fSSLzNbYve9eXGOa8JSHgmi7EHYcPSWzggPbZrKLrsG5WmbIHuFfZ/YQbdSVAzhqwmAf w3psZ7P+JaUJet35WcJssbcRyoHj/ct9o4h7x//GxIFuAgDChtL+jXsI4qB/vVQlunRv iruoubVkuoMOvcpqaIGL364rLeFVoFH6mQUTML+f8VZOMX7HncJZ5Oip72+uFxNVgu74 pgig== X-Gm-Message-State: ALoCoQlRHeYuXRA20iYQoHqgCYBoaxs/fy11phS/pabwJo4522ji1pBSvKD/QxKXPMNa7mp5Jmns5tTwh3qDCs7fbNt6zMpWQg== X-Received: by 10.50.70.42 with SMTP id j10mr15397146igu.9.1452194662646; Thu, 07 Jan 2016 11:24:22 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.102.3 with SMTP id fk3ls924100igb.1.canary; Thu, 07 Jan 2016 11:24:21 -0800 (PST) X-Received: by 10.50.57.84 with SMTP id g20mr551334igq.3.1452194661815; Thu, 07 Jan 2016 11:24:21 -0800 (PST) In-Reply-To: <568E0C83.7030609@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:23585 Archived-At: ------=_Part_7648_334481014.1452194660536 Content-Type: multipart/alternative; boundary="----=_Part_7649_1447318905.1452194660537" ------=_Part_7649_1447318905.1452194660537 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, January 7, 2016 at 1:58:16 AM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > Le 07/01/2016 06:02, Nicol Bolas a =C3=A9crit : > > On Wednesday, January 6, 2016 at 4:57:47 PM UTC-5, Vicente J. Botet=20 > Escriba wrote:=20 >> >> Le 06/01/2016 19:40, Nicol Bolas a =C3=A9crit : >> >> On Wednesday, January 6, 2016 at 1:13:48 PM UTC-5, Vicente J. Botet=20 >> Escriba wrote:=20 >>> >>> 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=20 >>> Escriba 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=20 >>>> 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=20 >>>>> (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 t= o=20 >>>> compile that way if the compiler can just use intrinsics or whatever t= o=20 >>>> enumerate the members of the struct. >>>> >>>> Thanks to all for your help. Could we conclude then that the generatio= n=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 the= m or if they are generated using some missing type trait or reflection trai= ts as an open question. =20 >>>> >>>> >>>> >>>> I realized while reading your post that the structured bindings=20 >>> proposal also keys off of being an aggregate when it is not, strictly= =20 >>> speaking, necessary. >>> >>> That's when I started to think about what these limitations exist. >>> >>> Aggregate initialization is all about the compiler generating=20 >>> construction code on the fly. Looked at from that perspective, the=20 >>> reasoning for the 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 directl= y;=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 w= ould=20 >>> best be expressed with a constructor. Also, virtual stuff alters the la= yout=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 eve= ry=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 t= he=20 >>> right place. >>> >>> When initializing a type, restriction #3 matters, since you have to fil= l=20 >>> out the appropriate information. But that information is irrelevant whe= n=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 an= d=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`. >> >> Maybe, but why do you want to preserve #1? >> > > First, `tuple` doesn't count, as its members are not required to be=20 > public, nor are they required to be in the appropriate order. So they're= =20 > going to have to use its specialized getters no matter what. > > As for the more general question... I suppose it is not *strictly*=20 > necessary either. So long as *all* of the NSDMs are publicly accessible= =20 > (and no virtual inheritance), it could still work. > >> =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. >> >> You didn't replayed to my questions? >> > > I didn't? How not? I replied by saying "look at how aggregate=20 > initialization in C++17 works. Make it work like that." That's the answer= =20 > I'm comfortable with. > > Or let me put it another way. Given this: > > SomeType aggregate =3D {val1, val2, val3, val4}; > > this ought to be true (reference types, movement, etc aside): > > get<0>(aggregate) =3D=3D val1; > get<1>(aggregate) =3D=3D val2; > get<2>(aggregate) =3D=3D val3; > get<3>(aggregate) =3D=3D val4; > > The index aggregate initialization would have used to set the value (even= =20 > if it's not, strictly speaking, an aggregate) is exactly the index that= =20 > tuple-based fetching should retrieve the value. And the same should go fo= r=20 > structured binding. > > My question was because as I interpret=20 > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0017r1.html from= =20 > the examples, The aggregation must be nested as in > > struct base1 { int b1, b2 =3D 42; }; > struct base2 {=20 > B() { > b3 =3D 42; > } > int b3; > }; > struct derived : base1, base2 { > int d; > }; > > derived d1{{1, 2}, {}, 4}; // full initialization > derived d2{{}, {}, 4}; // value-initialized bases > > But maybe I'm wrong. > > > Vicente > No, you're right. I'd forgotten that this is how it works, that base=20 classes are considered member-subobjects. But my overall point stands: it should work as the exact opposite of=20 aggregate initialization. So in your example, the first index of the tuple= =20 `A` should be the `A1` base class. The second index should be the `A2` base= =20 class. And actually, that brings up a really good reason why we should exclude=20 virtual types of any kind. Because such accesses (particularly structured= =20 binding) encourages *slicing* of types. --=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_7649_1447318905.1452194660537 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thursday, January 7, 2016 at 1:58:16 AM UTC-5, Vicente J. Botet Escriba = wrote:
=20 =20 =20
Le 07/01/2016 06:02, Nicol Bolas a =C3=A9crit=C2=A0:
On Wednesday, January 6, 2016 at 4:57:47 PM U= TC-5, Vicente J. Botet Escriba wrote:
Le 06/01/2016 19:40, Nicol Bolas a =C3=A9crit=C2=A0:
On Wednesday, January 6, 2016 at 1:13:48 PM UTC-5, Vicente J. Botet Escriba wrote:
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, Nicol 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&quo= t;.
>> 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 <= br> >> 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 probably be faster to compile that way i= f 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 the= y 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<= /i> 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`.
Maybe, but why do you want to preserve #1?

First, `tuple` doesn't count, as its members are not required t= o be public, nor are they required to be in the appropriate order. So they're going to have to use its specialized getters no matter what.

As for the more general question... I suppose it is not strictly= necessary either. So long as all of the NSDMs are publicly accessible (and no virtual inheritance), it could still work.
=C2=A0
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&>(a)

Yes. It matches with aggregate initialization in C++17.
=C2=A0
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 didn't replayed to my questions?

I didn't? How not? I replied by saying "look at how aggreg= ate initialization in C++17 works. Make it work like that." That&#= 39;s the answer I'm comfortable with.

Or let me put it another way. Given this:

SomeType aggregate =3D {val1, val2, val3, val4};

this ought to be true (reference types, movement, etc aside):

get<0>(aggregate) =3D=3D val1;
get<1>(aggregate) =3D=3D val2;
get<2>(aggregate) =3D=3D val3;
get<3>(aggregate) =3D=3D val4;

The index aggregate initialization would have used to set the value (even if it's not, strictly speaking, an aggregate) is exactly the index that tuple-based fetching should retrieve the value. And the same should go for structured binding.

My question was because as I interpret http://www.open= -std.org/jtc1/sc22/wg21/docs/papers/2015/p0017r1.html from the examples, The aggregation must be nested as in

=20 
struct base1 { int b1, b2 =3D 42; };
struct base2 {=20
    B() {
        b3 =3D 42;
    }
    int b3;
};
struct derived : base1, base2 {
    int d;
};

derived d1{{1, 2}, {}, 4};  // full initialization
derived d2{{}, {}, 4};      // value-initialized bases

But maybe I'm wrong.
Vicente

No, you're right. I'd fo= rgotten that this is how it works, that base classes are considered member-= subobjects.

But my overall point stands: it should work as the exact= opposite of aggregate initialization. So in your example, the first index = of the tuple `A` should be the `A1` base class. The second index should be = the `A2` base class.

And actually, that brings up a really good reas= on why we should exclude virtual types of any kind. Because such accesses (= particularly structured binding) encourages slicing of types.

--

---
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_7649_1447318905.1452194660537-- ------=_Part_7648_334481014.1452194660536-- .