Explicitly disallow importing an identifier whose type needs to be inferred

[smarter]

The following code:

class Hi {
  class A
}

class Foo {
  val x = new Hi
  import x._
  def bar: A = new A
}

fails with:

java.lang.RuntimeException: Can't resolve selector Ident(A)

It seems that either importing from something with type InferredTypeMarker should be disallowed or that everything in scope after such an import should get type InferredTypeMarker.

[gkossakowski]

Good catch. Importing from terms with inferred types should be disallowed.
Terms with inferred types are already ruled out from appearing in paths (e.g. x.type is not allowed).

[smarter]

Terms with inferred types are already ruled out from appearing in paths (e.g. x.type is not allowed).

In your blog post you mentioned that no Scala language feature prevents the use of outline types, but isn't that contradicted by the fact that you have to introduce restrictions like this? How would you deal with this in a real compiler?

[gkossakowski]

In the blog post introducing outline types I discussed the difficulty of vals mentioned in paths:

The solution I see is to outlaw such Scala programs: if you have a val that you want to use in path-depent types, it can’t have an inferred type — its type has to be provided explicitly.

At the time, I thought that vals with inferred types has to be only disallowed from appearing in paths. I missed import nodes.

Kentucky Mule is about exploiting a clear boundary between declaration typechecking and expression typechecking for improving the overall speed of typechecking. This boundary almost already exists in Scala except a few cases we're now identifying.

I'm pretty sure Scala users would be willing to give up on inferred types connivence in some cases (in paths and in imports) if they were promised 10x compiler speed upgrade in return.

[smarter]

I'm pretty sure Scala users would be willing to give up on inferred types connivence in some cases (in paths and in imports) if they were promised 10x compiler speed upgrade in return.

I agree, just thought that this needed to be clarified :)