Final variables without explicit type: Intersection types issue.

Reinier Zwitserloot reinier at
Sun Mar 22 07:01:07 PDT 2009

The problem would be complexity; now, for the first time, you can have  
method-local variables whose type is an intersection type; until now  
that wasn't possible. I don't advocate allowing this syntax for fields  
(private final foo = "hello!";) but if that is ever added, what type  
would foo be if you ask via reflection?

If that kind of complexity is within scope for coin, by all means.

If type intersections already find a common supertype in the obvious  
cases, that's great! Makes this proposal even simpler.

  --Reinier Zwitserloot

On Mar 22, 2009, at 01:35, Neal Gafter wrote:

> Type inference, and the lub() operation that generates these  
> intersection types, does not produce intersection types in which any  
> member is a subtype of any other member of the set of intersected  
> types.  So, these rules about how to handle such situations are not  
> necessary.
> What's the problem just leaving the type of the variable an  
> intersection type?
> On Sat, Mar 21, 2009 at 3:51 PM, Reinier Zwitserloot <reinier at 
> > wrote:
> 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<String>();
> foo's type would be List<String>, because that's the type of one of
> the intersections (List<String>), and all other types of that
> intersection (ArrayList<String>) 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<String>() : new
> ArrayList<String>();
> would be a compiler error. What should foo be? List<String>?
> AbstractList<String>? 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<String>, 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