Re: [scala] Conformance to bounds in higher-order type parameters

> Hi Christos,
>
> Constraints on nested type parameters of a higher-order type parameter
> work in backwards direction: it is OK to substitute a type constructor
> with unconstrained nested type parameters instead of a higher-order
> type parameter with constrained nested type parameters.
>
> In my example, it is possible to work around the current compiler
> behavior with type aliases:
>
> ////////////////////////////////////////////////////////
> trait A[B[X, Y <: X, Z <: Y]]
>
> trait C[X, Y <: X, Z <: X]
> trait D[X, Y, Z <: X]
> trait E[X >: Y, Y, Z]
>
> type D1[X, Y <: X, Z <: Y] = D[X, Y, Z]
> type E1[X, Y <: X, Z <: Y] = E[X, Y, Z]
> ////////////////////////////////////////////////////////
>
> Now, the type applications A[D1], A[E1] are accepted. But I would like
> that it worked without aliases.
>
> Thanks,
> Vladimir
>
> On 6/16/09, Christos KK Loverdos <loverdos@...> wrote:
>> Hi,
>>
>> It is apparent that in the definitions of D, E, types Y & Z
>> respectively are unconstrained. This is incompatible with how A is
>> defined, where both Y & Z are constrained. So the errors you mention
>> (I have not run the example) are expected.
>>
>> BR
>> Christos
>>
>> On Jun 16, 2009, at 1:49 PM, Vladimir Reshetnikov wrote:
>>
>>> Hi,
>>>
>>> Given the following definitions,
>>>
>>> ///////////////////////////////////////////
>>> trait A[B[X, Y <: X, Z <: Y]]
>>>
>>> trait C[X, Y <: X, Z <: X]
>>> trait D[X, Y, Z <: X]
>>> trait E[X >: Y, Y, Z]
>>> ///////////////////////////////////////////
>>>
>>> Scala 2.7.5 accepts the type application A[C], but rejects A[D] and
>>> A[E]. But they all seem equally type-safe. What part of SLS  
>>> describes
>>> how these type-checks should proceed? Is the current behavior  
>>> correct
>>> or desirable?
>>>
>>> Thanks,
>>> Vladimir
>>
>> --
>>  __~O
>> -\ <,       Christos KK Loverdos
>> (*)/ (*)      http://ckkloverdos.com
>>
>>
>>
>>
>>
>>