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

[Giuseppe D'Angelo]

On 31/01/2022 17:36, Thiago Macieira wrote:
> 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.

I was referring to the "defaulting to C++-latest". In order to know what 
*is* the "latest" you can target, you need to detect the CMake and the 
compiler versions. That means start building tables of supported 
combinations. Probably nothing too complicated, still, work to do.


>> 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.

That's an orthogonal decision. Bumping the minimum requirement of Qt to 
C++20 will simply reopen the same questions for C++23, won't it?


>> 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.

So, concretely, this just means: use feature macros to guard the 
relevant APIs. The C++17 project won't see the APIs as available, so it 
can't use them, and won't get no compile errors.


>> 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.

Is this a "no" to the better QoI, or to the overall idea of making a 
C++17 build of Qt work with a C++-latest project?


Thanks,

-- 
Giuseppe D'Angelo | giuseppe.dangelo at 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 - The Qt, C++ and OpenGL Experts
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220131/61f6df2d/attachment-0001.bin>