220 20544 article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Draft D0065: Movable initializer lists, rev. 2 Date: Mon, 21 Sep 2015 12:11:57 +0800 Lines: 250 Approved: news@gmane.org Message-ID: References: <87343e65-eecd-4b96-86b7-a883aa7f9d1d@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24" X-Trace: ger.gmane.org 1442808812 31900 80.91.229.3 (21 Sep 2015 04:13:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 21 Sep 2015 04:13:32 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBYUH72XQKGQEJTPLDTQ@isocpp.org Mon Sep 21 06:13:26 2015 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 1ZdsTk-0000CB-CD for gclcip-std-proposals@m.gmane.org; Mon, 21 Sep 2015 06:13:24 +0200 Original-Received: by oiww128 with SMTP id w128sf181982184oiw.0 for ; Sun, 20 Sep 2015 21:13:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:message-id:mime-version :subject:date:references:to:in-reply-to: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=mOYRL5F/0myPppiyUOWyMYdrhwBF3b/LmYIGITaK8TY=; b=R/XYGRK5+kbN1x3TqMX9DzFpxyKisf61T8FhnvJgJ9bqh9vRg4kcnPXNBQGbc16CbZ d5DOECw72Pun/Fw2EMPUJ43dQ8RbuoHZs+8qy1HeDowJOS5LN/uGc/+gmsBhpYINvPx0 uo+PAsrwYgmNw5kdbGJsrm15A+SHpBDfEqdCjcyuh102FkEZwNmbvNBk13eB4HV0u2WT Rv/2j9G1wtFfmJyEhGbFflrX4bpUipCDJrWcr0+pRoIrffM5F9UUIOemBg9xgMv4XZFH 6J+WAzIf3U1Dx8x8AJD2e/eVnwueDk2aqHyhoNmzDWtsQTlaOeEOVGLmpknmg6rWw1Vh ViBg== X-Gm-Message-State: ALoCoQn7D6dAz25Sbm34I7REpDFyE9sL3fQig7LyQEcGwo9uwoUh0BSlWslWl2F97hijMgJKmcZx X-Received: by 10.182.66.5 with SMTP id b5mr14945661obt.41.1442808803569; Sun, 20 Sep 2015 21:13:23 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.112.169 with SMTP id ir9ls725898igb.28.canary; Sun, 20 Sep 2015 21:13:22 -0700 (PDT) X-Received: by 10.66.141.111 with SMTP id rn15mr22267887pab.118.1442808802774; Sun, 20 Sep 2015 21:13:22 -0700 (PDT) Original-Received: from mail-pa0-x241.google.com (mail-pa0-x241.google.com. [2607:f8b0:400e:c03::241]) by mx.google.com with ESMTPS id ur6si19172838pac.30.2015.09.20.21.13.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Sep 2015 21:13:22 -0700 (PDT) Received-SPF: pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::241 as permitted sender) client-ip=2607:f8b0:400e:c03::241; Original-Received: by padew5 with SMTP id ew5so12677774pad.0 for ; Sun, 20 Sep 2015 21:13:22 -0700 (PDT) X-Received: by 10.68.129.198 with SMTP id ny6mr22434988pbb.42.1442808802603; Sun, 20 Sep 2015 21:13:22 -0700 (PDT) Original-Received: from [172.20.10.2] ([121.54.54.44]) by smtp.gmail.com with ESMTPSA id k10sm21470027pbq.78.2015.09.20.21.13.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 21:13:22 -0700 (PDT) In-Reply-To: <87343e65-eecd-4b96-86b7-a883aa7f9d1d@isocpp.org> X-Mailer: Apple Mail (2.2104) X-Original-Sender: potswa@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of potswa@gmail.com designates 2607:f8b0:400e:c03::241 as permitted sender) smtp.mailfrom=potswa@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=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:20544 Archived-At: --Apple-Mail=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 > On 2015=E2=80=9309=E2=80=9321, at 3:02 AM, Tomasz w= rote: >=20 > I have a question regarding the rationale for keeping own_initializer_lis= t movable. This still may lead to several dangling reference problems, f= or example most common one is to treat own_initializer_list as normal co= ntainer and store as class member, Declaring a class member of own_initializer_list type is a diagnosable erro= r. See the last paragraph in =C2=A72: > This likewise requires forbidding cases where initializer_list generates = dangling pointers: when it is used as a member, a base class, the value of = a return statement, an exception object, or the type in a new-expression. >=20 It would be nice if this applied to ordinary initializer_list too, but that= ship might have sailed. Anyway, it would be another proposal. Perhaps it should be more strongly worded so as not to appear as a continge= ncy: =E2=80=9CIt is forbidden to=E2=80=A6=E2=80=9D > Both situations are non-trivial to understand and requires knowledge abou= t internal implementation (stack array) and are source of errors in the pro= gram. Both of them would be fixed by making the own_initializer_list non-co= pyable and non-moveable. That would not be sufficient as a fix, because constructing an initializer = list object from a braced-init-list does not always involve an intermediate= temporary that needs to be moved. > The cost of the change would be that you will be no longer able to write: > auto list =3D {"ala"s, "ola"s}; > //Will requires move constructor to intializer from temporary on left han= d side. However the syntax: No, there is no temporary there. Copy-list-initialization, unlike other cop= y-initialization, does not convert to the type as a temporary and then copy= -initialize. > auto&& list =3D {"ala"s, "ola"s}; > //Will still be valid. > The functions will be required to accept own_initializer_list&&, but I do not think that this is a problem; >=20 > There is a situation, when the non-copyable non-moveable class can still = be transfered. One is: > own_initializer_list makeComponets() > {=20 > return {std::make_unique(), std::make_unique()}; > } >=20 > auto && list =3D makeComponets(); > However, I believe in this case the standard will guarantee that list is = no longer dangling. No, there is no such guarantee and it=E2=80=99s unimplementable for all pra= ctical intents. Most compilers have already implemented a diagnosis for thi= s case. > In situation as above, the standard requires that own_initializer_list will be constructed on call side, as creation of stack array is= part the construction of own_initializer_list, the array wil= l be placed on call side. Can this be reconciled with the Common ABI? > And the second: > auto* p =3D new own_initializer_list{std::make_unique(), std::make_unique()}; > The paper still does not qualify if this is safe. Already covered by the above quote. > The array may be placed both on stack (dangling), or on the heap with own= _initializer_list object. std::initializer_list followed a misguided philosophy of standardization, t= hat the standard would only state a few minimal behavioral guarantees, to r= ely on the wisdom of implementers to find the most efficient realization. T= his led to mass confusion as the C++11 spec was unimplementable. Users tend= ed to expect that the list would be placed on the heap as by an array-new e= xpression, if necessary =E2=80=94 and what=E2=80=99s so unreasonable about = that? So CWG formalized the most common behavior, which is to create a temp= orary array object and allow lifetime extension. In the process, the one op= timization to be specifically intended by design, static storage, inadverte= ntly became nonconforming. Perhaps the proposal should go into more detail, but I tried to simply ackn= owledge the status quo by mentioning stack allocation, in the abstract and = the first sentence of =C2=A72, and mentioning the optimization elsewhere. I= foresee more questions about this=E2=80=A6 perhaps folks feel that heap al= location was a possibility that was snatched away. > Choosing the second resolution and making own_initializer_list non-moveab= le will eliminate all dangling reference problems occuring in situation whe= n own_initializer_list is stored by value. Storing it by reference, will= provide to dangling reference, as for any other class. My proposal allows you to have a member of own_initializer_list&& refere= nce type. Such a member reference can become dangling, but a list itself ne= ver does. This is mentioned in the sentence after the above quote. My other EWG proposal, =E2=80=9CLifetime extension for accessors and views= =E2=80=9D (bit.ly/genlife ) seeks to solve or at lea= st diagnose such dangling reference issues. --=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/. --Apple-Mail=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8
On 2015=E2=80=9309= =E2=80=9321, at 3:02 AM, Tomasz <tomaszkam@gmail.com> wrote:

I have a questi= on regarding the rationale for keeping own_initializer_list<T> movabl= e. This still may lead to several dangling reference problems, for example = most common one is to treat own_initializer_list<T> as normal contain= er and store as class member,

<= /div>
Declaring a class member of own= _initializer_list type is a diagnosable error. See the last paragrap= h in =C2=A72:

This likewise re= quires forbidding cases where initializer_list= generates dangling pointers: when it is used as a member, a base cl= ass, the value of a return statement, a= n exception object, or the type in a new-expression.

<= /blockquote>

It would be nice if = this applied to ordinary initializer_list= too, but that ship might have sailed. Anyway, it would be another p= roposal.

Perhaps it should be more stro= ngly worded so as not to appear as a contingency: =E2=80=9CIt is forbidden = to=E2=80=A6=E2=80=9D

Both situations are non= -trivial to understand and requires knowledge about internal implementation= (stack array) and are source of errors in the program. Both of them would = be fixed by making the own_initializer_list non-copyable and non-moveable. =

That would not be s= ufficient as a fix, because constructing an initializer list object from a = braced-init-list does not always involve an intermediate temporary that nee= ds to be moved.

The cost of the change would be t= hat you will be no longer able to write:
auto list =3D {"ala"= s, "ola"s};
//Will requires move constructor to intializer fr= om temporary on left hand side. However the syntax:

No, there is no temporary th= ere. Copy-list-initialization, unlike other copy-initialization, does not c= onvert to the type as a temporary and then copy-initialize.

auto&& list =3D {"ala"s, "ola"s};
//Will = still be valid.
The functions will be required to accept own_= initializer_list<ComponentPtr>&&, but I do not think that thi= s is a problem;

There is a situation, when the= non-copyable non-moveable class can still be transfered. One is:
own_initializer_list<ComponentPtr> makeComponets()
{
  return {std::make_unique<ConcreteComposite1>= ;(), std::make_unique<ConcreteComposite2>()};
}

auto && list =3D makeComponets();
However, I believe in this case the standard will guarantee that list is= no longer dangling.

No, there is no such guarantee and it=E2=80=99s unimplementable for all pr= actical intents. Most compilers have already implemented a diagnosis for th= is case.

In situation as above, the standard req= uires that own_initializer_list<ComponentPtr> will be constructed on = call side, as creation of stack array is part the construction of own_initi= alizer_list<ComponentPtr>, the array will be placed on call side.

Can this= be reconciled with the Common ABI?

And the secon= d:
auto* p =3D new own_initializer_list<ComponentPtr>{s= td::make_unique<ConcreteComposite1>(), std::make_unique<ConcreteCo= mposite2>()};
The paper still does not qualify if this is = safe.

Already covere= d by the above quote.

The array may be placed = both on stack (dangling), or on the heap with own_initializer_list<T>= object.

std::initializer_list followed a misgui= ded philosophy of standardization, that the standard would only state a few= minimal behavioral guarantees, to rely on the wisdom of implementers to fi= nd the most efficient realization. This led to mass confusion as the C++11 = spec was unimplementable. Users tended to expect that the list would be pla= ced on the heap as by an array-new expression, if necessary =E2=80=94 and w= hat=E2=80=99s so unreasonable about that? So CWG formalized the most common= behavior, which is to create a temporary array object and allow lifetime e= xtension. In the process, the one optimization to be specifically intended = by design, static storage, inadvertently became nonconforming.
Perhaps the proposal should go into more detail, bu= t I tried to simply acknowledge the status quo by mentioning stack allocati= on, in the abstract and the first sentence of =C2=A72, and mentioning the o= ptimization elsewhere. I foresee more questions about this=E2=80=A6 perhaps= folks feel that heap allocation was a possibility that was snatched away.<= /div>
Choosing the second resolution and making own_ini= tializer_list non-moveable will eliminate all dangling reference problems o= ccuring in situation when own_initializer_list<T> is stored by value.= Storing it by reference, will provide to dangling reference, as for any ot= her class.

My proposal allows you to have a member of own_initializer_list<T>&& reference type. Such a me= mber reference can become dangling, but a list itself never does. This is m= entioned in the sentence after the above quote.
My other EWG proposal, =E2=80=9CLifetime extension for accessors a= nd views=E2=80=9D (bit.ly/genl= ife) seeks to solve or at least diagnose such dangling reference issues= ..

--

---
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>.
--Apple-Mail=_25F2DF85-E5AC-43AB-8E3E-B4A454EADC24-- .