C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Deprecate and eventually remove std::initializer_list

From: Jonathan Wakely <cxx_at_[hidden]>
Date: Fri, 27 Jun 2025 09:37:51 +0100
On Fri, 27 Jun 2025 at 04:17, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Thu, Jun 26, 2025 at 6:56 PM Maciej Cencora <m.cencora_at_[hidden]>
> wrote:
> >
> > They already mean different things, the first one is aggregate
> initialization with brace-ellision, the other one is a list-initialization
> that invokes a user-defined constructor taking an std::initializer_list.
> And that already doesn't mean the same thing - for aggregate if elements
> are initialized from prvalue there is no-copy nor move, while for classes
> the copy is unavoidable.
>
> OK, that's true. They do different things to achieve their results.
> Now, the question is this:
>
> Does the user *care*?
>
> Because I suspect the user who wrote `std::vector<int> arr{1, 2, 3, 4,
> 5};` didn't actually care if it does aggregate initialization or
> creates an `initializer_list`. What they most likely care about is
> that they have a container and want to initialize it with a sequence
> of values.
>

Then why does the same syntax also work for std::vector<int>{1, 2,
std::allocator<int>()} ?
This isn't a sequence of values.

It's a muddled mess.



>
> The rest are just details.
>
> > The problem is that these mean different things:
> > std::vector<int> a(1, 2);
> > std::vector<int> a{1, 2};
> >
> > For me they should only differ in one thing - list initialization should
> fail if it would trigger narrowing conversion (as it does now), but
> otherwise it should select the same constructor as direct-initialization
> (proposed behaviour).
>
> Well, that's one way to view list initialization. But list
> initialization's syntax was originally conceived for the express
> purpose of those two *being different*. You used `{}` if you wanted to
> initialize a container with a sequence of values. It was only after a
> few revisions that "uniform initialization" was tacked onto it, where
> `{}` could call arbitrary constructors.
>

That history is not really relevant now though. What was in the working
draft at various times between C++03 and C++11 doesn't change anything,
what we got is a mess.


> You can debate whether "uniform initialization" is a failure or not.
> But if you do consider it a failure, the part that fails the most is
> *not* "initialize this container with a sequence of values".
>

Yes, that's fair.

Received on 2025-06-27 08:38:07