3 ms·
> That's why the author only suggests non-breaking changes in this article. One of the proposals in the article is to change the meaning of things like "if (a
by cesarb 3y ago
> That's why the author only suggests non-breaking changes in this article.
One of the proposals in the article is to change the meaning of things like "if (a != b > c)" and "if (0 <= index < max)". That changes program behavior and therefore is a breaking change (for instance, the code might accidentally be depending on the "wrong" results of these odd comparisons, and "fixing" them makes it go through an untested path which does the wrong thing).
- jcelerier 3y agoIt's ok if the current behaviour is changed into a compiler error
- cesarb 3y agoI agree; while changing it into a compiler error could be considered "breaking" (it no longer compiles), it's not a silent break and forces the developer to fix the code. (I would only worry about developers doing the "obvious" fix to shut the compiler up without looking at the surrounding code to see if it was masking some other bug.)
- saghm 3y agoThat feels imprecise to the point of rendering the entire conversation useless. If every major C++ compiler shipped a copy of `rustc` renamed to `g++` or `clang++` or whatever, that would also make every breaking change a compiler error, but I don't think that's what anybody is talking about here.
- Kranar 3y agoOn the contrary, it's the absurd claim that making "if (a != b > c)" a compiler error is somehow remotely comparable to changing C++ syntax so that it's the same language as Rust is what renders the entire conversation useless and is not what anybody is talking about here.
- PH95VuimJjqBqy 3y agothat's how you get companies to stop upgrading and eventually end up sitting on a 20 y/o version of C++. 2nd and 3rd order thinking is a thing.
- Kranar 3y agoIf a company won't update because it really needs to depend on whether one bool compares greater to another then by all means they can stick to using 20 year old version of C++. Other companies with modern engineering disciplines that don't write hacky code like that can benefit from a sane and sensible compiler instead of being dragged down.
- PH95VuimJjqBqy 3y agoIf you can't understand how the expense of doing that may be onerous on a business then you shouldn't be let anywhere near decision making.
- Kranar 3y agoToo late for that, I am in a decision making position at a quant firm with very strict engineering standards and I absolutely stand by my decision that businesses that write code that compares booleans together like that should not be in a position to hold back other businesses that don't. They can continue using 20 year old compilers and quit making the language worse for the rest of us who have put in the effort and cost of writing modern software.
- PH95VuimJjqBqy 3y agoIt's always easy to make a decision when you're not the one paying the cost for it, or don't imagine you will be. In fact, one of the red flags for decision makers is the inability to understand the above tenet.
- 3y ago
- tovej 3y agoThe example given here is a different interpretation of a statement. The source would stay the same for correct and incorrect use,there is no way for the compiler to catch this and send an error message.
- Kranar 3y agoIt's certainly possible to make an expression of the form "bool > bool" a compiler error and require that developers rewrite it as "x && !y"