Type member inference issue

[VladKopanev]

The code below compiles with scalac 2.12, but not with dotty

trait Foo {
  type State
  def bar(f: Bar[State] => Bar[State]): Foo = this
}
object Foo {
  def unit: Foo = new Foo {
    type State = Any
  }
  def doBar: Foo = unit.bar(bar => bar)
}
case class Bar[+A]()

Code like this will produce following compilation error:

[error] 17 |    identity.bar(bar => bar)
[error]    |                        ^^^
[error]    |           Found:    scalaz.zio.test.Bar[scalaz.zio.test.Foo#State](bar)
[error]    |           Required: scalaz.zio.test.Bar[Nothing]
[error] one error found

If we change the declaration of Bar to case class Bar[A]() (got rid of covariance) we will get another error:

[error] 16 |  def doBar: Foo = unit.bar(bar => bar)
[error]    |                                   ^^^
[error]    |                                   Found:    scalaz.zio.test.Bar[_](bar)
[error]    |                                   Required: Nothing
[error] one error found

If we change unit to be a val instead of def it compiles, but this is just a distilled, minimum code that produces the same error as we encountered during scalaz-zio compilation with dotty 0.13.0-RC1, see related ticket zio/zio#702

[odersky]

I had a long look at this. The root cause is that we don't support existential types anymore.

To see why, let's try to answer the question: What is the type of unit.bar?

scalac said: Bar[_1.State] => Bar[_1.State] where _1 is a hypothetical value of type Foo.

But if you actually try to give the parameter type of the argument bar => bar explicitly, it does not work, since _1.State is not a legal type you can write. So something fishy is going on here.

Dotty, not having existential types uses an "avoidance"algorithm instead. Since the result type Bar[_1.State]is not expressible, it has to be approximated from below (since it is argument position). That's what gives Nothing.

To fix this, the program should be rewritten so that parameter types could be given explicitly. If you can write them explicitly, there's a good chance they can be inferred as well.

Both of the following would work:

• Make unit a val instead of a def, or
• Make unit have to Foo { type State = Any }

As a way to improve the situation we plan to improve support for stable values. I.e. we would provide ways to declare a method like unit stable, which means it will be treated like a val in paths. That would then be a third way to make the program compile.

[nafg]

Is there going to be an automatic rewrite for things like this?

…

On Mon, Apr 1, 2019, 8:38 AM odersky ***@***.***> wrote: I had a long look at this. The root cause is that we don't support existential types anymore. To see why, let's try to answer the question: What is the type of unit.bar ? scalac said: _1.State => _1.State where _1 is hypothetical value of type Foo. But if you actually try to give the parameter type of the argument bar => bar explicitly, it does not work, since _1.State is not a legal type you can write. So something fishy is going on here. Dotty, not having existential types uses an "avoidance"algorithm instead. Since the result type Bar[_1.State]is not expressible, it has to be approximated from below (since it is argument position). That's what gives Nothing. To fix this, the program should be rewritten so that parameter types could be given explicitly. If you can write them explicitly, there's a good chance they can be inferred as well. Both of the following would work: - Make unit a val instead of a def, or - Make unit have to Foo { type State = Any } As a way to improve the situation we plan to improve support for stable values. I.e. we would provide ways to declare a method like unit stable, which means it will be treated like a val in paths. That would then be a third way to make the program compile. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#6199 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGAUBHPIewi2dKzJtc7ujtDCPAabalWks5vcf3VgaJpZM4cVPsY> .

[smarter]

I think the scheme we used for as-seen-from before 91ee02f supported this kind of usecase. It has a complexity cost but if this pattern is prevalent enough it might be worth bringing back a variant of it.

[nafg]

I'm pretty sure I use it in multiple places

…

On Mon, Apr 1, 2019 at 12:22 PM Guillaume Martres ***@***.***> wrote: I think the scheme we used for as-seen-from before 91ee02f <91ee02f> supported this kind of usecase. It has a complexity cost but if this pattern is prevalent enough it might be worth bringing back a variant of it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#6199 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGAUCf2Bw63pFKGdowjWaDpu8ZpngYXks5vcjJegaJpZM4cVPsY> .

[neko-kai]

So, removal of existentials means that any path-dependent type whose path prefix is not present as a bound val in scope just can't be interacted with meaningfully anymore?

[smarter]

@nafg @Kaishh Could you post some examples showing how you need this in practice ? I might have a not-too-invasive fix for this and concrete examples would help me fine-tune it.