> 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_.
> [...]
>
> Th
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, C
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 ca
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
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
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
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 ki
>> 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 QSp
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
> 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 QSplitt
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
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
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
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
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)
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
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 A
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 case
> 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
>> timelin
> 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.
+1
He's doing a great job.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
> 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 b
+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 Ed
+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
+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 Dev
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.
A
> 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 bo
+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 o
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 nomi
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, actual
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 comm
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: Develop
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 ven
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
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 experiment
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
36 matches
Mail list logo
