Should the Default Allocator use Uniform Initialization?

[Jakob Riedle]

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

[Nicol Bolas]

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.

[Ville Voutilainen]

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

[Nicol Bolas]

Please, please make it turn off narrowing prevention!

 

[Jakob Riedle]

Am Montag, 8. Januar 2018 17:25:28 UTC+1 schrieb Nicol Bolas:

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.

Yay! I was hoping for something like this, but couldn't find anything.

Thank you!

  

And if you have another possible solution not on that list, please let me know.

The solution proposed is, what I would have expected.

Jakob

[Ville Voutilainen]

On 8 January 2018 at 20:10, Nicol Bolas <jmck...@gmail.com> wrote:
>> 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!

I will include that consideration, thanks; I am not hell-bent on it
either way - there's some value in having
paren-initializing aggregates mean exactly the same thing as
brace-initializing them, but there's also some
value in having paren-init not prevent narrowing. Turning off
narrowing prevention makes some sense to me, but
I can live without it. I can also easily imagine some user somewhere
saying "no, don't do that, I intentionally
left out constructors with the expectation that my type can *not* be
initialized with narrowing conversions,
and just because it can now be initialized with a syntax that wasn't
ok before should not change that without
my opt-in". ;)