As I mentioned elsewhere, we probably don't want to allow omitting the type after "covariant", so maybe:

simpleFormalParameter:
  metadata ("covariant" "final"? type | finalConstVarOrType?) identifier

If covariant is neither a keyword nor a built-in identifier, then it can also be used as a type name, so it makes sense that we would require a type to follow it in order to prevent ambiguity.

class covariant {
  void m(covariant covariant c) {}
}

but what about the case of a function signature? Consider

class covariant {}
class Timer {
   int time(covariant f()) {}
}

How should we interpret the covariant before the parameter f?

Also, as a minor nit, the way the production normalFormalParameter is written the covariant keyword comes before the metadata for the parameter. I assume that isn't the intent. (Technically, the spec makes the same mistake for static and/or external functions, but analyzer ignores that and expects the metadata to precede any keywords. I expect we should do the same here.)

That was the reason that I want to require the type.
The function type is a problem, though.

Looking more closely at Lasse's suggestion, it isn't clear to me why we'd disallow the use of either const or var with covariant, or why final would require a type. If those aren't desired restrictions, how about:

simpleFormalParameter:
  metadata ("covariant" finalConstVarOrType | finalConstVarOrType?) identifier

I think that could work too. The only problem with omitting the type (and why people will probably not do it even if they can) is that it's not clear which type the parameter is covariant wrt. Still, it should work.

Also, the function type example above isn't a problem because that syntax isn't handler by simpleFormalParameter. It means that you can't write covariant in front of a function signature (or if you do, it's a type - but that's silly, so maybe we should just make it a built-in identifier as soon as possible, it's not going to break anybody anyway).

I've introduced a new functionFormalParameter to work as the variant of functionSignature which is intended to declare a formal parameter. That one needs to admit covariant on the parameter declaration as a whole, but other usages of functionSignature (e.g., for declaring a top-level function) should not. We can't just add covariant in front of a functionSignature in the rule for normalFormalParameter, because it would then put the metadata in an inconsistent location.

Next, I have made covariant a built-in identifier, which I believe is accepted at this point. So covariant cannot be a type, and hence we cannot have the function header void foo(covariant covariant covariant);.

This means that we do not need to disambiguate unconditionally when seeing covariant in the parser, which means that we do allow omitting the type (void foo(covariant x);) and using covariant as the name of the parameter (void foo(covariant); and void foo(bool covariant);).

As a consequence, we interpret int time(covariant f()) as having a covariant parameter named f whose type is dynamic Function().

Ah, @bwilkerson, I overlooked that you already mentioned the metadata/"keyword" ordering issue. As mentioned, I do handle the issue for covariant in the proposal, but I created a new issue about the similar issues that arise with static and external.

field -> instance field

(I know, "field" usually means instance, but it hasn't been formally defined - the formal name is "instance variable").

Now using non-final instance variable.

Sounds slightly weird:
X can only do foo or bar, and it can do baz.
It's technically correct, but how about:

The covariant modifier can only be applied to a formal parameter on an instance
method, instance setter, or instance operator, or to a non-final instance field.

I'm now using the usual spec style 'It is a compile-time error if ..'.

"Type checking" is very overloaded. I would expect it to be the checking of values against types.
Maybe "... the validity of the type of the overriding ..." (but not perfect either)

This is now completely different.

You can remove "directly". Since it's transitive, it's the same thing, but I think it's simpler without.

The spec defines 'overrides' to mean 'overrides directly' (cf. \ref{inheritanceAndOverriding}: 'Then $m$ overrides $m^\prime$ if $m^\prime$ is not already overridden by a member of at least one of $S_1 \ldots S_{j-1}$'). This means that we can talk about 'overrides' and 'indirectly overrides'. But I thought that would be too subtle, so I made it a bit more explicit and used 'directly overrides' and 'indirectly overrides'.

Of courses, the spec never needs to talk about 'indirectly overrides', because it suffices to talk about the relationship between a declaration and the declaration that it directly overrides for all current purposes. But that won't suffice for covariant parameter type checking.

I'm not sure what this shows - subtyping never had anything to do with member signatures. Either elaborate what the concern could be, or remove the section, because I can't figure out what point it's trying to make.

Removed from the informal spec part, which is what I'm currently working on. It is still present at the end of the document (I'll return to that soon).

The one that reports an error at compile time won't fail at runtime - since it can never run.

Just use the actual return type. It must be a subtype of all other return types, and there is nothing special about return types that makes you need to look at super declarations.
It's only because the "original type" is different from the "desired type" and "original type" isn't written in the function declaration, that we need to look at super-declarations to find it for covariant parameters.

Right, I'll just use the declared return type!

The LUB/MAX we are discussing elsewhere has the property that it sometimes has to give up. In that case, we should probably use Object here (which is always an upper bound). For inference, we want something else that defaulting to Object, so it's not part of the "LUB" computation.

We could also simply reject the covariant parameter which creates a situation where there is no "reasonable" dynamic type. (Or we could use guarded functions ;-)

Long sentence. Could there be a comma before "the meaning"?

Does "contextual" keyword mean that covariant is neither a keyword nor a built-in identifier in the sense defined in the spec?

If possible, yes. That's the least breaking way to introduce it.

The alternative is to make it a built-in identifier like get and set, but I would prefer to avoid that, at least until 2.0.

I've had widespread support for making it a built-in identifier today. We can take another fight or two about it, but my current work is based on that assumption.

If covariant is neither a keyword nor a built-in identifier, then it can also be used as a type name, so it makes sense that we would require a type to follow it in order to prevent ambiguity.

class covariant {
  void m(covariant covariant c) {}
}

but what about the case of a function signature? Consider

class covariant {}
class Timer {
   int time(covariant f()) {}
}

How should we interpret the covariant before the parameter f?

Also, as a minor nit, the way the production normalFormalParameter is written the covariant keyword comes before the metadata for the parameter. I assume that isn't the intent. (Technically, the spec makes the same mistake for static and/or external functions, but analyzer ignores that and expects the metadata to precede any keywords. I expect we should do the same here.)