Il 14/06/23 14:59, Marc Mutz via Development ha scritto:
A) new enums MUST have an explicit underlying type¹²
For unscoped enums, the compiler otherwise picks one, possibly resulting
in BiC when new addtions change the underlying type or otherwise just
warnings because one compiler uses a
On 14.06.23 14:59, Marc Mutz via Development wrote:
> A) new enums MUST have an explicit underlying type¹²
It's actually worse. In the 6.6 header review, several enums add
enumerators that cross a power-of-two boundary, one even crosses 2⁸.
The C++ standard give compilers a lot of leeway in
I'm technically not a maintainer of either QtQml or QtQuick, but I think
I'm qualified to chime in here:
QML has (slightly hidden in
https://doc.qt.io/qt-6/qtqml-cppintegration-data.html#enumeration-types)
a way to disable this behavior by setting
Q_CLASSINFO("RegisterEnumClassesUnscoped",
> On 14 Jun 2023, at 14:59, Marc Mutz via Development
> wrote:
[…]
> C) scoped enums SHOULD NOT repeat (part of) an enum's type name in the
> enumerators²
[…]
> I have been told today that QML allows scoped C++ enums to be used
> without the scope. If this is true, it should be fixed to
On Friday, 16 June 2023 01:04:30 PDT Stephen Kelly wrote:
> >> https://godbolt.org/z/4EWjWhvfa
> >
> > That's the "massive code update and can't be helped with macros" I
> > mentioned in my other email.
>
> Are you talking about the type of the oopsLostType variable?
No, I'm talking about
On 15/06/2023 23:34, Thiago Macieira wrote:
On Thursday, 15 June 2023 15:23:47 PDT Stephen Kelly wrote:
And, you can introduce it in a way which is source-compatible until the
user upgrades their compiler to a compiler version which implements
`using enum`:
https://godbolt.org/z/4EWjWhvfa
On Thursday, 15 June 2023 15:23:47 PDT Stephen Kelly wrote:
> And, you can introduce it in a way which is source-compatible until the
> user upgrades their compiler to a compiler version which implements
> `using enum`:
>
> https://godbolt.org/z/4EWjWhvfa
That's the "massive code update and
On 15/06/2023 22:20, Allan Sandfeld Jensen wrote:
On Mittwoch, 14. Juni 2023 22:53:13 CEST Thiago Macieira wrote:
On Wednesday, 14 June 2023 12:49:22 PDT Allan Sandfeld Jensen wrote:
As discussed earlier. Better naming in many cases until we can depend on
C++20 in API.
There's nothing in
On Mittwoch, 14. Juni 2023 22:53:13 CEST Thiago Macieira wrote:
> On Wednesday, 14 June 2023 12:49:22 PDT Allan Sandfeld Jensen wrote:
> > As discussed earlier. Better naming in many cases until we can depend on
> > C++20 in API.
>
> There's nothing in C++20 that would allow us to design APIs
Am 04.05.2023 um 15:51 schrieb Sune Vuorela:
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.
On Wednesday, 14 June 2023 14:26:52 PDT Giuseppe D'Angelo via Development
wrote:
> I think this should be a completely different question than the usage of
> scoped enums in new code. For instance, I'm all for scoped enums and
> against such refactoring.
The refactoring *could* be done now, but
Il 14/06/23 22:15, Volker Hilsheimer via Development ha scritto:
-1 to B from me as well.
We can allow unscoped enum as an acceptable (if explained) exception from the
rule of using scoped enums. Otherwise we remove a tool from our toolbox, even
if it has it’s uses in certain (increasingly
On Wednesday, 14 June 2023 12:49:22 PDT Allan Sandfeld Jensen wrote:
> As discussed earlier. Better naming in many cases until we can depend on
> C++20 in API.
There's nothing in C++20 that would allow us to design APIs differently.
You may be thinking of C++23 "using enum" feature, which is
+1 to A and C.
> On 14 Jun 2023, at 21:49, Allan Sandfeld Jensen wrote:
>
> On Mittwoch, 14. Juni 2023 17:48:27 CEST Thiago Macieira wrote:
>> On Wednesday, 14 June 2023 08:35:16 PDT Marc Mutz via Development wrote:
>> B) new enums MUST be scoped, also when nested in classes¹²
>
>
On Mittwoch, 14. Juni 2023 17:48:27 CEST Thiago Macieira wrote:
> On Wednesday, 14 June 2023 08:35:16 PDT Marc Mutz via Development wrote:
> > >>> B) new enums MUST be scoped, also when nested in classes¹²
> > >>
> > >> -1 Disagree
> > >
> > > -1 Disagree
> >
> > Ok. But _why_? (Q to both)
>
>
> On 14 Jun 2023, at 17:48, Thiago Macieira wrote:
>
> On Wednesday, 14 June 2023 08:35:16 PDT Marc Mutz via Development wrote:
> B) new enums MUST be scoped, also when nested in classes¹²
-1 Disagree
>>>
>>> -1 Disagree
>>
>> Ok. But _why_? (Q to both)
>
> I'm inclined to
On Wednesday, 14 June 2023 08:35:16 PDT Marc Mutz via Development wrote:
> >>> B) new enums MUST be scoped, also when nested in classes¹²
> >>
> >> -1 Disagree
> >
> > -1 Disagree
>
> Ok. But _why_? (Q to both)
I'm inclined to agree with (B), so I'd like to understand the objections.
--
On 14.06.23 16:33, Tor Arne Vestbø via Development wrote:
>> On 14 Jun 2023, at 16:20, Allan Sandfeld Jensen wrote:
[...]
>>> B) new enums MUST be scoped, also when nested in classes¹²
>> -1 Disagree
>
> -1 Disagree
Ok. But _why_? (Q to both)
>>
>>>
>>> C) scoped enums SHOULD NOT repeat (part
On 14 Jun 2023, at 16:20, Allan Sandfeld Jensen wrote:
On Mittwoch, 14. Juni 2023 14:59:40 CEST Marc Mutz via Development wrote:
On 02.05.23 10:58, Volker Hilsheimer via Development wrote:
During the header review, but also in API discussions leading up to it, we
had a few cases where it would
On Mittwoch, 14. Juni 2023 14:59:40 CEST Marc Mutz via Development wrote:
> On 02.05.23 10:58, Volker Hilsheimer via Development wrote:
> > 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
> >
On 02.05.23 10:58, Volker Hilsheimer via Development wrote:
> 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.
Was there some consensus here? We're
On Monday, 8 May 2023 00:21:32 PDT Sune Vuorela wrote:
> How would you do the extensions (e.g. user roles or user events)
> if you convert to enums ?
Still with the enum, but you need to somewhere write extra code to cast that
new number to the proper type. That's all.
--
Thiago Macieira -
On 2023-05-04, Marc Mutz via Development wrote:
> 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.
How would you do the extensions (e.g. user roles or user events)
if you convert to enums ?
/Sune
--
On Friday, 5 May 2023 03:49:58 PDT Allan Sandfeld Jensen wrote:
> Wasn't there a new C++ proposal for decoupling the two separate features of
> enum class?
It's probably the using enum, which is C++20 and requires GCC 11 or Clang 13.
On Mittwoch, 3. Mai 2023 19:40:18 CEST Marc Mutz via Development wrote:
> 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.
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,
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
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
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
>> 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
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
> 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
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
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
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
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
> 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
: 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
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
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,
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
[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
; 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 n
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
>
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:
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
+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
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
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
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
53 matches
Mail list logo
