220 36569 article Path: news.gmane.org!.POSTED!not-for-mail From: Nicol Bolas Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Should the Default Allocator use Uniform Initialization? Date: Mon, 8 Jan 2018 08:25:28 -0800 (PST) Lines: 111 Approved: news@gmane.org Message-ID: 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_14607_1502439270.1515428728281" X-Trace: blaine.gmane.org 1515428620 2380 195.159.176.226 (8 Jan 2018 16:23:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 8 Jan 2018 16:23:40 +0000 (UTC) To: ISO C++ Standard - Future Proposals Original-X-From: std-proposals+bncBCEKFTV6ZUMBB6NWZ3JAKGQEQRTW6XY@isocpp.org Mon Jan 08 17:23:36 2018 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-ua0-f198.google.com ([209.85.217.198]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eYaCt-0008Gr-7r for gclcip-std-proposals@m.gmane.org; Mon, 08 Jan 2018 17:23:27 +0100 Original-Received: by mail-ua0-f198.google.com with SMTP id j7sf7176070uak.18 for ; Mon, 08 Jan 2018 08:25:31 -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=rPwtynWX6GXuk/j4dbr7Ja2u/lKba68p9tENtZbJYuc=; b=XEPZb6oek4SjRvwem26IfhVa1kdTYKbs0Ca4aQLULuWZhMUBw5aelLpvy9QTyWAM2u veoPrVEmKEzBRwXK5nc+PtZpPRfcNUPDhYNui76soUoak5RPV3P+plvqjNd5nXpuaA2R f5J4PVZOK5tSamAnj+EPUXRhd2zSzx+Xz1hzmUpazT9OjqzWY5rEx+2rFXbJEUJ2Msl1 6yjIa+Y1LM7zYTfl5+xzfCbXDmm38vTg3Q/xdCNRE64cE5MErzzxy6gwEamJHwEhFDYS jPKRCPd3UP+3SGPpaOPciMeed8kI6hEi2nkbQXhNfTKpT/l3yKUGOsC+VNkmCg/FEpqN x9wQ== 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=rPwtynWX6GXuk/j4dbr7Ja2u/lKba68p9tENtZbJYuc=; b=eZpeGTz4wdg+YC5b7hXvBqQG1RidpPuI+Zr0+2VNj0GH67w44aplSdXYQNl/u0MSOV UYxATq8WdNTeqOH4BnnS+FguHsBJywR61MbYHq/34YumBS86oWfXab4I0f/fMnN79FaD I/T9NaL8vuI8MIduzqLpKDNWAtDFu6icE4i3GKkjap7HX62n4T+DfoWtEUb2DnKBL6ZG 0GAiX2zegIh8LN4SH2VhMkY4Sjh+8hfW91rh9R5kRWro65AVUsg1MfcRdywAD/EaG9i3 88vqc/Uj1k/8S7xmle44q/++87DPDyKUwxkhgSSE5aeMg+phXm6/vvCb2hAzp6eT6zlG ITqw== 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=rPwtynWX6GXuk/j4dbr7Ja2u/lKba68p9tENtZbJYuc=; b=tPuTCEJg3hwQqbF0n1QwW0YNrLGGDye5+sUNRVb1Qk+uAZ7QoESS8qOTL9rWeGfrdO OG/tczOV1zF+MT0TRHH+B9QYSNybRcDpPjqYRgoH20xXz3eRw0WI6R46n97re904ay5m p918TviDSD7LSvn7zfyThadTvkfKMStgYdr0g2dwEbzD3oaUHmj2aq81M9NO+XAzViWT Lq2vf/jGonnssCqjMnN3aSHLXtVAZEqxgkR7i08WqLzDH7EMlwDNQyyvfLNHv1BkB4t7 xpaVXGO3wNuI6QviL221uE1gs9zwSkJn4M8xPTzaBnTCZXNFsvSXUqu88w4u2Ccno7WK yjvw== X-Gm-Message-State: AKwxytcG23xZHDLnOXQ76GPujSKlh7cs17xhPX/Z3sdzU0pHIyLAG3UX gEGaEyw7d/PBNNV4ebNM5xJOJQ== X-Google-Smtp-Source: ACJfBou5hyZMwKY5kjWQjfCAaAPsN8e4cO5E1y5fPS7SYM3eHpK291GJnJpuWXEiEd4Y5zPpzkvpDw== X-Received: by 10.31.55.2 with SMTP id e2mr6232255vka.118.1515428730595; Mon, 08 Jan 2018 08:25:30 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.176.17.220 with SMTP id q28ls185882uac.5.gmail; Mon, 08 Jan 2018 08:25:29 -0800 (PST) X-Received: by 10.31.168.202 with SMTP id r193mr1319776vke.4.1515428729072; Mon, 08 Jan 2018 08:25:29 -0800 (PST) In-Reply-To: <0c6b5fb2-c26f-4cd1-8a63-a3da77fb7d40@isocpp.org> 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:36569 Archived-At: ------=_Part_14607_1502439270.1515428728281 Content-Type: multipart/alternative; boundary="----=_Part_14608_199337935.1515428728281" ------=_Part_14608_199337935.1515428728281 Content-Type: text/plain; charset="UTF-8" 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. -- 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/ad3e7a1f-eba9-4395-9ea1-2b4852fc921a%40isocpp.org. ------=_Part_14608_199337935.1515428728281 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Monday, January 8, 2018 at 11:16:36 AM UTC-5, J= akob Riedle wrote:
Hello Folks,

currently, std::allocator (and<= b> std::allocator_traits) use value initialization, that is placement <= b>new (p) ().
.
However, this prevents it from initializin= g aggregates (see here).

Since using unifo= rm initialization is the recommended (as of C++14) way of initializing vari= ables,

Recommended by whom? It&= #39;s broken. Uniform initialization can hide constructors. Its narr= owing restrictions, especially with forwarded argument, play havoc w= ith initialization.

Uniform initialization is good= syntax bound to bad initialization rules. It is not some default recommend= ation for initializing variables.
=C2=A0
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.

<= div>Yes. That's why LWG-2089 exists. I've 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/ad3e7a1f-eba9-4395-9ea1-2b4852fc921a= %40isocpp.org.
------=_Part_14608_199337935.1515428728281-- ------=_Part_14607_1502439270.1515428728281-- .