[Development] Qt 5 types under consideration for deprecation / removal in Qt 6

[Thiago Macieira]

On Wednesday, 5 June 2019 13:36:01 PDT André Pönitz wrote:
> > Yes, I've complained that most distros can't seem to compile them to be
> > compatible correctly. But that's not Qt's problem that one (or most) of
> > them fail to do their job properly.
> 
> It's not "Qt's problem" per se, but it's becoming the problem of Qt _users_
> once Qt is not shielding them anymore.

Technically true, but I don't think it's actually a very relevant fact, for 
two reasons:
 1) no one really wants to mix C++ standard libraries, despite the option 
    being there
 2) the boat has sailed: people use other libraries like Boost that do use C++
   Standard Library API, which means those codebases are already affected

> > In a properly configured environment, there could be users who want to
> > perform this mixing.
> > 
> > But no, I don't think we should use that as an argument for avoiding
> > Standard Library API in our classes.
> 
> Neither me, actually. But it should also not serve as an excuse to run a
> "quixotic crusade to de-Qt Qt" [1]

I agree with you. You know I dislike the Standard Library API and I really 
wish not to read ".empty()" in Qt code and wonder if that is in the 
imperative. After all, if it's ok for "clear", why not "empty"?

But I am not in the mood for reimplementing perfectly good API. I may find 
that std::chrono is overengineered, but it is something I can work with.

And I am not above wrapping bad Standard Library API when I think we can do 
better. Quod vide QRandomGenerator.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel System Software Products