220 36566 <0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40@isocpp.org> article Path: news.gmane.org!.POSTED!not-for-mail From: Jakob Riedle Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Should the Default Allocator use Uniform Initialization? Date: Mon, 8 Jan 2018 08:16:36 -0800 (PST) Lines: 86 Approved: news@gmane.org Message-ID: <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_14787_415954940.1515428196693" X-Trace: blaine.gmane.org 1515428083 7705 195.159.176.226 (8 Jan 2018 16:14:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 16:14:43 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCX2XNFO6MPRBZVSZ3JAKGQEVFEHOQQ@isocpp.org Mon Jan 08 17:14:39 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f199.google.com ([209.85.217.199]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYa4K-0001WI-1r for gclcip-std-proposals@m.gmane.org; Mon, 08 Jan 2018 17:14:36 +0100 Original-Received: by mail-ua0-f199.google.com with SMTP id t5sf7363613uaj.15 for ; Mon, 08 Jan 2018 08:16:39 -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:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=4L7RcICEx1vubkGX1v0XJSwWEVPB4fHSBy4i5jMorR8=; b=xpfj7b4kqIuPmtSKKh3XExFM3JB4U8ng1ysHAN73sMxQJyr0BxtQ72H29mFU7buVMR DCbm5qiKP6ufOfQLnfG53bKoEuhUKsl6CqwLbbrK8eyH+RSL9uOxmFycgatR8w3qCpQ0 myyn+h3Ve8x2we9DLayjweI9S+6QIrpbLnhiwvjZ9WnqubgRO5co8ig9jccM5MUS/iTi h91Lw7wD4deVOzKGijG2rZrdUMdaYfzMfgZuB/u4GLA4tI9F0Aet/pOCUcJbK2uiqsn2 6k45B5cS0mYM5BdjMyDHWzyxlodgL/wijI3W8eS59n96Jxez2ZsSJiOEhl2bwORc7WTg py7g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:message-id:subject:mime-version:x-original-sender :reply-to:precedence:mailing-list:list-id:list-post:list-help :list-archive:list-subscribe:list-unsubscribe; bh=4L7RcICEx1vubkGX1v0XJSwWEVPB4fHSBy4i5jMorR8=; b=p2lvZW0pD5Y2gw/sUDPEo0spDKI0oNa0ak2SPUln3YZDePSrQW9+Cmqx2mK0/YH+8M YhkALIfw2HLZoJp03/EV7Sj35fZmbxOcfuBAJ2RJhyPLdFwh3Ua8VOHVSf6+S15fGYbL gH/JIi5HLXY8lZh7da1tIJXmWioCCprWoKrR/rSjEc/2JOx+J/4ipdUBJ66K7qCDhOEq vWMGJvVWcBtDF7KND5z+WSHba3pQPvtsH4dy7SAALLBXJg27CalPkY2C1NT9TlmnRmHG FsrDtBBjJQytUdjAZ5mELPFtewtVBIvaPBM6/3MfUHWsYWDb3IjctxE6B2DFo0xYKCzW QLJQ== 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: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=4L7RcICEx1vubkGX1v0XJSwWEVPB4fHSBy4i5jMorR8=; b=d5fpDtMteBroOT53GmIu6ggpP20ZkRHt7NUasQAXr6u/Xxh7LF8m9ToCgUr5/+0ONt GNKUbRz82TI+/lbo4ABrRaykZBjKqosOzAVzTuBDXkhSRGylMRYKUkUmWZPXBD9Z/+We u4ovMf/MnEPGIfa+407gFRyRmRf6iGV7Kz0X6OFb+YfyS4H/6X8Kxo38BqyOKDzge3Lf PTeA/5/S9icZw+iZzvbyripOeSygHPeLAj8vYwBo34nebsbpucyjt8Ur2ViWD7u0npBh TBJan1prJide7nMbQj+dx2T2NEcWZIGSosAA37FiEWmJFj3dfxi/1gtVhgXFPotBmA/8 x46w== X-Gm-Message-State: AKwxytfBJEtSPdgjuKZ9hW/W1MGS5IRg5+gOZoqLNi6hNBgHZqBUcdwa xwcCjbZYqMQZx4ol+4Yj2yjCBw== X-Google-Smtp-Source: ACJfBouZbLa3KUyjCwfBF98/Ya+tH9QFlVHKtjKnQZi6L6L113Ff/uat4xXNYgfMqlh3OrsU/woczQ== X-Received: by 10.31.13.82 with SMTP id 79mr6269759vkn.65.1515428199205; Mon, 08 Jan 2018 08:16:39 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.31.222.199 with SMTP id v190ls167439vkg.3.gmail; Mon, 08 Jan 2018 08:16:37 -0800 (PST) X-Received: by 10.31.52.71 with SMTP id b68mr1316408vka.13.1515428197068; Mon, 08 Jan 2018 08:16:37 -0800 (PST) X-Original-Sender: jakob.riedle@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:36566 Archived-At: ------=_Part_14787_415954940.1515428196693 Content-Type: multipart/alternative; boundary="----=_Part_14788_1175322597.1515428196693" ------=_Part_14788_1175322597.1515428196693 Content-Type: text/plain; charset="UTF-8" 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, *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. There might be several downsides to this. I have found the following one: - it breaks implicit narrowing conversions not possible with uniform initialization What are your thoughts on this? How to fix this the best way? Should we fix it? One possible (maybe not desired) solution is to SFINAE-overload *new(p)(...)* with *new(p){...} *inside *::construct()*, preferring the latter if viable. I look forward to hearing from you! Cheers, Jakob -- 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/0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40%40isocpp.org. ------=_Part_14788_1175322597.1515428196693 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Folks,

currently, std::allocat= or (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 r= ecommended (as of C++14) way of 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() ag= gregates is an incompleteness.

There might be = several downsides to this. I have found the following one:
    it breaks implicit narrowing conversions not possible with uniform initia= lization
What are your thoughts on this?
How to fix this= the best way? Should we fix it?

One possible (may= be not desired) solution is to SFINAE-overload new(p)(...) with n= ew(p){...} inside ::construct(), preferring the latter if viable= ..

I look forward to hearing from you!
Cheers,
Jakob

--
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/0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40= %40isocpp.org.
------=_Part_14788_1175322597.1515428196693-- ------=_Part_14787_415954940.1515428196693-- .