Spec grammar doesn't accept "covariant late final" instance field

[munificent]

The grammar rules for instance fields are:

declaration ::= // other rules...
  | 'covariant' 'late'? varOrType initializedIdentifierList
  | 'late'? 'final' type? initializedIdentifierList
  | 'late'? varOrType initializedIdentifierList

As far as I can tell, that prohibits:

class C {
  covariant late final int x;
}

The VM and analyzer accept this without error.

The corresponding rule for local variables and parameters is:

declaredIdentifier ::= 'covariant'? finalConstVarOrType identifier

finalConstVarOrType ::= 'late'? 'final' type?
  | 'const' type?
  | 'late'? varOrType

And that does let you get covariant late final, so it seems like this is likely a spec bug in declaration. (Though as far as I can tell it's never useful because you're either using declaredIdentifier for a local variable where covariant is prohibited or for a parameter where late is prohibited.)

[lrhn]

Seems like a bug.
For instance variables, a late final variable with no initializer does have a setter, so it should be allowed to be covariant.

It's true that late is disallowed for parameters, and covariant is disallowed for local declared variables, so the combination is useless for local variables in general.

The grammar for a single instance variables, as I understand them, could be written as:

`external`? `abstract`? `static`? `covariant`? `late`? <finalConstVarOrType> <identifier> <initializer>? `;`

with the constraints that:

• An abstract declaration must not be external.
• A static declaration must not be abstract.
• A covariant declaration must not be static and must have a setter (so not final unless late and no initializer).
• A late declaration must not be external or `abstract``.
• A const declaration must be static and not late and must have an initializer (and maybe must not be external, don't remember off-hand)
• A declaration with an initializer must not be external or abstract.
• A non-static, non-abstract, non-external declaration without an initializer must either not be final, be late or be initialized by all generative constructors.

(Or something like that).

[eernstg]

@munificent wrote:

As far as I can tell, that prohibits:

class C {
  covariant late final int x;
}

Nice catch! We should certainly include covariant late final for an instance variable without an initializer.

@lrhn wrote:

The grammar for a single instance variables, as I understand them, could be written as:

That could be a refreshing clean-up operation on all those syntactic rules!

One detail is that we don't have external variables in the language specification now, and we shouldn't add them before we have released the stable 2.8 spec.

There are some cases which are not covered by these rules, e.g., static final x; is an error because it must be initialized.

But a grammar could still be similarly concise (and it does not rely on additional constraints, except for the non-grammatical rule that a nullable type requires initialization for some variables):

<varType> ::= 'var' | <type>
<coVarType> ::= 'covariant' <varType>
<finalVarType> ::= 'final' <type>? | <varType>
<initializer> ::= '=' <expression>

<instanceVariableDeclaration> ::=
  'external' ('static'? <finalVarType> | <coVarType>) <identifier> ';'
  'abstract' (<finalVarType> | <coVarType>) <identifier> ';'
  'static' <varType> <identifier> ';'
  'static' ('const' <type>? | <finalVarType>) <identifier> <initializer> ';'
  'static' 'late' <finalVarType> <identifier> <initializer>? ';'
  ('covariant' <varType> | 'late' <finalVarType>) <identifier> <initializer>? ';'
  'covariant' 'late' (<finalVarType> <identifier> | <varType> <identifier> <initializer>) ';'

I believe the grammatical form may be seen as more constructive (it's possible for a reader to derive all the forms, which is a goal-seeking constructive activity) whereas the constraints are oriented towards considering any particular possibility (invent something!) and then going over all the rules in order to see whether it's allowed.

[eernstg]

Closing: Fixed in #1728.