OK, that's a fair point. So how about this then. The default (no tag) would be determined by the compiler depending on what major version was being used to build the application. If you were using Go 2.0, 2.1 etc, then the absence of the tag would mean that new keywords would be treated as such and couldn't therefore be used as ordinary identifiers.
However, you could still build code which didn't use the new features with version 2.x of the compiler by adding a "go 1" tag to the package clause. By the time Go 3.0 came along, you'd have the choice of building 'old' code with the new compiler by including either the "go 1" or "go 2" tag. New code wouldn't need any tag but wouldn't be able to use new keywords as ordinary identifiers. TBH I don't know of any other language that has used this approach. They've either said: hey, it's a new keyword - get used to it - or matters have been arranged so that new keywords are always contextual and can therefore be used as ordinary identifiers outside that context. The latter approach has had some success (take C# for example) but can distort the language somewhat if a non-optimal approach is used for new features just to fit in with this philosophy. Alan On Sunday, October 28, 2018 at 3:44:09 AM UTC, Ian Lance Taylor wrote: > > On Sat, Oct 27, 2018 at 4:52 PM, alanfo <alan...@gmail.com <javascript:>> > wrote: > > > > As it's a package (rather than a file) level aspect, I propose adding an > > optional tag to the package clause. > > > > If there were no tag, then the compiler would only recognize version 1 > > keywords and newer ones would be treated as ordinary identifiers. > > > > If there were a tag such as: > > > > package whatever "go 2" > > > > then all keywords introduced up to version 2 would be recognized as such > and > > their use as ordinary identifiers outlawed. > > > > Assuming new keywords would only appear in new major versions of the > > language, we could then carry on with tags of "go 3", "go 4" etc. > > The problem I see with that approach is that people new to Go will > read about the current language, and will try to use features from the > current language, but those features will not work if they forgot to > add "go 2". Adding a "go 2" tag makes sense today, but it doesn't > make sense tomorrow. I'm not aware of any language that uses an > approach like that. > > 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.
