[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: Qt::WindowFlags f = nullptr in framworks headers
From:       Stephen Kelly <steveire () gmail ! com>
Date:       2017-01-21 11:15:36
Message-ID: o5vfsi$3e0$1 () blaine ! gmane ! org
[Download RAW message or body]

Kevin Funk wrote:

> On Wednesday, 18 January 2017 21:12:07 CET Stephen Kelly wrote:
>> Hello,
>> 
>> As a result of the recent porting from 0 to nullptr, we have things like
>> 
>>  Qt::WindowFlags f = nullptr
>> 
>> in frameworks headers. See for example kruler. That is - enum default
>> parameter values have been ported incorrectly.
>> 
>> I don't know if some clang tooling is being used to do the porting, but
>> if so, the tool is buggy.
> 
> clang-tidy was used.
> 
> I don't see why the tool is buggy.

QFlags does indeed have a constructor taking a nullptr. However:

* I don't know why, and it might be a hack in QFlags
* Using `= nullptr` for something which is a flags/enum is 
confusing/unexpected to the human reader
* The flags can be uint if Q_NO_TYPESAFE_FLAGS is defined[*]. That would 
fail to compile. This reinforces the idea that QFlags is just pretending to 
be a typesafe something-else.

[*] Note that Q_NO_TYPESAFE_FLAGS is currently broken/unusable and probably 
unfixable.

>   Qt::WindowFlags f = nullptr

Looks odd to the human, right?

> As I said on the Diff already, just port it to this if you want to:
>   Qt::WindowFlags = {}

Yes, that should always be preferred for all types instead of `= nullptr` in 
all cases IMO. 

Thanks,

Steve.

[prev in list] [next in list] [prev in thread] [next in thread]