-
Notifications
You must be signed in to change notification settings - Fork 26
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
Document the nullness of special APIs on enum and annotation types #509
Comments
There are really 2-3 separate classes of APIs here, which we could choose to handle differently:
(I think I confirmed recently that Kotlin recognizes the non-nullness of all these APIs already.) |
(To be clear, I don't think that any of this matters a ton. I'm just continuing to write notes as they pop into my head.) In practice, what matters most is probably special handling for In theory, what matters most is probably the special handling for annotation elements: No one should be able to implement an annotation with nullable return types (either by declaring the annotation itself with nullable return types or by overriding methods inherited from a null-unmarked annotation type), since there is already a contract that annotation elements should have non-null values. |
Fortunately I don't see anything too controversial here, so I agree with it just being filed as a docs to-do. |
In theory, this could become part of the spec, similar to #301 (comment) (mentioned in the original post). But I don't see that as a 1.0 blocker, since tools are always welcome to add their own knowledge to what JSpecify provides. (#301 is arguably more important than this one, since JSpecify rules there can give the "wrong" answer (" |
SomeEnum.values()
returns a non-nullable array of non-nullable valuesSomeEnum.valueOf(String)
returns non-null (which may be a useful fact for tools that want to warn about unnecessary null comparisons, like https://errorprone.info/bugpattern/ImpossibleNullComparison)I may be forgetting other examples, as well as other autogenerated methods with known nullnesses. I guess we already have some posts about
equals
methods of record classes, as distinct fromequals
methods as a whole. (That first link mentions the alternative of considering all such methods to be null-unmarked. But I doubt there's much upside to that.)We could discuss where this information belongs. For now, I wanted to jot some notes so that I can link to them from elsewhere.
The text was updated successfully, but these errors were encountered: