OK, I get your point now.  Your concern is not about *inference*, but 
specifically how *diamond* will snap to the bound when it infers a wildcard, 
because `new` doesn’t allow wildcards.  But we do something differently for 
inferring type variables of generic methods (we’ll gladly infer a capture) or 
locals (we’ll project a capture to a nearby super type without capture.)

On Jan 27, 2022, at 8:20 AM, fo...@univ-mlv.fr<mailto:fo...@univ-mlv.fr> wrote:



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


Reply via email to