[Development] Proposing to officially allow C++20 types in Qt 6 ABIs

[Thiago Macieira]

On Monday, 31 January 2022 05:23:45 PST Giuseppe D'Angelo via Development 
wrote:
> 1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the
> latter, Qt 6 does the former. I would be fine at restoring C++-latest,
> with command line switches available to picking a specific C++ version
> if so desired.

It defaults to C++17. We actually know of a few issues with C++20 with some 
compilers and those need to be fixed, regardless of what we do about this 
thread. And we should at a minimum test our headers with multiple versions of 
the C++ standard, because that's an acceptable choice our users can make.

> However, this smells of maintenance burden; what "latest" means depends
> on the specific compiler version, that is, we need to start building
> compiler+CMake version lists (older CMakes does not recognize the latest
> C++ versions).

I don't see why that would be a problem for us. So an older CMake doesn't know 
that GCC 10 has C++2b mode? Then we just test the C++2b mode in an OS that 
comes with a suitably recent CMake.

Additionally, I'd also limit the testing to a version of the compiler we've 
concluded that it supports the language correctly. We will find implementation 
bugs, shortcomings, and limitations because those things are in development.

> On top of that, C++17 is still the official minimum (= need CI coverage
> for C++17 builds on all platforms).

Not if we decide that we must use C++20.

> 2) Should a C++-latest build of Qt work on a C++-17 only toolchain? I
> would say absolutely not, we don't support toolchain downgrades.

Speaking specifically about building Qt, not building user code, I agree. For 
two reasons: first, that we reduce our own maintenance burden. Second, because 
of the issue I raised: binary compatibility.

> 3) Should a C++-latest build of Qt work for a C++17-compiled project? I
> would say that this should work. If the post-C++17 features are guarded
> by the right #ifdefs, would that be a problem?
> 
> The added bonus of making this work would be that we could offer
> C++-latest binary builds of Qt and projects could still pick their
> preferred C++ version to use.

I think it's a must, unless we say that user code must also use C++20 to work 
with Qt and I don't think we're there yet.

> 4) Should a C++17 build of Qt work for a C++-latest project? I'd say
> "yes", but what happens if the project tries to use an API that uses a
> C++-latest datatype? At first approximation, the user might simply get a
> link error (the function hasn't been built into Qt). Can we offer better
> QoI here, and completely hide those functions from such builds of Qt?
> 
> Not sure if it's easy -- it would mean baking the "has C++ feature"
> detection into the Qt build, maybe via CMake magic? But I would say that
> it's worth it; link errors are completely meaningless to an end user.

I'd say no. That was my reply to Lars just now and the gist of my opposition 
to Marc's initial proposal: a C++17 build of Qt is an unsupported "send 
patches, not bug reports" build.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering