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

[Mutz, Marc]

On 2019-05-29 16:06, Vitaly Fanaskov wrote:
>> === QAtomic -> std::atomic ===
>> 
>> It already is just a thin wrapper around std::atomic, so there's not
>> much point keeping it.
> 
> There is the interesting question in light of this: are we really going
> to widely use std::* in public interfaces of Qt? If so, how all related
> mess is supposed to be handled? I know that we already use some of 
> them,
> for example, in QTimer and QString, but these cases are minor.
> 
> This decision should be very well justified and clearly defined
> somewhere before making suggestions like above.

AFAIK, this was decided long ago (at least two years). The problem used 
to be that Qt, by coincidence, didn't care which std library the user 
application linked to, because all its STL use was either internal or in 
inline functions. This used to have some merit on OSX, and could have 
had some merit on Linux had distributions compiled libc++ against GCC's 
language library to make it compatible with libstdc++, which, however 
most didn't.

But of course, that's a fallacy, because as soon as Qt internally uses 
said inline functions, every use of them by the user with a different 
STL is an ODR violation and therefore UB. So, again AFAICT, the decision 
was that we can use std types in the API now, even when not inline.

Someone correct me if I'm wrong.

What changed since then is that we can now assume many more of the C++11 
types to be available unconditionally.

Thanks,
Marc