CC @bcmills @matloob

I think this question is more related to the Go command? Feel free to switch it back to cmd/compile -- sorry for the noise if I'm wrong.

Also, for future reference, I think situations where you're unsure if there's a bug in the toolchain or if you're just misunderstanding something, a good place to start is the golang-nuts mailing list.

@oliverpool, a negative build constraint is not the right tool, unfortunately. A toolchain that knows how to compile go1.21 will satisfy that constraint even if the language version specified in go.mod is lower.

See:

• doc: mention language downgrading via //go:build #61894
• cmd/go: go directive is insufficiently documented for module authors to be able to make a decision about its value #30791

This seems to be working as designed given #59033, although it's unfortunate that that makes the polyfill use-case more difficult.

Given that you have the polyfill file anyway, is there some reason you can't use the polyfill definition of min all the time?

Anyway, how can I use the min builtin from go1.21 with a fallback for go1.20?

In this particular case, you could take advantage of the property that the meaning of the go directive changed between 1.20 and 1.21. In 1.20, it was advisory, and in 1.21, it becomes the minimum required.

Specifically, a way for you to use the predeclared min in 1.21 and a fallback in 1.20 is to set the go directive to 1.21. It'll work with 1.21 (where it's the minimum, but satisfied), and it will work in 1.20 (where it's below minimum, but still considered advisory). Consider:

 module code.pfad.fr/exp

-go 1.20
+go 1.21

$ go run .
min 1

$ GOTOOLCHAIN=go1.20.11 go run .
min 1

This is a one-time transitional quirk that won't apply in the future though.

@dmitshur thanks for the tip! The main drawback is that I won't know if I use any features of go1.20 without a proper polyfill (without actually using go1.20).

Another (cumbersome, but I believe still available in the future) solution is to rename to min_ and add 2 files:

min_21.go

//go:build go1.21

package main

func min_(a, b int) int {
	return min(a, b)
}

min.go

//go:build !go1.21

package main

// min is a pseudo-polyfill for go1.21 min function
func min(a, b int) int {
	if a < b {
		return a
	}
	return b
}

In any case, I find think this unexpected behavior should be better documented (if not changed):

the language version declared by the go directive of the go.mod is not used to satisfy build constraints (which are checked against the currently running Go toolchain).

Should I close this issue in favor of #61894 ?

Thinking more about this, it is only relevant for builtins since syntax changes and new stdlib features can't have a "single-file" polyfill (they need the "2-files" workaround from above).

Because it only concerns builtins:

• a special treatment could be implemented in the toolchain, if a builtin was introduced in a later version, check for a polyfill using build tags
• or maybe such a "special treatment" is too cumbersome for such a niche usecase: simply improve the documentation

I guess the second option is much easier, what do you think?

given #59033 i think it should work in the future when the go directive is > 1.21.0 ?

@seankhliao apparently it is already implemented: #59033 (comment)

My "2-file" example seems to take advantage of it: #64308 (comment) (however my go.mod states "go 1.20", so maybe this is unrelated?)

I think this can be folded into #61894