I had an impression that it is enough to erase Array[_ <: T] to AnyRef, and then we will be fine, will we not? To be more precise, we could erase to Array[Object] if T is AnyRef or a subtype. Hence in this case we probably cannot say that lub loses essential information.

On Fri, May 3, 2013 at 10:45 AM, Paul Phillips <notifications@github.com>
wrote:

>> @@ -6775,6 +6775,29 @@ trait Types extends api.Types { self: SymbolTable =>
>>    private val lubResults = new mutable.HashMap[(Int, List[Type]), Type]
>>    private val glbResults = new mutable.HashMap[(Int, List[Type]), Type]
>>  
>> +  /** Some types cannot be represented at runtime in a manner which is
>> +   *  consistent with the meaning of the type. When such a type participates
>> +   *  in a lub calculation, there is a risk that the calculated lub
>> +   *  (according to scala type rules) will leaves us in violation of
>> +   *  jvm requirements without our realizing it. For instance,
>> +   *     List(Array[Int](), Array[Nothing]())
>> +   *
>> +   *  Without intervention this would infer a list type of Array[Int] - but
>> +   *  Array[Nothing] appears at runtime as Array[Object]. So here we map these
>> +   *  types to their runtime representation, so a weaker lub is calculated,
>> +   *  one to which all participants can conform.
> Well, to answer my own question, the lub can't be a pure function of the input types if that means it will lose information which it cannot afford to lose. As long as there are types which have one behavior before erasure and a different, incompatible behavior after (like Array[Nothing] and Array[Object]) then there's no way to avoid awareness of this when performing type computation. Otherwise it's like throwing a few divide-by-zeros into your proofs.
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/scala/scala/pull/2486/files#r4070583