A plea for a readable Java (for each, Set Integer & subclasses )

Question

I like the new language features a lot, but I don't like the proposed syntax. I thought the great thing about Java was that it got us away from the awful C++ punctuation soup. Here's my proposal for a more readable syntax without adding new keywords to the language:
for each (Item i in collection) { ... }
'for' is already a keyword. By separating this, we can part this production as:
ForStatement: for Identifier ( Type VariableDeclaratorId Identifier Expression ) Statement
(Using the productions and terminals in the JLS).
Note that, after the first 'for' is encountered, the parser can look at the next token (right-paren or Identifier) to determine whether this is a 'for each' or an old-style 'for' statement. We don't need to make 'each' or 'in' into an keyword, and they don't conflict with variable, method, or class names. Semantic checking will simply ensure that the Identifiers mentioned have the appropriate contents.
Next, for the variance syntax:
Set<Integer & subclasses> Set<Integer & superclasses> Set<*>
Again, the grammar here is:
Identifier < Type & Identifier> | Identifier < * >
The '&' is not otherwise allowed in parameterized types before 'extends', so there is no grammar ambiguity. The Identifier following & in this production is checked to be only 'subclasses' or 'superclasses' (otherwise a syntax error). There is no conflict with class names, because Set<Integer & Foo> is not a legal use for a class named 'Foo'.
To save typing, perhaps 'subclasses'/'superclasses' can be shortened to 'sub'/'super' without sacrificing readability. I expect invariant types will still be most-heavily used, so I don't think fingers will be hurting all that much.
Perhaps this Identifier-not-keyword idea can be taken further with some of the other new grammar productions? I await suggestions!
Comments/Votes?

Answer 1

Read the papers on variance. In a nutshell, a generic
type A<X> is not related to the generic type A<Y>,
regardless of the relationship between X and Y.
Variance changes that and is a proposed addition in
the (very) new generics implementation.I find your comment confusing. Maybe I am misunderstanding the OPs intentions with this syntax.
Right now:
List<java.util.Date> is a List that only allows instances of java.util.Date. I can still add a java.sql.Date to this list, though, because an instance java.sql.Date is an instance of java.util.Date.
His proposal:
List<String & superclasses> Now given the current syntax, I would take this to mean that this defines a List that takes instances of String and an instances of any superclass of String i.e. instances of Object i.e. anything other than primitives.
I think what you are saying is that if I define a method (for example) like so, method(List<java.util.Date>) that I can't pass an List<java.sql.Date> to it. Understood, though I find that puzzling because that means an method that accepts a List shouldn't accept a List<String>. I didn't see anything in the OPs post that makes me think that is the context which this syntax would be used though it could be. Clarification would be nice.
In that context, however, List<String & superclasses> would still be quite useless because wouldn't it still evaluate to a method that accepts a List<Object>? What would be the value of rejecting more specifc List types but allow the most generic List type?