proposal: cmd/go: allow fine-grained go build constraints for go version

[pjebs]

Proposal Details

It would be great if *.go files can allow more fine-grained version constraints.
The go.mod file permits it - so it seems like an incongruency.

My project is dealing with compiled object files which have been compiled on a very specific go version/OS/arch. It is important to be able to differentiate between different versions of go with precision.

=== go.mod ===
module mymod
go 1.22.3

=== main1.go ===
//go:build go1.23.5 && !go1.23.6
package main
func main() {
	println("built using go1.23.5")
}

=== main2.go ===
//go:build go1.23.6 && !go1.24
package main
func main() {
	println("built using go1.23.6")
}

$ go1.23.5  run .
package mymod: build constraints exclude all Go files in /Users/x/Documents/test-go-build-constraints

$ go1.23.6  run .
package mymod: build constraints exclude all Go files in /Users/x/Documents/test-go-build-constraints

[gabyhelp]

Related Issues

• go/ast, go/build/constraint: support for per-file Go versions using //go:build lines #59033 (closed)
• cmd/go: use go.mod to define the required version of Go #26499 (closed)
• cmd/go: go directive is insufficiently documented for module authors to be able to make a decision about its value #30791 (closed)
• go build ignores GoVersion in go.mod file #58420 (closed)
• cmd/go: do not modify the 'go.mod' or 'go.sum' files if the 'go' directive indicates a newer-than-supported version? #34262
• cmd/go: consider matching newly added _goos.go, _goarch.go or _goos_goarch.go suffixes based on go.mod go version (rather than Go toolchain version only) #44626
• proposal: cmd/go: GOTOOLCHAIN=mod to use exact version of toolchain directive #69956

Related Documentation

• go.mod file reference > go > Notes
• Go Wiki: Comments > Directives > go tool directives > //go:build
• Go Modules Reference > go.mod files > go directive

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[seankhliao]

I believe this is one of the reasons we removed support for binary only packages, I don't see it making it's way back.

[pjebs]

My example was specific to my use-case. The proposal is more general in terms of use-cases. Perhaps a Go patch version has a bug that you want your build to avoid. And that's not to mention the inconsistency with go.mod allowing it.

@ianlancetaylor What do you think?

[ianlancetaylor]

I think this is separate from binary-only packages.

[ianlancetaylor]

CC @matloob @samthanawalla

[matloob]

I think we'd want to have strong use cases to consider adding a feature like this, given the increased complexity.

My project is dealing with compiled object files which have been compiled on a very specific go version/OS/arch. It is important to be able to differentiate between different versions of go with precision.

Could you explain your use case more? I don't fully understand it.