+1 to A and C. > On 14 Jun 2023, at 21:49, Allan Sandfeld Jensen <k...@carewolf.com> 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¹² >>>>> >>>>> -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. > > As discussed earlier. Better naming in many cases until we can depend on > C++20 in API. I disagree with designing API for standards we are not yet > allowed to use. And there are a few rare cases with flags or other composite > value types, where the implicit casting is desirable. I wouldn't mind saying > scoped enums are the preferred default, and any unscoped enum needs to be > justified in the commit message, but I would hate to ban them out right. > > Best regards > Allan
-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 rare, perhaps) situations. More importantly, I don’t agree with the footnoted proposal of making all currently unscoped enums scoped in Qt 7. Such a change would cause a massive porting effort (tool or not), with zero value for users. There might be exceptions where we have genuine issues from certain enums being unscoped, we can fix those with appropriate porting aids and compatibility wrappers/aliases. Volker -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
