Whether to define a simplification/revision of JLS "type paths"

[jspecify]

Whether to define a simplification/revision of JLS "type paths"

[donnerpeter]

Sorry, I don't quite understand "Parent is a inner type whose nearest outer type is the child". Could you please give an example?

[kevinb9n]

Sure, like this. The type as seen in code is on the left, how I want to picture that as a tree on the right.

And the phrase you're asking about is abbreviated as just "inner-of".

[cushon]

One saving grace for enclosing instance of types is that they're always going to be @NonNull, so that part really only matters for nullness when talking component types of the enclosing instance (e.g. Bar) in your example, which could still be @Nullable.

[kevinb9n]

Note in the diagram above that:

1. whether Foo can potentially be nullable is governed by the edge type pointing to it (inner-of, therefore "no")
2. whereas, whether Baz can potentially be nullable is governed by what type context this is whole tree is sitting in.

This illustrates that it is really Baz that sits directly in the type context, and Foo that comes in underneath.

[kevinb9n]

Oh and there's more. I think it's very desirable that every subtree of the type tree is itself a valid type.

[kevinb9n]

I believe the arguments in this thread strongly support the idea that JLS "type paths" are not a useful model for us to base on. We won't try to redefine what "type path" means but we should mostly strive to avoid the concept (except in contexts where we specifically must map to JLS terminology).

We should define our own term like type "containment".