From kde-frameworks-devel Sat Jan 21 11:15:36 2017 From: Stephen Kelly Date: Sat, 21 Jan 2017 11:15:36 +0000 To: kde-frameworks-devel Subject: Re: Qt::WindowFlags f = nullptr in framworks headers Message-Id: X-MARC-Message: https://marc.info/?l=kde-frameworks-devel&m=148499740027641 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.