Change is volatile

[odersky]

Fixes #1047 and prepares the way for other realizibility tests involving null and type projections.

[odersky]

Also fixes #50 and #1050 and SI-7278.

[odersky]

State so far: Problems involving type projections and laziness should be addressed by this PR. Problems involving null need the planned changes to the typesystem which model null explicitly. Problems involving uninitialized fields need to be handled separately.

[odersky]

What's the review status of this one? If there are no further comments this will be merged.

[smarter]

I'll review this today

[smarter]

This method is never used.

[smarter]

This patch makes the following code illegal:

trait HasA {
  type A
}
trait Foo[T <: HasA] {
  type B = T#A // error: T is not a legal path since it is not a concrete type
}

However, I think that we can safely allow this, because Foo#B is not a valid path, you need to write Foo[something]#B and we will check at that point if the type is legal or not. What do you think?

[smarter]

Nevermind, if we allow this then the following would compile:

object Test {
  trait C { type A }

  type T = C { type A >: Any }
  type U = C { type A <: Nothing }

  trait Foo[Elem <: T] {
    def foo: Elem#A = 1
  }

  def main(args: Array[String]) = {
    val a = new Foo[T & U] {}
    val z: String = a.foo
  }
}

[smarter]

This pull request needs to be rebased.

[smarter]

What about AndTypeTree, OrTypeTree, RefinedTypeTree, etc? Maybe we should add a case like:

case typ: TypTree =>
  checkRealizable(typ.tpe, typ.pos)

I think that if we do this, then my proposition at #1051 (comment) becomes safe, because Foo[T & U] will be invalid.

[odersky]

That's not how things are done in DOT. We have one scheme to ensure soundness that we know works and a lot of others that we thought worked at some time, but didn't in the end. So we should stick to the one that works. I believe approximating realizability of other types is too strict and is also not necessary.

[Atry]

Is it possible to treat singleton types as stable?
Does it sound?

object O {
  type T = String
}

val stableVal: O.type = O

def stableMethod: stableVal.type = stableVal

def doesItSound(x: stableMethod.T) = x

[smarter]

@Atry Maybe, but it seems cleaner to never allow defs to be stable. In your example you could just write val stableMethod: O.type = O instead, is there a specific reason why you would want it to be a def?

[Atry]

val stableMethod costs some memory overhead at runtime.

[Atry]

Thinking about a very complex monad transformer chain, each depends on another.

[DhashS]

Hey, I'm fairly new to Scala and was curious about just this in something I'm writing.

Having both # and the dot-notation way of accessing the inner type is not particularly ergonomic.
In the function body, I think they do different things. (If i'm understanding https://stackoverflow.com/questions/9443004/what-does-the-operator-mean-in-scala correctly).

The existing behaviour is semi-attractive, but if the # syntax for in declaring function argument types is probably expected behavior, disallowing dot-notation there might make sense.

I'm not super-sure what I've said is sensical, I'm a fairly new Scala programmer, and not a compiler dev.