Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This seems like something that we would have discussed previously, but I can't find any evidence of that. - Maybe the hope was that we'd soon implement _full_ support from scratch based on forthcoming JSpecify rules for `@PolyNull`? - Maybe the hope was that we'd be able to [make `@PolyNull` "imply" `@Nullable`](jspecify/jspecify#307 (comment)) soon? - Maybe the plan was to tell Checker Framework users to write [`@Nullable @PolyNull`](jspecify/jspecify#35)? - Maybe we once had a principle of recognizing only annotations that were "universally" recognized (or at least recognized by Kotlin), while `@PolyNull` is _not_? But if so, we moved away from that long ago. For now, it seems useful to at least recognize it. I could see us backtracking if we were to fall back to a policy of (at least optionally) recognizing _only_ JSpecify annotations or _only_ "universally" recognized annotations. But if we do so, that will involve a larger change than just reverting back this PR. (My immediate motivation is that J2CL is looking at `@PolyNull` support (@kevinoconnor7 FYI), and we've been trying to keep our lists of annotations in sync with theirs.) Hmm, and you know, only now that I'm writing this am I realizing that making `@PolyNull` imply `@Nullable` would not actually be sound, at least for the class definition of `@PolyNull`. I'll leave a note on jspecify/jspecify#79 and maybe in a doc or two that we have going about `@Implies`, assuming that I don't convince myself that I'm wrong by then.
- Loading branch information