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