https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80654
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Frank Heckenbach from comment #8) > (In reply to Ville Voutilainen from comment #7) > > That's not a bug. You need to make the copy constructor of s conditionally > > deleted depending on whether T is copyconstructible. > > The copy constructor of std::vector doesn't seem to do that either > (bits/stl_vector.h:326 in 7.3.0) unless I'm missing something. It's impossible to do it for std::vector, because whether the vector is copy-constructible depends on whether the value_type is CopyInsertable (**not** copy-constructible) which depends on the allocator and is not known (or knowable) at the right time, because std::vector allows its value_type to be incomplete. > Is that what Daniel Krügler meant by "not SFINAE-friendly"? But he also > wrote: "This is a QoI issue but not a violation of the requirements of the > standard.", so I'm confused now. The standard doesn't say that std::vector has a conditionally deleted copy constructor, so it doesn't require traits to give the right answer. We could add partial specializations for std::vector<unique_ptr<T>> (where the allocator behaviour is known) but we can't do it for std::vector<MoveOnly> or std::vector<std::unique_ptr<T>, ArbitraryAllocator>.
