question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

unhelpful warning for unsupported Scala 2 existential types

See original GitHub issue

Compiler version

3.1.0

Minimized code

Not sure, but I have a Scala 3 sbt project that depends on a Scala 2.13 project.

Output

[error] An existential type that came from a Scala-2 classfile cannot be
[error] mapped accurately to to a Scala-3 equivalent.
[error] original type    : x forSome type x
[error] reduces to       : x
[error] type used instead: Any
[error] This choice can cause follow-on type errors or hide type errors.
[error] Proceed at own risk.
[error] one error found
[error] one error found

Expectation

The error message would ideally tell me which Scala-2 classfile the symbol came from, or which Scala-3 compilation unit the reference is happening in (or both). We use x forSome type x dozens of times in our Scala code so I can’t narrow down where the error is coming from.

Issue Analytics

  • State:closed
  • Created 2 years ago
  • Comments:6 (6 by maintainers)

github_iconTop GitHub Comments

1reaction
oderskycommented, Nov 4, 2021

Note it’s not equivalent to a wildcard.

Array[?] corresponds to Array[x] forSome { type x}, not Array[x forSome { type x }]

0reactions
adampaulscommented, Nov 4, 2021

We used this pattern a lot. It was the way we would get code like this to compile:

def compare(x: Comparable[_], y: Comparable[_]): Int = {
  type T = x forSome { type x }
  x.asInstanceOf[Comparable[T]].compareTo(y.asInstanceOf[Comparable[T]])
}

Without the casts, you get

found   : y.type (with underlying type Comparable[_])
[error]  required: _$4

I know you can also do

x.asInstanceOf[Comparable[Any]].compareTo(y.asInstanceOf[Comparable[Any]])

in this case, but I’m pretty sure that doesn’t work if there are type bounds on the type parameter. Declaring an explicit type variable also just seems less like a hack. Is there a better way?

Read more comments on GitHub >

github_iconTop Results From Across the Web

Where is the scaladoc for scala.language.existentials?
This gives you the ClassTag object for the generic parameter that you can use to access the Class given when objects are being...
Read more >
Dropped: Existential Types - Scala 3 - EPFL
Existential types using forSome (as in SLS §3.2.12) have been dropped. The reasons for dropping them are: Existential types violate a type soundness...
Read more >
Dropped: Existential Types
Existential types using forSome (as in SLS §3.2.12) have been dropped. The reasons for dropping them are: Existential types violate a type soundness...
Read more >
Existential types are not raw types - Typelevel
In both Java and Scala, this is an existential type. ... warning: [rawtypes] found raw type: List // missing type ... Raw Types...
Read more >
Clarify the reasons for dropping existentials #4353 - GitHub
with other Scala constructs. This is a little too vague of an explanation for users who are going to miss existentials. Existential types...
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found