5 ms·
You might be overestimating the type of change required to break source compatibility. A benign example is adding a keyword. Let's say you want to add a new lan
by dcow 3y ago
You might be overestimating the type of change required to break source compatibility. A benign example is adding a keyword. Let's say you want to add a new language feature and the community unarguably wants the feature and the right or only way to add it is with a new keyword. If you're not allowed to break source, then you can never add the feature.
I understand your argument for big things like changing the semantics of the language. But a backwards-incompatible change can also be rather benign.
- rsc 3y agoIt's not true that Go can't add new keywords. Now that we have Go modules, all Go code is now explicitly annotated with the version of Go it was written against. We can add a new keyword in a later version of Go as long as the compiler can still also compile code written for the older versions of Go. (The go command tells the compiler which version of Go to use for each package it compiles.) What we're not going to do is abandon all the code written for older versions of Go, like Python 3 or Perl 6 did. Python is recovering now but it easily lost a decade to the Python 2 -> Python 3 transition, almost certainly unnecessarily. And Perl lost even more.
- jen20 3y agoThis is a the TL;DR I wish was the first paragraph of the article! Could this mechanism be used to patch up unfortunate evolutions in the standard library also? For example, all of the `WithContext` functions that could be folded into the (more common?) non-contextful versions?
- crickey 3y agoI dont undestand your example, plenty of languages add new keywords without breaking backwards compatibility, its removing a keyword that would cause such and issue.
- meepmorp 3y agoI have named a function 'foo', in current version of language. A future change makes 'foo' a keyword. My code was broken by adding a keyword.
- earthboundkid 3y agoThis is not theoretical: Python broke a lot of async packages when they made “async” a keyword!
- crickey 3y agoI guess, some languages get around this by having a destinction between functions and keyword functions not having the () braces in the syntax. But really if ur defning functions as keywords u should just put it in the standard library
- kodra 3y agoWhy can't it add keywords? Adding a new keyword doesn't break backward compatibility. It breaks "forward compatibility."
- Dylan16807 3y agoOld code becoming a compiler error sound like a backwards compatibility issue to me.
- kodra 3y agoI guess it's a terminology thing. As someone from a C# background, not all keywords are reserved words. Only new reserved words break backward compatibility. C# has added some keywords (record, and, or) without breaking backwards compatibility.
- tptacek 3y agoNew keywords are like the textbook example of a backwards compatibility problem. It's probably why C overloads "static" so many different ways.
- kodra 3y agoYou mean new reserved words? For example, I'm quite sure when C# added "record" it didn't break backward compatibility, as old code that uses "record" as a variable name still compiles.
- tptacek 3y agoGo has made changes like that by adding new predeclared identifiers ("any" is an example, I think?) but there's a distinction between predeclared identifiers and keywords.
- pcwalton 3y agoYou can sort of add new keywords backwards-compatibly using a trick called "contextual keywords": you require that they be placed in a syntactic position in which no identifier could legally go, and you maintain them as legal identifiers for compatibility. C++ used this trick to introduce "final" and "override" by moving them before the opening "{".