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>
>
>
>
>
>
