Primitives in instanceof and patterns

forax at univ-mlv.fr forax at univ-mlv.fr
Sun Sep 11 10:19:16 UTC 2022


----- Original Message -----
> From: "Brian Goetz" <brian.goetz at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Sent: Saturday, September 10, 2022 4:01:23 PM
> Subject: Re: Primitives in instanceof and patterns

>> I think you are overstating how useful a pattern that do a range check is.
> 
> I think you're falling into the trap of examining each conversion and
> asking "would I want a pattern to do this."  That's a recipe for more
> complexity because we'll end up with another ad-hoc,
> not-like-anything-else construct (which is what the Java 19 primitive
> type pattern semantics is.)  It's not about "is range check useful"
> (though, it is), its about "is casting to/from primitives safely" useful.

Given that only primitive widening casts are safe, allowing only primitive widening is another way to answer to the question what a primitive type pattern is.
You are proposing a semantics using range checks, that's the problem.

> 
>> I'm not against changing what a type pattern is but it should be done
>> in concert with changing the other rules (overriding rules especially)
>> and the retrofitting of primitive types to value classes.
> 
> It's not about "changing other rules", its about aligning to them. We're
> aligning to cast conversion here.  When we have named patterns, we will
> have to define overload selection for patterns; again, this should just
> be the existing overload selection with "arrows reversed", which means
> we want boxing for patterns to also be "boxing with arrows reversed"
> (otherwise it doesn't compose.) The language we have now is telling us
> how patterns should work; we should listen.

As an example, instanceof rules and the rules about overriding methods are intimately linked, asking if a method override another is equivalent to asking if their function types are a subtypes.

if int instanceof double is allowed, then B::m should override A::m
  class A {
    int m() { ... }
  }
  class B extends A {
    @Override
    double m() { ... }
  }

This is what i meant by changing other rules.

Rémi


More information about the amber-spec-experts mailing list