kossebau accepted this revision. kossebau added a comment. This revision is now accepted and ready to land.
In https://phabricator.kde.org/D3987#96434, @kfunk wrote: > In https://phabricator.kde.org/D3987#96418, @kossebau wrote: > > > In https://phabricator.kde.org/D3987#95858, @kfunk wrote: > > > > > Closing. This Diff refactored the code technically correct. > > > > > > Technically correct, as in: it builds. > > But semantically it is incorrect and a regression when it comes to flags, especially as high level languages are made for humans in the first line, not compilers ;) > > > Not true, the patch does /not/ change behavior. See explanation in https://phabricator.kde.org/D3987#78426. Na, I meant, for the human reader it is semantically incorrect to pass a (null) pointer as value for a set of bitflags :) Type mismatch in human brain :) (additional false brain alarm when one knows QFlags stores using an `int`, which we learnt in school to not always have bitsize of pointer type) (Personally I count that QFlags constructor hack for dealing with literal 0 values by that pointer-type overload an example of a hack blowing up with language changes, and now feeding nonsense stuff into the dependencies, next to bogus API dox in Qt itself, "zero must be a literal 0 value." when the default value shown right above is Q_NULLPTR, and compilers starting to complain about literal 0 being used (http://doc.qt.io/qt-5/qflags.html#QFlags-2). And my bug filed got instantly bounced, API quality seems to be not a shared value among everyone... tss... >>> If you want to replace `MyFlags flags = nullptr` by `... = {}` please do so in a follow-up patch/review. >> >> Seems you do not see yourself in the duty to do the fix-up. so I have to scratch this itch myself, tss :) > > Yes, honestly I think either way is fine (`nullptr` or `{}`). Get... used to the new look I'd say ;) Eh, I am too old to add another code-reading exception to my stable brain, but too young yet to not stand up and fight non-sense ;) Also have I had to explain too many artifacts in code to too many beginners, so I rather invest my free time into sane code ;) So will soon make contact with that clang-tidy then, openSUSE not having it as package invites me anyway to build/run from sources... Revision hopefully now unlocked for closing by selecting "Accept Revision" action, too bad I could not convince you to improve this yourself :) REPOSITORY R280 Prison REVISION DETAIL https://phabricator.kde.org/D3987 To: kfunk, #frameworks, dfaure, kossebau Cc: skelly, kossebau, dfaure, graesslin
