False Positive with Is_Copy_Constructible on Vector<Unique_Ptr>

False positive with is_copy_constructible on vector unique_ptr

This is because of a flaw in the design of std::vector. std::vector defines copy construction even if it will fail to compile, and relies on users of std::vector to not invoke the method if it will fail to compile.

The alternative design would be to SFINAE block the invocation of the method if the type contained in the vector does not have a copy constructor. However, std::vector was designed before modern SFINAE techniques developed.

It could possibly be retro fitted into a new iteration of C++, as there would be very little code that would break. One cannot say no code would break, because you could have code that relies on the fact that std::is_copy_constructible< std::vector< no_copy_type > > is std::true_type, or equivalent expressions, but that is a pretty strange dependency.

On top of the fact that std::vector is older than the SFINAE techniques that could solve this problem, doing so with SFINAE is pretty messy (as SFINAE is a messy technique). The new concepts-lite proposed for C++1y may make it cleaner, and more tempting to include in a new iteration of the language.

My work around when I have a container that needs to know if the contained object can be safely copied, compared and ordered is to specialize for std::vector on a custom traits class, and fall back on the value of the custom traits class on the contained type. This is a patchwork solution, and quite intrusive.

template<template<typename>class test, typename T>
struct smart_test : test<T> {};
template<template<typename>class test, typename T, typename A>
struct smart_test<test, std::vector<T,A>> : smart_test<T> {};

which gives us:

template<typename T>
using smart_is_copy_constructible = smart_test< std::is_copy_constructible, T >;

and similar for < and ==. I can add more specializations when I run into more container-types that should really forward their properties down to their data, or I could write a fancier SFINAE container-test and traits and extract the underlying value-type and dispatch the question to the test on the value-type.

But in my experience, I mostly end up doing these tests on std::vector.

Note that since c++11 vector has had "participates in overload resolution" rules added to it, which is standards-speak for "do SFINAE" tests.

C++ non-copyable lambda behaves copyable?

Is there some exception for lambda's and copy constructability traits?

No. If you test std::is_copy_constructible<std::vector<std::unique_ptr<int>>>::value you will find that it's also true.

The reason is that std::vector has an accessible and non-deleted copy constructor even if the element type is noncopyable. If the copy constructor is instantiated, it will fail to compile, but that's outside the immediate context, and thus cannot be detected by the std::is_copy_constructible trait.

It might be tempting to make the copy constructor of std::vector SFINAE on the copy constructibility of the element type, but I believe it will break a type that stores a vector of the type itself as a member: struct Node { std::vector<Node> children; }, since in this case, the copy constructibility of Node and std::vector<Node> would be mutual dependent.

Smarter is_copy_constructible for handling Containers

Yes, std::enable_if_t will do it:

// I'd recommend following the standard library's naming convention
template<typename T, typename = void>
struct smart_is_copy_constructible : std::is_copy_constructible<T> { };
template<typename T>
struct smart_is_copy_constructible<T, std::enable_if_t<has_value_type<T>::value>> : std::is_copy_constructible<typename T::value_type> { };

template<typename T>
constexpr bool smart_is_copy_constructible_v = smart_is_copy_constructible<T>::value;

Godbolt

But has_value_type is mostly superfluous. Your implementation doesn't work, and the implementation I gave in the comments is short enough to inline (though, as Nicol Bolas suggests, you may want to make has_value_type more complicated):

template<typename T, typename = void>
struct smart_is_copy_constructible : std::is_copy_constructible<T> { };
template<typename T>
struct smart_is_copy_constructible<T, std::void_t<typename T::value_type>> : std::is_copy_constructible<typename T::value_type> { };

Godbolt

(The corrected has_value_type as used in the first example is

template <typename T, typename = void>
struct has_value_type : std::false_type {};
template <typename T>
struct has_value_type<T, std::void_t<typename T::value_type>> : std::true_type {};

)

Are copy constructors defined implicitly always, or only when they are used?

From [class.copy.ctor]/12:

A copy/move constructor that is defaulted and not defined as deleted is implicitly defined when it is odr-used ([basic.def.odr]), when it is needed for constant evaluation ([expr.const]), or when it is explicitly defaulted after its first declaration.

A's copy constructor is defaulted, so it's implicitly defined only when it is odr-used. A a2(a); is just such an odr-use - so it's that statement that would trigger its definition, that would make the program ill-formed. Until the copy constructor is odr-used, it should not be defined.

Compiler B is wrong to reject the program.

Tools to generate higher-quality error messages for template-based code?

Let's have a stab at an answer (I marked this community wiki so we get a good response together)...

I'm working since a long time with templates and error messages have generally improved in some way or another:

• Writing a stack of errors creates a lot more text but also typically includes the level the user is looking at and this generally includes a hint at what the actual problem is. Given that the compiler only sees a translation unit tossed at it, there isn't a lot which can be done determining which error in the stack is the one most suitable for the user.
• Using concept checkers, i.e. classes or functions which exercise all the required members of template arguments and possibly generating errors messages using static_assert() give the template author a way to tell users about assumptions which apparently don't hold.
• Telling the user about types he writes rather than expanding all typedefs as the compiler like to see at the lowest level also helps. clang is rather good at this and actually gives you error messages e.g. talking about std::string rather than expanding things type to whatever it ends up to be.

A combination of the technique actually causes e.g. clang to create quite decent error message (even if it doesn't implement C++2011, yet; however, no compiler does and as far as I can tell gcc and clang are leading the pack). I know other compiler developers actively work on improving the template error messages as lots of programmers have discovered that templates actually are a huge leap forward even though the error messages are something which takes a bit of getting used to.

One problem tools like stlfilt face is that C++ compilers and libraries are under active development. This results in error messages shifting all the time, causing the tool to receive different outputs. While it is good that compiler writers work on improving error messages, it certainly makes life harder for people who try to work from the error messages they got. There is another side to this as well: once a certain error pattern is detected to be common and is picked up e.g. by stlfilt (well, it isn't actively maintained as far as I know) compiler writers are probably keen to report the errors following these patterns directly, possibly also providing additional information available to the compiler but not emitted before. Put differently, I would expect that compiler writers are quite receptive to reports from users describing common error situations and how they are best reported. The compiler writers may not encounter the errors themselves because the code they are working on is actually C (e.g. gcc is implemented in C) or because they are so used to certain template techniques that they avoid certain errors (e.g. omission of typename for dependent types).

Finally, to address the question about concrete tools: the main "tool" I'm using when I get kind of stuck with a compiler complaining about some template instantiation is to use different compilers! Although it isn't always the case but often one compiler reports an entirely incomprehensible error messages which only makes sense after seeing the fairly concise report from another compiler (in case you are interested, I regularly use recent version of gcc, clang, and EDG for this). I'm not aware of a readily packaged too like stlfilt, however.

---

Related Topics