On Wednesday, 8 July 2020 12:29:27 PDT Kyle Knoepfel via Std-Discussion wrote:
> 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.

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

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel System Software Products