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

[Vitaly Fanaskov]

Do you know is there is any official policy published? I’ve tried to look into both internet and intranet, but found pretty much nothing.

I entirely agree with increase of using new language features and STL, but it should be done wisely and under well-defined policy. If we don’t have one, we need to develop it. Without an official document users cannot rely on Qt. We also might easily violate ABI-compatibility policy and so on.

--
Best Regards,

Fanaskov Vitaly
Senior Software Engineer

The Qt Company / Qt Quick and Widgets Team

On 29 May 2019, at 17:17, Mutz, Marc via Development <development at qt-project.org<mailto:development at qt-project.org>> wrote:

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20190529/aa172d8a/attachment.html>