Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TypeTag of path-dependent type cannot be inferred by the compiler #12113

Open
tribbloid opened this issue Aug 12, 2020 · 7 comments
Open

TypeTag of path-dependent type cannot be inferred by the compiler #12113

tribbloid opened this issue Aug 12, 2020 · 7 comments
Labels
dealias compiler isn't dealiasing when it should, or vice versa reflection
Milestone

Comments

@tribbloid
Copy link

This problem has been recorded in:

https://stackoverflow.com/questions/59708880/in-scala-why-it-is-impossible-to-infer-typetag-from-type-alias-or-dependent-typ

A similar problem that may have the same cause has been reported in:

fthomas/singleton-ops#152

reproduction steps

using Scala 2.13.3 OR 2.12.11,

object TTagFromPathDependentType {

  import universe._

  def infer(): Unit = {
    type U = (Int, String)

    val ttg1 = implicitly[TypeTag[(Int, String)]]

    val ttg2 = implicitly[TypeTag[U]]
  }
}

problem

Compiler throws the following error:

[Error] /home/peng/git/shapesafe/spike/src/main/scala/edu/umontreal/kotlingrad/spike/arity/TTagFromPathDependentType.scala:15: implicit error;
!I e (No TypeTag available for U): TypeTag[(Int,String)]
one error found

FAILURE: Build failed with an exception.

If the compiler is working properly it should have easily found the TypeTag for (Int, String)

@Jasper-M
Copy link

Related work scala/scala#5836

@SethTisue SethTisue added this to the Backlog milestone Aug 12, 2020
@SethTisue SethTisue added the dealias compiler isn't dealiasing when it should, or vice versa label Nov 11, 2020
@SethTisue
Copy link
Member

SethTisue commented Nov 11, 2020

it appears to me that the problem is that the type isn't path-dependent, but rather is local to the block:

scala 2.13.3> object O { type U = (Int, String) }
object O

scala 2.13.3> implicitly[TypeTag[O.U]]
val res4: reflect.runtime.universe.TypeTag[O.U] = TypeTag[O.U]

scala 2.13.3> { type U = (Int, String); implicitly[TypeTag[U]] }
                                                  ^
              error: No TypeTag available for U

@Jasper-M
Copy link

Jasper-M commented Nov 11, 2020

@SethTisue The problem is with "free" types,
of which local types are an example. But also path dependent types whose definition is not statically accessible (for lack of a better specification):

val a = new { type T = Int }
typeOf[a.T]

trait Foo { type T }
val foo = new Foo { type T = Int }
typeOf[foo.T]

@tribbloid
Copy link
Author

@Jasper-M are you saying that once I moved those definition into a class or an object instead of a function the error will disappear?

@Jasper-M
Copy link

are you saying that once I moved those definition into a class or an object instead of a function the error will disappear?

If you move the type for which you want a TypeTag out of the function it should work yes.

@SethTisue
Copy link
Member

SethTisue commented Apr 21, 2022

I'm wondering if we should just close this, on the grounds that it's an understandable and reasonable limitation, rather than a bug or shortcoming.

(At least, that's what I think about the case where the path in the path-dependent type is local. Less sure what I think about Jasper's case.)

@tribbloid
Copy link
Author

Yes I agree it is a free type, but it is also a type alias that can be immediately de-aliased to a dependent type.

Theoretically this is not a variable binding, so no guarantee for type equivalence, but developers may still perceive it that way

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dealias compiler isn't dealiasing when it should, or vice versa reflection
Projects
None yet
Development

No branches or pull requests

3 participants