[External] : Re: Primitive type patterns

[forax at univ-mlv.fr]

----- 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: Monday, February 28, 2022 10:00:08 PM
> Subject: Re: [External] : Re: Primitive type patterns

> This is a valid generalized preference (and surely no one is going to
> say "no, I prefer to play to our weaknesses.")  But at root, I think
> what you are saying is that you would prefer that pattern matching
> simply be a much smaller and less fundamental feature than what is being
> discussed here.  And again, while I think that's a valid preference, I
> think the basis of your preference is that it is "simpler", but I do not
> think it actually delivers the simplicity dividend you are hoping for,
> because there will be subtle mismatches that impede composition and
> refactoring (e.g., new "null gates" and "box gates".)

There are two ways to express "match non null Integer + unboxing",
this one
  Integer value = ...
  switch(value) {
    case Integer(int i) -> ...
  }

And we already agree that we want that syntax.

You are proposing a new one
  Integer value = ...
  switch(value) {
    case int i -> ...
  }

Obviously, your proposal makes things less simple because we new have to ways to say the same thing.

Moreover, introducing assignment conversions introduce more corner cases,
we already discussed about 
- unboxing + widening being supported while than the widening + unboxing is not,
- pattern matching behaving differently from the visitor pattern/method overriding rules

There is also issues IMO when you start mixing wrappers and primitive types.

Just ask yourself, can you predict if the following codes compiles and if it compiles, which case is called depending on the value of value.

    Integer value = ...
    switch(value) {
      case double d -> ...
      case Integer i -> ...
    }

    int value = ... 
    switch(value) {
      case float f -> ...
      case Integer i -> ... 
    }

    int value = ... 
    switch(value) {
      case Float f -> ...
      case Integer i -> ... 
    }

I think we do not need assignment conversions *and* that introducing them makes the semantics harder to understand.

Rémi