-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: generic code behaves differently from non-generic code #59827
Comments
It's not generic vs non-generic, but concrete type vs interface type. Change
AFAICT, this behavior is right. According to the spec:
|
But |
May be related to #52025. |
@dmitshur I think this should be a new problem, instead of a backlog problem. |
As @cuonglm points out, the generic code using type parameters behaves the same as how interface calls work. Ack that this differs from how the same code would work when specialized to execute with a single, concrete type argument. I think this is a spec ambiguity issue. The semantics around promoted methods, interface method calls, method values, and defer statements are still fuzzy, IMO. |
It looks this specified problem is more about the inconsistency between interface method value and non-interface method value evaluation: package main
type I interface {M(int); P()}
type V int
func (v *V) M(n int) {*v = V(n)}
func (v V) P() {print(v)}
func F(x *V) {defer x.P(); x.M(7)}
func G[T I](x T) {defer x.P(); x.M(7)}
func H(x I) {defer x.P(); x.M(7)}
func main() {
F(new(V)) // 0
G(new(V)) // 7
H(new(V)) // 7
} It really breaks many people's expectations to view type parameters always as interfaces. |
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What did you do?
What did you expect to see?
Same behavior.
What did you see instead?
Different behavior.
The text was updated successfully, but these errors were encountered: