I posted in the other thread, glad to hear you aren’t wanting to remove implicit casts entirely. I wonder if the generalization is going to make it harder for new users, and posed the same question over there. I don’t feel overly invested, but if we want to treat vtkNew like unique_ptr I wonder if we might want to add a fourth smart pointer named as such with the narrower scope.
At the end of the day some of us like RAII, short, concise code with minimal repetition that clearly conveys our intent. VTK forces all instances to be pointers, and as such there will always be some level of nudging things around to fit a more familiar STL C++11 feel unless we make the huge leap to embrace the language as it is now and radically alter API.
I fought pretty hard to get vtkNew in over a period of a year before auto was even a possibility to replace ugly VTK_CREATE macros and stop having huge lines that discouraged safe practices by their verbosity and repetition. We should keep pushing for more modern APIs, improved best practices, and ideally simple mappings to language features if we want to attract more people to VTK’s C++ API.
Things like improved memory handling, const-correctness, returning values where possible, pass by value or const ref, not exposing internal data, thread safety, asynchronous execution and more represent significant challenges/questions on how much change is OK. Also how do we manage change, several disruptive changes every 6-12 months is likely to drive users away.