Hi, I certainly would like to use vocabulary types like std::span in our API rather sooner than later. I have some questions regarding your proposal, though. Did I understand you correctly that we - would still guard any such method with an #if __cplusplus >= ..., - would compile our shipped artifacts in C++20 mode on all platforms where this is possible - and users still could compile their own code in C++17 mode on those platforms without issues? - Lastly, in your proposal, platforms without C++20 support would still be able to build Qt, but lack the newer API? And if at some point they would gain a newer compiler, they would have to recompile Qt to get access to those methods, and linker errors otherwise?
If the above is correct (and it actually works), then I think we can do that. The only tricky part is the last point (you upgrade your compiler to support C++20, but your Qt still doesn't provide the C++20 methods you see in the headers), but I think this would be fine if it gets documented. Regards, Fabian ________________________________________ Von: Development <[email protected]> im Auftrag von Marc Mutz <[email protected]> Gesendet: Donnerstag, 27. Januar 2022 12:38 An: [email protected] Betreff: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs Hi, C++20 brings several new library features that would be great to use in the Qt API, foremost among them are coroutines and std::span. Yet, both of these are, in a sense, type-erasure techniques, and therefore most useful across ABI boundaries. Traditionally, Qt has defined a set of minimum supported C++ compilers and whatever their lowest common denominator was, that's what could be used in the Qt ABI, everything else, let's call it conditionally-supported, could only be used in inline API. It is worth noting that on MSVC, inline API in exported classes already forms part of the ABI, and no-one seems to have cared. I would therefore like to propose to soften our ABI guidelines such that we can officially use said conditionally-supported types also in the ABI. This would allow to create non-inline APIs that use std::span and coroutines without having to wait for all compilers to support them. This is not such a big step: We already have that, de facto, in MSVC. The only difference would be that a C++20 project would require a C++20(or later)-build of Qt. The error upon failure to comply would be unspectacular: linker not finding a symbol in the Qt library. Seeing as we have allowed C++latest types in our ABI de-facto in the past, I think it's time to allow it de-jure, too. Discuss 🙂 Thanks, Marc Marc Mutz Principal Software Engineer The Qt Company Erich-Thilo-Str. 10 12489 Berlin, Germany [email protected]<mailto:[email protected]> www.qt.io<https://www.qt.io> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B [https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/qt-company.png]<https://www.qt.io/> [https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook.png]<https://www.facebook.com/qt/> [https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter.png] <https://twitter.com/qtproject> [https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin.png] <https://www.linkedin.com/company/the-qt-company/> [https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube.png] <https://www.youtube.com/QtStudios> _______________________________________________ Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
