On Wed, Oct 24, 2018 at 10:05 AM, Michael Jones <michael.jo...@gmail.com> wrote: > > Agree on the industry dynamics observation--I remember too--but want to > raise another point of view on 100% backwards compatibility: when Go was > just a baby, in pre-1.0 days, there was exploration and new ideas. There was > also "Go Fix" to rewrite "go of the past" as "go of today." This seemed > genius to me in a systemic way; it meant that even bold changes could be > easy and 100% reliable to change. It worked. > > I'd like to see this mindset extended in two ways: to rewrite Go to new > idioms and to rewrite Go 1 to Go 2. On the idioms front, if the standard > library now appreciates read-from over write-to, then let's autoidiomatize > it. If new Go 2 error checking is introduced, let's design the rewrite > system and the feature in concert. > > I like this mindset and wonder if it could be sufficient to allow > introduction of breaking changes. This is my question here--would rewrite > fool assurances be enough to feel compatible in the way sought by the OP?
`go fix` was cool and we should resurrect it where appropriate as we change the language. But I think that at this stage of the language evolution `go fix` is not enough to permit redefinitions of code. We can use `go fix` to handle removals from the languages: cases that no longer work, that can be rewritten to a form that will work. But where we have cases in which the same code works one way in Go 1.N and works a different way in Go 1.N+1, `go fix` is insufficient, because we no longer know reliably what meaning was intended by the author of the code. Before Go 1 we could assume that everybody always meant the current version, whatever that was. I don't think that is true today. Ian -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
