Description Sebastian Zarnekow 2011-04-06 09:24:21 EDT

TypeConformanceComputer#isConformant(TypeRef left, TypeRef right) may use lot of information to determine, whether the right reference is conformant to the left. It may query the synonym types provider or infer a function type from an interface that defines exactly one method. However, this information is only used and known internally to #isConformant.

There are several use cases that would benefit from something like

TypeConformanceComputer#findConformantType(TypeRef left, TypeRef actualRightType): TypeRef

e.g. type inference for branches or parameterized operations could leverage the expected type in a more advanced fashion.

//==========
val Iterable<Object> closure = [|<Object>newArrayList('a').iterator] // OK
val Iterable<Object> array = newArrayList('a').toArray // OK 
//==========
val Iterable<Object> branch = 
  if (true) 
    [|<Object>newArrayList().iterator]
  else
    newArrayList('a').toArray

The latter is a valid expression but the current inference algorithm will provide 'Object' as the type of the if-expression since it does not know about the applicable conversions for the closure and the array.

The same happens for inference of operation type arguments if a type parameter is used more than once and conversion is necessary to find a compatible type for all occurrences.

Important note:

Please search for a simple workaround for the var args problem in relation to primitives in the TypeArgumentContextProvider. The code is marked with the URL of this ticket.