As a general principle, Ian, that makes sense to me and perhaps it's something we could all unite on.
The remaining problem is how to distinguish between the two cases - new keywords used as such or as ordinary identifiers. Your suggestion is to leave it to the compiler to figure that out from usage whereas rog favors stating up front which version of the language is being parsed. Personally, I think I prefer rog's approach as it would then be immediately clear to both the compiler and the human reader what was intended. 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. Alan On Saturday, October 27, 2018 at 10:10:55 PM UTC+1, Ian Lance Taylor wrote: > > On Sat, Oct 27, 2018 at 3:31 AM, <alan...@gmail.com <javascript:>> > wrote: > > > > Both the above are also 'take it or leave it' approaches. Either you can > use > > the new keywords as such or you can use them as ordinary identifiers - > you > > can't do both in the same package which my suggestion would allow. > > That is an interesting feature but I don't think it's a necessary one. > It's important that we be able to continue to compile existing code > that uses identifiers that are now keywords. But it's not important > that we permit that code to start using the keyword without renaming > the identifier. Keywords always start with a lowercase letter, and so > the corresponding identifiers are never exported. It's always > possible to stop using an unexported identifier without breaking any > other packages. So if you want to start using a keyword, stop using > the identifier, by renaming the existing uses. That seems like a > clear and reasonable requirement for moving forward to a new language > version. We can even provide a `go fix` hook for it. > > 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.
