https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #6 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
(In reply to Jason Merrill from comment #5)
> (In reply to Arthur O'Dwyer from comment #4)
> > My first, reduced, example, where `std::list<A> v = {1,2,3}` is accepted for
> > move-only type `A`, is 100% a bug and should be fixed. But that is easy to
> > fix.
>
> It's pedantically a bug, but only because of the suboptimal specified
> initializer_list semantics. Just looking at that line I expect a list of As
> initialized from integers [...] It's also unfortunate that initialization
> from a prvalue initializer_list can't use A's move constructor.
Yes, but since you just implemented P2752, you know why we can't do *that*. :)
I strongly disagree that this is [only] "pedantically" a bug. The behavior of
std::initializer_list is super fundamental to "Intro C++". If GCC continues
with this behavior, I guarantee there will be tons of newbies asking (me, other
instructors, StackOverflow, etc) "If initializer lists are so immutable, then
why does this code compile? You told me it wouldn't!"
Before C++20, I got tons of the same question for GCC's acceptance of
int f(auto x) { return x; }
I still think it would be nice if GCC stopped supporting
int f(std::vector<auto> v) { return v[0]; }
, at least silently by default.
Similarly here: I wouldn't actually mind if GCC supported
std::vector<std::move_only_function<int()>> v = { f, g, h };
with an on-by-default warning. It's that it accepts the extension *silently*,
and the extension is *so visible to newbies* and *so critical to their
understanding of the actual language*, that has me worried.
Here's a sketch of the `vector<move_only_function>` example:
https://godbolt.org/z/dPnfbnhsf
