[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: Thursday, January 27, 2022 2:04:35 PM
> Subject: Re: [External] : Re: Diamond in type patterns (was: Reviewing feedback
> on patterns in switch)

>> 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’d like to drill into this supposition. My supposition (maybe wrong) is that we
> already solved most of this when we did `var`, with upward projection.

> To recap, we spent a lot of time with `var` on what to do about non-denotable
> types. These included the null type (banned on the grounds of uselessness),
> intersection types (allowed), and capture types (sanitized with upward
> projection.) The basic idea of upward projection is that when we infer
> List<cap>, we replace it with a super type that has no capture types, and get
> List<?> out. (There’s also a downward projection.)

> Let’s start with your examples of where ordinary inference produces an
> undesirable result, and then evaluate whether either or the projections solves
> the problem?

I don't think current projections are enough because we may want the inference to insert a wildcard by itsef, 
for example with 
Object o = ... 
var list = (List<>) o; 

or maybe we should not try to infer such code. 

Rémi 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/amber-spec-experts/attachments/20220127/2261f1d2/attachment-0001.htm>