Yield as contextual keyword

[Alex Buckley]

On 5/23/2019 2:29 PM, Dan Smith wrote:
> 2) Type names: 'yield' might be used as the name of a class, type of
> a method parameter, type of a field, array component type, type of a
> 'final' local variable etc. Or we can prohibit it entirely as a type
> name.
>
> We went through this when designing 'var', and settled on the more
> restrictive position: you can't declare classes/interfaces/type vars
> or make reference to types with name 'var', regardless of context.
> That way, there's no risk of confusion between subtly different
> programs—wherever you see 'var' used as a type, you know it can only
> mean the keyword.
>
> I think it's best to treat 'yield' like 'var' in this case.
>
> 3) Method names: 'yield(' at the start of a statement means
> YieldStatement, but what about other contexts in which method
> invocations can appear?
> Taking inspiration from the treatment of type names, my preference
> here is to make a blanket restriction that's easy to visualize: an
> *unqualified* method invocation must not use the name 'yield'.
> Context is irrelevant. The workaround is always to add a qualifier.

This policy is "You can declare a method called `yield`, but you can 
only invoke the method by using qualified invocation syntax." OK, great.

Could the policy in SE 10 have been similar? -- "You can declare a type 
called `var`, but you can only declare a variable at the type by using a 
qualified name." -- `var x = ...` to always indicate LVTI, 
`com.example.api.var x = ...` to still be possible. The need for 
TypeIdentifier to kick `var` out of type names (such as the type name 
used in a LocalVariableDeclarationStatement) would be unnecessary, as 
the rules of 14.4.1 would special-case the `var` identifier like they do 
today.

OTOH, no-one has noticed that types called `var` can't be declared 
anymore, so maybe no-one will notice if types called `yield` can't be 
declared anymore.

Alex