On Sat, Mar 11, 2023, 10:34 AM Giuseppe D'Angelo via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

Il 11/03/23 13:34, LoS via Std-Proposals ha scritto:
> - since some container adapters also use overloaded constructors for
> std::initializer_list, there is not reason not to introduce them into
> the other container adapters.

Unfortunately there *is* a reason: in the general case you can't add an
initializer_list constructor "after the fact" and keep source
compatibility. Consider for instance

> Foo *ptr;
> Container c{ptr, ptr+10};

What does this code do? Does it build a Container<Foo> of 10 elements
from the [ptr, ptr+10) range, or a Container<Foo *> containing 2
elements (ptr and ptr+10)?

For std::queue in C++23 it means the former; which already means we will
never be able to add an initializer_list constructor, because it would
change the meaning of the code (to mean the latter). Probably even
adding the constructor in C++17 would've been too late, because it would
change the meaning of code like

> std::deque<int> d;
> std::queue q{d}; // queue<int> using `d` as inner container, or queue<deque<int>> of 1 element?

It's a real cone of shame because this *keeps happening*: with
queue/stack here, with std::span in C++20 (P2447 was rejected for this
very reason) and who knows if it'll happen again in the future.

My 2 c,
Giuseppe D'Angelo | giuseppe.dangelo@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

For the nth time, there is no CTAD issue with span and initializer_list. This is because span<T> isn't actually constructible from initializer_list<T>, only span<T const> is.

The kind of code that changes meanings is stuff like

any a;
span<any> s{&a, &a+1};

Which goes from a [non-dangling] span containing 1 any to a [dangling] span containing 2.