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 Wednesday, 14 June 2023 01:52:49 PDT Marc Mutz via Development wrote:
> == Why E _and_ O? ==
>
> The reason we need E _and_ O for ordered types instead of just O is that
> O needs to order the lhs w.r.t. the rhs, which generally involves
> looking at all the state of the objects whereas E just
> 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
Marc Mutz (14 June 2023 10:52) wrote:
> == Naming E ==
>
> So far, we've been using equal(). equals() doesn't work for technical
> reasons, but while it'd work as a member function lhs.equals(rhs),
> it's also kinda wrong if the function is taking two arguments
> (equals(lhs, rhs), but there are
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 03.11.22 10:40, Marc Mutz via Development wrote:
> TL;DR: provide named functions for the minimal set of op== and op<=>
> we'd have to write in C++20, then use macros to turn these into op==,
> op!=, op<, op>, op<=, op>= for C++17 builds and op== and op<=> for C++20
> builds.
This part somehow
Hi all,
https://code.qt.io/cgit/qt/qtdoc.git/tree/doc/src/whatsnew/whatsnew66.qdoc
seems to be quite unfinished ☹ It would be good to get some more content there
for Qt 6.6 Beta1 (which is planned to happen during this week). So please do at
least most important updates now; finalizing and
Hi,
TL;DR:
- we should add Q_DISCARD_CTOR to all ctors of classes with class-level
[[nodiscard]], esp. RAII objects
- class-level [[nodiscard]] seems to be abused atm to get ctor-level
[[nodiscard]] semantics in C++!7
- do we want to mark (almost) all ctors as [[nodiscard]], in the future?
16 matches
Mail list logo
