The spec deals with the language. Modules isn't part of the language, it's part of the toolchain.

CC @jayconrod, @bcmills.

Hey Alan, hope all is well. We miss you over here.

I think it would be reasonable to note within the spec that clarify the build tool (cmd/go, Bazel, Blaze) is responsible for interpreting import paths and may impose additional restrictions. The restrictions for module paths are documented in Module paths and versions.

Incidentally, in 1.16.2, we rolled back some of the changes in 1.16 because they were affecting more users than we anticipated. Import paths are now validated separately from module paths, and import paths may begin with a leading dot and may contain + characters.

cc @bcmills @matloob

The spec is wrong. At the least, an implementation needs to be able to insist on Unicode normalization that would exclude some of those code points. But further restrictions should be allowed as well, along with name-specific restrictions (we don't allow a package named "com1" for example).

@rsc It's a pity that Go will do normalization since package ʕʘϖʘʔ is fine with spec and go tool now.

https://pkg.go.dev/github.com/mengzhuo/moe

import (
        "fmt"
        ʕʘϖʘʔ "github.com/mengzhuo/moe"
)

func main() {
        fmt.Println(ʕʘϖʘʔ.Ꮷಠ_ಠ("ʕʘϖʘʔ powered"))
}

This is in the Go1.18 milestone. Is it likely to happen for 1.18? Thanks.

@rsc You assigned this to yourself back in April.

@griesemer see #44970 (comment)

@griesemer This is in the 1.18 milestone; time to move to 1.19? Thanks.

Not urgent. Moving to 1.19.

As a case study for this, #53954 was an issue relating to macOS's handling of Unicode file names.

The test involved the character Ä, which can be represented either as the composed character c3 84 or the decomposed character 41 cc 88. In Git, we had file paths and source files using the composed character (c3 84).

However, on macOS, the file names are rewritten to use the decomposed characters (41 cc 88). This caused problems with the test, because test/run.go used the file name to construct cmd/compile's -p flag; so it invoked cmd/compile with -p=test/\x41\xcc\x88foo, and wrote the result as ./\x41\xcc\x88foo.a.

Then when compiling the second package, cmd/compile saw import "./\xc3\x84foo" and tried opening ./xc3\x84foo.a. The macOS file system layer silently translated this into opening ./\x41\xcc\x88foo.a instead, but that tripped a recently added assertion that ensures the -p flag used to compile a package (i.e., "test/\x41\xcc\x88foo") matches the import path string used to import it (i.e., "test/\xc3\x84foo").