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.

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

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.

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.

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

The new design does complicate some use cases.

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

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.

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.)

Is this mis-closed?

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.

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