Yield as contextual keyword
alex.buckley at oracle.com
Thu May 23 23:51:48 UTC 2019
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
> 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
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
More information about the amber-spec-observers