220 23551 <568D5959.9000501@wanadoo.fr> article Path: news.gmane.org!not-for-mail From: "Vicente J. Botet Escriba" Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: n4428 and Tuple-like access interface reflection Date: Wed, 6 Jan 2016 19:13:45 +0100 Lines: 325 Approved: news@gmane.org Message-ID: <568D5959.9000501@wanadoo.fr> 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> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------000402030500050505010405" X-Trace: ger.gmane.org 1452104041 25117 80.91.229.3 (6 Jan 2016 18:14:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 6 Jan 2016 18:14:01 +0000 (UTC) Cc: mwoehlke.floss@gmail.com To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDH67CONY4PBBW5SWW2AKGQECCEFCGI@isocpp.org Wed Jan 06 19:13:52 2016 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-lf0-f72.google.com ([209.85.215.72]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aGsai-0004Tm-Dm for gclcip-std-proposals@m.gmane.org; Wed, 06 Jan 2016 19:13:48 +0100 Original-Received: by mail-lf0-f72.google.com with SMTP id z124sf203148450lfa.1 for ; Wed, 06 Jan 2016 10:13:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type: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=zzutldmiMrcML5hjTxJ8rMW9d/cfiu+XUviyYAHkogM=; b=lSf3uCfltOS/J7Po9PmTm6YHtD2RBu6qktsPO3fazC+rB11sQeUpGYx1/X9ikZ2ASy M6He2ozPm+Ln9y+HGocVzLtLH0gCVtpsAec7Fb7gvHfohFrMTI5JP7TVoc93eKvhUTHL 4U6kg3GF2yNs73rAGNwyet39set47VRZX2TzoVaSrU9glC3hYOST7gZn0ZA2rddrdIq/ IQ4EHp+ajvnngn9PlP1Kd7UBG5zVizwzGomIRLLVWPmlFNTyh3cEXVFkaYxx3QN/wrhO TEjw4Ja3lfs5hOARC1ka/guZ2WFeiAj9IxRSrTy/L7hY+fevI/KCnqXTV4tn79Utl17Q 84ww== 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:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-type: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=zzutldmiMrcML5hjTxJ8rMW9d/cfiu+XUviyYAHkogM=; b=RS5MWhT5pTuLAdU89quL++HhTHmyLivcagGNax4QfzJbA8SgvnXJmxUsAWWR46cpnS a33VihOVKB8LG6mi+kCWACq2YRgb7EE6MrVH8z2CBXYCjWIAdznqaNjghs52VR64oxkX V8SQ3PgGbDfqwDtsOssfV2LuCzUWQCg79V6pcbt7m/RGVsftCnpayv8CPGlxvV444/8R olHV8wPH0HsWM0DsoD5NXfULbXaKcgZ1cs2MiB9R/osadlDOFGUYYthKRZ35VBXLKiOa X4HXo7FUn+MpHAztjYTwVXMXcHvrT1yC8ei32U5KW9YfCnc5RyffipPpIwKOXlek0mPn Fl X-Gm-Message-State: ALoCoQk3vQonCqiiiC+i5ugd2cOrVaYXlOzaZKjKlm1MnaR9Z1aTBrIJFZDxjchLrFTMsrm7tIjpQMV5MJj6rKSpgi51KJz9ZA== X-Received: by 10.194.246.106 with SMTP id xv10mr11366602wjc.4.1452104027929; Wed, 06 Jan 2016 10:13:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.28.153.141 with SMTP id b135ls391425wme.4.gmail; Wed, 06 Jan 2016 10:13:46 -0800 (PST) X-Received: by 10.194.119.68 with SMTP id ks4mr107394405wjb.45.1452104026598; Wed, 06 Jan 2016 10:13:46 -0800 (PST) Original-Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr. [80.12.242.128]) by mx.google.com with ESMTPS id h7si161346093wjy.46.2016.01.06.10.13.46 for (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 06 Jan 2016 10:13:46 -0800 (PST) Received-SPF: neutral (google.com: 80.12.242.128 is neither permitted nor denied by best guess record for domain of vicente.botet@wanadoo.fr) client-ip=80.12.242.128; Original-Received: from new-host.home ([2.10.6.67]) by mwinf5d41 with ME id 2iDl1s00K1SlsaA03iDlpl; Wed, 06 Jan 2016 19:13:46 +0100 X-ME-Helo: new-host.home X-ME-Auth: dmljZW50ZS5ib3RldEB3YW5hZG9vLmZy X-ME-Date: Wed, 06 Jan 2016 19:13:46 +0100 X-ME-IP: 2.10.6.67 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 In-Reply-To: X-Original-Sender: vicente.botet@wanadoo.fr X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 80.12.242.128 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-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:23551 Archived-At: This is a multi-part message in MIME format. --------------000402030500050505010405 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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: > > 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: >> >> 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 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 *directly* (as in, there may be no visible >> declaration of the generic form of such), or whether get >> 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 members and > - (2) no base classes > ? > > Do you see a better characterization? > > We can let the answer to whether it is the compiler that generates th= em or if they are generated using some missing type trait or reflection tra= its as an open question. > > > 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=20 > directly; 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=20 > would best be expressed with a constructor. Also, virtual stuff alters=20 > the layout 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,=20 > what does it matter? Yes, the layout is not defined by the standard,=20 > but every class /has/ a layout. The compiler knows what that layout=20 > is, so the compiler can figure out how to put each item in the=20 > aggregate list in the right place. > > When initializing a type, restriction #3 matters, since you have to=20 > fill out the appropriate information. But that information is=20 > irrelevant when /accessing/ NSDMs, either for these auto-tuplizing=20 > functions or for 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 :( I wonder about multiple inheritance. if struct A: A1, A2 {...}; Is everyone comfortable with get<0>(a) !=3D get<0>(static_cast(a) BTW, what would get<0>(a) be? static_cast(a) or=20 get<0>(static_cast(a))? If we want that this applies to the current access for std::tuple the=20 answer should be get<0>(static_cast(a)). > > Let us call this collection of types "publicly accessible". All of its=20 > NSDMs are accessible to the public. Even though the layout isn't=20 > necessarily specified by the standard, there is still a fixed,=20 > well-understood layout for the type. As such, we can define a standard=20 > ordering for the elements of such types, which is all that is needed=20 > for auto-tuplizing or structured binding. > Vicente --=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/. --------------000402030500050505010405 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 "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 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 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 :(

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)

BTW, what would get<0>(a) be? static_cast<A1&>(a) or get<0>(static_cast<A1&>(a))?

If we want that this applies to the current access for std::tuple the answer should be get<0>(static_cast<A1&>(a)).


Let us call this collection of types "publicly accessible". All of its NSDMs are accessible to the public. Even though the layout isn't necessarily specified by the standard, there is still a fixed, well-understood layout for the type. As such, we can define a standard ordering for the elements of such types, which is all that is needed for auto-tuplizing or structured binding.

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.
Visit this group at https://groups.google.com/a/isocpp.org/group/std-proposals= /.
--------------000402030500050505010405-- .