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.

Sign up for GitHub

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

Jump to bottom

Existential types working incorrectly for case classes #8997

Closed
scabug opened this issue Nov 21, 2014 · 4 comments
Closed

Existential types working incorrectly for case classes #8997

scabug opened this issue Nov 21, 2014 · 4 comments
Assignees
@retronym
Labels
backend duplicate help wanted typer

Comments

@scabug
Copy link

scabug commented Nov 21, 2014

This doesn't work:

        type SerializableList[T <: Serializable] = List[T]

        scala> case class NetworkDataCC(things: SerializableList[_])
        <console>:9: error: type arguments [_$1] do not conform to type SerializableList's type parameter bounds [T <: Serializable]

But this works:

       scala> type SL = SerializableList[_]
      defined type alias SL

      scala> case class NetworkDataCC(things: SL)
      defined class NetworkDataCC

You can also workaround it using high-order type:

 
     case class NetworkDataCC[SerializableList[_]](things: SerializableList[_])

It's reproducing for case classes only.
@scabug
Copy link
Author

scabug commented Nov 21, 2014

Imported From: https://issues.scala-lang.org/browse/SI-8997?orig=1
Reporter: Dmytro Kondratiuk (dk14)
Affected Versions: 2.10.2, 2.11.4

@scabug
Copy link
Author

scabug commented Dec 3, 2014

@retronym said:
This also works:

case class NetworkDataCC(things: SerializableList[_ <: Serializable])

@scabug
Copy link
Author

scabug commented Dec 3, 2014

@retronym said:
Here's a non case class reproduction:

object Test {
  type SerializableList[T <: Serializable] = List[T]
  class C(val sl: SerializableList[_])
  def unapply(x: C): Unit = Some.apply(x.sl)
}

I think redeclaring the bound is the right approach with Scala's current existential implementation. We've tried a few alternatives (see #1786), but haven't found a robust way to avoid that boilerplate.

@scabug
Copy link
Author

scabug commented Dec 3, 2014

@retronym said:
Marking as a duplicate of #1786

@scabug scabug closed this as completed Dec 3, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@retronym retronym

Labels
backend duplicate help wanted typer
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@retronym @scabug