[External] : Re: Primitive type patterns

[Brian Goetz]

On 3/2/2022 2:36 PM, forax at univ-mlv.fr wrote:

> 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.

Wait, what?  The above is not yet on the table; we will have to wait for 
deconstruction patterns on classes to be able to express that. When we 
get there, we'll have a choice of whether we want to add a deconstructor 
to the wrapper classes.  (At which point, you might well say "we already 
have a way to do that"...)

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

But if it was on the table now, it would still not be particularly 
notable as a "new way" of anything; this would be true for *every single 
nested pattern*.  In fact, that's a feature, not a bug, that you can 
unroll a switch with a non-total nested pattern to a nested switch, and 
that is a desirable refactoring to support.

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

Not obvious at all.  Java's simplicity does not derive from "exactly one 
way to do each thing"; suggesting otherwise is muddying the terms for 
rhetorical effect, which is not helpful.

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

The former is a valid opinion, and is noted!