220 5738 article Path: news.gmane.org!not-for-mail From: Richard Smith Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Uniform intialization with std::intializer_list is not uniform. Date: Wed, 14 Aug 2013 20:29:53 -0700 Lines: 172 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bd6c2c45a365f04e3f416d2 X-Trace: ger.gmane.org 1376537396 14193 80.91.229.3 (15 Aug 2013 03:29:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Aug 2013 03:29:56 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBDVNBJG4YAIBBMMWWGIAKGQEI3MOZOA@isocpp.org Thu Aug 15 05:29:59 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ye0-f199.google.com ([209.85.213.199]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V9oG3-0000WR-74 for gclcip-std-proposals@m.gmane.org; Thu, 15 Aug 2013 05:29:55 +0200 Original-Received: by mail-ye0-f199.google.com with SMTP id l12sf290275yen.2 for ; Wed, 14 Aug 2013 20:29:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:x-original-sender:x-original-authentication-results :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe:content-type; bh=UAUZbaBMwofeSZJ6eKpyeGTkiro8eX1lQWx2fiGNcu4=; b=y2aN+VAo88OkWLxh+OfCUl0eFGK7ZbUUK/hdytNadpBQCM6xyOJPeAGvSelB2cSPrp 959aZkKIvQhK091Gj1z2naC+8/RigCDzlDt+1iX/Le0TbW0aiSAyLLFgDzBl/RLA6a79 P8sEYzVP8/tlcd2lnhrkBqxq4e6jYMHjla2P1hayqLMzOIzp0s47Nwkt9oHc4L0jzc6E CLFALc7WrtCzAaJ0p/5ZqEkr3sDJ/QltiRsyx3zrLCT5gFnjCbMSf72/eiv+iVg/9Dbo eO1EdhgfBtRG7DfRjN8thDWNRUq1i/vHofBlwIT1DAZg6gdhPuRoeRvC6EUj+OLiA0TS 1U5A== X-Received: by 10.58.144.134 with SMTP id sm6mr3994422veb.27.1376537394238; Wed, 14 Aug 2013 20:29:54 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.49.48.49 with SMTP id i17ls164829qen.44.gmail; Wed, 14 Aug 2013 20:29:53 -0700 (PDT) X-Received: by 10.221.51.206 with SMTP id vj14mr12541692vcb.17.1376537393703; Wed, 14 Aug 2013 20:29:53 -0700 (PDT) Original-Received: from mail-vb0-x22a.google.com (mail-vb0-x22a.google.com [2607:f8b0:400c:c02::22a]) by mx.google.com with ESMTPS id gq6si1207821veb.129.2013.08.14.20.29.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Aug 2013 20:29:53 -0700 (PDT) Received-SPF: pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c02::22a as permitted sender) client-ip=2607:f8b0:400c:c02::22a; Original-Received: by mail-vb0-f42.google.com with SMTP id e12so216429vbg.1 for ; Wed, 14 Aug 2013 20:29:53 -0700 (PDT) X-Received: by 10.58.235.69 with SMTP id uk5mr12426635vec.17.1376537393376; Wed, 14 Aug 2013 20:29:53 -0700 (PDT) Original-Sender: metafoo@gmail.com Original-Received: by 10.58.12.168 with HTTP; Wed, 14 Aug 2013 20:29:53 -0700 (PDT) In-Reply-To: X-Original-Sender: richard@metafoo.co.uk X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of metafoo@gmail.com designates 2607:f8b0:400c:c02::22a as permitted sender) smtp.mail=metafoo@gmail.com; dkim=pass header.i=@gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: 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:5738 Archived-At: --047d7bd6c2c45a365f04e3f416d2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen < ville.voutilainen@gmail.com> wrote: > On 14 August 2013 17:39, Daniel Kr=FCgler wro= te: > >> > I think it would be worthwhile to explore whether we can do a fix that >> > doesn't require such work-arounds. The "wait for the expected >> range-support" rings an alarm >> > bell in my head. >> >> I don't understand why. Are you against range-support? IMO >> > > No. I'm against lumping every problem we have under the range umbrella. > string::split being one of them, this move-from-braced-list being another= .. > I don't think ranges are the proper solution for such things. > > >> std::initializer_list constructors in the library are just a special >> case of a more generalized range support pattern and I find it more >> reasonable to look for a more general solution instead of trying to >> mutate std::initializer_list to something that it was not intended to >> be. >> > > That's ok, I don't know what the solution should be yet, perhaps > mutating initializer_list isn't it. The problem shouldn't be "this is how > initializer_lists work, don't expect braced-initializers to work > differently". > I'm not supposed to KNOW there's an initializer_list involved when > I construct a vector from a braced list. At least I'm under the impressio= n > that initializer_list was supposed to be implementation plumbing > rather than something that's in-my-face. And again, I don't think > that implementation plumbing works quite right if I can't braced-init > with move-only types. Other people can freely agree to disagree > with that. > I agree. vector> can't be brace-initialized, so we have not fully arrived at the clean, simple, uniform initialization syntax we wanted. initializer_list is supposed to be the vehicle for communicating a braced-init-list from an initialization to a constructor, and it's not fully succeeding at that task. The core of the problem seems to be that initializer_list does not own its elements, not that the elements are immutable. If we merely made the contents of the initializer_list mutable, we would break move-safety: initializer_list> x =3D { a, b, c }; auto get() { return x; } std::vector> v(get()); // oops, implicitly move here We could fix this by adding a move-only std::unique_initializer_list (or similar) that owns its elements, but it seems overly-complicated to have two similar-but-different initializer_list types in the library. Conversely, it's probably too late to fix initializer_list to own its contents (and thus be move-only). --=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/. --047d7bd6c2c45a365f04e3f416d2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen <ville.voutilainen@gmail.com> wrote:
= On 14 August 2013 17:39, Daniel Kr=FCgle= r <daniel.kruegler@gmail.com> wrote:
> I think it would be worthwhile to explo= re whether we can do a fix that
> doesn't require such work-arounds. The "wait for the expected= range-support" rings an alarm
> bell in my head.

I don't understand why. Are you against range-support? IMO

No. I'm against lumping every probl= em we have under the range umbrella.
string::split being one = of them, this move-from-braced-list being another.
I don't think ranges are the proper solution for such things= ..
=A0
std::initializer_list constructors in the library are just a special
case of a more generalized range support pattern and I find it more
reasonable to look for a more general solution instead of trying to
mutate std::initializer_list to something that it was not intended to
be.

That's ok, I don't kn= ow what the solution should be yet, perhaps
mutating initializer_list is= n't it. The problem shouldn't be "this is how
initializer_l= ists work, don't expect braced-initializers to work differently".<= br>
I'm not supposed to KNOW there's an initializer_list inv= olved when
I construct a vector from a braced list. At least = I'm under the impression
that initializer_list was supposed to be im= plementation plumbing
rather than something that's in-my-face. And again, I don't thinkthat implementation plumbing works quite right if I can't braced-init=
with move-only types. Other people can freely agree to disagree
with that.


The core of the problem seems to be that initializer_li= st<T> does not own its elements, not that the elements are immutable.= If we merely made the contents of the initializer_list mutable, we would b= reak move-safety:

initializer_list<unique_ptr<T>> x =3D { a, = b, c };
auto get() { return x; }
std::vector<unique_= ptr<T>> v(get()); // oops, implicitly move here

We could fix this by adding a move-only std::unique_initializer_list&l= t;T> (or similar) that owns its elements, but it seems overly-complicate= d to have two similar-but-different initializer_list types in the library. = Conversely, it's probably too late to fix initializer_list to own its c= ontents (and thus be move-only).

--
 
---
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-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-proposals/<= /a>.
--047d7bd6c2c45a365f04e3f416d2-- .