cmd/go: avoid using the term "work space" to refer to a GOPATH in documentation

[vdepabk2t]

What is the URL of the page with the issue?

https://pkg.go.dev/cmd/go#hdr-Import_path_syntax

What is your user agent?

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

Screenshot

What did you do?

Read the page and tried to understand it.

The page says:

An import path (see 'go help packages') denotes a package stored in the local file system. In general, an import path denotes either a standard package (such as "unicode/utf8") or a package found in one of the work spaces (For more details see: 'go help gopath').

and:

Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with "go install" (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.

What did you expect to see?

A description or definition of what a "work space" is. (I also looked in the output of go help gopath and didn't find it.)

What did you see instead?

No such description or definition.

From context, I'd guess a "work space" may be a directory (package? module???) in the local file system, possibly outside GOPATH; but I hate guessing. Besides, "Go programs cannot use relative import paths within a work space" seems to rule this out.

(Importance: very low; urgency: non-existent)

[Splizard]

Related to #45713

[bcmills]

I think this documentation dates back to near the introduction of GOPATH, and this “work space” refers to a directory listed in GOPATH. I agree that it is confusing in the context of modules.

CC @matloob @stevetraut @jayconrod