220 5739 <87k3jnmwjh.fsf@euclid.axiomatics.org> article Path: news.gmane.org!not-for-mail From: Gabriel Dos Reis Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Uniform intialization with std::intializer_list is not uniform. Date: Wed, 14 Aug 2013 23:02:10 -0500 Organization: axiomatics.org Lines: 111 Approved: news@gmane.org Message-ID: <87k3jnmwjh.fsf@euclid.axiomatics.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1376539330 30342 80.91.229.3 (15 Aug 2013 04:02:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Aug 2013 04:02:10 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCSYNQUB2UHRBQ5FWGIAKGQEHN2FUUA@isocpp.org Thu Aug 15 06:02:13 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ob0-f198.google.com ([209.85.214.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V9olJ-0004q6-2Y for gclcip-std-proposals@m.gmane.org; Thu, 15 Aug 2013 06:02:13 +0200 Original-Received: by mail-ob0-f198.google.com with SMTP id wc20sf1231559obb.5 for ; Wed, 14 Aug 2013 21:02:12 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:subject:in-reply-to:organization:references:sender:date :message-id:lines:mime-version: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:content-transfer-encoding; bh=4LnuzD0jqWSZm4q38Tu6YuWtzycPVW5o1KcCgww6GGc=; b=Bv4ukGWEc9zS2QNdppTVNfRdLAx80PvrIbRHJ4BV7RocoIC6Jrvo/U5KUkwPT7G/7z aM31x1F1W+ldmvl02M04SksmkV0sjZw7dMnFMnfWdHveAn6VycyHfAWWqYHIOJPQEoBL PkLU2x44X7Ietu9ovrEXpzcyALGzLr4K84I8sB6/Lw9vAOJTyK1zrSINvU09ys1l0p/8 WiOehIIYeedVaHriQ3y97lgc2NXaHnSG9S7/jVrflm7VPw7oMl0Ly0y09R+xPgCKND5+ HfZhJjxrNVjQ9plYNAxzTmt90gqITItcfx+X2kzBuCMhvmv3rID76NaKtDOnd8WUhWU9 BWig== X-Received: by 10.42.253.74 with SMTP id mz10mr7804325icb.28.1376539331989; Wed, 14 Aug 2013 21:02:11 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.18.46 with SMTP id t14ls267669igd.3.gmail; Wed, 14 Aug 2013 21:02:11 -0700 (PDT) X-Received: by 10.68.249.68 with SMTP id ys4mr5714124pbc.159.1376539331243; Wed, 14 Aug 2013 21:02:11 -0700 (PDT) Original-Received: from mail.axiomatics.org ([2600:3c00::f03c:91ff:feae:e0e6]) by mx.google.com with ESMTP id zs4si30390066pbb.16.2013.08.14.21.02.10 for ; Wed, 14 Aug 2013 21:02:10 -0700 (PDT) Received-SPF: neutral (google.com: 2600:3c00::f03c:91ff:feae:e0e6 is neither permitted nor denied by best guess record for domain of gdr@axiomatics.org) client-ip=2600:3c00::f03c:91ff:feae:e0e6; Original-Received: by mail.axiomatics.org (Postfix, from userid 1000) id 32509ED0D; Wed, 14 Aug 2013 23:02:10 -0500 (CDT) In-Reply-To: (Richard Smith's message of "Wed, 14 Aug 2013 20:29:53 -0700") Original-Sender: gdr@euclid.axiomatics.org Original-Lines: 79 X-Original-Sender: gdr@axiomatics.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 2600:3c00::f03c:91ff:feae:e0e6 is neither permitted nor denied by best guess record for domain of gdr@axiomatics.org) smtp.mail=gdr@axiomatics.org 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:5739 Archived-At: Richard Smith writes: | On Wed, Aug 14, 2013 at 9:50 AM, Ville Voutilainen wrote: |=20 | On 14 August 2013 17:39, Daniel Kr=FCgler = wrote: |=20 | > I think it would be worthwhile to explore whether we can do a f= ix | that | > doesn't require such work-arounds. The "wait for the expected | range-support" rings an alarm | > bell in my head. |=20 | I don't understand why. Are you against range-support? IMO |=20 |=20 | No. I'm against lumping every problem we have under the range umbrell= a. | string::split being one of them, this move-from-braced-list being ano= ther. | I don't think ranges are the proper solution for such things. | =A0 |=20 | std::initializer_list constructors in the library are just a spec= ial | case of a more generalized range support pattern and I find it mo= re | reasonable to look for a more general solution instead of trying = to | mutate std::initializer_list to something that it was not intende= d to | be. |=20 |=20 | 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 impre= ssion | 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. |=20 |=20 | 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 fu= lly | succeeding at that task. |=20 | 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 cont= ents | of the initializer_list mutable, we would break move-safety: |=20 | initializer_list> x =3D { a, b, c }; | auto get() { return x; } | std::vector> v(get()); // oops, implicitly move here |=20 | 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 b= e | move-only). I agree with some of the descriptions here. However, I have to wonder whether we are in a classical configuration of 'perfect is the enemy of goo= d'. If we get 95% right, then realistically, I consider we've done a good job. Initialization in C++ is a multi-faceted and treacherous problem -- from what I've learned working on this problem for a very long period of time. It is very easy to get one facet perfect, 100% right. Putting all the perfect solutions to the isolated problems together is a highly non-trivial whack-a-mole. My conjecture is, somewhere we are going to make a community or an expert unhappy about one resolution or the other. Even as of today, I still consider the current solution acceptable. It does not mean that I believe we can't make improvement though -- but I just think that any substantial improvement from now is going to result in complication for some segments of users. -- Gaby --=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/. .