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

Aaron Puchert noreply at phabricator.kde.org
Tue Oct 2 16:33:08 BST 2018


aaronpuchert added a comment.


  In D15694#333087 <https://phabricator.kde.org/D15694#333087>, @rjvbb wrote:
  
  > My point here was that making a whatever-you-call it more or less obligatory in something that is (used to be) shared with a closely related language introduces unnecessary confusion ("wait, am I writing C or C++ here"). And extra overhead when reusing algorithms between those languages.
  
  
  C and C++ have substantially diverged over the years, and aren't really "closely related". They have shared roots, but not only has C++ added tons of features that C hasn't, C has also added features that C++ doesn't support. Consider designated initializers <https://en.cppreference.com/w/c/language/struct_initialization>, variable-length arrays, and the restrict <https://en.cppreference.com/w/c/language/restrict> keyword. Compatibility between the two was never about the implementation, but about being able to share declarations (headers). Reusing algorithms was never on the table.
  
  Even for headers the ability to reuse doesn't come for free, usually some preprocessor magic is required like
  
    #ifdef __cplusplus
    extern "C" {
    #endif
  
  
  
  > I don't see any good reason why the same syntax wouldn't be used in C.
  
  That's up to the C standard committee, not to the C++ committee, and certainly not up to us. I'd appreciate it if we limited the discussion to this change.
  
  > And I wasn't thinking of a complete overhaul of the syntax, only of the statement name, in this case ("multi" instead of "switch", for instance).
  
  As I wrote, that requires changes to the language syntax including new reserved keywords that affect existing code. The attribute syntax doesn't require that, it's already there. But we're not the standards committee, so this is the wrong place to discuss such issues. If you don't like the direction C++ is taking, complain to them and not to me.

REPOSITORY
  R32 KDevelop

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

To: aaronpuchert, #kdevelop, mssola, brauch
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/20181002/a73f4fbd/attachment-0001.html>


More information about the KDevelop-devel mailing list