[Development] unique_ptr and Qt, Take 2

[Daniel Teske]

> The patch I propose does not take that into account and is indeed 
> almost entirely source compatible.
>
Scratch the "not".


> And while I'd encourage someone to try it out, I'm of the firm opinion 
> that Qt should try to get over its NIH attitude. One of the issues 
> with Qt in the real world is that it's just that tiny bit differently 
> than what non Qt C++ users are familiar with for. Sometimes that's for 
> a good reason. but there's a cost there that is imho unappreciated 
> inside the Qt bubble.
>
That sounds a bit harsher than intended and I should expand a bit on the 
costs:

* Non Qt C++ developers can be expected to be familiar with how 
unique_ptr works. Today that might not be a entirely true, but we aren't 
deciding the api for today. We are deciding on the api for the next years.

* Static analyzers understand standard c++ but are unlikely to 
understand the Qt dialect. [1]

* Using standard c++ means, that any evolution in c++ benefits Qt 
automatically.

daniel

[1] For another example, clang-tidy knows about standard smart pointers 
for its use after move check: 
https://clang.llvm.org/extra/clang-tidy/checks/bugprone-use-after-move.html