I suggested a //go:lang directive to select non-backwards-compatible features on the issue below, but it was rejected.
https://github.com/golang/go/issues/28221 Note also the semver suggestion that each new version which provides non-backwards-compatible features should get a new major version, meaning a Go 3.x series shortly after Go 2.x. On Wednesday, October 24, 2018 at 12:16:15 PM UTC-7, Ian Denhardt wrote: > > Hey all, > > Today I've seen a lot of messages re: concerns about adding new keywords > and breaking backwards compatibility. People have floated a couple > approaches to avoiding breakage. But I feel like all of them that I've > seen so far will make code confusing. I'd like to propose an > alternative, which doesn't perfectly preserve backwards compatibility, > but: > > 1. Allows go 1 and go 2 to be mixed, provided they're in different > source files, and > 2. Has a clear and trivial upgrade path that can be automated, and > can also be done incrementally in a non-disruptive fashion. > > Here's the idea: the first Go release that includes the new > keywords introduces a new specially-recognized comment, something > like > > // go:keywords 2 > > This comment can be used to control which version of the language > source file is interpreted as. So to opt into the new features, a source > can add that comment to a source file. > > At the top. Other source files will continue to treat the new keywords > as identifiers. > > Note that since the keywords are all lower-case, this won't cause > problems with interoperability at the API level; any Go 1 package > that currently uses one of these keywords as an identifier only > does so privately, so Go 2 code can still import those packages and > not run into problems with not being able to specify a name in the > package. > > When we finally release "Go 2.0," the only backwards-incompatible > change we make is that that the default is to use the new keywords, and > we add another specially-recognized comment: > > // go:keywords 1 > > which causes the keywords to be treated as identifiers, as in Go 1. > > We could also add a flag to go build, so that users wanting to build an > old Go 1 codebase can just run: > > go build -go1 > > And everything will just work. Updating to the new version is easy and > can be done incrementally: just rename any variables that collide with > the keyword. > > Thoughts? > > -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.
