Primitives in instanceof and patterns

[Brian Goetz]

>> (When we get to overloading deconstruction patterns, we'll have all the
>> same issues as we have with overloading methods today -- it is not
>> obvious looking only at the call site, which overload is called, and
>> therefore which conversions are applied to arguments or returns.)
> We do not need overloading of patterns !
> I repeat.
> We do not need overloading of patterns !

You would be incorrect about that.

Deconstruction patterns are the dual of constructors.  Pairing a 
constructor (or factory) with a deconstruction (or static) pattern forms 
an embedding-projection pair, which is what drives, e.g., the `with` 
construct.  This is a very powerful relationship. Constructors can be 
overloaded; saying "but deconstructors can't" is just a gratuitous 
restriction, and it undermines the role of patterns as the dual of 
ctors/methods.

At the risk of repeating myself, it is clear that you just want pattern 
matching to be a much smaller feature.  That's a valid opinion, but 
please stop with the "not a good idea" / "not needed" / "useless" / 
"YAGNI" at every turn.  There's a big story here; you can agree with it 
or not, but please, please, please stop trying to talk down every part 
of the story because it seems "too big" to you.  If you don't understand 
the big story, ask (constructive) questions.  But please, please, stop 
trying to YAGNI away everything.  It's not helpful.

> Nope,
> let me recapitulate.
>
> 1) having a primitive pattern doing a range check is useless because this is rare that you want to do a range check + cast in real life,
>    How many people have written a code like this
>
>     int i = ...
>     if (i >= Byte.MIN_VALUE && i <= Byte.MAX_VALUE) {
>       byte b = (byte) i;
>       ...
>     }
>
>    It's useful when you write a bytecode generator without using an existing library, ok, but how many write a bytecode generator ?
>    It should not be the default behavior for the primitive type pattern.
>
> 2) It's also useless because there is no need to have it as a pattern, when you can use a cast in the following expression
>     Person person = ...
>     switch(person) {
>       // instead of
>       // case Person(double age) -> foo(age);
>       // one can write
>       case Person(int age) -> foo(age);  // widening cast
>     }
>
> 3) when you read a conditional primitive patterns, you have no idea what is the underlying operation until you go to the declaration (unlike the code just above).
>
>
> 4) if we change the type pattern to be not just about subtyping, we should revisit the JLS to avoid to have too many different semantics.
>

Thanks for stating your concerns succinctly.  (Some of this is just 
subjective "I want patterns to be a smaller feature"; some is 
disagreement with decisions that are already made.)