3. By requiring our deleters to be convertible, we make them sign a contract. By making Deleter<U> be convertible to Deleter<T>, the author of Deleter promises that Deleter<T> can delete pointer of type U* after being converted to T*. And the fact that DefaultDeleter<T> is empty does not mean that all possible deleters are empty. 4. It doesn't matter here if we inherit privately or publicly. I just did it because data hiding is generally a good habit, but in this case it doesn't really change anything.

@jdav22 1. I assume it might be to prevent accidental copies of the deleter, but I don't really know. I was just following the standard here. 2. There is no point in calling std::move, since argument and parameter are both the same l-value-reference type. std::move would cast to rvalue-reference and that be implicitly be converted to lvalue again.

@Deduplicator Thanks for pointing this out, I hoped there was a way to do it without two implementations for class types and non-class types.

Why do you construct objects in your test cases if you are only testing static properties of the types?

I just checked libc++'s implementation of unique_ptr and its converting constructor and it doesn't perform any of the checks you suggest. I know that pointer conversions from derived to base can change the value of the pointer, even in a way that cannot be known at compile time, if virtual inheritance is involved. But that is what virtual destructors are for afaik. If you have the time, I would gladly see a counter example of where the checks are necessary.

That is my understanding at least. If this is not correct I'd gladly be corrected :-)

I think std::unique_ptr solves this problem by requiring the deleters to be convertible. std::unique_ptr<T, D> p = std::unique_ptr<U, E>(/*...*/); is only valid if U* is convertible to T* and if E is convertible to D. And by allowing conversions between your different deleter types, you implicitly say: D can delete all pointers that E can delete (after being converted to the type of pointer D can delete). So worrying about the deleters being compatible is not the responsibility of unique_ptr but that of the deleters.

I'm confused. OP already has a converting constructor as far as I can see. And why would you go through any of the hassle with std::is_pointer_interconvertible_base_of? The standard does not require the deleter of the old unique_ptr to be invoked with the old value of the pointer when the new unique_ptr is destroyed. I.e. if Base* q = p has a different value than Derived* p, delete q still works fine and deletes the object as long as Base has a virtual destructor. Also wrapping every call to delete in a std::function can be a nightmare for performance.

@jdav22 Yes, exactly