For C++ especially, most of these conventions and techniques co-evolved with the language, so requiring the compiler to produce an error for failing to follow them would be a breaking change. You might be able to configure your particular environment to produce more errors than the standard requires, which is what some of the mentioned warning flags are about. GCC and LLVM both support syntax like this to flag specific warnings as errors: -Werror=reorder (this specific one will error out if member variables aren't declared and initialized in the same order).

I yearn for compilers that can break backwards-compatiblity and strictly enforce best practices. This should be a achieved with a relatively simple command line flag to the compiler (instead of hunting for the right combination of dozens of -Werror=*, which then still let a lot of unclean code through)

Won't see widespread usage outside of learning because you can no longer trust any compiler upgrade not requiring a rewrite to your code, as it arbitrarily decides what the latest best practice.

What might be useful though is something like -wall printing all flags representing current best practices, so you can have a snapshot of it when writing new code (the problem with current -wall is again potentially arbitrary changes on compiler updates as new warnings get added, if it actually did warn on everything)

Then you can choose when you want to update to whatever modern best practices

That would be fine! Although, I also don't think "best practices" would be something that changes every 6 months (maybe every 5 years), and being forced by the compiler to rewrite code to keep up with best practices is absolutely a good thing!

I've been the lead on a fairly large Fortran project, and we make a point to run our test suite on as many compilers as possible, with the strictest flags to avoid any kind of "undefined" behavior (which is rarer in Fortran than in C). I believe it's the only way to ensure long term maintainability.

clang-tidy goes some way towards this goal.

There are some places where only the programmer can know that the undefined case doesn't happen (like integer overflow). But yeah, what purpose does it serve that the order of side effects in "a() +b()" is unspecified? I assume that's for historical reasons.

A fixed evaluation order may be (very slightly) less efficient than if the compiler is allowed to reorder. Consider evaluating "x + f()" when x is global and the compiler can't prove that x cannot change during execution of f. If the order of evaluation is fixed from left to right, then it must do the following:

1. load x into a register

2. spill the register holding x to the stack

3. call f

4. reload the "local" version of x from the stack

5. add

On the other hand, if the order of evaluation can be chosen by the compiler, it can do this:

1. call f

2. load x into a register

3. add

(Details depend on whether the caller or the callee saves x, but you get the idea.)

In practice, all competitive optimizing compilers are SSA-based, and thus they fix an order of evaluation early in the compilation process. I always wondered how much performance could be gained by actually delaying decisions about evaluation order.

Not sure if you're tyring to suggest that SSA-based compilers cannot do this reordering. For my example above, GCC reorders as I sketched, while Clang keeps the program order: https://godbolt.org/g/8KDvFo

I think this is done early, during lowering to a "mid-end" intermediate representation (whether SSA or not). This is the best time to do it, since the legality of this reordering is a property of the source language, which you want to forget about in the mid-end. On the other hand, in this particular example (function call vs. global variable access), I don't think there is any reason to delay this; doing the call first should never be worse than loading the global first.

As for deciding other things later, instruction scheduling and global code motion can reorder a lot of things, though calls and memory accesses block many movements.