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