A language can evolve backwards-compatibly only by filling in parts of the syntax and semantics that were previously occupied by errors.
-
-
Replying to @TimSweeneyEpic
Even errors are observable behavior at some level (either through meta-programming, or actually outside the compilation/runtime), so I guess it depends on how you want to define "backwards compatible".
1 reply 0 retweets 0 likes -
Replying to @Poita_
C++ is unique in making a sweeping mistake with SFINAE, freezing all current errors into template semantics forever (or, in practice, making every new version backwards-incompatible).
2 replies 0 retweets 7 likes -
Replying to @TimSweeneyEpic
SFINAE is one example, but beyond that it's also easy to break backwards compatibility with tooling (build scripts/tests that look for compilation failures, parsers etc.) Obligatoryhttps://xkcd.com/1172/
1 reply 0 retweets 7 likes
Backwards compatibility should be defined only in terms of success or failure of compilation and observable values or existence of errors at runtime. Any more granular notion (such as performance, or exact text of error messages) would be counterproductivdly constraining.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.