Why do std classes not use static_assert on non-copyable types?

Question

Why does the std library not use these instead? Currently if a call is made to the copy constructor on a non-copyable object, the error message can be a little 'cryptic' or confusing to someone who has never encountered one before.

The first time I had this error message I had no idea what the problem was (I never thought of the idea of inaccessible ctors) until I looked up the class and saw "non-copyable" and finally understood.

what were the benefits of making the copy-ctor private? It is still visible in VS intellisense for ctor overloads.

why did they not simply choose to:

public:
someClass(const someClass&) { static_assert(false, "someClass is of non-copyable type. calls to copy constructor are disallowed."); }

if someone tries to compile their code they will see this error message, which states the reason of the error more explicitly. Compared to (const someClass&) is inaccessible. Imagine how difficult it would be to understand this when heavy use of templates are involved?

so, what benefits are there to a private copy-ctor vs a static_assert?

Answer 1

1. The reason of cryptic messages is a problem of compiler, not C++, although that's true that for C++ implementing good messages is harder. Clang provides much better error messages than other compilers, for example.

2. I don't know why MS decided to show private overloads in VS intellisense - but that's definitely not a С++ problem but a problem of IDE (or there is some hidden, unknown for me sense).

3. static_assert is supported only in C++11 and it would require to change even more standard specs just to change error message.

4. Private constructor is more idiomatic in C++ than custom static_asserts.

5. This suggestion doesn't even make any sense. The static_assert will cause a compiler error. Always. Whether anyone tries to call the copy constructor or not. (As pointed out by @BenjaminLindley in comments)

Answer 2

In C++11 there is a better way:

someClass(const someClass&) = delete;

Unfortunately, MSVC does not support it yet.

But, maybe there is hope:

Yep, I was super busy getting the STL ready for VS 2013 Preview. I've got a VCBlog draft with a detailed changelog that I'll be able to publish after the Build conference.