Open jvasileff opened 6 years ago
I'm not sure the ability to "skip" outer types when satisfying a nested type (e.g. allowing CSup satisfies J
despite BSup
being in the way) is worth the typesystem and backend complexity, although maybe I'm missing some obviously useful example.
Without this "skipping", inner classes would only ever have a single outer
capture that would be applicable for all supertypes that are nested types, and a conceptual Outer
type would exist (as envisioned by @Zambonifofex in https://gitter.im/ceylon/user?at=5a673dd298927d57452691ba), which would simply be the qualifying type.
(Edit: actually, I suppose a change to the subtyping rules would also be required to support @Zambonifofex's Outer
type)
Given an interface
I
and a nested interfaceI.J
, it's possible to define a typeA.B.C
which satisfiesI.J
as both<A of I>.<C of J>
and<A.B of I>.<C of J>
.This is possible when
A
,A.B
, andA.B.C
extendASup
,ASup.BSup
, andASup.BSup.CSup
respectivelyA
andA.B
both satisfyI
ASup.BSup
does not satisfyI
A.B.C
andASup.BSup.CSup
both satisfyI.J
If
I
has type parameters, the two supertypesI.J
may differ.Two problems occur in 1.3.4-SNAPSHOT:
A.B.C
to refineI.J
's members to properly satisfy the requirements of<A.B of I>.<C of J>
. This can result in unsound behavior.A.B.C
can be widened toASup.BSup.CSup
which can be widened the (generic) type that correspends to<A of I>.<C of J>
, butA.B.C
cannot be widened to<A of I>.<C of J>
directly.Sample code for 1.3.4-SNAPSHOT (the behavior in 1.3.3 is slightly different):