[External] : Re: Diamond in type patterns (was: Reviewing feedback on patterns in switch)

[forax at univ-mlv.fr]

> 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: Wednesday, January 26, 2022 3:34:21 PM
> Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing feedback
> on patterns in switch)

>> I think we should figure out how it should work on cast and then we can happily
>> applied it on patterns.

> I’m happy to have the cast discussion happen concurrently, but right now, my
> priority is on patterns, as we’re already two previews into patterns-in-switch.

remember, the move from preview to real feature should be only when we are ready 

> But I’m not ready to say “we can’t solve this for patterns unless we also solve
> it for cast RIGHT NOW. So I agree with the goal (solve it everywhere,
> eventually) but not with the ordering constraint.

It's more an engineering thing here, we have far more casts than switch + pattern in existing code, and given that we suppose (perhaps wrongly) that the semantics of the inference is not exactly one already existing, 
i think we will get better result if we try to automatically transforms all existing casts using a parametrized type to diamond casts and see when the inference fails and why. 

Also this feature is fully orthogonal with the rest of the patterns because the diamond syntax in type pattern is an invalid syntax, so this feature can have it's own tempo. 

>> despite the syntax being the same, the diamond syntax, i don't think we can
>> reuse the same inference rules between the new diamond and the cast diamond.

> Understood. (This is why, for example, we introduced upward and downward
> projection when we did var, because the rules for inference were not what we
> wanted for var.) But before we go on to the details, are we agreed on the goal?

Agree on the goal, but do you agree on the methodology i propose above. 

Rémi