The output of $ go help packages perhaps disagrees:
$ go help packages
Many commands apply to a set of packages:
go action [packages]
Usually, [packages] is a list of import paths.
An import path that is a rooted path or that begins with
a . or .. element is interpreted as a file system path and
denotes the package in that directory.
Otherwise, the import path P denotes the package found in
the directory DIR/src/P for some DIR listed in the GOPATH
environment variable (For more details see: 'go help gopath').
If no import paths are given, the action applies to the
package in the current directory.
It may disagree on the basis of what an import path means. If import path ~= folder, then the file main.go is not a package, but the set of .go files in the directory is a package.
If we are to say that main.go is given as an identifier for its package, then go run main.go should pull in all source files for the package. I think that if main.go is given as a package in and of itself, this is different to an import path in the usual semantics of the language and the documentation (and wealth of tutorials, books, and so forth) about the language should also be updated.
The text was updated successfully, but these errors were encountered:
You mentioned go help packages, but didn't get to the paragraph that covers this case:
As a special case, if the package list is a list of .go files from a single directory, the command is applied to a single synthesized package made up of exactly those files, ignoring any build constraints in those files and ignoring any other files in the directory.
In that case, the “package” is still “a collection of source files in the same directory that are compiled together“ — it's just that the subset of the directory included in the package is determined by the command-line arguments rather than the usual build constraints.
changed the title
cmd/go: run behavior does not agree with docs for pkg main with more than one fileOct 7, 2020
I guess the interpretation boils down to where the active word in the sentence "A package is a collection of source files in the same directory that are compiled together." is. If being in the same directory is acting, then it states that all go files in a directory must be in the same package. It is a compiler (linter? At least tooling...) error when you have files that declare different packages in the same directory. The majority of writing on Go nods in that direction.
If being in the same directory is passive (a requirement, but not defining), then I would say the behavior of go build main.go in this case is correct, otherwise I believe it is a bug.
There is a meta topic, too, of what determines what a package is at all -- can command line arguments restrict the scope of consideration for being a package? Why? Do the language rules allow sufficient ambiguity for there to be interpretation? Isn't the point of the language to be completely explicit, always, and remove ambiguity?