Final variables without explicit type: Intersection types issue. (original) (raw)

Reinier Zwitserloot reinier at zwitserloot.com
Sat Mar 21 15:51:44 PDT 2009

Intersection types are annoying, to say the least. Possibly hand-wave
it away by stating that you can't use those expressions in this new
language construct.

Or, a slight adaptation to that: If all but 1 of the intersection
types are subtypes of the other one, and this can be said for only 1
type, then that type wins. Thus:

final foo = someBoolean ? Arrays.asList("foo", "bar") : new
ArrayList();

foo's type would be List, because that's the type of one of
the intersections (List), and all other types of that
intersection (ArrayList) are a subtype of this, and there's no
other type for which this can be said. However, writing up the
specifics of this sounds difficult to say the least, and it can always
be added in java8 if it causes an inordinate amount of whining.

Either way, this:

final foo = someBoolean ? new LinkedList() : new
ArrayList();

would be a compiler error. What should foo be? List?
AbstractList? Serializable? Cloneable? Object? They're all
common supertypes, and there's no clear winner in the set; attempting
to use the nearest common parent still gives you 2 winning options:
Serializable, and Cloneable, while in actual fact you were probably
shooting for List, which isn't even close to the winner here,
what with AbstractList in the way, and AbstractList itself being 2
removed from LinkedList, which extends AbstractSequentialList, which
extends AbstractList.

I think it'll be okay to just compiler-error on those, because I
expect the majority usage would be something akin to:

final foo = methodCall();

--Reinier Zwitserloot

On Mar 21, 2009, at 22:46, Florian Weimer wrote:

* John Rose:

On Mar 21, 2009, at 12:52 PM, Marek KozieĊ‚ wrote:

Allow final variables and final Fields (except blank final), to not having explicit Type. Yes. Someone should work exactly this (and no more) into a separate proposal, if it hasn't been done already. What should be the inferred type of an expression with an intersection type? Is there an answer which is acceptable in the COIN context?

More information about the coin-dev mailing list