Skip to content

Special handling in the typer of scala.Singleton is missing #2997

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

Closed
soronpo opened this issue Aug 21, 2017 · 5 comments · Fixed by #3774
Closed

Special handling in the typer of scala.Singleton is missing #2997

soronpo opened this issue Aug 21, 2017 · 5 comments · Fixed by #3774

Comments

@soronpo
Copy link
Contributor

soronpo commented Aug 21, 2017

  case class Foo[T <: Int with Singleton](t : T)
  val one = 1
  final val final_one = 1
  val a : 1 = Foo(1).t //Type Mismatch Error
  val b : Int = Foo(one).t //OK, but unexpected
  val c : 1 = Foo(final_one).t //Type Mismatch Error

Scastie link: https://scastie.scala-lang.org/DcDeG4eYQTG17exjb2FigQ

@smarter
Copy link
Member

smarter commented Aug 21, 2017

I don't think this has anything to do with class fields, it's just that Dotty doesn't know anything about theSingleton trait.

@smarter smarter changed the title Literal types loosing narrowness as class fields Special handling in the typer of scala.Singleton is missing Aug 21, 2017
@soronpo
Copy link
Contributor Author

soronpo commented Aug 21, 2017

Even without the Singleton the behavior differs between a function argument and a class field.

  object Test {
    val one = 1
    final val final_one = 1

    object OK {
      def foo[T <: Int](t : T) : T = t
      val a : 1 = foo(1)
      val b : Int = foo(one)
      val c : 1 = foo(final_one)
    }

    object Fail {
      case class Foo[T <: Int](t : T)
      val a : 1 = Foo(1).t //Error: Type mismatch
      val b : Int = Foo(one).t
      val c : 1 = Foo(final_one).t //Error: Type mismatch
    }
  }

@smarter
Copy link
Member

smarter commented Aug 21, 2017

Ah, that's interesting, still not specific to class fields though :). val a: 1 = Foo(1).t becomes val a: 1 = Foo.apply(1).t, when inferencing the type parameter of apply we first pick up >: 1 from the argument, we should pick up <: 1 from the return type of a but we don't for some reason, I'll open a separate issue for that.

@smarter
Copy link
Member

smarter commented Aug 21, 2017

See #2998

@soronpo
Copy link
Contributor Author

soronpo commented Aug 21, 2017

OK, thanks!

allanrenucci added a commit to dotty-staging/dotty that referenced this issue Jan 4, 2018
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 7, 2018
When interpolating type variables we should use all available information
at this point, including the expected result type. One situation where this makes
a difference is if the expected type is a singleton type, because type variables
are instantiated to singleton types only if their upper bounds are singleton types.

Also fixes scala#2997.
odersky added a commit to dotty-staging/dotty that referenced this issue Jan 7, 2018
When interpolating type variables we should use all available information
at this point, including the expected result type. One situation where this makes
a difference is if the expected type is a singleton type, because type variables
are instantiated to singleton types only if their upper bounds are singleton types.

Also fixes scala#2997.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants