On 10/10/2024 18:57, Thiago Macieira wrote:
Re: https://codereview.qt-project.org/c/qt/qtbase/+/463425

TL;DR: for some std::format functionality, we really want to have out-of-line
implementations, which requires QtCore compiled with C++20. See
https://codereview.qt-project.org/c/qt/qtbase/+/595309/2/src/corelib/text/
qstring.cpp for the thinking. Let's focus first on the C++ language, because
the ABI discussion is irrelevant if we don't do this.

So I'd like to propose that we switch all Qt builds to C++20 by default where
the compilers support it and have supported it for years, but not require it
for platforms where either the compiler or the standard library are unable to
compile in C++20 mode.

This switch can be overridden in the configure/cmake command-line in a
developer-build-like "use voids warranty" option. That is, the only people who
should change the default are people reading this mailing list. Other users,
including all Linux packagers, Homebrew, vcpkg and the official QtC binaries
should not touch that option. This override is intended solely so we can test
the ability to compile C++17 without having to install those OSes above (none
of which are freely available anyway).

Do you foresee any problems at actually guaranteeing that we still work with C++17, should one force the C++ version (via whatever means)? I mean, we have to keep work in C++17 anyhow (for some toolchains), what's the harm at saying that Qt actually works everywhere that way?

Is it an implementation concern, or e.g. because by default the CI won't test it anymore (will test in C++20), or...?

(Indeed testing is especially tricky. Do we run the full autotest suite on those platforms that won't get C++20 by default? Should we still keep C++17 coverage around on at least one platform, say, Linux?)


Moreover, our headers must build with C++17, so this is not a licence to use
C++20 without compile-time checks (asking for that for the desktop platforms
is a future discussion).

Because this is meant to be developer-build-like only, I think we need to
remove the FEATURE_cxx20 and FEATURE_cxx2b cmake options too. This is because
some user scripts may be using those and users need to understand the change
in nature, that this is "voids warranty" now.

Points of discussion:
0) should we do this? Is there any side-effect?
Please note that downgrading compilers and Standard Library versions has never
been allowed, so even if the Qt libs get some stickiness to the lib as a
result of this, that is by itself not a problem. But it would be a problem if
we do get it on a symbol that is not yet guaranteed to be ABI-stable.

Right now that includes, for instance, libstdc++, which still marks C++20 and later as experimental, and can break API/ABI at will.

MS-STL is more conservative, and doesn't expose unstable C++20 features behind /std:c++20, only behind c++latest. I'm not sure about libc++.

So, what happens to us if libstdc++ breaks (for instance) ABI in some std::format utility?



2) how should other modules inherit qtbase's setting?
The current patch does not inherit the setting at all and, instead, each
module gets the default again. Each module can be independently overridden
using CMAKE_CXX_STANDARD.

I prefer it this way because:
a) it's simpler, without inter-module dependencies
   (it was much simpler to implement)
b) the only people switching the language are us (incl. the CI) and we can
    simply pass -DCMAKE_CXX_STANDARD where desired
c) allows for modules to make their own choices if they want to mandate C++17
   or C++20 for some reason

There's the remote chance that some *private* header may become C++20-only, and thus breaking dependent modules, but I wouldn't really worry about that...

d) allows for the CI to test mix-and-match C++17 and C++20 downstream of
   qtbase

Alexandru makes a point that some developers may want to have a setting in one
place and have it inherited to all other modules. This need not remove any of
the points I made above, though, except that it would be a slightly more
complex implementation.

What about the qt-configure-module script? Is it going to inherit qtbase's settings?


3) how should we detect the platforms where C++17 is still required?
I hardcoded it:
* QNX, INTEGRITY, VxWorks: C++17 by default
* everyone else: C++20 by default
There's no configure-time checking that C++20 works for those platforms where
it's set by default. The current patch allows CMake to fall back if it can't
find the functionality, but maybe we just don't allow it to fall back.

There's an implicit question here whether having a per-platform default is a
good idea. My stance on this is that I think being held back by platforms that
won't update more than once a decade puts undue penalty on everyone else who
does. I don't begrudge anyone from choosing those three above, but I also
don't want your choices to constrain me.

4) should we support building Qt with C++17 on the C++20-by-default platforms?
Please note this is about building Qt itself, not about user code. User code
must be compilable with C++17 because we don't know yet whether they have
content that fails at C++20 for some reason.

My answer, as shown by my labeling the override option "voids warranty" is a
very clear and definite NO. This means that if you have GCC 10 or later or
Clang 13 or thereabouts or later or Visual Studio with the normal Standard
Libraries, your only supported build is C++20. This means all desktop
platforms, Android, and Apple mobile devices would use C++20.

Because we need that build ourselves to check our own headers, we will need to
keep it working. But there will be consequences, when we do start allowing
limited ABI dependency (like std::format).

Same question as above: given the C++20 code would still need some sort of protection (feature macros, QT_CONFIG, whatever) because it needs to build on the C++17 platforms, what's the harm at keeping C++17 "working" everywhere?

Effectively, I don't see much difference from the current situation, where we "pretend" that we require C++17 but in reality we just check that we can pass `-std=c++17` to the compiler. Any usage in Qt code of individual language/library features still requires protection, because they're not universally implemented.


My 2 c,
--
Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - Trusted Software Excellence

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Reply via email to