Re: @cryos, I’m not opposed to adding a unique_ptr equivalent if vtkNew is intended for only stack-based usage. This would imply that holding a vtkNew as a struct field is bad practice, as it implicitly disables move semantics for the owning struct:
struct Foo
{ // Foo(Foo&&) will not be available by default.
vtkNew<...> Bar;
};
which was my main motivation for adding move semantics to the smart pointers. The new async ParaView refactoring will be making use of C++11 and C++14 paradigms, including move semantics, and allowing these smart pointers (and containers that hold them) to support moves will simplify that work considerably.
That said, other than the name not quite fitting right, I’m not sure why we would need to prevent vtkNew from having these extra abilities, and all of the problems we’re discussing today about vtkNew would still apply to a vtkUniquePtr.