spec: nil, true, false not reserved words

[simen]

What version of Go are you using (go version)?

go1.7.3 darwin/amd64

What operating system and processor architecture are you using (go env)?

$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/simen/go"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.7.3/libexec"
GOTOOLDIR="/usr/local/Cellar/go/1.7.3/libexec/pkg/tool/darwin_amd64"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_9/2x43ffkj2t13pf5wn5fwnwtc0000gn/T/go-build537154098=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"

What did you do?

https://play.golang.org/p/5dRCQ7TYEB

package main

import "fmt"

func main() {
  nil := "World"
  true := false
  if (true == false) {
    fmt.Printf("Hello, %s!", nil)
  }
}

What did you expect to see?

Expected the code not to compile because it assigns arbitrary values to (what I expected to be) important reserved words.

What did you see instead?

The code works as … unexpected and prints "Hello, World".

I understand these have status as Predeclared identifiers (https://golang.org/ref/spec#Predeclared_identifiers) but question the value of not flagging these as errors immediately.

[minux]

This is intentional. They are predefined identifiers: https://golang.org/ref/spec#Predeclared_identifiers One of the reason is that we can extend the language by introducing more of these without breaking existing program that already make use of the extended identifier as a user identifier. Please ask questions on other mediums, see https://golang.org/wiki/Questions.

[atombender]

One of the reason is that we can extend the language by introducing more of these without breaking existing

@minux: Making "nil" a reserved word does not prevent the introduction of future identifiers that are not called "nil", so the explanation doesn't make sense. Certainly, if you were to introduce a new special value today called "foo", for example, you simply couldn't avoid having to make it identifier instead of a reserved word. But "nil" and friends have existed since before the dawn of Go.

Besides, does assigning new values to true, false, nil, iota (all of which have globally destructive effects) even have legitimate use cases? It can be argued that any such assignment is going to lead to Very Bad Things, or at least Pretty Silly And Unexpected Things.

Go is very strict about things like unused imports and unused variables, yet it curiously has no problem with this. At the very least go vet should say something, which it doesn't.

[minux]

The explanation does apply to "append", which is introduced later. One other reason is that a lot of the predeclared identifiers makes perfect sense to be used as a user defined name sometimes (within in a small scope, perhaps). For example, naming two variables old and new is quite reasonable. go vet shouldn't out law such uses. I think this question has been discussed extensively in the past, please search the mailing list archives.

[ianlancetaylor]

@atombender Making nil a reserved word would break existing correct Go programs, and would therefore violate the Go 1 guarantee (https://golang.org/doc/go1compat).

[atombender]

Of course. However, that does not explain the rationale for why it was designed like this in the first place.

…

On Dec 5, 2016, at 01:16, Ian Lance Taylor ***@***.***> wrote: @atombender Making nil a reserved word would break existing correct Go programs, and would therefore violate the Go 1 guarantee (https://golang.org/doc/go1compat). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[griesemer]

@atombender The rationale is pretty simple: Only identifiers that must be keywords for syntactic reasons are keywords.

In fact, in the very beginning there was some discussion as to whether things like nil, iota, etc. should be keywords. Eventually we agreed on the rule above which settled it.

[ianlancetaylor]

I'll add that once the language has this concept, it becomes easy to add new predeclared identifiers without breaking existing programs.

[simen]

That's been clearly stated by now, but seeing as the go vet generally very strict and opinionated, it is impossible to grasp why it would not also warn about reassigning nil or bona fide boolean literals. I struggle to imagine a situation where that would be intentional and well advised.

[atombender]

@griesemer: I suggest that the documentation is updated to include the explanation, because it's not obvious to someone who wasn't there. The rationale is unusually unpragmatic compared to Go's other design choices, and also unusually lax for Go, which is otherwise terribly strict and opinioned about so many things.

[griesemer]

@simen It's not impossible to grasp, it's just not been done... :-) And the reason is probably that it's not important to check because it just doesn't happen to be an issue. There's simply more important things to worry about. Also, it's a different issue from this one, so please don't hijack this issue for another subject. This issue is closed. Thanks.

@atombender Feel free to submit a CL for review (perhaps for the FAQ). Also, I respectfully disagree. The rationale is very pragmatic: it's a simple rule that makes it easy to decide what needs to be a keyword and what doesn't; and as @ianlancetaylor has pointed out, it makes it easy to add new predeclared identifiers. Finally, Go is in no way unusual about where it is strict and where not as far as statically typed languages go. The approach chosen for keywords and predeclared identifiers is not new either and has a long history going back at least 40 years of programming language design (Pascal).

[atombender]

@griesemer But other languages are more strict than Go here; 40 years of programming language design has provided us with unassignable constants for these things.

You can't redefine or reassign nullptr or true in C++, except using macros. Since you mentioned Pascal: FreePascal and ObjectPascal don't allow reassigning true or nil (no idea about other implementations). Same thing in Java and D, I believe. Even Python and Ruby are more strict. From what I can tell it's Go that stands out.

I'll submit a PR if I have time.

[bradfitz]

I'll submit a PR if I have time.

A PR isn't the problem. This was a design decision.

[griesemer]

@atombender I'm not surprised about C++... But at least the Python I checked doesn't do anything special:

$ python
Python 2.7.10 (default, Jul 30 2016, 18:31:42) 
[GCC 4.2.1 Compatible Apple LLVM 8.0.0 (clang-800.0.34)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = True
>>> True = False
>>> False = x
>>> True
False
>>> False
True
>>> 

I'm not saying there's isn't languages where this is not the case. But Go is not the only language that made the respective decision.

There's also a question about the wisdom of making these restrictions: It doesn't really prevent people from writing bad code. I could still write var True = false (notice the capital T), and mislead readers. And so forth. Adding restrictions to a language and making it more complicated for a situation that in practice never occurs is in my mind not a good use of resources.

[griesemer]

A FAQ entry may be ok explaining this was simply deliberate and carefully thought out design decision - but there's no need to debate this any further. I'm going to lock this issue.