+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

Reply via email to