220 5736 article Path: news.gmane.org!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Uniform intialization with std::intializer_list is not uniform. Date: Wed, 14 Aug 2013 16:59:13 -0700 (PDT) Lines: 202 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="----=_Part_2999_31542940.1376524753480" X-Trace: ger.gmane.org 1376524756 22256 80.91.229.3 (14 Aug 2013 23:59:16 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 14 Aug 2013 23:59:16 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCEKFTV6ZUMBBU5TWCIAKGQETA2Q2UI@isocpp.org Thu Aug 15 01:59:18 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-oa0-f71.google.com ([209.85.219.71]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V9kyD-0004aP-JJ for gclcip-std-proposals@m.gmane.org; Thu, 15 Aug 2013 01:59:17 +0200 Original-Received: by mail-oa0-f71.google.com with SMTP id k18sf471327oag.6 for ; Wed, 14 Aug 2013 16:59:16 -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 :x-original-sender:reply-to:precedence:mailing-list:list-id :list-post:list-help:list-archive:list-subscribe:list-unsubscribe :content-type; bh=X468FC4OPQHW23T/HCDAheOQKo4rpiU0gGxl/QsH7WE=; b=Z5zcxYv5ZBaxS69QeZDYCiQ/M9OKEW15RCKg123mw8XcbBBe1R13LU2inzdJjcmVlt kaklt8Giq1gfSQyzwaJpSiDMo/NsWwExcejGWOYzfl6aLT01CCPgtyZxwlWoSPFGZUj4 bvYa21NTbUSHiMgpCDYfJDH15FztK5G/8yuXtWZDUevQd5Eaw3Z9mqVo59s6qDGE49k3 HoZqdnIfvQck497X46ACTVIkyWcqls9sxrxXjKCUtt+XNYJJn62PD6dhY4aIrBpUBbDU ZIX/FfUddBlyndTlCcpWBgheBxz1x+JOT3pTJrifWqc1uGS6ukqS/ovYMNUi9GHvaM0t fwzg== X-Received: by 10.42.70.138 with SMTP id f10mr7023537icj.16.1376524756552; Wed, 14 Aug 2013 16:59:16 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.107.9 with SMTP id gy9ls2224183igb.9.canary; Wed, 14 Aug 2013 16:59:15 -0700 (PDT) X-Received: by 10.50.29.72 with SMTP id i8mr8548igh.1.1376524755652; Wed, 14 Aug 2013 16:59:15 -0700 (PDT) In-Reply-To: X-Original-Sender: jmckesson@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:5736 Archived-At: ------=_Part_2999_31542940.1376524753480 Content-Type: text/plain; charset=ISO-8859-1 On Wednesday, August 14, 2013 1:42:38 PM UTC-7, toma...@gmail.com wrote: > > 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 impression >> 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. >> >> > The std::initializer_list is only the solution of the uniform > initialization problem, > not the problem itself. So while the design of initializer list is > perfectly valid (thanks > Daniel for the papers), this model failed to achieve the main goal: > > Provide uniform initialization for build-in types (arrays) and > user defined types. > No. Uniform initialization was about the copy vs. direct vs. aggregate initialization paradigm. That is, providing a single way to initialize a type that works exactly the same in all circumstances, which can be used for all types. But because it used {} syntax, it was also adopted into providing a way to initialize an arbitrary object from a sequence of equivalently typed parameters. But that wasn't its primary purpose. That is the slogan/promotional phase for the most of materials about C++11. > But the initialization of the vector is not uniform with the build-in > arrays, which > is suprising for the users and make learning of C++ harder, not easer as > uniform initialization suppose to. Especially when no > presentation/material know to me > on C++11 mentions this - they use the slogan. > That's because it's fairly minor, all things considered. The far more eggregious issue with UI is that initializer_list constructors can hide constructors that just so happen to take the same types of parameters. The fact that you can't put a non-copyable type in a braced-init-list that will be converted into an initializer_list is pretty minor next to hiding important constructors, thus forcing you back into () constructor syntax. > *Was another approach possible?* > I think yes. To point is to not use 2-face initialization and use > varidatic templates instead: > Um, how does that help? It now turns something that was quite simple into something incredibly complex. Yes, it solves one problem, but it creates many more. It makes accidental narrowing very possible. It makes the compiler errors you get for creating a braced-init-list of different types much more oddball. It causes the generation of lots of pointless code, bloating compile times needlessly (it's a list of known size. We shouldn't have to template metaprogram recurse through it). It also conflicts with other parts of uniform initialization: being able to call non-initializer_list constructors with braced-init-lists.** Lastly, there's no way to differentiate between a variadic template intended for some other purpose and an object that you want to be constructed from an arbitrary list of values. > Of course this code needs allocator support (std::allocator_arg should be > used), but this > is doable. > > This will of course make writing an STL-like container even harder, but > the allocator support > and exception safety already make this a really hrd task so that should > not be a problem. Also > there will be some problem with ambiguity of constructor. But from the > user perspective the goal will > be achived - the vector intialization will be uniform with intialization > of build in arrays, even considering > performance. > There are a lot more uses for having an object with an initializer_list constructor than *just* an STL-compliant container type. We shouldn't make you have to go through that much effort to process *an array*. As people have said, this is a solveable problem. We may need a new "initializer_list" type to solve it, but it can certainly be resolved under the existing paradigm. -- --- 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 email 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/. ------=_Part_2999_31542940.1376524753480 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wednesday, August 14, 2013 1:42:38 PM UTC-7, toma...@gm= ail.com wrote:
That's ok, I don't know what the solution = should be yet, perhaps
mutating initializer_list isn't it. The problem s= houldn't be "this is how
initializer_lists work, don't expect braced-ini= tializers to work differently".
I'm not supposed to KNOW there's an initializer_list involved wh= en
I construct a vector from a braced list. At least I'm unde= r the impression
that initializer_list was supposed to be implementation= plumbing
rather than something that's in-my-face. And again, I don't think
that i= mplementation plumbing works quite right if I can't braced-init
with mov= e-only types. Other people can freely agree to disagree
with that.
 
The std::init= ializer_list<int> is only the solution of the uniform initialization = problem,
not the problem itself. So while the design of initializer list= is perfectly valid (thanks
Daniel for the papers), this model failed to= achieve the main goal:
That is the slogan/promo= tional phase for the most of materials about C++11.
But the initializati= on of the vector is not uniform with the build-in arrays, which
is supri= sing for the users and make learning of C++ harder, not easer as
unifor= m initialization suppose to. Especially when no presentation/material know = to me
on C++11 mentions this - they use the slogan.
 
That's because it's fairly minor, all things = considered. The far more eggregious issue with UI is that initializer_list = constructors can hide constructors that just so happen to take the same typ= es of parameters. The fact that you can't put a non-copyable type in a brac= ed-init-list that will be converted into an initializer_list is pretty mino= r next to hiding important constructors, thus forcing you back into () cons= tructor syntax.
 
Was another approach possible?
I think yes. To point is to not use = 2-face initialization and use varidatic templates instead:
=

Um, how does that help? It now turns something = that was quite simple into something incredibly complex. Yes, it solves one= problem, but it creates many more.

It makes accidental narrowing ve= ry possible. It makes the compiler errors you get for creating a braced-ini= t-list of different types much more oddball. It causes the generation of lo= ts of pointless code, bloating compile times needlessly (it's a list of kno= wn size. We shouldn't have to template metaprogram recurse through it). It = also conflicts with other parts of uniform initialization: being able to ca= ll non-initializer_list constructors with braced-init-lists. Lastly,= there's no way to differentiate between a variadic template intended for s= ome other purpose and an object that you want to be constructed from an arb= itrary list of values.
 
Of course this code needs allocator su= pport (std::allocator_arg should be used), but this
is doable.

Th= is will of course make writing an STL-like container even harder, but the a= llocator support
and exception safety already make this a really hrd tas= k so that should not be a problem. Also
there will be some problem with = ambiguity of constructor. But from the user perspective the goal will
be= achived - the vector intialization will be uniform with intialization of b= uild in arrays, even considering
performance.

There are a lot more uses for having an object wit= h an initializer_list constructor than just an STL-compliant contain= er type. We shouldn't make you have to go through that much effort to proce= ss an array.

As people have= said, this is a solveable problem. We may need a new "initializer_list" ty= pe to solve it, but it can certainly be resolved under the existing paradig= m.

--
 
---
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>.
------=_Part_2999_31542940.1376524753480-- .