> On 28 Feb 2020, at 11:52, fo...@univ-mlv.fr wrote:
>
> ----- Mail original -----
>> De: "Brian Goetz" <brian.go...@oracle.com>
>> À: "Remi Forax" <fo...@univ-mlv.fr>, "Gavin Bierman"
>> <gavin.bier...@oracle.com>
>> Cc: "amber-spec-experts" <amber-spec-experts@openjdk.java.net>, "jan lahoda"
>> <jan.lah...@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 ?
>
That’s exactly it! We just want to make sure we don’t bake something in that
won’t work for more general overloaded deconstructors.
Gavin
