220 36577 <0b33061f-3b5a-481f-849b-3c7da72897db@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Re: Should the Default Allocator use Uniform Initialization? Date: Mon, 8 Jan 2018 10:10:27 -0800 (PST) Lines: 154 Approved: news@gmane.org Message-ID: <0b33061f-3b5a-481f-849b-3c7da72897db@isocpp.org> References: <0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40@isocpp.org> Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_14999_901955929.1515435027671" X-Trace: blaine.gmane.org 1515434912 23481 195.159.176.226 (8 Jan 2018 18:08:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 18:08:32 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBBFHIZ3JAKGQEJB3VAEQ@isocpp.org Mon Jan 08 19:08:27 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-vk0-f70.google.com ([209.85.213.70]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYbqU-0005i7-9W for gclcip-std-proposals@m.gmane.org; Mon, 08 Jan 2018 19:08:26 +0100 Original-Received: by mail-vk0-f70.google.com with SMTP id y127sf7185176vkg.17 for ; Mon, 08 Jan 2018 10:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isocpp-org.20150623.gappssmtp.com; s=20150623; 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; bh=5Cy3WEHl25c6FedNEeVGMINNG5leXit8iLu9E/I0B6Y=; b=mSZq4RqVTVd8MT0kp3WRH7tpZdbNA+3iiwwrJ6+RTNtKe7QSlxYBuySNAA4rerezSX T6OgVQC8a9Khjnp68ExHUEgCRrSACoVJJ2nb0GT5io043Mw6mLth2SZJzEA8CkZxCDdx N5hpT1z186Nc/zHJui5eR5N2JLT/UGWUHvyDdK9bQGis7/uqHPNV+1FKZ9D/LaKOzefk LrM0qfpNN393f0MKCyzAyL/c9gSLS3s8Rqgla3ebhED2rM3FFIEWN2BKPnEpHt0RnT6O kCO7+jzXvMhQ/aSCTDJp4Am9C/KVyNbagx85qC5PkGrmbHaJdFaN9eDh44vpx46iOs4s 2p7A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; 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; bh=5Cy3WEHl25c6FedNEeVGMINNG5leXit8iLu9E/I0B6Y=; b=LcL5ZSveHyGR59ZUx33faChDqXdFFCxm8kqHOGGwK21Wmd+SE5QAU/fTehopBzsyBJ 5jyz2K0OKbggKsJB+osm1TkxdnzdBEdZSwrU3DMPzWRgv5hbY7yPagT/o4mmXODlUD0X U2GCHPoCUp2KnMTYtVoVuA6TgpwQaaWYV53jy7T1wsRtwu7rMjJUWHJimSm4sPrlEmcV YyGGfg8TNHFIJgthQCg/EfUFUM7ShykKlmrWzi2/xZs1e/wb8ESVLyCLZSFNuruWEcyN YQRIyXVtKY5Nupj0Vaw80pqPKqaq/cjV3TgXOc/maa2J4gmqG6Ho7bO3ZeC8ksvQnNak dEMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:message-id:in-reply-to:references :subject:mime-version:x-original-sender:reply-to:precedence :mailing-list:list-id:x-spam-checked-in-group:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=5Cy3WEHl25c6FedNEeVGMINNG5leXit8iLu9E/I0B6Y=; b=TtSZ91xLK7c2+trPanvrPkr1CSTc3gffh0gBrFlRdnXCezmUTpSVSsEHAGYQXlPbZw miCfZX63qdr+z2ROI4J7E4OtggIniQzNjJv6PavXKpIyGkVirXsaGmjk4g5GVn6plQI2 oC51UW3qIPzTaeOF4y5Z9D06jFZSM7hubDiOH3h/LJL+b8veyWT9yk17bqg0tpuKauH5 hMThTTyAJvloh6F646PJ/JxKF/9Mja9+OAMYXekZSGrUjlNz1nzodsfRuyKuoKfnwDhO sPWaLtt5Dwsrr8NkK77O8sgEuY3muJjoa97kOiOU5uMHv8RAX8MbUfvVWp38gZq/WAqG 6Axg== X-Gm-Message-State: AKwxytcYxdaK93XPYVKwt2opYD5I+DTGhqShfuCwsYWvCihaIYSuljp9 plH+LFgbI3YhUpYIHatxSDVEfQ== X-Google-Smtp-Source: ACJfBouYlYzOagG5mtPexnrT1pqdHv5cCMAQg98qRDDdNDwGV7TtXZxpsrOVM8vO39/uZQp1TtEqrg== X-Received: by 10.176.72.132 with SMTP id x4mr6223909uac.84.1515435029665; Mon, 08 Jan 2018 10:10:29 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.29.7 with SMTP id j7ls283747uak.2.gmail; Mon, 08 Jan 2018 10:10:28 -0800 (PST) X-Received: by 10.31.162.200 with SMTP id l191mr1349427vke.14.1515435028184; Mon, 08 Jan 2018 10:10:28 -0800 (PST) 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-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:36577 Archived-At: ------=_Part_14999_901955929.1515435027671 Content-Type: multipart/alternative; boundary="----=_Part_15000_1409491456.1515435027671" ------=_Part_15000_1409491456.1515435027671 Content-Type: text/plain; charset="UTF-8" On Monday, January 8, 2018 at 12:25:18 PM UTC-5, Ville Voutilainen wrote: > > On 8 January 2018 at 18:25, Nicol Bolas > > wrote: > > > > > > On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrote: > >> > >> Hello Folks, > >> > >> currently, std::allocator (and std::allocator_traits) use value > >> initialization, that is placement new (p) (). > >> . > >> However, this prevents it from initializing aggregates (see here). > >> > >> Since using uniform initialization is the recommended (as of C++14) way > of > >> initializing variables, > > > > > > Recommended by whom? It's broken. Uniform initialization can hide > > constructors. Its narrowing restrictions, especially with forwarded > > argument, play havoc with initialization. > > > > Uniform initialization is good syntax bound to bad initialization rules. > It > > is not some default recommendation for initializing variables. > > > >> > >> std::allocator and std::allocator_traits should follow this guideline. > >> I think, we can all agree, that in general, not being able to emplace() > >> aggregates is an incompleteness. > > > > > > Yes. That's why LWG-2089 exists. I've written something that covers the > > proposed solution, corrects it, and thoroughly investigates all of the > > issues around it and pretty much every possible language and library > > solutions. > > > > And if you have another possible solution not on that list, please let > me > > know. > > > I plan to propose allowing paren-initializing aggregates. That > proposal should appear in the pre-Jacksonville > mailing. > Please,* please* make it turn off narrowing prevention! -- 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. To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/0b33061f-3b5a-481f-849b-3c7da72897db%40isocpp.org. ------=_Part_15000_1409491456.1515435027671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, January 8, 2018 at 12:25:18 PM UTC-5, V= ille Voutilainen wrote:
On 8 Ja= nuary 2018 at 18:25, Nicol Bolas <jmck...@gmail.com> wrote:
>
>
> On Monday, January 8, 2018 at 11:16:36 AM UTC-5, Jakob Riedle wrot= e:
>>
>> Hello Folks,
>>
>> currently, std::allocator (and std::allocator_traits) use valu= e
>> initialization, that is placement new (p) ().
>> .
>> However, this prevents it from initializing aggregates (see he= re).
>>
>> Since using uniform initialization is the recommended (as of C= ++14) way of
>> initializing variables,
>
>
> Recommended by whom? It's broken. Uniform initialization can h= ide
> constructors. Its narrowing restrictions, especially with forwarde= d
> argument, play havoc with initialization.
>
> Uniform initialization is good syntax bound to bad initialization = rules. It
> is not some default recommendation for initializing variables.
>
>>
>> std::allocator and std::allocator_traits should follow this gu= ideline.
>> I think, we can all agree, that in general, not being able to = emplace()
>> aggregates is an incompleteness.
>
>
> Yes. That's why LWG-2089 exists. I've written something th= at covers the
> proposed solution, corrects it, and thoroughly investigates all of= the
> issues around it and pretty much every possible language and libra= ry
> solutions.
>
> And if you have another possible solution not on that list, please= let me
> know.


I plan to propose allowing paren-initializing aggregates. That
proposal should appear in the pre-Jacksonville
mailing.

Please, please make it turn off= narrowing prevention!
=C2=A0

--
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.
To view this discussion on the web visit https://groups.google.= com/a/isocpp.org/d/msgid/std-proposals/0b33061f-3b5a-481f-849b-3c7da72897db= %40isocpp.org.
------=_Part_15000_1409491456.1515435027671-- ------=_Part_14999_901955929.1515435027671-- .