cmd/compile: allow some calls to generic functions in pre-go1.18 code

[rogpeppe]

What version of Go are you using (go version)?

$ go version
go version devel go1.21-af8f94e3c5 Tue Jul 11 21:30:51 2023 +0000 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

N/A

What did you do?

https://go.dev/play/p/a0oi0qhsoM1?v=gotip

What did you expect to see?

Running code.

What did you see instead?

foo/x.go:4:2: implicit function instantiation requires go1.18 or later (-lang was set to go1.14; check go.mod)

Even though the function signature has been changed in a (mostly) backwardly compatible manner, the version-agnostic code fails to call the new version of the function, even though no code change is required to make it do so.

Perhaps we should allow calls to generic functions where they don't involve explicit generic type parameter syntax.

[mvdan]

Worth noting that if you duplicate x.go as-is but with pre-generics and post-generics build tags, then it magically works: https://go.dev/play/p/fjNq6y2Djuo?v=gotip

It makes sense given the current limitation, but it's unfortunate to have to duplicate code like that - especially when the written syntax is literally the same.

[zigo101]

I totally don't get how the magic works. @mvdan, could you elaborate more on the logic?

[mvdan]

I just duplicated the file with the call site (x.go) into two copies, one with a //go:build go1.18 build tag, which then allows the call site to use a generic parameter.

Note that opting into generics for just one file only works on Go tip (1.21) due to #59033. That doesn't work with 1.20; the entire module would need to be bumped to go 1.18 via go.mod.

[zigo101]

I'm aware of these facts. I just didn't got what is the difference between one x.go file and two x.go files.

After thinking for a while, I think the difference is:

• before Go 1.21, language versions are per-packagemodule based.
• since Go 1.21, language versions are per-file based.

[mvdan]

Correct. That's why I pointed to #59033.

[zigo101]

The new design does complicate some use cases.

[mknyszek]

@rogpeppe Does #61689 (comment) address your issue? (i.e. being able to duplicate the file as a workaround in Go 1.21+)

[mvdan]

I mentioned this workaround for the sake of exploring options, but for what it's worth I don't think it's a good solution. In most practical cases the amount of code will be significant, so you end up needing to duplicate hundreds of lines, or splitting up little bits of code into a separate file to then duplicate, which also feels awkward.

[gopherbot]

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)

[zigo101]

Is this mis-closed?

[mknyszek]

It was marked waiting-for-info because we were waiting for info, and gopherbot has a timeout on such issues.

But I agree that it should probably be left open.

[rogpeppe]

What @mvdan said. In my particular case, the duplication needed would have been a deal breaker.