Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Possibility of eventually moving to stdlib Equiv/PartialOrdering/Ordering #2455
In this issue, I'd like to have a discussion on:
goal (of this issue)
I don't intend for this issue to linger around forever. It can be closed when either of the following happens:
plausibility and timeline
At this point, it's unclear whether or not this change even could feasibly happen, let alone the timeline involved. I haven't yet spoken to any standard library maintainers about this; I wanted to see where Cats maintainers stood first. But if any standard library maintainers happen to be reading this, I'd love to hear your input.
For most of the differences listed below, I've given a brief summary of my thoughts on how much of a compatibility concern it might raise in the standard library.
At this point I suspect that it's too late in the Scala 2.13 lifecycle for these changes to be proposed in the standard library. I wanted to get this out there because I've been thinking about it for quite some time but have never acted on it.
There's no question that
I think that looking the many conversions between
differences between Cats and standard library
I wasn't involved in the initial creation of
The Cats versions of these typeclasses are all
I'm guessing that we'd need to see specialization of these type classes in the standard library to consider using them. I don't know how open to this change the standard library authors would be.
PartialOrder: Double vs Option[Int]
In the standard library's
I'm guessing that performance-conscious people using
In the standard library, there is a universal Equiv instance in the
I think that in order for Cats to use
Cats uses machinist to provide zero-cost syntax for these type classes, while the standard library does not. I know that this is supposed to provide a measurable performance improvement, but I can't speak to the magnitude or whether people who are performance-conscious could "bolt" machinist on somewhere outside of the standard library. Unfortunately, I think that there are very few people who understand machinist well (see this unanswered Cats comment from a year ago). Hopefully @non can weigh in.
In the standard library there are implicit conversions from
Cats has a Comparison enum-like type (
Starting with Scala 2.12,
Yeah this one is really the only deal-breaker, but boy is it bad
In general, I personally think cats-kernel is mature enough to suggest moving virtually all of it into the standard library, and I think we should try to do so.
On Equiv, it is absolutely essential that we remove the default universal equality instance if we are to make any progress in my view.
I bet that is something we could propose for 2.14. I wonder if it is too late to mark that as deprecated in 2.13?
I also view cats-kernel as quite mature (with a notable exception being the unanswered questions about machinist that I referenced above).
I do think that there are some parts of kernel that are a bit more opinionated than others. For example,
@johnynek since the
@johnynek how would opaque types help with this example (laziness)?
Just to make sure that I'm clear, I agree with the choice that was made for
added a commit
Sep 2, 2018
However, even some cats'
It would be great if stdlib instances were actually tested to at least satisfy the equivalence laws (without the indiscernibility of identicals) on types that do not contain floating point types.