Hacker News Reader

Comment by scala_hacker | Hacker News Reader

It is interesting that he does not mention any plans to fix the several egregious type soundness holes in Scala's type system.

View on HN

That would go under bug fixes. But you could help us by filing tickets on trak. The general issue (type volatility) is well known, but you have discovered a loophole which wasn't.

This is the first time I've heard this particular criticism of Scala. Could you please describe in a little more detail exactly what problems you believe exist, or link to an article that does?

Consider the following program:

  trait X {
    trait A { type T >: Int <: Int }
      val x : A
      var n : x.T = 3
    }

  trait Y extends X {
    trait B { type T >: String <: String }
    lazy val x : A with B = x
    n = "foo"
  }

  new Y {}

I just used this because it is extremely simple and is just the tip of the iceberg. It is possible to exploit this in much more interesting ways and dangerous ways, but those are less concise.

It is worth noting that this is not just a simple compiler bug, but a deep flaw in the way type members and type composition interact.

what do the :> and :< operators mean in this context, I though they were used for indicating sub/super types?

They place upper and lower bounds on the type member.

This looks slightly contrived. Can you provide an example more likely to crop up in typical usage?

I think you and I have different definitions of "extremely simple".

Interesting.

Seems this depends on path-dependent types (x.T in the example) ?

Do you think it's possible to fix the type system to avoid this without throwing away large parts of it?

Is there are a relevant scala trac ticket?

Reply on news.ycombinator.com