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

[Giuseppe D'Angelo]

On 28/01/2022 02:07, Thiago Macieira wrote:
> On Thursday, 27 January 2022 16:49:22 PST Marc Mutz wrote:
>> That would break projects that build their Qt themselves (embedded), and
>> with C++17 (because, you know, compile times increase with every std
>> version 🙂).
> Ok, then we make it optional to turn back the clock and compile as C++17. But
> we default to C++20. This option would be as ABI-breaking as the feature
> system or choosing qreal == float.

I'm not 100% sure I understood the outcome. Trying to summarize the 
thread here.

We want to use C++-latest stdlib types in our API _and_ ABI (i.e. out of 
line functions). For that, we obviously need a C++-latest build of Qt. 
Having C++-stdlib types in our ABI is a sailed ship, and so is getting 
an ABI break from changes in a given stdlib implementation (not our 
problem).


Debate points:

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.

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

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


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.


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.


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.


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/5a0908c5/attachment.bin>