Add prototype conversion with dependent functions support

[nicolasstucki]

Instead of writing a Conversion as

Conversion[T, U]

we would use

Conversion[T => U]

which also allows dependent conversion

Conversion[(x:T) => x.U]

Conversion (ConversionFunction in the test) would be an opaque type

opaque type Conversion[+F <: Nothing => Any] = F

This alternative definition of Conversion would fix the issue stated in #7412.

[liufengyun]

LGTM

[odersky]

I am not convinced this will solve the problem. There is some very funky code in the compiler to support dependent implicit conversions. The problem is that eligible implicits are pre-computed and cached. So,
if we have an implicit conversion of type x: T => x.M, say, it still has to fit into the framework that it is a conversion between two types A and B, because that's what we search the cache with. A = T, but what is B? We can't say B = Any since then the conversion would not fit anything. Instead we say it's B = <?>, where <?> is the wildcard type.

Now this is already quite dubious because <?> is not really a type but a prototype and we should not populate our caches with this. It's also potentially very inefficient. What will happen now is that the conversion has to be tried for every source type matching T since it might also match the target type. Depending what your implicit search patterns are, this could slow down compilation a lot.

So, in summary, I would actually be rather glad if we could drop support for dependent conversions once implicit def is phased out. They really don't play well with the implicit search optimizations, so risk to slow down compilation a lot.

[smarter]

We can't say B = Any since then the conversion would not fit anything. Instead we say it's B = <?>, where <?> is the wildcard type.

Could you point me to where in the code we do this?

[odersky]

@smarter It's in stripImplicit and normalize, where we call resultApprox. resultApprox actually creates fresh type variables for dependent parts fo the result type not wildcard types (I think it was wildcard types first, but that did not work out). That's more systematic, but still suffers the problem of vert large implicit searches.

[odersky]

In any case it's good to have this as a test, to document a possible scheme.