----- Original Message -----
> From: "Brian Goetz" <brian.go...@oracle.com>
> To: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>
> Sent: Tuesday, January 25, 2022 8:49:12 PM
> Subject: Diamond in type patterns (was: Reviewing feedback on patterns in
> switch)
>> 4. Diamond for type patterns (and record patterns)
>
>
> The type pattern `T t` declares `t`, if the pattern matches, with the type T.
> If T is a generic type, then we do a consistency check to ensure soundness:
>
> List<String> list = …
> switch (list) {
> case ArrayList<String> a: A // ok
> case ArrayList<?> a: B // ok
> case ArrayList a: C // ok, raw type
> case ArrayList<Frog> a: // error, would require unchecked conversion
> }
>
> All of these make sense, but users are going to be tempted to use `case
> ArrayList a` rather than the full `case ArrayList<String> a`, and then be sad
> (or confused) when they get type errors. Since the type can be precisely
> defined by inference, this seems a place for allowing diamond:
>
> case ArrayList<> a: B
>
> (And the same when we have record patterns.)
The questions we did not answer the last time we talk about that subject
- why should we allow raw types here ?
- given that this is equivalent to an instanceof + cast, why we can not use
diamond inference on cast ?
- how this inference work ? Is is the same inference than with the diamond
constructor ?
By example, if we have
List<?> list = ...
switch(list) {
case ArrayList<> a:
}
Do we really want to infer ArrayList<Object> to then rejects it because it's
an unsafe cast.
regards,
Rémi
