Pattern Matching for instanceof (Preview 2)

[forax at univ-mlv.fr]

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>, "Gavin Bierman" <gavin.bierman at oracle.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>, "jan lahoda" <jan.lahoda at oracle.com>
> Envoyé: Mardi 18 Février 2020 16:14:57
> Objet: Re: Pattern Matching for instanceof (Preview 2)

>>> I don’t know what you mean here. There are two patterns, a type test pattern and
>>> a deconstruction pattern. In v2 we propose to support deconstruction patterns
>>> over record types *only*. A deconstruction pattern looks like this: Point(var
>>> a, var b), i.e. all the components are either (recursively) deconstruction
>>> patterns, or `var` <identifier>, i.e. with no type needed. I added a note to
>>> the JEP page pointing out that this is a starting point, and eventually we will
>>> support other patterns in the argument position, specifically <type>
>>> <identifier>; hopefully in this release.
>> Currently we don't support mixing var and non var in lambda parameters.
>> So my question is: does this pattern Point(var x, int y) that mix a 'var' and an
>> explicit type allowed or not ?
> 
> Unequivocal "yes".   There is a universe of patterns.  Some might be
> disallowed in certain contexts (e.g., `instanceof var x` seems kind of
> silly), but once we decide on the set of patterns allowable in which
> contexts, any pattern can be nested inside a deconstruction pattern.
> 
> The `var x` pattern can equally be thought of as inference for a total
> type pattern, or an "any" pattern; they are semantically equivalent.
> 
> If you're asking "but why can I not mix them in a lambda", the answer
> is: because we don't support partial inference in lambdas at this time.
> We could, and we might someday.  (If you're suggesting that the
> consistency between the two superficially-related forms is the most
> important consideration here, I would disagree.)


with a record, there is no real inference, but when you will have several deconstructors, we will need inference, right ?

Rémi