Proposal: Improved Wildcard Syntax for Java

[Neal Gafter]

On Sat, Feb 28, 2009 at 11:08 PM, Reinier Zwitserloot
<reinier at zwitserloot.com> wrote:
> This proposal is lacking in the 'disadvantages' section, in two ways.
>
> The listed disadvantage is unfairly sugared over; because the 'out/in'
> terminology does not allow you to bind the generics parameter, the
> 'extends'/'super' syntax will never become outdated and the need to
> remember that 'out' is analogous to 'extends' and 'in' is analogous to
> 'super' does not go away.

I don't understand.  out/in bind the generic parameter in precisely
the same way that ?extends and ?super do.  What you describe is a
disadvantage of the current syntax, but when using the new syntax you
don't have to remember it, because the new syntax is self-mneumonic.

> There's another disadvantage that isn't listed at all: Neither 'in'
> nor 'out' are keywords in java currently. Therefore, you introduce the
> notion of a context-sensitive keyword, but as far as I understand it,
> java does not currently have context-sensitive keywords. Adding them
> is a big can of worms that should probably warrant some discussion (in
> the sense that it may complicate java parsers, and how the idea of
> context-sensitive keywords makes it a lot harder for any parser to use
> a keyword as an anchor point); at any rate it is a disadvantage that
> should be listed.

Any change in syntax has to be considered for its interaction with
other tools, but for this particular case the general concerns you
express don't seem to be an issue.  For example, this syntax is very
easy to parse with no more than the usual one-token lookahead.

> There's also a typo in 'mneumonic' :)
>
> NB: For what it's worth, because the need to remember super-produces
> extends-consumes does not go away, I don't think this is going to help
> much.

You don't have to remember that when reading and writing the new syntax.

> Perhaps make 'out' and 'in' valid context-sensitive keywords
> that can be used as a substitution for super and extends

That's exactly what we've done, but with in/out you don't use the
question mark either.

> and add that
> a missing generics variable on the LHS implies a wildcard?

I don't understand what you propose, or see how it relates to this proposal.