Proposal: Improved Wildcard Syntax for Java
reinier at zwitserloot.com
Sun Mar 1 10:49:06 PST 2009
Neal, what I mean is the following sample cannot be translated to your
public static <T extends Comparable<? super T>> void sort(List<T>
The "T extends Comparable" part cannot be replaced with just 'out
Comparable'. My suggestion involves allowing this to be rewritten as:
public static <T out Comparable<in T>> void sort(List<T> list);
Though, I share Stephen Colebourne's concern that the out/in syntax
can be just as confusing in other situations, again highlighting how
out/in and extends/super would co-exist (instead of a slow but steady
migration towards out/in syntax), complicating the language.
On Mar 1, 2009, at 08:28, Neal Gafter wrote:
> 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/
>> 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
>> '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
>> 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
>> 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
>> 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
> You don't have to remember that when reading and writing the new
>> 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
More information about the coin-dev