-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
Comments
The promoted method evaluation timing rules need rethought. BTW, no matter which way is chosen, this issue is absolutely a SERIOUS bug and should be fixed as earlier as possible. |
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 |
Bumping to 1.21. The behavior in 1.20 still seems inconsistent to me, but it's unchanged from 1.18/1.19 (except that the erroneous "interface conversion: interface is nil, not main.I" panic is now "runtime error: invalid memory address or nil pointer dereference"). |
@mdempsky based on your last message, it seems like this should happen during the dev cycle? Moving to Backlog since it was already bumped once. Feel free to move it to Go 1.22 if you plan to work on it. Thanks! |
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 }
, orstruct { *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
The text was updated successfully, but these errors were encountered: