> From: "Brian Goetz" <brian.go...@oracle.com> > To: "Remi Forax" <fo...@univ-mlv.fr> > Cc: "amber-spec-experts" <amber-spec-experts@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
