D3987: Use nullptr in all Frameworks (just diff in KIO shown here)

[Friedrich W. H. Kossebau]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20170323/9b56d2fa/attachment.html>