The reason the compiler does not agree with this is because the standard does not report this.
The reason the standard says that this is not so is because the committee did not introduce, in order to introduce a rule, that const MyTemplate<Derived*> is a bound type to const MyTemplate<Base*> , even if non-context types are not bound. And they, of course, did not want a special rule for std :: set, since in general the language does not make special cases for library classes.
The reason the standards committee did not want to bind these types is because MyTemplate might not have container semantics. Consider:
template <typename T> struct MyTemplate { T *ptr; }; template<> struct MyTemplate<Derived*> { int a; void foo(); }; template<> struct MyTemplate<Base*> { std::set<double> b; void bar(); };
Then what does it even mean to pass const MyTemplate<Derived*> as const MyTemplate<Base*> ? These two classes do not have common member functions and are not compatible with layouts. You will need a conversion operator between the two, or the compiler had no idea what to do, regardless of whether they are or not. But the way the templates are defined in the standard, the compiler has no idea what to do even without specialized templates.
std::set itself could provide the conversion operator, but it just needs to make a copy (*), which you can do quite easily. If there was such a thing as std::immutable_set , then, I think, it would be possible to implement such that a std::immutable_set<Base*> could be built from std::immutable_set<Derived*> , simply by pointing to the same pImpl. However, strange things will happen if you have non-virtual operators in the derived class being overloaded - the base container will call the base version, so the transformation can de-order the set if it had a non-standard comparator that did something with the objects themselves, not their addresses. Thus, the appeal will be accompanied by serious reservations. But in any case, there is no immutable_set , and const is not the same as immutable_set.
Additionally, suppose Derived is associated with Base with virtual or multiple inheritance. Then you cannot just rethink the Derived address as the Base address: in most implementations, an implicit conversion changes the address. It follows that you cannot simply batch convert a structure containing Derived* to a structure containing Base* without copying the structure. But the C ++ standard actually allows this to happen for any class other than POD, and not just with multiple inheritance. And Derived is a non-POD, since it has a base class. Therefore, to support this change to std::set , the basic principles of inheritance and the layout of the structure must be changed. This is the main limitation of the C ++ language that standard containers cannot be re-interpreted the way you want, and I don’t know any tricks that could do them without compromising efficiency or portability, or both. It is frustrating, but it is difficult.
Since your code passes value by value anyway, you can simply make this copy:
std::set<Derived*> objs; register_objects(std::set<Base*>(objs.begin(), objs.end());
[Edit: you changed your sample code so as not to jump by value. My code still works, and afaik is the best you can do, besides refactoring the calling code, to use std::set<Base*> in the first place.]
Writing a wrapper for std::set<Base*> , which ensures that all Derived* elements, a way to work with Java generics, is easier than organizing the transformation you want to be efficient. So you can do something like:
template<typename T, typename U> struct MySetWrapper {
(*) In fact, I think he could copy-to-write, which in the case of the const parameter used in the usual way, would mean that he never needs to make a copy. But copy-by-file copying is a little discredited in STL implementations, and even if I had no doubt that the committee would want to impose such a detail on a heavy implementation.