[Development] unique_ptr and Qt, Take 2

Daniel Teske qt at squorn.de
Wed May 8 08:59:43 CEST 2019

> 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 

* 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 


[1] For another example, clang-tidy knows about standard smart pointers 
for its use after move check: 

More information about the Development mailing list