220 20580 <29244e83-c129-4411-900a-100c0ae8e3c3@isocpp.org> article Path: news.gmane.org!not-for-mail From: Tomasz Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Draft D0065: Movable initializer lists, rev. 2 Date: Mon, 21 Sep 2015 12:03:18 -0700 (PDT) Lines: 197 Approved: news@gmane.org Message-ID: <29244e83-c129-4411-900a-100c0ae8e3c3@isocpp.org> References: <87343e65-eecd-4b96-86b7-a883aa7f9d1d@isocpp.org> <6fb8e5c2-65a8-4a31-a8f0-7ca85b9b7247@isocpp.org> <0B1AA60B-3BEF-4C04-BB26-3AC839FE73AB@gmail.com> <3e38b15f-10a7-41e1-9652-338f94ac3ab9@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_755_199973864.1442862198883" X-Trace: ger.gmane.org 1442862210 18513 80.91.229.3 (21 Sep 2015 19:03:30 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 19:03:30 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBDNPVXXG6IGBB55IQGYAKGQEXLF5LUY@isocpp.org Mon Sep 21 21:03:26 2015 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f200.google.com ([209.85.214.200]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Ze6N2-0002nI-IE for gclcip-std-proposals@m.gmane.org; Mon, 21 Sep 2015 21:03:24 +0200 Original-Received: by obcfb16 with SMTP id fb16sf221630570obc.1 for ; Mon, 21 Sep 2015 12:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to: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=B6MggPxlJwr6slbQhpnpb6zh9JKYCg5gLmntPU81rNw=; b=hkHWt+6NtfoQo5AWvxwHkyt94StuFcrui0xNRrMniTetLj4O5qP9x7DEyStRMF4f5s ODgKxjiLQVfKQ6frLIHoHvyXKbm3gxxWrJVPQzjQrtGC7kcrdRA+COz7y2I590xfvpid DzrvR//6OALzJVLx6xaqNb8uG89tk5aUL/GWBqsG4Xm/I4yuODCa9nXPtlroA0durcU0 vnPtiuhwgmrFdFHfO55dweuif0lvqU0A3IMovgbP85OnGlgBp0gtO7WSHzpaI/0hLzMC noRtfXH5bxp6IgR8lvMG9j/ahk9bBnUG//W8ZQnZIGKK+IbFo5jtAHLEPnHryeDReF7B PszQ== 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: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=B6MggPxlJwr6slbQhpnpb6zh9JKYCg5gLmntPU81rNw=; b=KnQgQz1yORvISMhI6Hxt8xVFhHvIrrKw0O2PTSAyE2KuO1Uk2ZjGh4lGRNrPD+RVdY Cr7IgU0REjxrvTnviTGOlBP4aYVqQCEQGGjejkrN0meel+io1a64GP5VAim9sQyQR80J GeVEQ/8vFC0hCyXuyNJxbG8gTZHT5M3RdJhg3NCgUX79nStIQp+zrzkoa51wPx52gD2L 1NakBPD3zwJrZSjo755uNGZ4cUsgZkI/6PwGLoGHT6lm86qyhad3K2ako6hbjPUHegEg zfSFdErt6FOYIfMsBunVt89zP5RuZH0AJkyj8kMkZru0RycfL4p2ih/9FbyICX3V7mzy Bnwg== X-Gm-Message-State: ALoCoQlkIWxkYUcJieSAw0irlBEoyiEPvitYadFCFwZ5T22PHCHkdeq2Xao0+o6KJnm9Ml2FS9M5 X-Received: by 10.50.79.129 with SMTP id j1mr12581758igx.7.1442862203416; Mon, 21 Sep 2015 12:03:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.79.135 with SMTP id j7ls95213igx.17.gmail; Mon, 21 Sep 2015 12:03:19 -0700 (PDT) X-Received: by 10.50.66.205 with SMTP id h13mr137831igt.10.1442862199520; Mon, 21 Sep 2015 12:03:19 -0700 (PDT) In-Reply-To: X-Original-Sender: tomaszkam@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:20580 Archived-At: ------=_Part_755_199973864.1442862198883 Content-Type: multipart/alternative; boundary="----=_Part_756_1167183467.1442862198884" ------=_Part_756_1167183467.1442862198884 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:26:56 UTC+2 u=C5=BCytkow= nik David=20 Krauss napisa=C5=82: > > > On 2015=E2=80=9309=E2=80=9321, at 4:54 PM, Tomasz > wrote: > > And we can avoid repeating the same design that lead to the above desing= =20 > for the newly introduced classes. If I check the class interface and you= =20 > will found that it is move constructible, I would expect that I will be= =20 > able to pass it to function by value (ok) and return it from the function= ,=20 > also by value (eliminated in your design for valid reasons). The design= =20 > that provide move constructor, but then prohibits usuall use of such will= =20 > lead to more confusion. > > > On the other hand, if I require a diagnosis for own_initializer_list,=20 > then the implementation can simultaneously apply it to the classic=20 > initializer_list as well (give or take status level as an error or=20 > warning). No additional elements of confusion are added, and all the=20 > existing confusion is addressed. > > To be clear, now I understand that your paper differentiates between=20 management and ownership of: 1. Lifetime of elements in their sequence. This is bound and actually=20 managed by the own_initializer_list object. Means that the ownership is=20 passed in move constructor and destruction of the object owning the list=20 destroys the list. 2. Lifetime of the stack allocated storage for the array. It may outlive=20 the own_initializer_list object, but the rules that prohibit various use=20 cases of this class is designed to quarantee that the own_initializer_list= =20 object will never outlive the storage (in constrast to initializer_list). This is a novum from the standard library perspective. Even for related=20 optional, the lifetime of storage is bound to the lifetime of object,=20 stored element may be destroyed earlier. The nearest equivalent in hand=20 written code would be: template struct inplace_object_handler { explicit inplace_object_handler(void* a_ptr) : ptr(reinterpret_cast(a_ptr)) { new(ptr) T() }; ~inplace_object_handler() { ptr->~T(); } T* operator->() const { return ptr; } private: T* ptr; }; alignas(double) char buffor[sizeof(double)]; { inplace_object_handler obj(buffer); }; However, I would make such class non-copyable and move-able to prevent=20 transfer of ownership (even if I can safely move it to nested scopes). I=20 know that this does not prevent all situations when such class could be=20 constructed, but eliminates most of them. So my first expectation was that= =20 own_initializer_list will also follow this design. This does not eliminate= =20 possibility of construct leading to dangling reference, so special rules=20 that makes them ill-formed would still be necessary, but exposition of this= =20 errors will be reduced. Furthermore, your paper also discuss possibility of introducing the=20 sequence_literal const& as alternative for the initializer_list and=20 deprecating old feature. In that case we cannot argument the confusing=20 behavior by pointing to current design initializer_list - if we provide=20 true replacement, then there will be no need to use initializer_list in new= =20 syntax. Have you considered eliminating ability to declare own_initializer_list=20 object by the programmer. And force use of auto&& list =3D { "ala"s, "ola"s= }=20 even of first declaration? Or dropping the initializer_list deduction for= =20 auto entirely? According to=20 http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3912.html, the=20 total elimination of special auto deduction also received strong support=20 (but with opposition when compared to current resolution). --=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 http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. ------=_Part_756_1167183467.1442862198884 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable W dniu poniedzia=C5=82ek, 21 wrze=C5=9Bnia 2015 11:26:56 UTC+2 u=C5=BCytkow= nik David Krauss napisa=C5=82:
=

On 2015=E2=80=9309=E2=80=9321, at 4:54 PM, Tomasz <toma...@gmail.com&g= t; wrote:

And we can avoid repeating the sam= e design that lead to the above desing for the newly introduced classes. If= I check the class interface and you will found that it is move constructib= le, I would expect that I will be able to pass it to function by value (ok)= and return it from the function, also by value (eliminated in your design = for valid reasons). The design that provide move constructor, but then proh= ibits usuall use of such will lead to more confusion.

On the other hand, if I require a diagnosis for = own_initializer_list, then the implementation= can simultaneously apply it to the classic initiali= zer_list as well (give or take status level as an error or warning).= No additional elements of confusion are added, and all the existing confus= ion is addressed.

To be clear, now I= understand that your paper differentiates between management and ownership= of:
1. Lifetime of elements in their sequence. This is bound and actual= ly managed by the own_initializer_list object. Means that the ownership is = passed in move constructor and destruction of the object owning the list de= stroys the list.
2. Lifetime of the stack allocated storage for the arra= y. It may outlive the own_initializer_list object, but the rules that prohi= bit various use cases of this class is designed to quarantee that the own_i= nitializer_list object will never outlive the storage (in constrast to init= ializer_list).

This is a novum from the standard library perspective= .. Even for related optional, the lifetime of storage is bound to the lifeti= me of object, stored element may be destroyed earlier. The nearest equivale= nt in hand written code would be:
template<typename T>
struct i= nplace_object_handler
{
=C2=A0=C2=A0 explicit inplace_object_handler(= void* a_ptr)
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 : ptr(reinterpret_cast<T*= >(a_ptr))
=C2=A0=C2=A0 { new(ptr) T() };

=C2=A0=C2=A0 ~inplace= _object_handler() { ptr->~T(); }

=C2=A0=C2=A0 T* operator->() = const { return ptr; }

private:
=C2=A0=C2=A0 T* ptr;
};

= alignas(double) char buffor[sizeof(double)];
{
=C2=A0 inplace_object_= handler<double> obj(buffer);
};
However, I would make such clas= s non-copyable and move-able to prevent transfer of ownership (even if I ca= n safely move it to nested scopes). I know that this does not prevent all s= ituations when such class could be constructed, but eliminates most of them= .. So my first expectation was that own_initializer_list will also follow th= is design. This does not eliminate possibility of construct leading to dang= ling reference, so special rules that makes them ill-formed would still be = necessary, but exposition of this errors will be reduced.

Furthermor= e, your paper also discuss possibility of introducing the sequence_literal = const& as alternative for the initializer_list and deprecating old feat= ure. In that case we cannot argument the confusing behavior by pointing to = current design initializer_list - if we provide true replacement, then ther= e will be no need to use initializer_list in new syntax.

Have you co= nsidered eliminating ability to declare own_initializer_list object by the = programmer. And force use of auto&& list =3D { "ala"s, &q= uot;ola"s } even of first declaration? Or dropping the initializer_lis= t deduction for auto entirely? According to http://www.open-std.org/JTC1/SC= 22/WG21/docs/papers/2014/n3912.html, the total elimination of special auto = deduction also received strong support (but with opposition when compared t= o current resolution).


--

---
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 http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
------=_Part_756_1167183467.1442862198884-- ------=_Part_755_199973864.1442862198883-- .