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
go/types: LookupFieldOrMethod no longer accepts a nil type (aka "should go/types accept nil types?") #50620
Comments
Thanks for filing. Adding the 1.18 milestone but not marking as a release blocker. I don't think it should be a problem for us to preserve (and document) this behavior. I wonder if we should also try to normalize our APIs by always accepting nil types (i.e. implementing and documenting a non-panicking behavior with respect to nil types in |
The old behavior for In some places ( |
I think I agree with griesemer. For I'm leaving this issue open so you can make the final decision, but I'd be inclined towards leaving things as they are, and fixing code that passes nils to |
Change https://golang.org/cl/379374 mentions this issue: |
Per the above discussion, leaving behavior of |
…ethod Document and enforce API expectation. Add a test so we don't inadvertently change the function behavior with respect to nil type arguments. Fixes golang#50620. Change-Id: Ic000bff7504a03006bd248a319c7a2d49dcf09c8 Reviewed-on: https://go-review.googlesource.com/c/go/+/379374 Trust: Robert Griesemer <gri@golang.org> Run-TryBot: Robert Griesemer <gri@golang.org> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
In previous versions of Go,
types.LookupFieldOrMethod
would accept a nil type and return a nil object. In 1.18, it panics instead. The function was never documented to accept nil types and this probably doesn't constitute a breaking change. I'm filing this issue primarily to document the change, but also so we can consider supporting the old behavior explicitly.Intuitively, the old behavior makes sense to me. Unfortunately, go/types isn't very consistent with handling nil types. Some functions, such as
types.Comparable
andtypes.IsInterface
never supported nil, whereas other functions, such astypes.Identical
explicitly handle nil. And other functions, like previouslytypes.LookupFieldOrMethod
support nil by accident. This prompts the question: should we strive for consistent handling of nil types, or should we leave things alone?Example program:
Go 1.17.6 output:
Go 3b5eec9 output:
/cc @findleyr @griesemer @mvdan
The text was updated successfully, but these errors were encountered: