Remove scala.collection.AnyConstr #7072
Conversation
This was added in collection-strawman for cross-compiling with Dotty. Nowadays Dotty doesn’t have `AnyConstr` anymore so there’s no point in moving it to `scala.AnyConstr` for compatibility.
|
|
||
| /** An `IndexedSeqOps` whose collection type and collection type constructor are unknown */ | ||
| type SomeIndexedSeqOps[A] = IndexedSeqOps[A, AnyConstr, _] | ||
| type SomeIndexedSeqOps[A] = IndexedSeqOps[A, Any, _] |
There was a problem hiding this comment.
That won't compile with Dotty because Any is not poly-kinded there.
There was a problem hiding this comment.
Well, yes, we'll need to change the sources for Dotty. We have to do that anyway, because the definition of AnyConstr wouldn't compile, either. What's the current replacement anyway?
There was a problem hiding this comment.
I was actually thinking of the original definition type AnyConstr = Any but now we have type AnyConstr[X] = Any which would cross-compile.
But we still shouldn't have scala.collection.AnyConstr. This is an implementation detail that is not supposed to leak into user code and it is not specific to collections. If we want to keep this abstraction it either needs to be properly supported (e.g. adding scala.AnyConstr in 2.13 and Dotty) or hidden away (is it possible?)
There was a problem hiding this comment.
Just write a type lambda, since Scala 2 doesn't have nice syntax for them you need to use the projection trick ({ type L[A] = Any })#L
There was a problem hiding this comment.
Using a private type alias would probably work too.
There was a problem hiding this comment.
Looks promising. I've opened #7077 to make it private. We can still consider better solutions for RC1.
|
The status quo is probably the best we can do. Adding |
This also provides a nice solution for AnyConstr (see scala#7077 and scala#7072): We simply don’t need it anymore.
This also provides a nice solution for AnyConstr (see scala#7077 and scala#7072): We simply don’t need it anymore. We really want to constrain both IterableCC and MapCC to Iterable (the latter because it’s needed for MapView) but that causes collisions after erasure, so we have to go back to IterableOnce for IterableCC. Using something more specific (like MapOps with Iterable) for MapCC is not possible because in MapView the MapCC is not actually MapView but only View.
3 participants
This was added in collection-strawman for cross-compiling with Dotty.
Nowadays Dotty doesn’t have
AnyConstranymore so there’s no point inmoving it to
scala.AnyConstrfor compatibility.