Sergey Torgashov
Sergey Torgashov
I would also like to add one more point on `par*`-like name. To me it looks like an established convention – if a method name starts with `parFooBar` then we...
So as a bottomline.. Did I get it correctly, that we all agreed on the `parFlatMapN` naming?
Seems that `Alternative` is already covered [here](http://typelevel.org/cats/typeclasses/alternative.html), isn't it? But there's a new typeclass `NonEmptyAlternative` already, which apparently is not.
Just to clarify: `ensureA` looks quite similar to `FlatMap#flatTap` in its shape, isn't it? ```scala def flatTap[A, B](fa: F[A])(f: A => F[B]): F[A] = flatMap(fa)(a => as(f(a), a)) ```
Technically (as a work-around), it can be achieved by converting a `Validated` to `Either` temporarily, making a call to `flatTap` and then converting the result back to `Validated`. There's a...
`andTap` or `thenTap` ? 🤔
~I have got a quite crazy idea on how we could approach that. What if we considered generalizing it:~ ```scala trait GenMap[C[_], K, V] { def get(k: K)(implicit C: C[K]):...
Oh no, disregard please. It won't work, I didn't think through enough)
> The internal structure only makes sense when you use the right value for the typeclass. By not keeping it together you are just hoping that users don't pass the...
Would it make sense to convert this issue to a "discussion" (the next tab to "Pull requests" in the Github tabs panel)? Because it looks like a discussion rather than...