Thanks. Yes, we did remove this syntax deliberately - apologies that it didn’t 
make the change list. 

I’ll tidy up the remaining inconsistency in the first version of the next 
records JEP JLS doc.

Gavin

> On 24 Jul 2020, at 05:06, Tagir Valeev <[email protected]> wrote:
> 
> Btw if this change is intended, then it looks like the changes in
> section 10.2 [1] must be dropped as well
> 
> The array type of a variable depends on the bracket pairs that may
> appear as part of the type at the beginning of a variable declaration,
> or as part of the declarator for the variable, or both. Specifically,
> in the declaration of a field, formal parameter, local variable, or
> record component (8.3, 8.4.1, 9.3, 9.4, 14.4.1, 14.14.2, 15.27.1,
> 8.10.1), the array type of the variable is denoted by <...>
> 
> Now, this text is inconsistent with 8.10.1.
> 
> With best regards,
> Tagir Valeev.
> [1] 
> http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/records-jls.html#jls-10.2
> 
> 
> 
> On Fri, Jul 24, 2020 at 10:55 AM Tagir Valeev <[email protected]> wrote:
>> 
>> Hello!
>> 
>> The JLS 14 record preview spec allows C-style array declaration in
>> components (like record R(int x[])) [1]:
>> 
>> RecordComponent:
>>  { VariableModifier } UnannType VariableDeclaratorId
>>  VariableArityRecordComponent
>> VariableDeclaratorId:
>>  Identifier [ Dims ]
>> 
>> However, it appears that JLS 15 draft spec doesn't allow it anymore [2]
>> 
>> RecordComponent:
>>  { Annotation } UnannType Identifier
>>  VariableArityRecordComponent
>> 
>> This change is not listed in the draft spec prolog in "The changes are
>> the same as those in the first preview of Records in Java SE 14,
>> except for the following", so I overlooked it when updated the records
>> support in IntelliJ IDEA. Is this intended change? If yes, then
>> probably the changes section should be updated to include it as well.
>> 
>> I must say that I heavily support this change. Supporting C-style
>> array declaration in records adds complexity in many places of our
>> codebase and introduces subtle bugs. It's somewhat depressing to fix
>> all of them, knowing that nobody would use this anyway.
>> 
>> With best regards,
>> Tagir Valeev.
>> 
>> [1] 
>> https://docs.oracle.com/javase/specs/jls/se14/preview/specs/records-jls.html#jls-8.10.1
>> [2] 
>> http://cr.openjdk.java.net/~gbierman/jep384/jep384-20200506/specs/records-jls.html#jls-8.10.1

Reply via email to