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
_______________________________________________
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
