> > Without showing how foo_ptr is used, I agree it's not clear why this
> > particular example is all that persuasive. In the use case I have in mind,
> > foo_ptr is handed off to a framework which then encapsulates it in a class
> > used for data-handling and persisting objects to disk. A combination of
> > templating and inheritance makes this possible, all predicated on the
> > necessity of using a unique_ptr.
> >
> > The interface is something like:
> >
> > framework.store(move(foo_ptr)); // or
> > framework.store(std::make_unique<Foo<int>>(external_library::make_foo());
> >
> > Ideally, either make_foo would change its interface, or framework::store
> > would change its interface--but I don't necessarily have control over
> > either.
>
> So you have an impedance mismatch here. One library returns the object by
> value and the other takes it by unique_ptr. This looks like a design problem.

Granted. But again...that's not under my control and I'm still faced with creating the unique_ptr one way or the other.

> Anyway, what you want isn't a make_unique deduction, but a make_copy.

Hmm, not really. I still need the unique_ptr, which is what std::make_unique constructs...and connotes. And if Foo<int> were std::vector<int>, then it wouldn't be a copy either, it would be a move. But maybe you weren't distinguishing between copying/moving in this case.

Kyle