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

Brian Goetz brian.goetz at oracle.com
Wed Mar 3 16:09:08 UTC 2021

>>> 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.

True, and I hate it.  This is related to the C-style array decl; for the 
first year it was really important that Java seem friendly to C 
developers, and this was one of the compromises.  For the rest of time, 
it is just an annoying irregularity.

>> 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.

Where I'm going here is that I don't want to introduce a "pattern 
assignment" statement that is new and different from local variable 
declaration with initializer; I want to make the semantics align 100%, 
so that pattern assignment is a pure generalization of local variable 
declaration with initializer.  We're 96% of the way there.

More information about the amber-spec-experts mailing list