Georgi Krastev
Georgi Krastev
Oh sorry I think I confused an old PR of mine but it was specific to higher-kinded types: scala/scala#8720
> I guess this is because T[_] and T[Any] are equivalent for a covariant T. That's right > Is that also true when looking at T vs T from Java's...
In `TT[_]` the `_` (which is an existential quantifier) **does not** inherit the bounds of the underlying type parameter. That's one of the reasons why we skip existential skolems in...
The equivalent question in Scala 3 is if `_` in `T[_]` is a bounded wildcard or not?
Also from that part of the spec: > Example Assume a covariant type `class List[+T]` The type `List[T] forSome { type T
So I think where things break down is that the spec states "for a covariant `T[+X]`, `T[_]` is equivalent to `T[Any]`" but the signatures generated from those two types differ...
I would expect it to use `foldLeft(num.zero)(num.plus)` directly. But a more interesting question is what to do with all the other methods which use the same pattern with `isEmpty`?
I think there is tension when relying on major Scala releases to sneak in breaking changes. When there is a new Scala release users and downstream libraries want to have...
I think it's pretty clear that Cats is prime for a rewrite with Scala 3 features. Source compatibility should definitely be a goal but binary compatibility is just not possible....
> All that said: I strongly agree that breaking source compatibility is a tax on users that slows adoption. It would be really nice to have a test suite for...