Re: [go-nuts] New keywords and backwards compatibility
I like the idea. Simple. I think the go documentation needs to have similar @Since annotations like Java. I would also strongly suggest no breaking APIs - ever... > On Oct 24, 2018, at 2:14 PM, 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. -- 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.
Re: [go-nuts] New keywords and backwards compatibility
On Wed, Oct 24, 2018 at 12:14 PM, Ian Denhardt wrote: > > Thoughts? Please read https://golang.org/issue/28221 and the background doc linked there. I suggest that you comment on that issue, which is exactly about the topics you raise here. Thanks. 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.
[go-nuts] New keywords and backwards compatibility
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.
