D15694: Make implicit fallthroughs a compiler error, remove unneeded breaks

[Aaron Puchert]

aaronpuchert added a comment.


  In D15694#330932 <https://phabricator.kde.org/D15694#330932>, @rjvbb wrote:
  
  > My gripe is more with having to change my habits in ways I don't necessarily agree with entirely, and which might interfere with coding in other contexts.
  >  It may not in KDevelop's code, but that's not all that all of us work on. Coding style and guidelines for KDevelop itself could reflect good practice you'd like to advocate in general.
  
  
  I would actually advocate for this in general. I'm not sure which other code bases you work on, but I'm pretty sure both changes are consistent with the consensus in the C++ community. (The projects I work on outside of KDE do the same.) Otherwise compiler writers wouldn't implement these warnings. The fallthrough attribute has actually been standardized now.
  
  > Not that `[[fallthrough]]` looks so great (esp. when I'm not wearing appropriate sight correction :D) - I'd be curious to know how this will be handled in ObjC (where I think it corresponds to doing something "not-done" twice). BTW, will there be a corresponding C standard that introduces the same keyword, I'd surely hope so?! If not I do wonder if when C++ is going to introduce a switch/case version that's more on par with the version in interpreted languages that can take non-const cases...
  
  You can use comments <https://developers.redhat.com/blog/2017/03/10/wimplicit-fallthrough-in-gcc-7/>, or `__attribute__((fallthrough))` in C. You probably want to hide the latter behind a macro, so that other compilers don't see it.
  
  Regarding readability: With these changes, every case block ends with either a terminator or a fallthrough annotation. That is easy to verify both by humans and by compilers. And it means that the programmer has to make explicit, hence think about, what should happen when the block ends. I think this a better strategy to guard against accidental fallthroughs, because how do I know if it was intended if there is no annotation, no comment, no indication that it was? This way we are forcing the programmer to be explicit, so whatever happens will be the intended behavior. There is no way to accidentally miss a `break` anymore.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D15694

To: aaronpuchert, #kdevelop
Cc: rjvbb, brauch, mssola, kossebau, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight, arrowd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20180927/929c44fd/attachment.html>