[External] : Pattern assignment statements (extracted from: Primitive type patterns and conversions)

Remi Forax forax at univ-mlv.fr
Wed Mar 3 11:18:03 UTC 2021

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> À: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "amber-spec-experts" <amber-spec-experts at openjdk.java.net>
> Envoyé: Mardi 2 Mars 2021 18:44:27
> Objet: Re: [External] : Pattern assignment statements (extracted from: Primitive type patterns and conversions)

>> A couple of other things to consider:
>> 1. C-style array declaration is not allowed in patterns.
> Wish we could phase out C-style array decls entirely...
>> 2. For local variable declaration, the initializer can omit `new int[]` part:
>> int data[] = {1, 2, 3}
> Good catch.  For some reason I was thinking this was only for fields,
> but it works for locals too.  There's a future story about collection
> literals, but it is unlikely we'll be able to retcon exactly this
> syntax.  (#include "bikeshed-deterrent.h")

the whole story about initializing a local variable with an array is weird,
  int data[] = {1, 2, 3};
compiles but
  int data[];
  data = {1, 2, 3};
does not.

> We may be able to address this by including a conversion from an array
> initializer to the target type of a pattern in an unconditional pattern
> assignment context.

while if think we have specify inference that uses the target type in order to avoid to avoid type patterns with a lot of redundant type information,
i'm not sure emulating that particular quirk of Java is a good idea. 

>> 3. Local variable type may affect the initializer type (e.g.
>> List<String> list = List.of()). What about patterns? Can we say that a
>> `List<String> list` pattern is a total pattern over `List.of()`
>> expression type?
> Yes, patterns have a notion of a target type, which is the type they
> have declared as their matchee.  For a type pattern `T t`, that target
> type is T.  We already evaluate whether the pattern is applicable to the
> matchee using this type.

yes, but we have to be careful here, as i said earlier, the inference you want when you do an instanceof/cast and the inference we already have can be at odd.
By example, with
  Object o;
  if (o instanceof List<> list) { .... }
inferring List<Object> has the current inference algorithm does will lead to a compile error.

Does it means we have two kind of inference algorithms ? In that case, how it works when they interact with each other (when i have a switch inside a lambda by example) ?
And in that case, what is the inference algorithm used in pattern assignment statements ?

At that point, my head explode :)



More information about the amber-spec-experts mailing list