compiler-devel

Great suggestion, I'll set up an issue tracker. A few people have ventured into the code to leave some comments inline, I welcome that.

Great suggestion.

Completely agree! Thank you for these suggestions.

This is interesting, are there languages in use today with these constructs?

> I almost never see anyone using it without a good reason

In any of those cases, could the code have been rewritten without goto?

That's great to hear! I'm sure I could find it, but are the libreoffice coding standards written down (and could you send them my way)?

On the topic of coding standards, there's an excellent github repo https://github.com/isocpp/CppCoreGuidelines which even quotes Bjarne Stroustrup as saying "Within C++ is a smaller, simpler, safer language struggling to get out." There are hundreds of recommendations, like 'ES.31: Don't use macros for constants or "functions"'.

Indeed. I conceded in my commit message that a linter or checker (such as clang-tidy) could be used to implement some or most of what I suggested (but not the mutable/const change of course). Aside from learning more about how clang works, I wanted to show that we can (and should?) modify the language. There appears to be inertia to drop legacy at the committee level. C++ needs a Snow Leopard release to do some of what I've done here.

Great suggestions all around. UB is a beast of a problem and compilers take advantage of UB for optimizations (some going so far as to break programmers' code).

Interesting idea!

Thank you, this indeed is the approach that I'd like to take. Like I mentioned in the commit message on the patch, one of my goals is to show that we can iterate the language (and our codebases) gradually. I'll add a feature flag to my patch to selectively enable and disable these changes.

const can serve to mark invariants in your code as well as provide the compiler with information that it can use for optimizations. I highly recommend Scott Meyers' "Effective C++" wherein Item #3 is to 'Use const whenever possible'.

Wow, thank you for this rich and thorough follow up. Interestingly, in the present C++ standard, 'mutable' indeed is a storage class like 'register' while 'const' is a CV-qualifier. I thought it quite odd that 'mutable' isn't a CV-qualifier (the standard leaves this gap open) and for nonmember variables, my patch makes it a CV-qualifier; otherwise it remains a storage class specifier.

WRT lambda changes, I have no particular timeline for this project as it's something I took up on the side. Pointers kinda break any data flow analysis that could be done. For example, imagine an object that serializes itself in one translation unit and is deserialized in another using a different class (this is somewhat common in telecommunications code. Imagine a struct Header { ..., void end[0]; }; which is used to handle messages of variable length but with the same Header types).

Java does just fine without goto (or have they added that since 2010?).

I think code that is intentional is more effective than code that is accidental. That said, I'd rather suppress the unused parameter warning with the '#pragma diagnostic ignored' mechanism than use a cast mechanic that just happens to address a compiler issue.

Thank you for the great list of rules! I agree with them all. Minor nit: you can't use static_cast to cast away constness.

Generally speaking a const member function can't call a member function that is non-const or a member function that modifies a member variable that's not declared mutable. If the present const member function has a const reference to something that's marked mutable, then it's effectively a no-op as far as const value qualifications are concerned.

Yes, good point, I retract what I said before. Thanks!

Great point, I was thinking of ints as 32 bits. You're absolutely correct for 64 bit ints!

Thank you for your thoughtful response. vector<int> wouldn't work because copy semantics wouldn't apply for a constant type, so mutable would be needed (as you rightly pointed out). I'm not sure that vector<int> should work unless the vector container was updated to move its elements by default (another commenter suggested move-by-default rather than copy-by-default as well). I've used RxCpp in the past and know what nightmare awaits should you have to explicitly state lambda captures, yet I've seen too many devs over capture with subtle bugs as a result. Is there a compromise here? I'm not sure that goto is required when one could use do { ... } while(false); with break statements for cases where goto would've been used (not ideal, but again this is an iterative approach). C style casts to void are useful for some memory operations but I'm not sure there's a case where they're required.

If you would, I'd love to hear some of your rules as it's clear you have a lot of C++ experience. Can you send some along? Thanks!

Some implicit conversions are okay, like type promotion from int to double. Some type coercions are fraught, like char to int or back again. I agree that array decay to pointer could be explicit, and pointers shouldn't cast to arrays.

No C style casts allowed, so maybe static_cast<bool>(...) ;-)

Agreed, that's why I started by modifying clang. I think we can start dropping some of the crufty legacy in the C++ language without throwing it all out and starting again. While clang tidy could be used to check for a lot of these, I wanted to show that we could change the language directly and what that could look like.

Thanks! Aside from the default const/mutable change, this was my approach. To improve adoption, it would be easy to add a feature flag for this set of changes which could be applied on a per file basis.

Yes, some (maybe most) could be implemented in a plugin. I wanted to make these changes in part to better understand the clang internals and also show that rather than use external tooling, the language itself can (should?) be changed.

Thank you for this great feedback. I'll do my best to respond to each of your points:

WRT const, you're correct and I'd need to go further in updating const behaviors in the language. I stole this idea from Rust (sort of) in that variable declarations in that language are const by default. Essentially, I wanted to 'flip' the semantics in C++ to match, and use mutable to allow variables to change after their declaration. I could go further to enforce transitivity (e.g. so you can't do something like mutable x = y; where y is const).

[&] is handy indeed yet this was motivated by my experience in legacy heavy codebases where there are often many variables in scope and some with external consequences (e.g. file descriptors, sockets). I don't want these accidentally captured if the lambda invocation site has lifetime implications beyond those resources.

I think I'm achieving the goal of a safer, less error-prone language because these changes could've prevented the 2014 'goto fail' from happening (and not just because the keyword goto would be omitted but because there was a conditional without braces in the affected source making the code less explicit and less clear).

Modified C++

Inspired by the paper "Some Were Meant for C" by Stephen Kell, I decided to show that it's possible to iterate C++ to be safer, more explicit, and less error-prone.

Here's a possible starting point: I didn't invent a new language or compiler, but took the world's best compiler, clang, and modified it to begin iterating towards a new furture of C++. Naming things is hard, so I call this 'Modified C++'. Some of the following could be implemented as tooling in a linter or checker, but the idea is to update the compiler directly. I also wanted to learn more about clang. This compiler needs a flag to enable/disable this functionality so that existing library code can be used with a 'diagnostic ignored' pragma.

You can build clang using the normal non-bootstrap process and you'll be left with a clang that compiles C++ but with the following modifications:

- All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration - Lambda capture lists must be explicit (no [&] or [=], by themselves) - Braces are required for conditional statements, case and default statements within switches, and loops - Implicit conversions to bool are prohibited (e.g., pointers must be compared against nullptr/NULL) - No goto support - Explicit 'rule of six' for classes must be programmer-implemented (default, copy, and move c'tors, copy and move assignment, d'tor) - No C style casts

Here's an example program that's valid in Modified C++:

mutable int main(int, char*) { mutable int x = 0; return x; }

Here's another that will fail to compile:

mutable int main(int, char*) { int x = 1; x = 0; // x is constant return x; }

I'd like your feedback. Future changes I'm thinking about are: - feature flag for modified c++ to enable/disable with 'diagnostic ignored' pragma, to support existing headers and libraries - support enum classes only - constructor declarations are explicit by default - namespaces within classes - normalize lambda and free function syntax - your ideas here