I agree that we can leak types in other circumstances - I'm not sure
that the potential for source compatibility breakages is the same though.
Maurizio
On 25/02/2020 14:22, Brian Goetz wrote:
Don't we have a similar problem with non-accessible supertypes and
inference? If I have:
private abstract class A { }
public class B extends A { }
public class C extends A { }
Won't I infer LUB(B,C) = A, rather than Object?
On 2/25/2020 6:08 AM, Maurizio Cimadamore wrote:
But if that's the case, I have to admit that I find it a bit awkward
that I can use javac to probe sealed interfaces to see which might
share a common implementation class, even if that implementation
class is out of my reach and hidden behind module boundaries. In
other words, while with the rules we have now, the user can always
"see" why a cast has succeeded or fail, with these new rules,
sometimes a cast can (statically) be rejected or not depending on
details which might be unavailable to the site where the cast
operation occurs. I wonder - should javac "stop" looking, and avoid
descending into subtypes which are not visible from the use site
(e.g. consider A and B as completely disjoint in the example above,
if the cast occurs outside M?)
