This whole article is a very verbose way to reach the conclusion that std::is_copy_constructible_v is a poorly chosen name, not reflecting the actual truth that the construct provides.
If it were called std::has_copy_constructor, there would be no need to write even the title of this article, let alone the body.
Also, maybe this should require a diagnostic due to it being statically obvious that it is calling a deleted constructor:
Derived(Derived const& d) : Base<T>(d) {}
... and if we use regular non-template classes, it does!
The problem with eager diagnostics and templates is that the program could define a `Base<int>` specialization that has a working copy constructor later. [0]
I think if you define an explicit instantiation definition, it should type check at that point and error. [1] I find myself sometimes defining explicit instantiations to make clangd useful (can also help avoid repeated instantiations if you use explicit declarations in other TUs).
I would argue that has_copy_constructor would also have the same issue in naming since most people would assume that has_copy_constructor means the damn thing works for copying.
Too many traits is my diagnosis, so I agree with "foiled by templates". Like almost any attempt to make a sane C++ codebase.
> most people would assume that has_copy_constructor means the damn thing works for copying
Assumptions that something "works" in C++ are generally too nuanced and optimistic to be a good idea. Calling the test "has_copy_constructor" would at least make explicit that it is a test about what declarations a class contains, which is a very rough compile-time approximation of being copy-constructible in practice: a valid declaration is only the first step towards calling a constructor without runtime errors and other trouble.
> If it were called std::has_copy_constructor, there would be no need to write even the title of this article
Ah, but then someone might ask "Why does the library report that my type has no copy constructor, when it is in fact copyable?" And then the blog post would have to be about how it's possible for a type to be copy-constructed using a constructor (or constructor template) that is not itself a copy constructor.
Of course, the existing state of C++ doesn't prevent us from having to write that blog post, either!
I guess it's better, but with C++ being C++, you will then need to decide if you consider
struct A { A(const volatile& A); };
as a class with a const copy constructor. Maybe someone cares?
Proper templated classes don't behave like this. If you manually define a copy constructor in a template class it has to work. And if it works only conditionally (like in many container classes) you need to add constraints on your constructors (>C++20) or derive from appropriately specialized base classes (e.g. std::_Optional_base in libstdc++).
It sucks to tell users "you're holding it wrong", but I don't think there's a way to make it simpler without breaking everything written since C++11.
If it were called std::has_copy_constructor, there would be no need to write even the title of this article, let alone the body.
Also, maybe this should require a diagnostic due to it being statically obvious that it is calling a deleted constructor:
... and if we use regular non-template classes, it does!Clang:
Clang: If the program requires a diagnostic which allows it to be rejected entirely, it then doesn't matter what is_copy_constructible returned.The only reason we don't get a diagnostic is that the language plays it loose with templates, in many cases deferring type checks until instantiation.
It is possible to argue that is_copy_constructible isn't necessarily badly named, but rather foiled by templates.