unhelpful warning for unsupported Scala 2 existential types
See original GitHub issueCompiler 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:
- Created 2 years ago
- Comments:6 (6 by maintainers)
Top 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 >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Note it’s not equivalent to a wildcard.
Array[?]
corresponds toArray[x] forSome { type x}
, notArray[x forSome { type x }]
We used this pattern a lot. It was the way we would get code like this to compile:
Without the casts, you get
I know you can also do
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?