4 ms·
> We don't break user space. That's one strategy. It has consequences, such as keeping around K&R declarations and implicit pointer/int conversion for decades
by munch117 3y ago
> We don't break user space.
That's one strategy. It has consequences, such as keeping around K&R declarations and implicit pointer/int conversion for decades after they started being warned against. Other strategies may have merit.
- Brian_K_White 3y agoI don't think either of those examples is the same. The problem isn't merely gaining or losing features or syntax, it's changing the meaing and behavior of an existing thing. Code is the definitive source of truth for the thing someone devised. It's not just a thing, it's the reference for how to implement the thing. If you have a recipe from 100 years ago that refers to ingredients and tools that are no longer available, or are now called something else, or need to be translated into current equivalents, those are all no problem. But if the old recipe uses a term that we do still have, but means something different now than it did when written, that's a problem. Now you're breaking the very concept of writing and communicating and documenting. That's not a sane thing to do intentionally. Think scientific and industrial processes not just cakes. In this particular case, since the feature happens to be presumed to be rarely used, it might be fairly easily addressed by just having the compiler issue a full stopping error for any use of auto by default, including the reason why so that the user doesn't just blindly add the flag to allow it. In the future, when someone tries to build some code, it will fail to build, and that is 1000% prefferable to successfully building the wrong output.