Skip to content

Conversation

@HarrisL2
Copy link
Contributor

Fixes #21629

Not sure if the tests are sufficient.

case tp: TypeRef if defn.isTupleClass(tp.symbol) => false
case _ => true

override def apply(tp: Type): Type = tp match
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about List<@Nullable String> from Java? I would expect an annotated type. Not sure if this is supporeted by the java parser or class reader?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Support can be added, however, in our nullification code, we chose to not recurse on type argument for generic types coming from Java, so supporting these annotations may be in conflict with that decision:

if `C` is Java-defined, then `n(C[T]) = C[T] | Null`. That is, we don't recurse
on the type argument, and only add Null on the outside. This is because
`C` itself will be nullified, and in particular so will be usages of `C`'s type argument within C's body.
e.g. calling `get` on a `java.util.List[String]` already returns `String|Null` and not `String`, so
we don't need to write `java.util.List[String | Null]`.

Now if we have a List<@Nullable String> or List<@Nonnull String>, I believe the above argument doesn't hold anymore.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Consider nullable annotations in explicit nulls

3 participants