220 23568 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 21:02:51 -0800 (PST) Lines: 500 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_1145_483468076.1452142972091" X-Trace: ger.gmane.org 1452142978 7004 80.91.229.3 (7 Jan 2016 05:02:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Jan 2016 05:02:58 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB7PCW62AKGQEMRE3YEQ@isocpp.org Thu Jan 07 06:02:57 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f72.google.com ([209.85.213.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aH2it-0007dZ-KR for gclcip-std-proposals@m.gmane.org; Thu, 07 Jan 2016 06:02:55 +0100 Original-Received: by mail-vk0-f72.google.com with SMTP id i129sf67297731vkb.2 for ; Wed, 06 Jan 2016 21:02:55 -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=I8DNVLJ4pOYAGKNbYmNo79Kuttu/Yun9hKf3sUNPnAc=; b=Lcpwi7Trw/7BJUfSHv0a2j2dL86osE6oeLLXNfg8+SgbP8PaMBl/hJ7LRSgSmHTkLW OV+2ArEIe6fOMQn7r8ADpoKE+ieExqWlCQyTa+H1Oxu6ivU1GvTrbF8zrG6U7otEtnkH HjuQdeztMFfAEElkPsC9TTNrNVTfKDf0i+ZYQETfQ5KiHqjZ3umZTTzXilw+D7yI+7cI wtDAmSYimtB+G6w/1k3mdDWMfDDBda0joNAh0KMI80+EpZYc6uBphFuF6cfZatL5ZgfK CQBpsqufSBxHoVwQbNI6NHyOuVeudtpj4WlnFDoxqx+qhY9eNP08ZjnqT72e3xjzESwQ JPlA== 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=I8DNVLJ4pOYAGKNbYmNo79Kuttu/Yun9hKf3sUNPnAc=; b=rX2wAXccaG4DPyDlhTH6dge/4dlA9oysnXjFw1tUY2z2MwQSO85lEdysydc3ftzOME cnCP4sxUylr9odM4V9q2J7ejbmqPhDwsOJEhKAFlJV49B8582f1x8BrOnfHTZwRnv/QJ rJOANwvJtdJL3z9Oj3aDs9wrlvyQE/fe7nEOlg9DW6Xut6/s35NqgEbJcKNCI+x99xVW nPXerC7utQkZ7vebB8tiSrbx/HZuHILYSnsl0u2eaRKzuYkehmrZasKIS/KyzMEEI3Gv 2UQ28GeY8OuFAguYisn5FKDIJNqIgm9cPa0qchXWiKC8BLOcBLeUWdYhyI1FsI5a93I4 nyWQ== 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=I8DNVLJ4pOYAGKNbYmNo79Kuttu/Yun9hKf3sUNPnAc=; b=X8mhw/Udu//NjWdPPI2b+O8mTIBxv0eOEtWtAYjdFBtNZbnDLrn4f/+SYEP9qeBXVX punq5mSvyyM68CfVDUHIAXWMsmxVrAU4LfvpJsk+wjS6O4rFc3h0LRCbjmEKQ0OrA8Aa VYYgcE3DhLMyycgUJyWue1/Z0pnYYwFxXGqwCSyEVfjAhvhslUW6QI6z9q2bcMMR1aYg 8OTFe0uNs9Fir4huhBnXQKMOvQMUPVtsNu9XOreBzNgYBgJBILIiF7jQWwEoJO3/4Ni7 JHCBVrySeUBo8rw42tjw9NDKA6dLuwsandns0k66jWNQM8PZYPtg5hzqqtizvCbmKiL/ W5Vg== X-Gm-Message-State: ALoCoQlU7pOSGsBi0wRMYKDvVwqeHAC1STceI6Ibb5v8P4iAymRd/tVGGzQIZNTlJ+D8CaPGiFth4BAI+QgtY/EyCMg+ef9x2g== X-Received: by 10.31.47.202 with SMTP id v193mr91078382vkv.6.1452142974623; Wed, 06 Jan 2016 21:02:54 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.50.139 with SMTP id c11ls761357igo.38.canary; Wed, 06 Jan 2016 21:02:53 -0800 (PST) X-Received: by 10.50.118.7 with SMTP id ki7mr428638igb.7.1452142973266; Wed, 06 Jan 2016 21:02:53 -0800 (PST) In-Reply-To: <568D8DD7.30303@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:23568 Archived-At: ------=_Part_1145_483468076.1452142972091 Content-Type: multipart/alternative; boundary="----=_Part_1146_1561077075.1452142972092" ------=_Part_1146_1561077075.1452142972092 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 6, 2016 at 4:57:47 PM UTC-5, Vicente J. Botet Escriba= =20 wrote: > > 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 Escrib= a=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=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 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 trait= s as an open question. =20 >>> >>> >>> >>> I realized while reading your post that the structured bindings proposa= l=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=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 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 wo= uld=20 >> best be expressed with a constructor. Also, virtual stuff alters the lay= out=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 ever= y=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 th= e=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`. > > Maybe, but why do you want to preserve #1? > First, `tuple` doesn't count, as its members are not required to be public,= =20 nor are they required to be in the appropriate order. So they're going to= =20 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 for= =20 structured binding. --=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_1146_1561077075.1452142972092 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wednesday, January 6, 2016 at 4:57:47 PM UTC-5, Vicente J. Botet Escriba= wrote:
=20 =20 =20
Le 06/01/2016 19:40, Nicol Bolas a =C3=A9crit=C2=A0:
On Wednesday, January 6, 2016 at 1:13:48 PM U= TC-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".
>> 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 "compile= r 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 probably 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 membe=
rs 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.<= br> 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`.
Maybe, but why do you want to preserve #1?
<= br>First, `tuple` doesn't count, as its members are not required to be = public, nor are they required to be in the appropriate order. So they'r= e going to have to use its specialized getters no matter what.

As fo= r the more general question... I suppose it is not strictly necessar= y either. So long as all of the NSDMs are publicly accessible (and n= o 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 aggregate ini= tialization in C++17 works. Make it work like that." That's the an= swer I'm comfortable with.

Or let me put it another way. Given t= his:

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

this ought to be true (reference types, movemen= t, etc aside):

get<0>(= aggregate<= span style=3D"color: #660;" class=3D"styled-by-prettify">) =3D=3D val1;
get<1>(aggregate) =3D=3D val2;
get<2&g= t;(aggrega= te)= =3D=3D val3;
get<3>(= aggregate)= =3D=3D val4;
<= br>The index aggregate initialization would have used to set the value (eve= n if it's not, strictly speaking, an aggregate) is exactly the index th= at tuple-based fetching should retrieve the value. And the same should go f= or structured binding.

--

---
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_1146_1561077075.1452142972092-- ------=_Part_1145_483468076.1452142972091-- .