I'm worried about this inflating headers and compile times due to everything becoming a template.

Would an approach like the Requirements struct work? (Defining a struct with implicit conversions from everything needed?) I think that would allow the functions to remain non-templated.

We can make the currently-explicit conversions to CommandPtr implicit...
Thoughts?

It probably should be fine, especially since most teams won't need to use ToPtr() (unless for some reason they're upcasting their pointers to Command*, but that probably won't happen).

I made the changes locally, and it's causing some issues. Maybe we should be consistent on everything being CommandPtr and that's it? To avoid the shenanigans of implicit conversions.

unless for some reason they're upcasting their pointers to Command*, but that probably won't happen

Wdym?

unless for some reason they're upcasting their pointers to Command*, but that probably won't happen

Wdym?

I might be wrong, but as I understand it, the point of ToPtr() is so that when given a compile-time Command*, the object can correctly be converted into a CommandPtr. (Naively doing CommandPtr(std::make_unique<Command>(std::move(command)) will not properly handle the virtual methods, which I'm guessing is because it just points to the Command part of the object, without the vtable stuff for the subclass, though I might be wrong about that) However, since most users will only deal with their actual command types, CommandPtr(T&&) should use the correct type argument for make_unique, and they won't need to use ToPtr(). I could be wrong about this, though- I only figured this stuff out today.