Re: [Development] API style guide: scoped enum or not?
On 04.05.23 00:18, Thiago Macieira wrote: > 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? That's an additional step we can take, but if clang-tidy has a modernize-scope-enums (or we could write it), then it would be preferable to just automatically port all users instead of writing code that keeps unported code running. The main issue isn't the scoping, the main issue will be the missing implicit conversion to underlying_type. -- 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
On 04.05.23 00:39, Thiago Macieira wrote: > 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. Coroutines will put async APIs upside down. It's a pretty dramatic shift in how you write async code and Qt as a large provider of async APIs is going to be strongly affected. -- 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
On 04.05.23 08:52, Maurice Kalinowski via Development wrote: [...] > This is the situation we experience in multiple industries still, with an > increasing pressure from multiple angles to get those finally supporting Qt > 6. Hence, things are getting better for C++17 _now_. [...] This actually sounds like an argument for _earlier_ adoption. If Qt, as an important component in the ecosystem, slows the pace, then OEMs feel even less pressure to update their toolchains, making the problem worse for the industry at large. The main problem I have with this line of reasoning is that I think it's the LTS's job to serve those customers that end up in these situations. So it's not like those customer's can't use Qt, they just can't use the latest features. But they can't, anyway, because they have such an old toolchain. I wonder how much of this is customer' requests and how much of it our desire to move customers off Qt 5? One way to skin this particular cat would be to keep non-core modules compatible with the last LTS to give users access to newer features in those modules without having to update tool-chains. Realistically, most of the bang we get from a C++20 requirement is in QtBase and, possibly, QtDeclarative. IIUC, we do this for some part of qtdeclarative and for qtwebengine already, and, while it's occasionally annoying, it lets us eat our own dog-food, too. Speaking with the tongue of the Qt OSS project, I fail to see how all this isn't SEP. Users of such OEM boards have several ways to solve the problem: - pressure the OEM to support a six-year-old C++ standard - pay someone (TQtC, KDAB) to build a newer toolchain on top of the old one, or do in-house - vote with your feet and switch to an OEM that has a better customer service Playing the devil's advocate: What's Qt got to do with this? Thanks, Marc PS: doesn't chromium now require C++20, too? How are we going to deal with another 5 years¹ of C++17 if a critical 3rd-party component, too huge for us to maintain ourselves, uses its clang-tooling foo to modernize every aspect of its code base w.r.t. C++20 idioms? ¹ Qt 6.8 release² in Mar '25 + 3yr support = Mar '28. ² dev qwebengine maintains compat with the last LTS -- 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
On 04.05.23 00:24, Thiago Macieira wrote: > 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. Ah, now I understand. You assume that a C++20 build will use the same DLL/SO/DYNLIB stdlib that a C++17 build will use, all else being equal. That may be the case, and, for the major platforms, that may even be probable, but personally, I wouldn't bet the house on it for embedded platforms. But yeah, that's something that can be checked, and would probably¹ enable said use-case. Thanks, Marc ¹ I say "probably" because history shows that our wholesale exporting of non-polymorphic classes will find a way to break this in corner-cases, I'm sure. -- 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?
Hi Thiago This is introducing dependencies on code which makes dependency breaking much harder. I very often need an enumeration in an interface but not the class itself. There are ways to get around that but it makes TDD harder if Qt is involved. From: Development on behalf of Thiago Macieira Sent: Thursday, May 4, 2023 0:17 To: development@qt-project.org Subject: Re: [Development] API style guide: scoped enum or not? 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 -- 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 (3 May 2023 19:20) wrote: > I don't see us adopting Modules any time soon, not even for the 6.9 > release. It's not well supported *today*. Also, they're a radical change to how source is organised and it "might not be a bad idea" to wait until the C++ world has developed some common practices in how to use them, and maybe even some best practices, so that however we go about using them can conform to the latter as far as is compatible with the former. That won't happen until support has been commonplace for long enough for (preferably other) people to make the mistakes that will establish the antipatterns that will inform the development of both common and best practices. Eddy. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Nominating Edward Welbourne as QLocale / date/time maintainer
Hi, I'd like to nominate Eddy as the maintainer for the QLocale and src/corelib/time QtCore subsystems. Eddy is filling that role de-facto already; making it de-jure sounds only logical. I asked, and he'd be on board, if we'd have him. Anyone else in favour? (I'm not sure I have a vote, actually...) 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] Nominating Edward Welbourne as QLocale / date/time maintainer
A very warm and happy +1 Von: Development im Auftrag von Marc Mutz via Development Gesendet: Donnerstag, 4. Mai 2023 12:10 An: development@qt-project.org Betreff: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer Hi, I'd like to nominate Eddy as the maintainer for the QLocale and src/corelib/time QtCore subsystems. Eddy is filling that role de-facto already; making it de-jure sounds only logical. I asked, and he'd be on board, if we'd have him. Anyone else in favour? (I'm not sure I have a vote, actually...) 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
+1! > On 4 May 2023, at 12:10, Marc Mutz via Development > wrote: > > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually...) > > 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
> On 4 May 2023, at 12:10, Marc Mutz via Development > wrote: > > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually…) +1 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
Il 04/05/23 12:10, Marc Mutz via Development ha scritto: Hi, I'd like to nominate Eddy as the maintainer for the QLocale and src/corelib/time QtCore subsystems. Eddy is filling that role de-facto already; making it de-jure sounds only logical. I asked, and he'd be on board, if we'd have him. Anyone else in favour? (I'm not sure I have a vote, actually...) I'm just an approver so I'm not sure either -- but in case it's a very convinced +1. 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] Nominating Edward Welbourne as QLocale / date/time maintainer
+1 From: Development on behalf of Giuseppe D'Angelo via Development Sent: Thursday, May 4, 2023 1:03 PM To: development@qt-project.org Subject: Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer Il 04/05/23 12:10, Marc Mutz via Development ha scritto: > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually...) I'm just an approver so I'm not sure either -- but in case it's a very convinced +1. 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
+1 He’s been doing that job without the title for years already :) Cheers, Lars > On 4 May 2023, at 12:10, Marc Mutz via Development > wrote: > > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually...) > > 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
+1 :) Mårten > -Original Message- > From: Development On Behalf Of > Marc Mutz via Development > Sent: torsdag 4. mai 2023 12:10 > To: development@qt-project.org > Subject: [Development] Nominating Edward Welbourne as QLocale / > date/time maintainer > > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually...) > > 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 -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
> On 4 May 2023, at 12:10, Marc Mutz via Development > wrote: > > Hi, > > I'd like to nominate Eddy as the maintainer for the QLocale and > src/corelib/time QtCore subsystems. Eddy is filling that role de-facto > already; making it de-jure sounds only logical. > > I asked, and he'd be on board, if we'd have him. > > Anyone else in favour? (I'm not sure I have a vote, actually…) Absolutely +1. It’s not a separate item today, but it’s plenty of code, and it requires very deep understanding of the domain, and of the various system APIs and libraries. So it’s a good idea to break it out of the rest of Qt Core, and Eddy is already doing the work. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer
+1 He's doing a great job. -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
> On 3 May 2023, at 18:40, Giuseppe D'Angelo via Development > wrote: >> 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.) Some concepts are abstract enough to be ubiquitous. On/Off, true/false. Horizontal and Vertical are IMHO implicitly clear. What it refers to is not clear anyway unless you see the code that uses the enum. I can make a slider or a layout or a text horizontal or vertical, and it’s IMHO obvious what calls to textLayout->setOrientation(Qt::Horizontal); slider->setOrientation(Qt::Vertical); are doing. The word “Orientation” in the enum itself adds no value. Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or QSlider::Orientation::Horizontal? I do think that these are the exceptions though. Cheers, Volker -- 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
> On 3 May 2023, at 19:20, Thiago Macieira wrote: > On Wednesday, 3 May 2023 08:56:07 PDT Volker Hilsheimer via Development wrote: >> 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. My thinking and assumption is: those users that don't upgrade their toolchain to something recent are also (typically) the users that stay on the latest LTS release. That will be Qt 6.8; what we do in 6.9 and 6.10 and until 6.11 LTS is of limited interest to those users. The C++ standard is just one aspect to this. But those that can and do upgrade their toolchain regularly might just as well upgrade to something fairly recent whenever they do that. Between 6.8 branching (the last LTS only requiring C++17, as per current plan) and 6.11 (the next LTS after that, if we stick to the current cadence), we and compiler vendors have another 18 months to work on the C++23 feature set. Why would we not want to start using some C++23 features with 6.11 (in H1/26, presumably)? Even if it’s only a subset of the standard - what we document is the compiler versions we support, and we have to limit ourselves mostly to the common denominator anyway. For non-LTS releases (or the first after the LTS, i.e. 6.9), we might want to bump the minimum compiler versions to something that's not older than 18 months (we can argue over that), and we stick to those versions until the following LTS release, one year later. And assuming that by H1/2025 there is a common subset of the C++23 standard that all compilers support, why would we not use those features? Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
On 2023-05-04, Marc Mutz via Development wrote:
> that keeps unported code running. The main issue isn't the scoping, the
> main issue will be the missing implicit conversion to underlying_type.
In few cases the implicit conversion to underlying_type is kind of important.
Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.
Qt::ItemDataRole is one of them that comes to mind.
switch(role) {
case Qt::UserRole+1:
QEvent::Type is another one where one registerEventType, recieves an int
and then force-cast it to QEvent::Type and still compares back to that
int in other places.
There are definitely more.
/Sune
--
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
On 3 May 2023, at 19:32, A. Pönitz wrote: 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 &continuation) does a sufficiently good job over here. That helps with specific cases, but for the general-purpose library APIs that have the flexibility we are used to in and from Qt, you need to cover when - continuation is a member function of guard (and then guard has to be the right type, which should be enforced at compile time) - guard lives in a different thread - guard is destroyed by the time you call continuation And you have to make things work with move-only functors and mutable lambdas. Getting all of that right was never particularly easy with a string-based syntax either though. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On Thursday, 4 May 2023 00:52:47 PDT Marc Mutz via Development wrote: > On 04.05.23 00:39, Thiago Macieira wrote: > > 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. > > Coroutines will put async APIs upside down. It's a pretty dramatic shift > in how you write async code and Qt as a large provider of async APIs is > going to be strongly affected. I'd like to see that. But "strongly affected" implies a major change to our code and API, which implies a major exploration phase. We can barely start doing that now. We need to start working with C++20 so we could try this, and preferably not lump all the big changes in one release either. -- 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
On Thursday, 4 May 2023 06:48:55 PDT Volker Hilsheimer via Development wrote: > But those that can and do upgrade their toolchain regularly might just as > well upgrade to something fairly recent whenever they do that. Between 6.8 > branching (the last LTS only requiring C++17, as per current plan) and 6.11 > (the next LTS after that, if we stick to the current cadence), we and > compiler vendors have another 18 months to work on the C++23 feature set. > Why would we not want to start using some C++23 features with 6.11 (in > H1/26, presumably)? Even if it’s only a subset of the standard - what we > document is the compiler versions we support, and we have to limit > ourselves mostly to the common denominator anyway. Because I'm being told in the same breath that "4-year-old compilers are too recent" when the C++20 update in March 2024 and LTS in September 2024 is not acceptable. Therefore, for a release in March 2025 and LTS in March 2026, requiring compilers released in 2023 is too recent too. Please give me a number: how old must a compiler be for it to be acceptable to require compilers to have updated to it or more recent than it? We could use C++23 features in 2025 that were supported in 2020 compilers. I'm just arguing that there aren't any that are worth the trouble. -- 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?
On Thursday, 4 May 2023 00:58:52 PDT Marco Bubke via Development wrote: > This is introducing dependencies on code which makes dependency breaking > much harder. I very often need an enumeration in an interface but not the > class itself. There are ways to get around that but it makes TDD harder if > Qt is involved. That's a good point, but it's a bigger change to our style guide than "to class or not to class". Requesting that we design our enumerations outside of any class/struct is a big change. -- 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?
On 04.05.23 15:51, Sune Vuorela wrote:
> On 2023-05-04, Marc Mutz via Development wrote:
>> that keeps unported code running. The main issue isn't the scoping, the
>> main issue will be the missing implicit conversion to underlying_type.
>
> In few cases the implicit conversion to underlying_type is kind of important.
>
> Especially in the cases where the api has int and is mostly used with
> enums or is somehow user extendable.
>
> Qt::ItemDataRole is one of them that comes to mind.
>
> switch(role) {
> case Qt::UserRole+1:
>
>
> QEvent::Type is another one where one registerEventType, recieves an int
> and then force-cast it to QEvent::Type and still compares back to that
> int in other places.
The int is the problem, not the enum. With C++17, scoped enums have a
kind of explicit ctor from underlying_type, so at least that direction
is reasonably convenient. For the other direction, there's
std::to_underlying/qToUndelying().
So, enum-backed APIs taking int will have to be ported to take the enum
instead. On the plus side, you get type-richer and safer APIs.
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?
On 04.05.23 15:38, Volker Hilsheimer via Development wrote: > Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or > QSlider::Orientation::Horizontal? Without looking at the docs, tell me what QSplitterHandle::orientation() means :) -- 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?
Il 04/05/23 15:51, Sune Vuorela ha scritto:
On 2023-05-04, Marc Mutz via Development wrote:
that keeps unported code running. The main issue isn't the scoping, the
main issue will be the missing implicit conversion to underlying_type.
In few cases the implicit conversion to underlying_type is kind of important.
Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.
Qt::ItemDataRole is one of them that comes to mind.
switch(role) {
case Qt::UserRole+1:
QEvent::Type is another one where one registerEventType, recieves an int
and then force-cast it to QEvent::Type and still compares back to that
int in other places.
There are definitely more.
There's little reason why registerEventType returns `int` and not
QEvent::Type, by the way. Model roles could become scoped enumerations,
which can be explicitly constructed from integers (all of this just to
retain the switch()-ability -- otherwise a model role should be
represented by a wrapper type around integers. Certainly not be kept as
a plain int).
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] API style guide: scoped enum or not?
> On 4 May 2023, at 17:34, Marc Mutz via Development > wrote: > > On 04.05.23 15:38, Volker Hilsheimer via Development wrote: >> Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or >> QSlider::Orientation::Horizontal? > > Without looking at the docs, tell me what QSplitterHandle::orientation() > means :) The same that it would mean if it would return Qt::Orientation::Horizontal or Qt::HorizontalOrientation :) I’m guessing: whether the handle gets dragged horizontally or vertically, ie the opposite of what one would expect (whether the handle is v horizontal or vertical line). In which case the problem is the name of the property not of the enum type. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
Il 04/05/23 09:10, Marc Mutz via Development ha scritto: With the same trick that C++20 did for std::memory_order? That's an additional step we can take, but if clang-tidy has a modernize-scope-enums (or we could write it), then it would be preferable to just automatically port all users instead of writing code that keeps unported code running. The main issue isn't the scoping, the main issue will be the missing implicit conversion to underlying_type. A few remarks: * I think it's pretty optimistic to assume that people can/will use clang-based tooling on their codebases. * This doesn't cope with an unspecified amount of other code -- thinking of .ui files, DBus XML interfaces, other serializations (QVariant?), etc. -- where the enumerators are currently written unscoped. We'd need a bunch of extra tools to fix all of that. * Something doable in Qt 6 already: we need a QFlagsV2 that works across multiple enumerations (and that can use 8/16/32/64 bits, while at it), because we *still* have int-based APIs where one has to mix values from two or more enumerators. 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] API style guide: scoped enum or not?
>> On 4 May 2023, at 17:34, Marc Mutz via Development >> wrote: >> >> On 04.05.23 15:38, Volker Hilsheimer via Development wrote: >>> Should we have Qt::TextLayout::Horizontal and Qt::Layout::Horizontal? Or >>> QSlider::Orientation::Horizontal? >> >> Without looking at the docs, tell me what QSplitterHandle::orientation() >> means :) > > The same that it would mean if it would return Qt::Orientation::Horizontal or > Qt::HorizontalOrientation :) > > I’m guessing: whether the handle gets dragged horizontally or vertically, ie > the opposite of what one would expect (whether the handle is v horizontal or > vertical line). In which case the problem is the name of the property not of > the enum type. I remember that couple of years ago Eike did a pool on how name actions regarding horizontal and vertical splitting inside QtCreator. So, for some, the "horizontal" means that they want to see a horizontal splitter bar after the split, and for others it means that they want to see horizontally arranged editors (from left to right). The outcome was that we have now "Split" and "Split Side by Side" actions. Jarek -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
On 04/05/2023 15:51, Sune Vuorela wrote:
On 2023-05-04, Marc Mutz via Development wrote:
that keeps unported code running. The main issue isn't the scoping, the
main issue will be the missing implicit conversion to underlying_type.
In few cases the implicit conversion to underlying_type is kind of important.
Especially in the cases where the api has int and is mostly used with
enums or is somehow user extendable.
Qt::ItemDataRole is one of them that comes to mind.
switch(role) {
case Qt::UserRole+1:
First of all, the use of Qt::UserRole+1 isn't really good practice.
Define your roles in a scoped enum. For this use case, we have been
using this little trick:
// Tool to convert class enum value to underlying type for easier use
template
constexpr typename std::underlying_type::type operator+(const E &e)
{
return static_cast::type>(e);
}
Now, we can write the switch like this:
switch (role) {
case +Roles::Name: //...
case +Roles::Age: //...
Of course, you can also do:
switch (static_cast(int)) {
case Roles::Name: //...
case Roles::Age: //...
But AFAIK, now you need to make sure the int value actually is in the
enum first to make that safe.
Cheers,
André
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
On 03/05/2023 21:42, Marc Mutz via Development wrote:
On 03.05.23 20:06, A. Pönitz wrote:
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...)
There is a pretty straight-forward migration path (and I'm sure that
clang-tidy has an automatic transformation already):
For amy unscoped
enum E { A, B, C, };
you can, since C++11, write
E::A, E::B, E::C
This rewrite is an automatable task, and, once done, we can make E
scoped, and just have to deal with (desired) fallout of the missing
implicit conversion to underlying_type.
So if your problem is consistency, then just scope the unscoped
enumerators in your code as if they were scoped.
Other fallout would be that currently A, B, and C will most often
include E in their name. That makes for the code becoming
E::EA, E::EB, E::EC or E::AE, E::BE, E::CE. I don't like that. Do you
think there also is tooling to go to a renamed version w/o the enum
name? Or would it be feasible to add such tooling?
Cheers,
André
Thanks,
Marc
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] API style guide: scoped enum or not?
On 04.05.23 19:35, André Somers wrote: [...] > Other fallout would be that currently A, B, and C will most often > include E in their name. That makes for the code becoming > > E::EA, E::EB, E::EC or E::AE, E::BE, E::CE. I don't like that. Do you > think there also is tooling to go to a renamed version w/o the enum > name? Or would it be feasible to add such tooling? Since the rename is specific to the enum at hand, there's no hope that such tooling exists today. However, simple semantic symbol replacement is an easy thing to implement in clang-tidy, yes. That could be accompanied by Thiago's memory_order trick and Q_DECL_DEPRECATED. 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?
On Thursday, 4 May 2023 21:43:01 PDT Marc Mutz via Development wrote: > Since the rename is specific to the enum at hand, there's no hope that > such tooling exists today. However, simple semantic symbol replacement > is an easy thing to implement in clang-tidy, yes. That could be > accompanied by Thiago's memory_order trick and Q_DECL_DEPRECATED. This should be doable right now for the Qt namespace. But I don't think it should be automated. Instead, we need to put some thought into the new names. For the majority of them, we can probably remove the noun that is part of the name (Qt::MouseButton::LeftButton → Qt::MouseButton::Left), but sometimes the change isn't obvious. We can also fix historical mistakes, like the colour names in Qt::GlobalColor being lowercase. Some of them won't work for other reasons, like Qt::Key_I can't become Qt::Key::I because the identifier I is defined in as a macro for the imaginary unit[1] (this shouldn't affect C++, but broken implementations exist). There are also enums that may serve multiple purposes, like the enumerator Qt::KeepEmptyParts. Right now, it's part of SplitBehavior, but it could just as well be used for joining. Or not, see [2] for discussion. And there are all the flags. For the vast majority of them, the only documented name is the QFlags typedef. For those whose QFlags typedef is just the plural of the enum, code like this is probably acceptable: Qt::Edges edges = Qt::Edge::Top | Qt::Edge::Left; But for those that use a very name, the API becomes cumbersome: Qt::Alignment al = Qt::AlignmentFlag::Left; Can we do better? With C++20 using enum (GCC 11, Clang 13, so not in my proposal) we could easily. [1] https://en.cppreference.com/w/c/numeric/complex/I [2] https://codereview.qt-project.org/c/qt/qtbase/+/471246?usp=email -- 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?
On Thursday, 4 May 2023 22:28:44 PDT Thiago Macieira wrote: > But for those that use a very name, the API becomes cumbersome: > > Qt::Alignment al = Qt::AlignmentFlag::Left; > > Can we do better? With C++20 using enum (GCC 11, Clang 13, so not in my > proposal) we could easily. Actually, we can leave that as an optional feature for GCC 10 and Clang 10, if we choose those as our minima. We wouldn't be able to use the used enumerations in our code until the feature became mandatory, but users whose compilers do support the feature could use it. https://codereview.qt-project.org/c/qt/qtbase/+/476084 -- 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?
On Thursday, 4 May 2023 22:48:44 PDT Thiago Macieira wrote: > On Thursday, 4 May 2023 22:28:44 PDT Thiago Macieira wrote: > > But for those that use a very name, the API becomes cumbersome: > > Qt::Alignment al = Qt::AlignmentFlag::Left; > > > > Can we do better? With C++20 using enum (GCC 11, Clang 13, so not in my > > proposal) we could easily. > > Actually, we can leave that as an optional feature for GCC 10 and Clang 10, > if we choose those as our minima. We wouldn't be able to use the used > enumerations in our code until the feature became mandatory, but users > whose compilers do support the feature could use it. > > https://codereview.qt-project.org/c/qt/qtbase/+/476084 Scratch that. This doesn't work and I don't know why: https://gcc.godbolt.org/z/6jf7Ebecq Looks like the using enum feature is not very useful for us. Back to the drawing board for scoped flags. -- 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
> On 04.05.23 08:52, Maurice Kalinowski via Development wrote: > [...] > > This is the situation we experience in multiple industries still, with an > increasing pressure from multiple angles to get those finally supporting Qt 6. > Hence, things are getting better for C++17 _now_. > [...] > > This actually sounds like an argument for _earlier_ adoption. If Qt, as > an important component in the ecosystem, slows the pace, then OEMs feel > even less pressure to update their toolchains, making the problem worse > for the industry at large. > > The main problem I have with this line of reasoning is that I think it's > the LTS's job to serve those customers that end up in these situations. > So it's not like those customer's can't use Qt, they just can't use the > latest features. But they can't, anyway, because they have such an old > toolchain. I wonder how much of this is customer' requests and how much > of it our desire to move customers off Qt 5? > [Maurice Kalinowski] I don't agree that Qt is slowing it, we are one of the drivers to accelerate. As I said, there are multiple players in this context, Qt being one of them. When we said that we are going to require C++17 for Qt 6, that caused a lot of concerns, as at the time of the announcement not all OS had support for it, the hardware vendors did not even start adding it, over players in this chain were unprepared as well. On the other end of the spectrum we had users, who wanted to use new functionality, but knew it is going to take time until they finally can. Again, we as Qt have been pushing, but things move slowly. > One way to skin this particular cat would be to keep non-core modules > compatible with the last LTS to give users access to newer features in > those modules without having to update tool-chains. Realistically, most > of the bang we get from a C++20 requirement is in QtBase and, possibly, > QtDeclarative. IIUC, we do this for some part of qtdeclarative and for > qtwebengine already, and, while it's occasionally annoying, it lets us > eat our own dog-food, too. [Maurice Kalinowski] Compatibility of LTS to non-LTS, or how to do versioned released of individual modules is an orthogonal discussion. I think we should not mix those, even though I am a fan of that idea personally. But the release team (amongst others) would hate me for that :) > > Speaking with the tongue of the Qt OSS project, I fail to see how all > this isn't SEP. Users of such OEM boards have several ways to solve the > problem: > - pressure the OEM to support a six-year-old C++ standard [Maurice Kalinowski] You might be mixing OEM with other players. OEMs (the people shipping devices in any shape or form) would love to use latest features as well. They get their BSPs from Tier1 who then get the base BSP from hardware/chipsetvendor who then... > - pay someone (TQtC, KDAB) to build a newer toolchain on top of the old > one, or do in-house [Maurice Kalinowski] In non-regulated industries that is one option, yes. We also checked whether we could be shipping those in parallel. It works for prototyping and potentially development phase, but not for getting approval to ship your device. > - vote with your feet and switch to an OEM that has a better customer > service [Maurice Kalinowski] Again, mixing terminology and unfortunately Qt is only one item in the whole decision process. Maurice -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
