Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

spec: clarify legality of non-ASCII graphic characters in import paths #44970

Open
adonovan opened this issue Mar 12, 2021 · 5 comments
Open

spec: clarify legality of non-ASCII graphic characters in import paths #44970

adonovan opened this issue Mar 12, 2021 · 5 comments
Assignees
Milestone

Comments

@adonovan
Copy link

@adonovan adonovan commented Mar 12, 2021

About import paths, the spec (https://golang.org/ref/spec#Import_declarations) says:

Implementation restriction: A compiler may restrict ImportPaths to non-empty strings using only characters belonging to Unicode's L, M, N, P, and S general categories (the Graphic characters without spaces) and may also exclude the characters !"#$%&'()*,:;<=>?[]^`{|} and the Unicode replacement character U+FFFD.

but the Go 1.16 release notes (https://golang.org/doc/go1.16#go-command) say

In module mode, the go command now disallows import paths that include non-ASCII characters or path elements with a leading dot character (.). Module paths with these characters were already disallowed (see Module paths and versions), so this change affects only paths within module subdirectories.

The latter wording appears to be a stronger restriction than allowed by the spec. Does the spec need to be changed?

@AlexRouSg
Copy link
Contributor

@AlexRouSg AlexRouSg commented Mar 12, 2021

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

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Mar 12, 2021

@jayconrod
Copy link
Contributor

@jayconrod jayconrod commented Mar 17, 2021

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

@rsc
Copy link
Contributor

@rsc rsc commented Apr 6, 2021

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).

@mengzhuo
Copy link
Contributor

@mengzhuo mengzhuo commented May 25, 2021

@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"))
}

@mknyszek mknyszek removed this from the Go1.17 milestone Aug 18, 2021
@mknyszek mknyszek added this to the Go1.18 milestone Aug 18, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants