Ian, thanks for commenting. I wonder if this might be viewed as motivation for "bigger, visible, clear" changes rather than nuanced ones.
As a ship captain, I'm trained to take "early and effective action" to avoid problems. Not just to solve them, but to do so ina way that signals the other boat what I'm doing. If a 3 degree heading change is enough, say, I might do 10 for a bit just to let them see clearly that I have turned for safety and then in a few minutes turn back closer to the 3 degree heading. This telegraphing helps all parties. Could be the same for changes. If they have to happen (regrettably) then maybe it is good to make them in such a way that bon confusion between new and old was possible, or at least to the degree that is practical. On Wed, Oct 24, 2018 at 2:04 PM Ian Lance Taylor <i...@golang.org> wrote: > 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 > -- *Michael T. jonesmichael.jo...@gmail.com <michael.jo...@gmail.com>* -- 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.
