On Tuesday, 7 July 2020 11:37:03 PDT Kyle Knoepfel via Std-Discussion wrote: 
> I routinely encounter situations where objects must be owned by (smart) 
> pointer, but the means in which the pointee is constructed is not under my 
> control. For example: 
> 
> namespace external_library { 
> template <typename T> 
> Foo<T> make_foo(); 
> } 

This is not a good example because make_foo did not return a pointer. It 
returned an object by value. Therefore, when you do: 

> auto foo_ptr = std::make_unique<Foo<int>>(external_library::make_foo()); 

The pointee is constructed fully in your control. You're creating a copy of 
Foo<int> and saving that in a unique_ptr. 

But note how Foo<int> can be copied. So are you sure you need unique_ptr in 
the first place? 

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.

Kyle