Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Wednesday, 3 May 2023 11:14:55 PDT Marc Mutz via Development wrote:
> [Sorry, yes, 6.9 is in spring '25. I messed up the counting]

As a native of the Southern Hemisphere, I ask that we use dates, not seasons 
to refer to times. Everyone knows that Spring happens in September, right 
before we go for Christmas and New Year at the beach for some suntan.

I also make a similar request of any Americans around: spell out you month 
names, so there's no mistaking whether "04/05/2023" means First Contact Day 
(Star Trek) or May The Fourth Day (Star Wars). Or use ISO dates.

> I'm not the one talking to these customers, but the feedback I get from
> those who do is that yes, it's too early. Then again, the internal plan
> calls for requiring C++20 for building (but not using) Qt 6.9. I don't
> see how that helps any user. If they can build Qt in C++20 (or arrange
> for it to be built for them), then they can build their own project in
> C++20, too. I get the desire to insulate users from having to port their
> own code to C++20, but as I said, I don't see how that's possible to
> avoid if Qt itself must be built with C++20.

Agreed: if the toolchain they're using can compile Qt in C++20 mode, then that 
toolchain can compile their application too. So long as the update of the 
toolchain retains compatibility with code that had been previously compiled, 
there aren't any major issues. All of the ones I work with do.

There may be a bit of code that compiled with C++17 and doesn't with C++20 
(like the implicit capture of this in [=]), but they're usually simple and 
easy to fix. 

There may also be issues with some other libraries that, unlike Qt and the 
Standard Libraries, do have different symbols depending on whether they were 
compiled with C++17 or 20 (e.g., an out-of-line operator<=>). Those would need 
to be recompiled with the new toolchain. Usually, vendors that have bothered 
with writing C++20 code would have such builds available, so I don't expect 
this need to be a big problem either.

But those are paper cuts. If you add enough of them...

> > If you're only going to make a VLTS release every 4.5 years, then we won't
> > be able to adopt every C++ release. C++23 may be too soon for adoption in
> > late 2024 (release March 2025), but we may then skip C++26 for the one
> > after.
> C++20 (like C++11) are a bit special as they're rather large releases.
> Companies and customers may be (rightfully) more reluctant to upgrade to
> C++20 than they were from, say, 11 to 14, which is what I expect 20-23
> to feel like.

Indeed, see my reply to Volker in the older thread. I don't see anything in 23 
that we'd push for.

And yet, the list of things we want from C++20 is not that big. It's nowhere 
as complex as C++11 and I'd argue that even the 17 upgrade for Qt 6.0 was a 
bigger jump. Unless we add concepts to the list, but I don't think we can 
until we've experimented with it for a while.

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


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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Wednesday, 3 May 2023 11:15:19 PDT Marc Mutz via Development wrote:
> That might be so, and I'm not Maurice or Vladimir, but if I was to
> decide, I wouldn't commit my company to a roadmap that requires forward
> binary compatibility from stdlib vendors without a written declaration
> from each of them that this is a supported use-case.

That problem exists whether we use C++20 or not. If a library decides to break 
BC, they'll likely *break* it for all versions. I don't think a C++20 symbol 
in 2025 is more likely to get replaced/removed than a C++17 or C++98 one.

Compiling with a new version of the library and running with an old one is not 
and has never been supported. No one is suggesting that. That's why I listed a 
few oldest minimum versions, so that anyone interested in creating binary 
builds could choose exactly those.

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


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

Re: [Development] API style guide: scoped enum or not?

[Thiago Macieira]

On Wednesday, 3 May 2023 10:40:18 PDT Marc Mutz via Development wrote:
> So if it's a vote: +1 for all new enums being scoped and +1 for all old
> enums being made scoped come Qt 7.

With the same trick that C++20 did for std::memory_order?

  enum class memory_order : int
{
  relaxed,
  consume,
  acquire,
  release,
  acq_rel,
  seq_cst
};

  inline constexpr memory_order memory_order_relaxed = memory_order::relaxed;
  inline constexpr memory_order memory_order_consume = memory_order::consume;
  inline constexpr memory_order memory_order_acquire = memory_order::acquire;
  inline constexpr memory_order memory_order_release = memory_order::release;
  inline constexpr memory_order memory_order_acq_rel = memory_order::acq_rel;
  inline constexpr memory_order memory_order_seq_cst = memory_order::seq_cst;


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


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

Re: [Development] API style guide: scoped enum or not?

[Thiago Macieira]

On Wednesday, 3 May 2023 10:51:18 PDT Jaroslaw Kobus via Development wrote:
> "enum class" has one advantage over "enum" inside a "class" : you may
> forward declare the "enum class", while the other not. That's quite often
> case that your header must include the other header just because you use
> the "enum" in "class" in your API and nothing more.

Hello Jarek

That's fair, but that requires a separate scope from the class itself. That 
alone may be a reason not to do so, and instead just declare the enum inside 
the class, as our current practice dictates, with the choice of plain enum or 
enum class.
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] API style guide: scoped enum or not?

[A . Pönitz]

[re-ordered]

On Wed, May 03, 2023 at 05:32:46PM +, Axel Spoerl via Development
wrote:
> > On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development
> >  wrote:
> > 
> > 02/05/23 10:58, Volker Hilsheimer via Development ha
> > scritto:
> >> During the header review, but also in API discussions leading up to
> >> it, we had a few cases where it would have helped if we had clearer
> >> guidelines about when to use scoped enums, and when not.  Scoped
> >> enums have some clear technical advantages (such as better type
> >> safety, thanks to no implicit conversion to int). And they
> >> sometimes result in better APIs when enum values don’t have to
> >> repeat the enum’s name in order to be clear.
> > 
> > Should we vote on this? To me it's a no brainer: any new enumeration
> > added to Qt shall be an enum class.
> > 
> >> But sometimes it’s also creating too much verbosity to use a scoped
> >> enum (ie. Qt::Orientation::Horizontal would perhaps not be an
> >> improvement).
> > 
> > I wouldn't consider this tiny bit of extra verbosity a huge
> > impediment. Note that Qt::Horizontal is violating the API naming
> > guidelines. It should've been called Qt::HorizontalOrientation. How
> > is that now better than Qt::Orientation::Horizontal?
> > 
> > No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified.
> > Does it refer to what? Text alignment? Text direction? Layout
> > direction? (Hint: none of these.)
> > 
> > The extra verbosity e.g. in switches can be tamed; one more reason
> > to upgrade to C++20:
> > 
> > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html
>
[...]
>
> +1 for every new enum added being an enum class. Exceptions to be
> approved here case by case. 

My main problem with enum classes _in Qt_ is that it is inconsistent
with what has been there traditionally. It is simply no fun to guess
what "style" some enum is (and sure, Peppe has a point when hinting that
the naming scheme wasn't applied uniformly in the pre-past either...)

I know uniform API isn't exactly en vogue anymore, but in this
particular case here I wonder whether it would be possible with
reasonable effort to go all-in on enum classes by offering "equivalent"
enum classes to non-class enums and e.g. suitable overloads in core API
so that I would have "one way to do it" again.

Opinions?

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

Re: [Development] Raising the minimum to C++20

[Marc Mutz via Development]

On 03.05.23 18:03, Thiago Macieira wrote:
> On Tuesday, 2 May 2023 23:16:19 PDT Marc Mutz via Development wrote:
>> [1] I also heard the idea to make C++20 mandatory for building Qt, but
>> user projects could continue to use C++17. That would require _forward_
>> binary compatibility between stdlib implementations. Given that a C++20
>> stdlib must needs contain more symbols (C++20-only features), it's
>> almost guaranteed that forward BC isn't maintained by stdlibs.
> 
> I don't see that as a conclusion.
> 
> The library is the library. Whether you've compiled as C++14, 17, 20 or 23
> before linking to it is immaterial. What matters is the symbols it provides
> and the Standard Libraries must, by necessity, offer all the symbols that any
> compilation of their headers would require.
> 
> Upping our build requirements would allow us to offer symbols in our libraries
> that could only be accessed by code compiled under C++20. Right now, we can't
> do that and we must provide certain workarounds.

That might be so, and I'm not Maurice or Vladimir, but if I was to 
decide, I wouldn't commit my company to a roadmap that requires forward 
binary compatibility from stdlib vendors without a written declaration 
from each of them that this is a supported use-case.

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
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] Raising the minimum to C++20

[Marc Mutz via Development]

On 03.05.23 18:24, Thiago Macieira wrote:
> On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote:
>> While I'd rather sooner than later see us switch to C++20, ever since
>> 5.7, we have dropped supported compilers only after an LTS release (5.6,
>> in that case).
> 
> We are after an LTS release (6.5). We could have done this for 6.6 and had the
> same ages for the compilers as 6.0 did, but it's too soon. So 6.7 sounds good.

We couldn't've done this for 6.6, because Integrity isn't there, yet.

>> Since I agree the train for 6.6 has left the station, as Integrity (and
>> possibly QNX?) don't have an official C++20 offering, yet
>> (https://ghs.com/products/compiler.html, IIRC, they're going to release
>> one this year, but I don't know what features they're shooting for), I
>> was assuming that 6.9 would be the next option.
> 
> I personally think that a March 2025 release is late. I'd like to pull that
> in. But since I don't think the 6.8 release will be acceptable, we get only
> the March 2024 release as another option.

[Sorry, yes, 6.9 is in spring '25. I messed up the counting]

>> Personally, I would support a break after 6.8. That's scheduled for
>> release in summer/autumn 2024, and has three years LTS, so gives
>> affected customers until autumn 2027 to update their tool-chains. By
>> that time, C++26 will be out already.
> 
> Qt 6.5 was released March 2023. If it's supported for 3 years for those
> customers, they have until March 2026 to upgrade. Is that so bad? (Honest
> question)

I'm not the one talking to these customers, but the feedback I get from 
those who do is that yes, it's too early. Then again, the internal plan 
calls for requiring C++20 for building (but not using) Qt 6.9. I don't 
see how that helps any user. If they can build Qt in C++20 (or arrange 
for it to be built for them), then they can build their own project in 
C++20, too. I get the desire to insulate users from having to port their 
own code to C++20, but as I said, I don't see how that's possible to 
avoid if Qt itself must be built with C++20.

Maybe TQtC needs to open the VLTS branches up a bit more, to allow a bit 
more risky kinds of backports than currently, to appease users stuck on 
these versions due to toolchain issues, but from a Qt OSS project POV, I 
don't think it's something we need to care about. That is what customers 
pay money for to TQtC, so it's TQtC's decision how to deal with this.

>> Even that, within TQtC, is seen as too early by some. After all, we
>> still support 5.15 and therefore C++11, in 2023. That's only because
>> 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a
>> VLTS release, too, if sufficient numbers of customer won't be able to
>> upgrade to C++20 by 2027.
> 
> If you're only going to make a VLTS release every 4.5 years, then we won't be
> able to adopt every C++ release. C++23 may be too soon for adoption in late
> 2024 (release March 2025), but we may then skip C++26 for the one after.

C++20 (like C++11) are a bit special as they're rather large releases. 
Companies and customers may be (rightfully) more reluctant to upgrade to 
C++20 than they were from, say, 11 to 14, which is what I expect 20-23 
to feel like.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
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] API style guide: scoped enum or not?

[Jaroslaw Kobus via Development]

"enum class" has one advantage over "enum" inside a "class" : you may forward 
declare the "enum class", while the other not. That's quite often case that 
your header must include the other header just because you use the "enum" in 
"class" in your API and nothing more.

Jarek


From: Development  on behalf of Tor Arne 
Vestbø via Development 
Sent: Wednesday, May 3, 2023 7:39 PM
To: Macieira, Thiago
Cc: development@qt-project.org
Subject: Re: [Development] API style guide: scoped enum or not?



On 3 May 2023, at 19:22, Thiago Macieira  wrote:

I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're sufficiently descriptive already.

Agreed, and this is also what our current API design guide says:


API Design Principles - Qt 
Wiki
wiki.qt.io
[favicon.ico]


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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[A . Pönitz]

On Wed, May 03, 2023 at 03:21:40PM +0200, Giuseppe D'Angelo via Development 
wrote:
> Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
> > 
> > What started as an attempt to provide a few building blocks for making it 
> > easier to build asynchronous APIs taking any kind of callable (like 
> > QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
> > longer journey to the core.
> > 
> > [1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
> > [2]https://codereview.qt-project.org/c/qt/qtbase/+/475168
> 
> A general problem here is whether we can provide this infrastructure as a
> public API. If I have a class of mine and want to provide convenience for
> connecting to slots/callables, how do I do it without using private APIs? In
> Qt 4 days that was a simple:
> 
>   void foo(..., QObject *receiver, const char *slot);
> 
> But it's not so simple/possible any more with the PMF syntax.

Something like

void foo(...,
QObject *guard,
const std::function )

does a sufficiently good job over here.

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

Re: [Development] API style guide: scoped enum or not?

[Marc Mutz via Development]

On 03.05.23 19:22, Thiago Macieira wrote:
> On Wednesday, 3 May 2023 09:40:42 PDT Giuseppe D'Angelo via Development wrote:
>>   To me it's a no brainer: any new enumeration
>> added to Qt shall be an enum class.
> 
> I'd say that any new enumeration in the Qt namespace should be enum class, but
> enums in classes may not be so if they're sufficiently descriptive already.

That's the wording we currently have, and I have two problems with that:

- it's subjective, which means we get to quarrel over every class-scope 
enum anew
- it completely ignores the point that scoped enums don't implicitly 
convert to underlying_type, which is a very welcome subtraction from 
C/C++'s infamous implicit conversion mess

So if it's a vote: +1 for all new enums being scoped and +1 for all old 
enums being made scoped come Qt 7.

Thanks,
Marc

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
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] API style guide: scoped enum or not?

[Tor Arne Vestbø via Development]

On 3 May 2023, at 19:22, Thiago Macieira  wrote:

I'd say that any new enumeration in the Qt namespace should be enum class, but
enums in classes may not be so if they're sufficiently descriptive already.

Agreed, and this is also what our current API design guide says:


API Design Principles - Qt 
Wiki
wiki.qt.io
[favicon.ico]


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

Re: [Development] API style guide: scoped enum or not?

[Tor Arne Vestbø via Development]

On 3 May 2023, at 18:40, Giuseppe D'Angelo via Development 
 wrote:

Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
During the header review, but also in API discussions leading up to it, we had 
a few cases where it would have helped if we had clearer guidelines about when 
to use scoped enums, and when not.
Scoped enums have some clear technical advantages (such as better type safety, 
thanks to no implicit conversion to int). And they sometimes result in better 
APIs when enum values don’t have to repeat the enum’s name in order to be clear.

Should we vote on this? To me it's a no brainer: any new enumeration added to 
Qt shall be an enum class.

But sometimes it’s also creating too much verbosity to use a scoped enum (ie. 
Qt::Orientation::Horizontal would perhaps not be an improvement).

I wouldn't consider this tiny bit of extra verbosity a huge impediment. Note 
that Qt::Horizontal is violating the API naming guidelines. It should've been 
called Qt::HorizontalOrientation. How is that now better than 
Qt::Orientation::Horizontal?

No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified. Does it 
refer to what? Text alignment? Text direction? Layout direction? (Hint: none of 
these.)

These are all straw men.

I’ll quote directly from 
https://wiki.qt.io/API_Design_Principles#Naming_Enum_Types_and_Values
Naming Enum Types and Values

The guiding principle is to avoid name clashes between enum values and to 
ensure readability code with reasonable verbosity.

Enums in Qt/global namespace

New enums in the Qt namespace should always use scoped/strong enumerators by 
default. The scoping/strong typing ensures that there is no conflict if the 
same enum value name is used multiple times:

 namespace Qt
 {
   enum class Color {
 Blue,
 Orange,
 Yellow
   };

   enum class FavoriteColor {
 Yellow,
 Orange
   };
 }

 Color yellow = Qt::Color::Yellow;
 FavoriteColor yellow2 = Qt::FavoriteColor::Yellow;
 yellow2 = Qt::Orange; // error


When using scoped enums additional naming rules (repeating of enum type name 
inside enum value name) for are not necessary.

Enums in classes

Enums inside a class do not have the same problem of names clashing, as they 
are already namespaced within the class.

There are still reasons to prefer scoped enums inside classes, but this should 
be decided on a case by case basis.

If the enum values have a clear relation to the parent class, prefer un-scoped 
enums:

 class TouchPoint
 {
   enum State {
Pressed,
Held,
Released
   };
};

// The context is clear when used outside the class
if (point.state() == TouchPoint::Pressed)
   ...

// As well as when used inside it
if (state() == Pressed)
   ...


Using scoped enums in this case would add redundant line noise:

if (point.state() == TouchPoint::State::Pressed)
   ...
if (state() == State::Pressed)
   ...


Note that the context where the enum is used, such as the name of the getter 
that returns the enum value, might be enough information to make a scoped enum 
redundant.

If the enum values do not have a natural relation to the class name, prefer 
scoped enums, e.g.:

 class QSslCertificate
 {
   enum class PatternSyntax {
RegularExpression,
Wildcard,
FixedString
   };
};

if (syntax == PatternSyntax::Wildcard)
  ...


Another option to avoid the name clash instead of scoped/strong enums is to 
embedded the enum type name into each enum value. This method was extensively 
used in Qt 4 before scoped/strong enums were available.

 class Widget
 {
  enum Corner {
   TopLeftCorner,
   BottomRightCorner,
…
  };
 };

 tabWidget->setCornerWidget(widget, Widget::TopLeftCorner);
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[Axel Spoerl via Development]

+1 for every new enum added being an enum class. Exceptions to be approved here 
case by case. 

> On 3 May 2023, at 18:42, Giuseppe D'Angelo via Development 
>  wrote:
> 
> Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:
>> During the header review, but also in API discussions leading up to it, we 
>> had a few cases where it would have helped if we had clearer guidelines 
>> about when to use scoped enums, and when not.
>> Scoped enums have some clear technical advantages (such as better type 
>> safety, thanks to no implicit conversion to int). And they sometimes result 
>> in better APIs when enum values don’t have to repeat the enum’s name in 
>> order to be clear.
> 
> Should we vote on this? To me it's a no brainer: any new enumeration added to 
> Qt shall be an enum class.
> 
>> But sometimes it’s also creating too much verbosity to use a scoped enum 
>> (ie. Qt::Orientation::Horizontal would perhaps not be an improvement).
> 
> I wouldn't consider this tiny bit of extra verbosity a huge impediment. Note 
> that Qt::Horizontal is violating the API naming guidelines. It should've been 
> called Qt::HorizontalOrientation. How is that now better than 
> Qt::Orientation::Horizontal?
> 
> No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified. Does it 
> refer to what? Text alignment? Text direction? Layout direction? (Hint: none 
> of these.)
> 
> The extra verbosity e.g. in switches can be tamed; one more reason to upgrade 
> to C++20:
> 
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html
> 
> 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 - The Qt, C++ and OpenGL Experts
> 
> -- 
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] API style guide: scoped enum or not?

[Thiago Macieira]

On Wednesday, 3 May 2023 09:40:42 PDT Giuseppe D'Angelo via Development wrote:
>  To me it's a no brainer: any new enumeration
> added to Qt shall be an enum class.

I'd say that any new enumeration in the Qt namespace should be enum class, but 
enums in classes may not be so if they're sufficiently descriptive already.

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


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

Re: [Development] About the timeline and phases to support C++20 with and in Qt

[Thiago Macieira]

On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote:
> The standing proposal is to move to C++20 with Qt 6.9, after the next LTS
> release. I see no pressing reasons to accelerate that. The value of the
> features Thiago listed - which excludes all the big stuff anyway - doesn’t
> seem so significant that it outweighs the impact on the community of users
> that are stuck on C++17, for a variety of reasons that we can’t just shrug
> off.

The big stuff you're talking about are Modules and co-routines. I don't see us 
adopting Modules any time soon, not even for the 6.9 release. It's not well 
supported *today*. Co-routines we'd need to learn how to make good use of them 
and we won't until we begin using them, so postponing buys us little.

That leaves concepts, which I think we could begin rolling in slowly. 
According to https://en.cppreference.com/w/cpp/20, the core language support 
appears to be there for the compilers versions I called out for, but not the 
concepts library for libc++. Upping the requirement for libc++ might be an 
acceptable compromise once we learn what we want to do with concepts.

> However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller
> challenge for compiler vendors to support after C++20. If we stick to the
> timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025,
> then perhaps we should skip C++20 and immediately require C++23. People
> that can move to a C++20 toolchain in 2025 can perhaps just as well move to
> a C++23 toolchain at that point. That needs more investigation, of course.
> But given the inevitable pain that comes with changing minimum
> requirements, moving to a standard that is already 5 years old seems a bit
> wasteful.

My opinion on C++23 reasonable features we'd like to use without workarounds:
* if consteval - not supported by current MSVC
* deducing this - not supported by any current compiler
* [[assume]] - we could use this now, https://codereview.qt-project.org/462807
*  - requires GCC 13 or LLVM libc++ 16

So my opinion is that aiming for C++23 is not possible for 6.9. For a release 
in March 2025, the interesting features are too recently supported or can be 
used without C++23 in the first place. The same goes for the next set of 
features from C++20 I'd like us to explore ( with GCC 13; 
std::source_location with libc++ 16, etc.). At best, we'd have the exact same 
feature set I proposed for C++20, except we'd compile with -std=c++23.

So, no, I think we should aim for the feature set I posted yesterday from 
C++20. The question is only when.

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


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

Re: [Development] API style guide: scoped enum or not?

[Giuseppe D'Angelo via Development]

Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto:

During the header review, but also in API discussions leading up to it, we had 
a few cases where it would have helped if we had clearer guidelines about when 
to use scoped enums, and when not.

Scoped enums have some clear technical advantages (such as better type safety, 
thanks to no implicit conversion to int). And they sometimes result in better 
APIs when enum values don’t have to repeat the enum’s name in order to be clear.


Should we vote on this? To me it's a no brainer: any new enumeration 
added to Qt shall be an enum class.




But sometimes it’s also creating too much verbosity to use a scoped enum (ie. 
Qt::Orientation::Horizontal would perhaps not be an improvement).


I wouldn't consider this tiny bit of extra verbosity a huge impediment. 
Note that Qt::Horizontal is violating the API naming guidelines. It 
should've been called Qt::HorizontalOrientation. How is that now better 
than Qt::Orientation::Horizontal?


No, Qt::Horizontal isn't "unambiguous" so it can't be non-qualified. 
Does it refer to what? Text alignment? Text direction? Layout direction? 
(Hint: none of these.)


The extra verbosity e.g. in switches can be tamed; one more reason to 
upgrade to C++20:


https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1099r5.html

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



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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Wednesday, 3 May 2023 09:23:53 PDT Philippe wrote:
> Not yet available with Apple CLang (I did not test today, but a fews ago).

$ clang -E -include bit -xc++ -std=c++20 /dev/null > /dev/null
$ clang --version; date
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin
Wed May  3 09:33:46 PDT 2023

I don't know if it's *functional* to the point we'd need it, but we won't know 
until we try.

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


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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Tuesday, 2 May 2023 23:01:57 PDT Maurice Kalinowski via Development wrote:
> We even have customers who are not able to upgrade to C++17 yet due to
> supply chain issues.

Hello Maurice

Can you provide more details on what the difficulties are and when relief 
should 
be expected for this?

When you say "supply chain issues" for C++17, I am thinking that those 
customers are buying compilers in a DVD in a box and that is stuck in a 
container still sailing from China. That obviously can't be the case.

My proposal was that C++20 wouldn't be required until March 2024 for non-LTS 
users. The first of your LTS to require it would be the one from October 2024, 
and it wouldn't become the oldest LTS until 3 years after 6.5 (March 2026).

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


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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Tuesday, 2 May 2023 22:51:02 PDT Marc Mutz via Development wrote:
> While I'd rather sooner than later see us switch to C++20, ever since
> 5.7, we have dropped supported compilers only after an LTS release (5.6,
> in that case).

We are after an LTS release (6.5). We could have done this for 6.6 and had the 
same ages for the compilers as 6.0 did, but it's too soon. So 6.7 sounds good.

> Since I agree the train for 6.6 has left the station, as Integrity (and
> possibly QNX?) don't have an official C++20 offering, yet
> (https://ghs.com/products/compiler.html, IIRC, they're going to release
> one this year, but I don't know what features they're shooting for), I
> was assuming that 6.9 would be the next option.

I personally think that a March 2025 release is late. I'd like to pull that 
in. But since I don't think the 6.8 release will be acceptable, we get only 
the March 2024 release as another option.

> Personally, I would support a break after 6.8. That's scheduled for
> release in summer/autumn 2024, and has three years LTS, so gives
> affected customers until autumn 2027 to update their tool-chains. By
> that time, C++26 will be out already.

Qt 6.5 was released March 2023. If it's supported for 3 years for those 
customers, they have until March 2026 to upgrade. Is that so bad? (Honest 
question)

> Even that, within TQtC, is seen as too early by some. After all, we
> still support 5.15 and therefore C++11, in 2023. That's only because
> 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a
> VLTS release, too, if sufficient numbers of customer won't be able to
> upgrade to C++20 by 2027.

If you're only going to make a VLTS release every 4.5 years, then we won't be 
able to adopt every C++ release. C++23 may be too soon for adoption in late 
2024 (release March 2025), but we may then skip C++26 for the one after.

>  From a maintenance POV, it should be easier to support a C++17-based
> VLTS release than one that's still stuck on C++11 (and doesn't actually
> test for compatibility with that version in the CI...).

Sorry, I can't help you there (literally).

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


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

Re: [Development] Raising the minimum to C++20

[Philippe]

>>   header

Not yet available with Apple CLang (I did not test today, but a fews ago).

Philippe

On Tue, 02 May 2023 17:39:01 -0700
Thiago Macieira  wrote:

> C++23 is on the way, so maybe it's time for us to raise our minimum to the 
> one 
> version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is 
> within one month, and lets us warn our users this is coming.
> 
> By this, I mean to:
> * modify our build system so Qt compiles with -std=c++20 or equivalent
> * require that user code compiling Qt headers be similarly done
> * remove the requirement for #if checks for C++17 Standard Library features
> * make a couple of C++20 features mandatory (see below)
> 
> Of the C++20 features I currently see a good reason to make mandatory:
> * feature-test macros (no change: we're already using them)
> * spaceship operator and  header
> * char8_t
> * std::is_constant_evaluated()
> * constinit
> *  header
> * (maybe) designated initialisers
> * (maybe) constexpr from  and 
> 
> I'm not proposing modules, concepts or coroutines be allowed in our code just 
> yet. I think concepts will be the first of those, but we need to understand 
> how 
> to use them first and how our code will change. I'd love to require 
> std::format 
> and std::source_location, but those don't seem to be ready in the proposed 
> versions above.
> 
> For this, I'd also like to request we raise our minimum compiler versions to:
> * GCC 10 (released May 2020)
> * Clang 10 (released March 2020)
> * MSVC 2022 that is current today
> * XCode that is current today
> 
> Clang and GCC will be, at the time of Qt 6.7's release, just under 4 years 
> old. That should be enough to have been included in any long-term support 
> Linux distribution. Currently, both SLE 15.4 and RHEL/RockyLinux 9 have GCC 
> 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian 
> will 
> probably release its next stable before Qt 6.7, though whether it'll still 
> upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum 
> of GCC 8 was of a lower age, at 2.5 years, so we could reasonably bump our 
> minimum GCC to 11 and still be 6 months more lenient. There are no new 
> features in GCC 11 that we could use without also requiring a more recent 
> Clang.
> 
> Speaking of Clang, I simply chose a contemporaneous version and one that had 
> a 
> similar feature list. FreeBSD 13-STABLE (13.2) comes with Clang 14, which is 
> much newer. We could raise the minimum if we wanted, but the intersection of 
> features with GCC 10 or 11 doesn't change much; we get std::bit_cast with 
> Clang/libc++ 14, but that's about it.
> 
> This proposal also drops MSVC 2019 and assumes that users of 2022, like 
> XCode, 
> keep their compilers reasonably up-to-date. That is, that they'll update to 
> the latest at least once in the next 10 months.
> 
> I don't have access to QNX and INTEGRITY toolchain information, so I'd like 
> to 
> request that they simply match the feature list above, with minimal 
> workarounds.
> 
> Opinions?
> -- 
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Cloud Software Architect - Intel DCAI Cloud Engineering


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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Wednesday, 3 May 2023 05:59:26 PDT Vladimir Minenko via Development wrote:
> “…1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
> 2. C++20 is required for the development of Qt itself -
> https://bugreports.qt.io/browse/QTBUG-109361

Which stage are we in? I think we're before 1.

I'd propose we move to #1 immediately, for 6.6: we build with C++20 if the 
compiler supports C++20.

See also https://codereview.qt-project.org/c/qt/qtbase/+/463425

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


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

Re: [Development] Raising the minimum to C++20

[Thiago Macieira]

On Tuesday, 2 May 2023 23:16:19 PDT Marc Mutz via Development wrote:
> [1] I also heard the idea to make C++20 mandatory for building Qt, but
> user projects could continue to use C++17. That would require _forward_
> binary compatibility between stdlib implementations. Given that a C++20
> stdlib must needs contain more symbols (C++20-only features), it's
> almost guaranteed that forward BC isn't maintained by stdlibs.

I don't see that as a conclusion.

The library is the library. Whether you've compiled as C++14, 17, 20 or 23 
before linking to it is immaterial. What matters is the symbols it provides 
and the Standard Libraries must, by necessity, offer all the symbols that any 
compilation of their headers would require.

Upping our build requirements would allow us to offer symbols in our libraries 
that could only be accessed by code compiled under C++20. Right now, we can't 
do that and we must provide certain workarounds.

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


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

Re: [Development] About the timeline and phases to support C++20 with and in Qt

[Volker Hilsheimer via Development]

Bumping this thread up in your inboxes as it includes the links to the JIRA 
tickets where the journey towards C++20 has been planned and discussed so far. 
Let's try to build on what we already know.

The standing proposal is to move to C++20 with Qt 6.9, after the next LTS 
release. I see no pressing reasons to accelerate that. The value of the 
features Thiago listed - which excludes all the big stuff anyway - doesn’t seem 
so significant that it outweighs the impact on the community of users that are 
stuck on C++17, for a variety of reasons that we can’t just shrug off.

However, C++23 adds a bunch of improvements, and perhaps it’s a much smaller 
challenge for compiler vendors to support after C++20. If we stick to the 
timeline of making a disruptive C++ version move with Qt 6.9 in H1/2025, then 
perhaps we should skip C++20 and immediately require C++23. People that can 
move to a C++20 toolchain in 2025 can perhaps just as well move to a C++23 
toolchain at that point. That needs more investigation, of course. But given 
the inevitable pain that comes with changing minimum requirements, moving to a 
standard that is already 5 years old seems a bit wasteful.


Volker



> On 21 Dec 2022, at 18:51, Vladimir Minenko via Development 
>  wrote:
> 
> Hello all,
> 
> I want to share on this mailing list a proposal for the timeline and phases 
> to support C++20 with and in Qt. Writing this, I’m aware that there were 
> other discussions about the support of C++20 on this mailing list. This 
> message is a step to get a list of features that all Qt users can expect 
> along a certain timeline. We want to make the landing with the adoption of 
> new C++ standards “softer” than it used to happen in the past, yet prompt 
> enough to make sure that Qt keeps and enlarges its popularity among C++ 
> developers.
> 
> We got four user stories on Qt Bug Reports:
> 
> 1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
> 2. C++20 is required for the development of Qt itself - 
> https://bugreports.qt.io/browse/QTBUG-109361
> 3. C++20 is mandatory for users of Qt - 
> https://bugreports.qt.io/browse/QTBUG-109362
> 4. Long term: C++23, Qt7, and unsorted  - 
> https://bugreports.qt.io/browse/QTBUG-109363
> 
> These user stories are linked to selected features from the list once created 
> by Marc in https://bugreports.qt.io/browse/QTBUG-99243
> 
> The above list is sorted in the order of time. Still, a particular "Fix 
> Version” is not set yet. We (all) have to set this, though. ASAP for #1, and 
> by the time we ship the version set in #1, we should set the version for #2, 
> etc. See the list of all releases at 
> https://wiki.qt.io/QtReleasing#Qt_releases
> 
> In addition, there is a task https://bugreports.qt.io/browse/QTBUG-109469 to 
> add a new page or extend an existing page (Supported Platforms?) with details 
> about the support of C++ standards. Plus, we need to get a simple way to test 
> the capabilities of a toolchain, see 
> https://bugreports.qt.io/browse/QTBUG-109470.
> 
> The latter should be a help mainly for Qt users on embedded platforms. Those 
> folks have serious problems again and again with "fast moves” towards new C++ 
> standards since they do not have the luxury of quick updates of compilers and 
> standard libraries as known on desktops.
> 
> Please have a look at the above issues, comment on Qt Bug Reports, and make 
> changes if applicable.
> 
> And now, the most important point ;-) - Merry Christmas and Happy New Year!
> 
> --
> Vladimir Minenko
> vladimir.mine...@qt.io
> +49 171 90 61 461
> 
> Senior Product Manager, Qt Foundation
> The Qt Company - https://qt.io
> 
> c/o Regus / Josephspitalstraße 15
> 80331 Munich, Germany
> 
> 
> 
> ___
> Development mailing list
> Development@qt-project.org
> https://lists.qt-project.org/listinfo/development

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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[Volker Hilsheimer via Development]

On 3 May 2023, at 15:21, Giuseppe D'Angelo via Development 
 wrote:

Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:
What started as an attempt to provide a few building blocks for making it 
easier to build asynchronous APIs taking any kind of callable (like 
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
longer journey to the core.
[1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2]https://codereview.qt-project.org/c/qt/qtbase/+/475168

A general problem here is whether we can provide this infrastructure as a 
public API. If I have a class of mine and want to provide convenience for 
connecting to slots/callables, how do I do it without using private APIs? In Qt 
4 days that was a simple:

 void foo(..., QObject *receiver, const char *slot);

But it's not so simple/possible any more with the PMF syntax.


Indeed, if we assume that functions-taking-callables are a part of the tools we 
want to use to make more Qt APIs asynchronous, then it’s important that we 
enable other Qt-based libraries to build such APIs as well. One aspect to think 
about is then to make sure that the respective APIs fail early and with good 
error messages when called with incompatible functors etc. For that, I’d rather 
add a library of concepts than making our current predicates and private 
helpers public.

So yes! Ultimately I’d like to provide the required building-blocks as public 
APIs. These changes are a step into that direction, I hope. The plumbing 
required to then correctly make the call to the callable in the right thread is 
still significant, but see also 
https://codereview.qt-project.org/c/qt/qtbase/+/469799 for another small step, 
and Fabian has some ideas about how we could inject a QMetaCallEvent into the 
event loop of the correct thread (without having to create a temporary receiver 
QObject).

Volker

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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[Giuseppe D'Angelo via Development]

Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto:


What started as an attempt to provide a few building blocks for making it 
easier to build asynchronous APIs taking any kind of callable (like 
QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a 
longer journey to the core.

[1]https://codereview.qt-project.org/c/qt/qtbase/+/470341
[2]https://codereview.qt-project.org/c/qt/qtbase/+/475168


A general problem here is whether we can provide this infrastructure as 
a public API. If I have a class of mine and want to provide convenience 
for connecting to slots/callables, how do I do it without using private 
APIs? In Qt 4 days that was a simple:


  void foo(..., QObject *receiver, const char *slot);

But it's not so simple/possible any more with the PMF syntax.

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: Firma crittografica S/MIME
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising the minimum to C++20

[Vladimir Minenko via Development]

Hello all,

on this occasion, I would like to call the Qt Development community for 
conscious and pragmatic decisions when it comes to changes in the "minimum C++ 
standard”.

For some reason, Qt became known to do these switches on some “surprising" 
basis. I recall well as a colleague was leaving the office in frustration some 
day in 2016 and saying, “I now need a break”, just because he installed Qt 
5.7.0 (C++11) and realized that his (large) project does not compile anymore, 
out of sudden and without any notice in advance. We cannot change how things 
happened in 5.7 or 6.0 (C++17), but we can make it better in the future.

On Dec 21st last year, I sent an email to this list with the subject "About the 
timeline and phases to support C++20 with and in Qt”:

https://www.mail-archive.com/development@qt-project.org/msg42196.html

This email also refers to related issues on Qt Bug Reports to the roadmap and 
plans with C++20:

“…1. Use C++20 code with Qt - https://bugreports.qt.io/browse/QTBUG-109360
2. C++20 is required for the development of Qt itself -
https://bugreports.qt.io/browse/QTBUG-109361
3. C++20 is mandatory for users of Qt -
https://bugreports.qt.io/browse/QTBUG-109362
4. Long term: C++23, Qt7, and unsorted  -
https://bugreports.qt.io/browse/QTBUG-109363
…”

It would be great to have a coordinated and well-communicated migration this 
time. Please consider commenting or even co-working on these issues.

Just to leave a note for clarification for one topic mentioned below on this 
thread. A more conservative approach to mandating C++ standards is not only 
driven by the support of such “exotic” platforms like QNX or VxWorks, which 
might be slow following changes in desktop compilers. There are many regular Qt 
users who do not have the luxury of switching compilers or libc in their 
projects as often as they would like to. Plus, I got to know some really big Qt 
fans in embedded development using embedded Linux who, unfortunately, got stuck 
on some older BSPs. They feel being ignored in their concerns by developments 
in Qt, with Qt 6.0 and C++17 in particular, but they still need to get their 
jobs done and get products on the market. So please do not forget these folks!

Please correct me if I’m wrong, but I think, Qt can still use new compiler 
versions even if not mandating the latest C++ standard.

Greetings!

--
Vladimir

On 3. May 2023, at 08:58, Sune Vuorela  wrote:

On 2023-05-03, Thiago Macieira  wrote:
13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian will
probably release its next stable before Qt 6.7, though whether it'll still
upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum

Debian 12 "Bookworm" is planned for june 10th, and will be with gcc 12.

/Sune

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

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

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

[Uwe Rathmann]

Hi all,

> What started as an attempt to provide a few building blocks for 
making > it easier to build asynchronous APIs taking any kind of 
callable (like > QTimer::singleShot ...


Sorry for posting without checking your implemented solution:

one of the goals of my QSkinny ( https://github.com/uwerat/qskinny ) 
project is to allow more lightweight Qt/Quick applications. And one 
detail is about not having to create QObjects for simple callback 
situations.


It is quite some time ago ( ~2017 ), that I made that implementation but 
IIRC the main challenge was about identifying the callback parameters 
using meta template programming instead of having them from the signal 
signature. The rest is more or less given by the design of 
QtPrivate::QSlotObjectBase


It does not make the definition of functor callback APIs a no-brainer - 
but IMHO it is much better than what you would have to do without.


See: 
https://github.com/uwerat/qskinny/blob/master/src/common/QskMetaFunction.h


The implementation is heavily used for processing machine data in a 
commercial project ( avoiding >1K of QObjects ). Unfortunately I can't 
show it here - but there is at least one example how to build an API 
with it in QSkinny itself:


https://github.com/uwerat/qskinny/blob/master/src/controls/QskShortcutMap.h
https://github.com/uwerat/qskinny/blob/master/support/SkinnyShortcut.cpp

There is a small demo/test program available that does a bit more with 
this all: https://github.com/uwerat/qskinny/tree/master/playground/invoker


In case you find something of interest in my implementation: QSkinny 
code is BSD-3-Clause.


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

Re: [Development] Raising the minimum to C++20

[Sune Vuorela]

On 2023-05-03, Thiago Macieira  wrote:
> 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian 
> will 
> probably release its next stable before Qt 6.7, though whether it'll still 
> upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our minimum 

Debian 12 "Bookworm" is planned for june 10th, and will be with gcc 12.

/Sune

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

Re: [Development] Raising the minimum to C++20

[Allan Sandfeld Jensen]

Perhaps we should start by using C++20 by default if supported, and then later 
require it? It seems we are missing a step. 

Best regards
Allan


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

Re: [Development] Raising the minimum to C++20

[Marc Mutz via Development]

Hi Maurice,

On 03.05.23 08:01, Maurice Kalinowski wrote:
> Basically, the idea from our end has been to take a two-step approach by 
> first enabling every developer to use C++20 in their projects and potentially 
> add helpers/functionality where possible. Only at a later stage we can then 
> start using it in Qt itself. Vladimir Minenko has all the details, as he has 
> been laying out the rough plan with the foundation engineering.

This is the status quo. Qt users can use C++20 with all active Qt 
versions, incl. 5.15, but it's a best-effort thing atm, not something we 
check on the CI.

Having taken this first step, the next one is, indeed, to make C++20 
mandatory (for building Qt and therefore for using Qt[1]).

Thanks,
Marc

[1] I also heard the idea to make C++20 mandatory for building Qt, but 
user projects could continue to use C++17. That would require _forward_ 
binary compatibility between stdlib implementations. Given that a C++20 
stdlib must needs contain more symbols (C++20-only features), it's 
almost guaranteed that forward BC isn't maintained by stdlibs.

-- 
Marc Mutz 
Principal Software Engineer

The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
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] Raising the minimum to C++20

[Maurice Kalinowski via Development]

As Marc already mentioned, we are having troubles with users not being able to 
upgrade on various platforms.

We even have customers who are not able to upgrade to C++17 yet due to supply 
chain issues.

Basically, the idea from our end has been to take a two-step approach by first 
enabling every developer to use C++20 in their projects and potentially add 
helpers/functionality where possible. Only at a later stage we can then start 
using it in Qt itself. Vladimir Minenko has all the details, as he has been 
laying out the rough plan with the foundation engineering.

This certainly is a good topic for a contributor summit, to which extend we 
want to establish fixed rules for those types of upgrades.

BR,
Maurice


> -Original Message-
> From: Development  On Behalf Of
> Marc Mutz via Development
> Sent: Wednesday, 3 May 2023 07:51
> To: development@qt-project.org
> Subject: Re: [Development] Raising the minimum to C++20
> 
> Hi Thiago,
> 
> While I'd rather sooner than later see us switch to C++20, ever since
> 5.7, we have dropped supported compilers only after an LTS release (5.6,
> in that case).
> 
> Since I agree the train for 6.6 has left the station, as Integrity (and
> possibly QNX?) don't have an official C++20 offering, yet
> (https://ghs.com/products/compiler.html, IIRC, they're going to release
> one this year, but I don't know what features they're shooting for), I
> was assuming that 6.9 would be the next option.
> 
> Personally, I would support a break after 6.8. That's scheduled for
> release in summer/autumn 2024, and has three years LTS, so gives
> affected customers until autumn 2027 to update their tool-chains. By
> that time, C++26 will be out already.
> 
> Even that, within TQtC, is seen as too early by some. After all, we
> still support 5.15 and therefore C++11, in 2023. That's only because
> 5.15 is a VLTS release, though. TQtC could decide to make 6.8 such a
> VLTS release, too, if sufficient numbers of customer won't be able to
> upgrade to C++20 by 2027.
> 
>  From a maintenance POV, it should be easier to support a C++17-based
> VLTS release than one that's still stuck on C++11 (and doesn't actually
> test for compatibility with that version in the CI...).
> 
> Thanks,
> Marc
> 
> On 03.05.23 02:39, Thiago Macieira wrote:
> > C++23 is on the way, so maybe it's time for us to raise our minimum to the
> one
> > version before that. Let's aim for Qt 6.7, because feature-freeze for 6.6 is
> > within one month, and lets us warn our users this is coming.
> >
> > By this, I mean to:
> > * modify our build system so Qt compiles with -std=c++20 or equivalent
> > * require that user code compiling Qt headers be similarly done
> > * remove the requirement for #if checks for C++17 Standard Library features
> > * make a couple of C++20 features mandatory (see below)
> >
> > Of the C++20 features I currently see a good reason to make mandatory:
> > * feature-test macros (no change: we're already using them)
> > * spaceship operator and  header
> > * char8_t
> > * std::is_constant_evaluated()
> > * constinit
> > *  header
> > * (maybe) designated initialisers
> > * (maybe) constexpr from  and 
> >
> > I'm not proposing modules, concepts or coroutines be allowed in our code
> just
> > yet. I think concepts will be the first of those, but we need to understand
> how
> > to use them first and how our code will change. I'd love to require
> std::format
> > and std::source_location, but those don't seem to be ready in the proposed
> > versions above.
> >
> > For this, I'd also like to request we raise our minimum compiler versions 
> > to:
> > * GCC 10 (released May 2020)
> > * Clang 10 (released March 2020)
> > * MSVC 2022 that is current today
> > * XCode that is current today
> >
> > Clang and GCC will be, at the time of Qt 6.7's release, just under 4 years
> > old. That should be enough to have been included in any long-term support
> > Linux distribution. Currently, both SLE 15.4 and RHEL/RockyLinux 9 have GCC
> > 13, while Ubuntu 22.04 and Debian 11 (current stable) have GCC 11. Debian
> will
> > probably release its next stable before Qt 6.7, though whether it'll still
> > upgrade from GCC 12 to 13 I don't know. When we released Qt 6.0, our
> minimum
> > of GCC 8 was of a lower age, at 2.5 years, so we could reasonably bump our
> > minimum GCC to 11 and still be 6 months more lenient. There are no new
> > features in GCC 11 that we could use without also requiring a more recent
> > Clang.
> >
> > Speaking of Clang, I simply chose a contemporaneous version and one that
> had a
> > similar feature list. FreeBSD 13-STABLE (13.2) comes with Clang 14, which is
> > much newer. We could raise the minimum if we wanted, but the intersection
> of
> > features with GCC 10 or 11 doesn't change much; we get std::bit_cast with
> > Clang/libc++ 14, but that's about it.
> >
> > This proposal also drops MSVC 2019 and assumes that users of 2022, like
> XCode,
> > keep their compilers reasonably