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

cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files #36319

Open
bradfitz opened this issue Dec 30, 2019 · 7 comments
Open

cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files #36319

bradfitz opened this issue Dec 30, 2019 · 7 comments

Comments

@bradfitz
Copy link
Member

@bradfitz bradfitz commented Dec 30, 2019

If I have a very simple Go package that doesn't depend on any language features added since the original Go 1 release, I naturally thought I could put in my go.mod file:

go 1

But that doesn't parse:

$ go install
go: errors parsing go.mod:
/home/me/proj/go.mod:3: usage: go 1.23

But go 1.0 is weird, because we never called it that. Is that correct? Docs don't say.

go 1.1 is also weird, because it implies that I'm depending on something that was added in Go 1.1, but I'm not.

So I guess go 1.11 for when modules were introduced?

/cc @ianlancetaylor @bcmills @jayconrod @dmitshur

bradfitz added a commit to bradfitz/iter that referenced this issue Dec 30, 2019
(It doesn't really depend on Go 1.11 but that's when modules were
added; see golang/go#36319)
@dmitshur

This comment has been minimized.

Copy link
Member

@dmitshur dmitshur commented Dec 30, 2019

A related issue is #30791. Also see #30791 (comment) specifically.

@cagedmantis cagedmantis added this to the Backlog milestone Jan 2, 2020
@jayconrod

This comment has been minimized.

Copy link
Contributor

@jayconrod jayconrod commented Jan 3, 2020

https://golang.org/cl/210799 should describe this in more detail.

go 1.11 makes sense to me: go.mod files didn't exist before that.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jan 7, 2020

I believe that the compiler itself only cares about versions back to 1.8 anyway.

The compiler doesn't track features added before 1.9, so it can't enforce language changes from before that point. (There were non-trivial language changes in 1.1, 1.2, 1.4, and 1.5.)

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jan 7, 2020

In other words: we probably should not allow a go directive older than 1.6, since we don't actually enforce anything that far back.

@bcmills bcmills changed the title cmd/go: how to say Go 1 language version in go.mod file? cmd/go: reject unenforced 'go' versions (older than 1.6) in 'go.mod' files Jan 7, 2020
@josharian

This comment has been minimized.

Copy link
Contributor

@josharian josharian commented Jan 7, 2020

It is worth noting that well-intentioned people like Brad or me may already have created go.mod files with older directives. (See e.g. josharian/intern@98cac2a. I picked that version because that was the version in which an optimization was introduced without which the package is useless.)

My 2c is that go 1 or go 1.0 would be the best magic markers for compatibility all the way back.

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jan 7, 2020

Perhaps rather than rejecting the older versions, we should upgrade them to 1.6 (and perhaps add a comment).

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Jan 7, 2020

I don't think a marker for “compatibility all the way back” is a good idea unless it is actually enforced, and I don't think it's worth the labor to retrofit actual enforcement.

Without enforcement, the marker would give a false sense of confidence: once might expect that a package that successfully compiles with a go 1.0 directive would also compile with an actual Go 1 compiler, but that doesn't even remotely hold today.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.