On Sat, Mar 11, 2023, 10:34 AM Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Hi,
>
> 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_at_[hidden] | 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.

Barry

>