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: generic method values behave differently than specific ones #54447

Open
mdempsky opened this issue Aug 14, 2022 · 2 comments
Open
Assignees
Labels
compiler/runtime Issues related to the Go compiler and/or runtime. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@mdempsky
Copy link
Member

mdempsky commented Aug 14, 2022

https://go.dev/play/p/zU0yk_nHw0_w

The above test program demonstrates the semantics of var t T; _ = t.M where T is either a type alias of one of a few types (I, struct { I }, or struct { *X }); or it's a type parameter instantiated as that same type.

I think the intended spec semantics are that the corresponding specific and generic cases should always match.

Further, under the interpretation in #6475 (comment), I believe that all cases should panic.

/cc @griesemer @ianlancetaylor for confirming expected behavior

@mdempsky mdempsky added the NeedsFix The path to resolution is known, but the work has not been done. label Aug 14, 2022
@mdempsky mdempsky added this to the Go1.20 milestone Aug 14, 2022
@mdempsky mdempsky self-assigned this Aug 14, 2022
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Aug 14, 2022
@go101
Copy link

go101 commented Aug 14, 2022

The promoted method evaluation timing rules need rethought.
I still agree with @ianlancetaylor and think the evaluation should not happen at compile time. to lower doc explanation difficulties and runtime implementation difficulties.

BTW, no matter which way is chosen, this issue is absolutely a SERIOUS bug and should be fixed as earlier as possible.

@mdempsky
Copy link
Member Author

mdempsky commented Aug 14, 2022

For the record, the other interpretation that I think is reasonable (and somewhat more closely explains the existing implemented semantics) is type parameters act like interfaces, but their dynamic type is always the type argument.

For example, changing var t T in the non-generic function literals to var t I = *new(T) matches when the generic functions panic: https://go.dev/play/p/igIVdyosrZC

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. NeedsFix The path to resolution is known, but the work has not been done.
Projects
Status: Todo
Development

No branches or pull requests

3 participants