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
