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

[Thiago Macieira]

On Monday, 31 January 2022 10:44:07 PST Giuseppe D'Angelo via Development 
wrote:
> 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.

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

Not exactly, because of the difference between incoming and outgoing ABI.

If we allow C++2N symbols in *our* ABI, then those must always be present in a 
supported build (if you don't want support, you can do whatever you want). If 
that implies raising the minimum compiler version or minimum CMake version, 
therefore dropping support for older OS environments, then so be it. That's 
our choice.

But we can allow use of C++2N symbols in the ABI we *use*, if those were 
detected during the build. Downgrading the compiler and its C++ standard 
library is not supported neither by us nor by the compiler vendors, so we can 
be assured that this build of Qt will be run against the same version or 
newer. Those symbols will be present. They just can't be mandatory for all 
source builds.

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

Correct, provided Qt was compiled with C++20.

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

To be clear: I don't mind saying that Qt now requires C++20 to build. That's 
our choice to make and I'll abstain from going either way.

However, I do mind the ABI. It must be the same for all supported builds of Qt 
that use the an ABI-compatible compiler & toolchain. I am opposing a change 
this.

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



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

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

[Giuseppe D'Angelo via Development]

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.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 - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [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



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

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

[Thiago Macieira]

On Monday, 31 January 2022 02:04:46 PST Lars Knoll wrote:
> We upgrade the default to C++20, but keep things compiling in C++17 mode. If
> we do that, we should however consider upgrading our minimum compiler
> requirements for the binaries (ie desktop and mobile platforms) to
> compilers that support C++20. In addition, we’ll need to add testing of
> C++17 builds in CI.

We don't need to do any of that. We don't to test that ABI-breaking options 
compile. Whoever uses them assumes the responsibility for any breakages and 
must have the will to submit patches to fix any issues they encounter. Don't 
report bugs.

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



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

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

[Giuseppe D'Angelo via Development]

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.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 - The Qt, C++ and OpenGL Experts


smime.p7s
Description: S/MIME Cryptographic Signature
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Lars Knoll]

> On 28 Jan 2022, at 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’d be fine with that given that we have good enough C++20 support on the 
desktop and mobile platforms. We upgrade the default to C++20, but keep things 
compiling in C++17 mode. If we do that, we should however consider upgrading 
our minimum compiler requirements for the binaries (ie desktop and mobile 
platforms) to compilers that support C++20. In addition, we’ll need to add 
testing of C++17 builds in CI.

The last question is whether we would do that switch for 6.4 or 6.5.

Cheers,
Lars



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

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

[Thiago Macieira]

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. 

And, as the feature system, don't report bugs; send patches instead.

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



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

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

[Marc Mutz]

Hi Thiago,

> On Thursday, 27 January 2022 13:35:54 PST Thiago Macieira wrote:
> > I think it's fine to make the check per OS. But we can't use the __cpp_lib
> > variables.
>
> Alternative: we use the __cpp_lib macros, but we assert they are set in a .cpp
> file for the platforms where binary compatibility and ABI matter.

That would break projects that build their Qt themselves (embedded), and with 
C++17 (because, you know, compile times increase with every std version ).

Basically, we need a way to provide C++20 ABIs when Qt was compiled in C++20 
mode, and if not, then not. We had that already in Qt 5.x, x < 7, when C++11 
was optional, but we used C++11 in exported inline API, so AFAIU, CMIIW, the 
move special member functions were part of the ABI if you compiled your Qt in 
C++11 on Windows and they were missing from the ABI when Qt was built in C++98 
mode. And there we even had the BiC between std::string/98 and std::string/11 
while exporting inline QString::toStdString() (granted, that was on GCC, but 
doesn't that mean we had the problem on MingW, then?).

Thanks,
Marc

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

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

[Thiago Macieira]

On Thursday, 27 January 2022 13:35:54 PST Thiago Macieira wrote:
> I think it's fine to make the check per OS. But we can't use the __cpp_lib
> variables.

Alternative: we use the __cpp_lib macros, but we assert they are set in a .cpp 
file for the platforms where binary compatibility and ABI matter.

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



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

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

[Thiago Macieira]

On Thursday, 27 January 2022 11:54:37 PST Marc Mutz wrote:
> Hi Thiago,
> 
> > So here's my counter-proposal:
> > 
> > We allow C++17 and C++20 Standard Library types in our ABI provided:
> > * we update our builds, all of them, to build with C++20 by default
> > * the use of those symbols in the ABI is NOT behind an #if __cpp_lib check
> 
> This limits our ABI on _all_ platforms to the lowest common denominator
> _across_ platforms. That is precisely what we want to change: we want to be
> able to provide ABI that uses std::span and coroutines _without_ having to
> wait for Integrity, QNX, and Apple to get their act together.

I think it's fine to make the check per OS. But we can't use the __cpp_lib 
variables.

Incidentally, please don't make people who have no access to those toolchains 
have to comply with them. Only people who have a commercial interested should 
be required to suffer them.

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



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

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

[Marc Mutz]

Hi Thiago,

> So here's my counter-proposal:
>
> We allow C++17 and C++20 Standard Library types in our ABI provided:
> * we update our builds, all of them, to build with C++20 by default
> * the use of those symbols in the ABI is NOT behind an #if __cpp_lib check

This limits our ABI on _all_ platforms to the lowest common denominator 
_across_ platforms. That is precisely what we want to change: we want to be 
able to provide ABI that uses std::span and coroutines _without_ having to wait 
for Integrity, QNX, and Apple to get their act together.

Unless we want to start with macros like Q_STDLIB_SPAN again?

Thanks,
Marc

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

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

[Tor Arne Vestbø]

> On 27 Jan 2022, at 18:14, Thiago Macieira  wrote:
> 
> On Thursday, 27 January 2022 08:53:31 PST Tor Arne Vestbø wrote:
>> I don’t know what other things you’re referring to, but just to clarify,
>> this is not the case for macOS. We build the binary Qt packages with as
>> recent of an Xcode (and corresponding toolchain) as we have available in
>> the CI, typically the latest version.
> 
> The Xcode case has the same constraint, just a different implementation of it.
> 
> We use the latest compiler and the latest SDK that Apple provides for us, but 
> we set the minimum macOS target (and the other Apple platforms) to the 
> minimum 
> that we still support. That has the effect that functions that have been 
> added 
> to the SDK since that minimum become weak symbols, which allow us to verify 
> whether they are present at runtime.

Right, I’m aware, just wanted to make sure we were on the same page on that bit 
:) 

Thanks!

Cheers,
Tor Arne

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

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

[Thiago Macieira]

On Thursday, 27 January 2022 08:53:31 PST Tor Arne Vestbø wrote:
> I don’t know what other things you’re referring to, but just to clarify,
> this is not the case for macOS. We build the binary Qt packages with as
> recent of an Xcode (and corresponding toolchain) as we have available in
> the CI, typically the latest version.

The Xcode case has the same constraint, just a different implementation of it.

We use the latest compiler and the latest SDK that Apple provides for us, but 
we set the minimum macOS target (and the other Apple platforms) to the minimum 
that we still support. That has the effect that functions that have been added 
to the SDK since that minimum become weak symbols, which allow us to verify 
whether they are present at runtime.

We know Apple has done such shenanigans for the libc++ headers in the past. 
Maybe not for an inline-only std::span, but certainly for filesystem and other 
content that has out-of-line content. That's one of the reasons why we have 
some checks in at our configure/cmake time whether such functionality is 
usable, above and beyond the __cpp_lib_xxx macros getting defined.

So here's my counter-proposal:

We allow C++17 and C++20 Standard Library types in our ABI provided:
* we update our builds, all of them, to build with C++20 by default
* the use of those symbols in the ABI is NOT behind an #if __cpp_lib check

The second requirement is to ensure that the oldest compilers support the 
symbol in question. If you make it optional, then the build will succeed but 
the symbol will be missing.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel DPG Cloud Engineering



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

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

[Tor Arne Vestbø]

> On 27 Jan 2022, at 17:19, Thiago Macieira  wrote:
> 
> We know a great deal of our users use the binary builds by the Qt Company. In 
> order to make those the most widely supported, they are compiled with the 
> oldest compiler we still support. 

I don’t know what other things you’re referring to, but just to clarify, this 
is not the case for macOS. We build the binary Qt packages with as recent of an 
Xcode (and corresponding toolchain) as we have available in the CI, typically 
the latest version.

Cheers,
Tor Arne

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

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

[Thiago Macieira]

On Thursday, 27 January 2022 03:38:05 PST Marc Mutz wrote:
> 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.

That's the problem and the thing that makes your proposal unacceptable.

We know a great deal of our users use the binary builds by the Qt Company. In 
order to make those the most widely supported, they are compiled with the 
oldest compiler we still support. Therefore, we must limit ourselves to what 
those have in our pre-built ABI.

If you meant to use the C++20 types that those compilers have, then we can 
proceed. But we will need an analysis of support for every single such type as 
they are added to the codebase.

Let's start with your example:

gcc $ git -P log --oneline --diff-filter=A libstdc++-v3/include/std/span
95e9a7616d3 Implement std::span for C++20
gcc $ git describe 95e9a7616d3
basepoints/gcc-10-2978-g95e9a7616d3
gcc $ cd ../llvm-project
llvm-project $ git -P log --oneline --diff-filter=A libcxx/include/span
8a0794b722bd Implement . Reviewed as https://reviews.llvm.org/D49338
llvm-project $ git tag --contains 8a0794b722bd | head -1
llvmorg-7.0.0-rc1

std::span was introduced to GCC's libstdc++ with GCC 10 and with libc++ 7.0.0. 
I don't know what the minimum Clang version we require is, particularly since 
Apple doesn't use the same numbering for Xcode, but GCC 10 is too new and we 
support GCC 9. See https://doc.qt.io/qt-6/supported-platforms.html.

Therefore, we can't use std::span in our ABI just yet.

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



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

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

[Philippe]

foremost among them are coroutines

Note that on OSX / Clang, coroutines is still in  wrote:

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
>   
> marc.m...@qt.io
>   
> www.qt.io
>   
>   
>   
>   
> Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
> Sitz der Gesellschaft: Berlin,
> Registergericht: Amtsgericht Charlottenburg,
> HRB 144331 B
>   
>   
>   
>   
>   
>   
>  
>   
>  
>   
> 
> 
> 
> 
> 

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

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

[Marc Mutz]

> Did I understand you correctly that we
> - would still guard any such method with an #if __cplusplus >= ...,

More likely __cpp_lib_span, etc, but yes in principle.

> - would compile our shipped artifacts in C++20 mode on all platforms where 
> this is possible

I presume that would be necessary, yes.

But I confess to not having thought about pre-compiled binaries before hitting 
"send"  so good point.

> - and users still could compile their own code in C++17 mode on those 
> platforms without issues?

That's the goal, yes. Within reason, of course.

There are two aspects here:

First, and easy, C++17 code will not see C++20 functions, so any C++20 code 
needs to be written such that the relation between a C++17 and C++20 build of 
Qt is the same as between a x.y and x.(y+1) build of Qt, respectively. Ie. 
backwards, but not forwards compatible. This means we can't have, say, virtual 
functions that use these types.

Second, and more subtly, this may unearth issues when a Qt compiled against 
C++20 is used to build an app in C++17 mode. I don't think we systematically 
test that. I'm thinking e.g. about issues of BC in the stdlib. Again, these 
issues would exist today, and not just on MSVC. E.g. we use std::function 
across the ABI boundary. If that were to change incompatibly, we'd need to ship 
separate C++17 and C++20 builds.

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

Correct.

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

Thanks,
Marc


Marc Mutz

Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany

marc.m...@qt.io

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://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube.png] 


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

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

[Fabian Kosmale]

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  im Auftrag von Marc Mutz 

Gesendet: Donnerstag, 27. Januar 2022 12:38
An: development@qt-project.org
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

marc.m...@qt.io<mailto:marc.m...@qt.io>

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
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

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

[Marc Mutz]

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

marc.m...@qt.io

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://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/facebook.png]
 
[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/twitter.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/linkedin.png] 

[https://s3.eu-north-1.amazonaws.com/email-signature-tool-leroy/youtube.png] 


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