Proposal: Improved Wildcard Syntax for Java

[Stephen Colebourne]

After some thought, I've decided I oppose this feature.

The basic reasoning is that 'out' and 'in' are sufficiently more 
meaningful to developers to justify the complexity of a language change 
and supporting two ways to define the same thing. I disagree with that.

(ie. I find nothing wrong with the technical aspects of the 
proposal/spec, other than a distaste for context sensitive keywords in 
general)

If I see the following:

  public static createList(Collection<? extends Number> coll)

then I read it as:

  "takes a collection of Number or anything extends Number".

If I see:

  public static sort(Comparator<? super Number> coll)

then I read it as:

  "takes a comparator of Number or any superclass of Number"

I personally don't find the PECS shorthand that useful. And the 'out' 
and 'in' keywords don't mean anything to me at all right now.

Perhaps the point is whether we want to define the type (Number or 
anything that extends Number) or the action we can take (get stuff 
'out'). I think Java is type-focussed, not action-focussed.

Stephen


Neal Gafter wrote:
> Improved Wildcard Syntax for Java
> http://docs.google.com/Doc?id=ddb3zt39_79g2mtpccz
> 
> AUTHOR(S):
> 
> Neal Gafter
> 
> OVERVIEW
> 
> The current syntax for Java's wildcards is confusing enough that
> mneumonics are required to read code.  We suggest adding an
> alternative syntax that is much more readable, and then migrating code
> to the more readable syntax over time.
> 
> FEATURE SUMMARY:
> 
> [Note: since this is an additional syntax for a feature already in the
> language, most existing tutorial material can be used.]
> 
> A covariant wildcard generic argument can be written either "? extends
> Y" or "out Y".
> 
> A contravariant wildcard generic argument can be written either "?
> super Y" or "in Y".
> 
> MAJOR ADVANTAGE:
> 
> While the existing syntax is mneumonic from the point of view of
> describing its effect on the type system, it is not mneumonic in its
> use.  The new syntax is self-mneumonic for users.
> 
> MAJOR BENEFIT:
> 
> Jave code that uses wildcards is more readable, as are diagnostics
> involving them.
> 
> MAJOR DISADVANTAGE:
> 
> Two ways of doing the same thing, though we hope code will migrate
> over time toward the new more readable syntax.
> 
> ALTERNATIVES:
> 
> None.
> 
> EXAMPLES
> 
> SIMPLE EXAMPLE:
> 
> interface Collection<E> {
>     boolean addAll(Collection<out E> c);
>     ...
> }
> 
> ADVANCED EXAMPLE:
> 
> class Collections {
>     public static <T extends Comparable<in T>> void sort(List<T> list) {...}
>     public static <T> void sort(List<T> list, Comparator<in T> c) {...}
>     int binarySearch(List<out Comparable<in T>> list, T key) {...}
>     public static <T> void fill(List<in T> list, T obj) {...}
>     public static <T> void copy(List<in T> dest, List<out T> src) {
>     ...
> }
> 
> DETAILS
> 
> SPECIFICATION:
> 
> "in" and "out" are added as context-sensitive keywords with precisely
> the same meaning of "? super" and "? extends".  As context-sensitive
> keywords, they continue to be usable as identifiers in all contexts.
> 
> COMPILATION:
> 
> As today.
> 
> TESTING:
> 
> As today, though a bit of additional work to ensure that the context
> sensitive keyword is handled properly by the compiler.  Specifically,
> that they continue to be fully usable as identifiers in other
> contexts.
> 
> LIBRARY SUPPORT:
> 
> None.
> 
> REFLECTIVE APIS:
> 
> None.
> 
> OTHER CHANGES:
> 
> None.
> 
> MIGRATION:
> 
> A trivial textual substitution can be used to translate old code to
> the new syntax.
> 
> COMPATIBILITY
> 
> BREAKING CHANGES:
> 
> None.
> 
> EXISTING PROGRAMS:
> 
> No impact.
> 
> REFERENCES
> 
> EXISTING BUGS:
> 
> None
> 
> URL FOR PROTOTYPE (optional):
> 
> None
> 
>