220 5737 <33da2678-819c-4925-97e5-50adf8bcd49b@isocpp.org> article Path: news.gmane.org!not-for-mail From: David Krauss Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Uniform intialization with std::intializer_list is not uniform. Date: Wed, 14 Aug 2013 18:35:58 -0700 (PDT) Lines: 88 Approved: news@gmane.org Message-ID: <33da2678-819c-4925-97e5-50adf8bcd49b@isocpp.org> References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_87_32955712.1376530558863" X-Trace: ger.gmane.org 1376530562 11771 80.91.229.3 (15 Aug 2013 01:36:02 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 15 Aug 2013 01:36:02 +0000 (UTC) To: std-proposals@isocpp.org Original-X-From: std-proposals+bncBCW25A7E3QCRBAHBWCIAKGQELXTYMMY@isocpp.org Thu Aug 15 03:36:03 2013 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ie0-f198.google.com ([209.85.223.198]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1V9mTp-0005F8-VN for gclcip-std-proposals@m.gmane.org; Thu, 15 Aug 2013 03:36:02 +0200 Original-Received: by mail-ie0-f198.google.com with SMTP id c11sf799611ieb.5 for ; Wed, 14 Aug 2013 18:36:01 -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=WsrRg44EVjo/CHQ9IXDv5WDuK6/gVu4LtENBhfh1A2Y=; b=TjormmAPtjOnuPfr4QbvhakdCLocg1ONPCxoVZmCBpjK/Q/5vam8Uay8vc0ts7/aER zGJNqix8mxbDFxazpwijGM6SxdGrDEzZkMbExsCkKPVy2dFinTVUqvaTCr+5JMWoblMp 3Gihaa23VdqIBg8gk/JgyN2ajiUGgk+zp+vWHaZyYiN2iZQO7g+gFYre1+7IExr+L7am 3hP59fMy/2n5IB3vc0yzecf3P7ZsKLxkOLwm9qZa1qZ4rOcvBP3poue3BOb0cb1x/cG5 DbfUCWh41P8htaxaxUVITy55GqD5BMWchyDJmDbnDH/b/hF089jbjokjYTPX5C2I892O oVUw== X-Received: by 10.42.41.77 with SMTP id o13mr7515741ice.20.1376530561024; Wed, 14 Aug 2013 18:36:01 -0700 (PDT) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.50.101.51 with SMTP id fd19ls4063398igb.10.canary; Wed, 14 Aug 2013 18:36:00 -0700 (PDT) X-Received: by 10.50.83.6 with SMTP id m6mr18232igy.1.1376530560073; Wed, 14 Aug 2013 18:36:00 -0700 (PDT) In-Reply-To: X-Original-Sender: potswa@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:5737 Archived-At: ------=_Part_87_32955712.1376530558863 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, August 15, 2013 7:59:13 AM UTC+8, Nicol Bolas wrote: > > 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. > What tools or flexibilities are available to solve within the existing paradigm? The really unfortunate thing is not that the initial solution fell short, but that the revision is already too late for C++14? Has there been any preliminary study of what might be changed and what is really essential as-is in the std::initializer_list spec? For example, so much would be fixed if begin() and end() could return non-const pointers. Is this a serious breaking change per se? It doesn't seem so to me. A good start would be to differentiate between const and non-const std::initializer_list. A function taking a const std::initializer_list *by value* would have read-only access to its contents, and allow the implementation to use storage in ROM, whereas dropping the const would force it into stack allocation. Although pass-by-const-value is generally useless, a quick trial in GCC shows that you're already allowed to overload const and non-const parameters (i.e. const does not decay away in a function parameter type), so the implementation might not be so bad. -- --- 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_87_32955712.1376530558863 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Thursday, August 15, 2013 7:59:13 AM UTC+8, Nicol Bolas= wrote:
There = are a lot more uses for having an object with an initializer_list construct= or 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. W= e may need a new "initializer_list" type to solve it, but it can certainly = be resolved under the existing paradigm.
=
What tools or flexibilities are available to solve within the existing = paradigm? The really unfortunate thing is not that the initial solution fel= l short, but that the revision is already too late for C++14?

Has th= ere been any preliminary study of what might be changed and what is really = essential as-is in the std::initializer_list spec?

For example, so m= uch would be fixed if begin() and end() could return non-const pointers. Is= this a serious breaking change per se? It doesn't seem so to me.

A = good start would be to differentiate between const and non-const std::initi= alizer_list. A function taking a const std::initializer_list by value would have read-only access to its contents, and allow the implementation= to use storage in ROM, whereas dropping the const would force it into stac= k allocation.

Although pass-by-const-value is generally useless, a q= uick trial in GCC shows that you're already allowed to overload const and n= on-const parameters (i.e. const does not decay away in a function parameter= type), so the implementation might not be so bad.

--
 
---
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_87_32955712.1376530558863-- .