scala/scala — pull request #2631 by retronym (2013-06-05 14:59:47+00:00)
Title: SI-5022 Retain precise existentials through pattern matching

From the dawn of scalac's existentials, the typer widens
existentials pt-s by substituting wildcard types in places
of existential quantifiers.

In this example:

class ForSomeVsUnapply {
def test {
def makeWrap: Wrap = ???
def useRep[e](rep: (e, X[e])) = ()

val rep = makeWrap match {
case Wrap(r) => r
};

useRep(rep) // error
}
}

the type of `r` is the result of typechecking:

Apply(
fun = TypeTree(
tpe = (rep#12037: (e#12038, X#7041[e#12038]) forSome { type e#12038 })
args = Bind(r @ _) :: Nil
}

This descends to type the `Bind` with:

pt = (e#12038, X#7041[e#12038]) forSome { type e#12038 }

`dropExistential` clobbers that type to `Tuple2#1540[?, X#7041[?]]`,
which doesn't express any relationship between the two instances
of the wildcard type. `typedIdent` sort of reverses this with a call
to `makeFullyDefined`, but only ends up with:

pt = (Any#3330, X#7041[_1#12227]) forSome { type _1#12227; type e#12038 }

I suspect that this existential dropping only makes sense outside of
typechecking patterns. In pattern mode, type information flows from the
expected type onwards to the body of the case; we must not lose precision
in the types.

For SIP-18 friendly existentials, one `dropExistential` is invertable with
`makeFullyDefined`, so this hasn't been such a big problem.

The error message improvement conferred by SI-4515 took a hit.
That might be a good example to consider when reviewing this change:
Does it tell us anything interesting about this `dropExistential`
business?

Review by @adriaanm.

If we go forward with this, I can address the two FIXME's introduced in this patch before merging.