Sergey Torgashov

@danicheg , @benhutchison , thank you for your feedback! Yes, I agree that we should choose better names – I picked those just to have something to start with. Regarding...

Another thing that I feel it is important to think through. Initially, I proposed the `Foldable` typeclass to use for the sake of generalization, which would be able to do...

@danicheg , > I even think that `ensureSole` should return an `Option[A]` and be defined on top of one of the `Foldable` type classes. Additionally, `ensureSoleOr` could return an `F[A]`...

Honestly, I'm not sure I'm following how come it was assumed that > Chain#hashCode is consistent with List#hashCode in the first place? What was the justification for that? I mean,...

@johnynek , > Also it would be easy to make a structural hash to cares about the construction order which we don't want. Oh, I see now, that is a...

Let me go ahead and merge it not awaiting the second approval. It seems to be a straightforward but still quite important change, so if Mima is happy, I am...

``` import cats.kernel.Order.Implicits._ ``` maybe or something like that? Not too cool, but still better than just ``` import cats.kernel.Order._ ```

`import cats.syntax.all._` can still be used in combination with `import cats.kernel.instances.order._`, but it is not the best experience in terms of API discoverability of course. UPD: changed "it is the...

Perhaps, it would make sense indeed, but why do you think it should be limited to `cats.Reducible` and non-empty collections only? Currently, the `Reducible`'s base trait `UnorderedTraverse` already has just...

I mean... `parLiftN` and friends just have been released... Can we consider risking it and ignore the binary incompatibilities there? We could quickly arrange 2.13.1 and recommend to hold on...