Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
rogpeppe opened this issue Aug 1, 2023 · 12 comments
Open

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

rogpeppe opened this issue Aug 1, 2023 · 12 comments
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone

Comments

@rogpeppe
Copy link
Contributor

rogpeppe commented Aug 1, 2023

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.

@rogpeppe rogpeppe added the generics Issue is related to generics label Aug 1, 2023
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 1, 2023
@mvdan
Copy link
Member

mvdan commented Aug 1, 2023

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
Copy link

zigo101 commented Aug 1, 2023

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

@mvdan
Copy link
Member

mvdan commented Aug 1, 2023

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
Copy link

zigo101 commented Aug 1, 2023

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
Copy link
Member

mvdan commented Aug 1, 2023

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

@zigo101
Copy link

zigo101 commented Aug 1, 2023

The new design does complicate some use cases.

@mknyszek
Copy link
Contributor

mknyszek commented Aug 2, 2023

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

@mknyszek mknyszek added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Aug 2, 2023
@mknyszek mknyszek added this to the Backlog milestone Aug 2, 2023
@mvdan
Copy link
Member

mvdan commented Aug 2, 2023

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
Copy link
Contributor

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

@gopherbot gopherbot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 2, 2023
@zigo101
Copy link

zigo101 commented Sep 3, 2023

Is this mis-closed?

@mknyszek
Copy link
Contributor

mknyszek commented Sep 3, 2023

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.

@mknyszek mknyszek reopened this Sep 3, 2023
@gopherbot gopherbot closed this as not planned Won't fix, can't repro, duplicate, stale Sep 3, 2023
@mknyszek mknyszek removed the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Sep 3, 2023
@seankhliao seankhliao reopened this Sep 3, 2023
@cherrymui cherrymui added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Sep 5, 2023
@rogpeppe
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. generics Issue is related to generics NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
Status: In Progress
Development

No branches or pull requests

7 participants