Qt::WindowFlags f = nullptr in framworks headers

Stephen Kelly steveire at gmail.com
Sat Jan 21 11:15:36 UTC 2017


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.



More information about the Kde-frameworks-devel mailing list