search

golang / go

The Go programming language
https://go.dev
BSD 3-Clause "New" or "Revised" License
123.92k stars 17.65k forks source link

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

Open bradfitz opened 4 years ago

bradfitz commented 4 years ago

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

dmitshur commented 4 years ago

A related issue is #30791. Also see https://github.com/golang/go/issues/30791#issuecomment-472684106 specifically.

jayconrod commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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.

josharian commented 4 years ago

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. https://github.com/josharian/intern/commit/98cac2a06bec17be11f0c76fd73d660186d69afc. 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 commented 4 years ago

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

bcmills commented 4 years ago

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.