Could Cats core be imported / merged with the standard library?

[BardurArantsson]

@ctongfei I think this is a very sensible suggestion. These type classes are pretty much settled and AFAICT an obvious improvement on the ones in the current stdlib.

I also think e.g. Semigroup/Monoid are pretty much settled in terms of basic algebra, but I wonder: is the resistance to inclusion in stdlib a matter of the “encoding” of these things?

EDIT: Generally speaking (as an FP-all-the-way person!), I think FP-in-Scala is missing out in a huge way by not having ‘standard’ Functor, Applicative, Monad type classes, etc. I do understand the maintainer reluctance since it seems that Scala 3 might make things a lot less contentious wrt. ‘encoding’, etc.

[mdedetrich]

@martijnhoekstra

Being a module rather than part of the stdlib doesnt affect binary compatibility of scalajs.

Theoritically no, but in reality it guarantees a hard line compatibility it cannot be broken. Scala stdlib is very strict about this. Also if we are talking about binary compatiblity, no single other async abstraction has been as stable as Future wrt bincompat.

@martijnhoekstra

I also don’t agree that being part of Akka can be reasonably called being in a separate module, at least, not in good faith, especially when talking about modularizing to avoid heavy dependencies.

Akka is comprised of modules itself, porting the futures over from Akka was pretty much almost copy/paste (which is a good indication of its modularity)

@sjrd

I can say that it was convenient that they were in the stdlib, but I cannot tell whether it would have been fundamentally more difficult if they had not.

My suspicion is that it would have been more difficult, at least definitely from an adoption PoV.