https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92727
--- Comment #3 from David Brown <david at westcontrol dot com> --- I may not have been very clear here. Let me try and take a step back here. >From the user's viewpoint, the problem is that they have made a class that can't be copied, and they have written code that tries to copy it. With the current error messages, point comes across - but it is hidden amongst a lot of messages about "allocators" that will be unfamiliar to many users, and unhelpful to most users. I fully appreciate the problem occurs when the allocator that tries to use the copy constructor. But the user has not specified an allocator, or picked an allocator, or mentioned allocators in their code - and perhaps does not even know what they are. Most users are happy to accept "it goes in memory somewhere", or "it is on the heap", without worrying about the details. What I am hoping for here is some way to help the user get the part of the error information that is important to them, and will help them fix their code, without unnecessary detail. What I meant about default template parameters is that - as you say - some people /do/ want all the details of the messages about the allocator. These are mostly in two groups - people using non-default allocators, and people who want to deal with the details of the standard library. The first group can be identified by their use of explicit allocators in the template instantiation rather than using the defaults, and the second could perhaps use an additional compiler switch (a little like the current "-Wsystem-headers" switch). So yes, I /am/ suggesting that the error location should be given as the "v.push_back(x);" line. And yes, I am aware that it would not be ideal for experts - but I think it would be clearer to a majority of users. And that would be novel! Part of the job of a compiler is to help people write correct code, and clear error and warning messages are essential for that. (Let me also say that gcc does a fine job here, and has improved enormously over the years that I have used it - though it could still be better.) Perhaps this could be better handled using concepts? Maybe "push_back" could be declared to take a parameter with a concept requiring either a type that could be copied into the vector or a type that is a compatible rvalue reference? Or perhaps concepts and "if constexpr" in C++17 would make it practical to make the "push_back(const T&)" overload unavailable if T is not copyable? That would get you straight to a "no matching function call for std::vector<X>::push_back(X&)" message on the offending line.
