While fiddling with template metaprogramming I managed to run into an
issue related to some std:: containers and type traits. As far as I have
researched it, it is a known (although not obvious at first) shortcoming.
Consider the following code snippet:
using MoveOnly = std::unique_ptr<Copyable>;
(BTW, the vector is used here as an example, but the list and
forward_list also behave the same way for the same reason)
Counter-intuitively, the static assert fails. This stems from the fact
that the vector's copy constructor is not a function template; thus it
cannot be SFINAEd (everything can be a verb if one tries hard enough ;))
away, because it's always declared.
Since C++20, the copy constructor can be constrained:
vector(vector const&) requires std::copyable<T>;
I think this would solve your issue. This would require the containers general requirements to lift this requirement (on `X u(a)`, that `T` is Cpp17CopyInsertable, etc.) from a precondition to a constraint. There are probably quite a few clauses that would need to be considered in such an effort.
It is logical in terms of how the language works, but at the same time
it is incorrect in terms of API's predictability.
I've been thinking if it can be fixed in some way. For C++11 and 14 I
believe that making the vector's copy constructor a function template
restricted by value_type being copyable should do.
However, that ship seems to have sailed in C++17 and further versions,
as vector is required by the standard to support incomplete types.
I wonder if this issue can be addressed by specialising
std::is_copy_constructible, std::is_copy_assignable and similar traits
based on vector's value_type, e.g.:
template <typename T>
inline bool constexpr is_vector_copy_constructible_v =
(for the sake of simplicity all allocator-related subtleties are omitted)
The obvious result would be the change of behaviour for incomplete
types. Therefore code like this:
would fail to compile. It seems a reasonable way of the compiler
communicating "I have no idea", but it would be a breaking change should
is_vector_copy_constructible become a partial specialisation of
The question is: is it even the right direction I'm headed with my
question? If so, is there a better way to address this or maybe it is a
"broken by design" case and I shouldn't even bother?
In case they're needed, live demos of my code snippets are here:
A. M. Miera
Std-Discussion mailing list