Comment 1:

From http://golang.org/ref/spec#Program_initialization_and_execution
""""
Variables may also be initialized using functions named init declared in the package
block, with no arguments and no result parameters.
func init() { … }
Multiple such functions may be defined, even within a single source file. The init
identifier is not declared and thus init functions cannot be referred to from anywhere
in a program.
""""
IMO, the error message reflects the specification well. As the identifier is not
declared, calling it is like calling any other undefined function. The identifier is
special, the error is not.

Comment 2:

I agree that this is technically correct, however the fact you can't call init is a
byproduct of the implementation which renames init to prevent colissions if multiple
init functions are present. 
Although I cannot suggest appropriate wording, I think this error message could be
improved.

Labels changed: added release-none, repo-main.

Status changed to Accepted.

Comment 3:

Well, then it should not be forgotten to, for consistency, do the same
(improve/specialize) for any other error message rooted in "referring to [init] from
anywhere in a program", which the call statement is not the only case.

I've mailed https://go-review.googlesource.com/c/34790 to reignite the conversation.

CL https://golang.org/cl/34790 mentions this issue.

I just saw the fix and I think it's not correct. See my comment on the CL, but in short init is only special at package-level. It's perfectly fine to call a variable named init if it's value is a function.

While the error message originally was not very helpful (but correct), now the error message is misleading. I think this requires a more careful approach.

Reopening.

CL https://golang.org/cl/37876 mentions this issue.

Thank you @griesemer for taking a look at it. Gotcha, I'll yield to someone else to work on it.

I think a message like in the reverted patch such as "cannot refer to init function in user code" is fine, but we should first check if there actually is an init function at package level which the user is/could be referring to.
I could do this but would need a hint how to extract the information if there are any init functions in the package.

Not urgent. Has been like this for a while. Quite possibly will be addressed by the front-end cleanup that's in the works.

Non-urgent. Moving to 1.12.

Still not urgent, and the error message is correct per spec. Moving to unplanned.