Type primitive pattern: the problem with primitive and boxing

[Brian Goetz]

Coming back to Remi's other question.

As a reminder, pattern matching has _almost no independent semantics_; 
its semantics are derived from that of conversions (and casting context.)

The second code does not compile _today_, because, while there is a 
conversion from byte to int, there is no conversion from byte to Integer 
(specifically, a primitive widening followed by a boxing operation.)  
Valhalla will introduce new conversions, such as `Foo! <--> Foo?` 
conversions, and possibly (as was discussed at JVMLS) user-defined value 
widening and narrowing conversions. All of this will require some revamp 
of Conversions and Contexts, including both restructuring of the 
presentation and adding some new conversions.  At the same time, 
irregularities like why is "PW+Box not in the same bucket as other 
unconditional conversions" can be addressed.

So yet again, this has absolutely nothing to do with the proposed 
semantics of type patterns; it has everything to do (again) with 
oddities and irregularities in the conversions story -- which can (and 
will) be improved.

And, just as with the previous, the wild leap from "something is 
imperfect now" to "OMG you are breaking the world" was ... 
overstated.  So I will reiterate the same reminder as the previous:

> So next time, if you see an inconsistency, instead of thumping your 
> shoe on the table and crying "mistake! mistake!", you could ask these 
> questions instead:
>
>  - This seems like an inconsistency, but is it really?
>  - If this is an inconsistency, does that mean that one case or the 
> other is mistake?
>  - If there is a mistake, can it be fixed?  If not, should we consider 
> changing course to avoid confusion, or are we better off living with a 
> small inconsistency to get a greater benefit?



On 9/11/2025 10:52 AM, Remi Forax wrote:
> Following Brian and Dan comments, I restart several different threads.
>
> The way JEP 507 semantics is defined does not work well with the idea that int can be seen as a subtype of Integer, or at least seen int and Integer! as interoperable.
>
> For example, this code compile
>    int v = ...
>    switch(v) {
>      case byte b -> ...
>      case int i -> ...
>    }
>
> But this code does not compile
>    Integer v = ...
>    switch(v) {
>      case byte b -> ...
>      case int i -> ...
>    }
>
> so at best there is a risk of making our lives (the Valhalla EG) miserable in the future because of the semantics of this JEP, at worst, in the future, people will declare the component of their records either as an Integer! or as an int to get the flavor of pattern matching they want.
>
> regards,
> Rémi
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/amber-spec-observers/attachments/20250912/151a4797/attachment.htm>