https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110102
--- Comment #4 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> --- I came across the `Widget` bug in the course of writing (and it's now mentioned in) this blog post on value semantics and PMR: https://quuxplusone.github.io/blog/2023/06/03/p1144-pmr-koans/#the-evil-allocator-aware-type FWIW I'm highly sympathetic to the idea that `Widget` is "not a sensible program" and I would love to see CWG or LWG make it UB. ;) It would make what I'm trying to do with value semantics in P1144 so much easier if some more of these "unreasonable programs" were less well-defined. But that seems like a *gigantic* task. 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. Jason, *I* don't know by what heuristic the optimizer decides to do this optimization or not... but are *you* at all worried that it might be a pessimization for some types? For example, suppose we had struct NthPrime { constexpr NthPrime(int); ... }; std::vector<NthPrime> primes = {1,2,3,4,5,6}; Here we *want* to make an initializer_list<NthPrime> backed by a static array of NthPrime at compile time. If we make an initializer_list<int>, then we'll have to run the NthPrime(int) constructor at runtime, and that's expensive. I tried out this example on Godbolt and the optimizer made the correct choice in this specific case, so that's good. But I figured I should mention the scenario in case it brings something to your mind.
