-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing NonEmpty Collection Helper methods #4070
Comments
The reason why #3998 got stuck on my side was a very valid concern from @johnynek on whether we should keep stuffing collection wrappers with ad-hoc methods or try to generalize some (or most) of them for appropriate typeclasses ( I agree with Oscar that generalization is better so I am not confident that it makes sense to merge #3998 until we elaborate some more generic solution. |
@satorg Agreed. That's why I wanted to list out all the methods that we had now, and open a discussion on how we can improve the current situation. These methods wouldn't exist if there wasn't some utility, so I think any general replacement needs to be nearly as convenient. I proposed 2 solutions but those only cover a subset of the missing methods. There is likely a way to split these missing methods into different categories and address the individually. But figured a single list to get started would help show the entire picture. |
I guess there's a typo in the description: |
@satorg Thanks, corrected. |
In the Cats library there are several aliases for various NonEmpty types and methods, for example
EitherNec
and1.leftNec
.However, there are a lot of inconsistencies with when a
*Nec
or*Nel
or other non-empty collection version of a method exists.We have the following non-empty collection types.
NonEmptyChain
NonEmptyLazyList
NonEmptyList
NonEmptyMap
(Doesn't seem to be used for any 'left' sides so not included below)NonEmptySeq
NonEmptySet
NonEmptyVector
See also PR: 3998 For a WIP to add a few more methods not listed here.
Below is an accounting of the missing methods. I would be happy to do a PR to add the below methods, but before I did,
I wanted to make sure there isn't some underlying principle, or typeclass, or something we could use to optimize this to a degree
so less of these helper methods will be added, while still granting their utility.
Some Ideas besides just adding the methods:
toNe*
methods to theBifunctor
syntax/ops.OneOf
typeclass (sort of thing) of the formtrait OneOf[F[_], A]{ def one(a: A): F[A]}
and make a add a genericleftLift
method onBifunctor
.OneOf
differs fromPure
in AlleyCats, because it allows you to say:implicit def oneOfNes[A: Order]: OneOf[NonEmptySet, A] = a => NonEmptySet[F, A].one(a)
implicit def oneOfApplicative[F[_]: Applicative, A]: OneOf[F, A] = a => Applicative[F].pure(a)
either.leftLift[NonEmptyLazyList]: EitherNell[A, B]
Added bonus, this works with Non-NonEmpty lists as well!
either.leftLift[List]: Either[List[A], B]
Either
Type Aliases
Object Ops
Ops
Id Ops
EitherT
Type Aliases
Ops
Ior
Type Aliases
Object Ops
Ops
Id Ops
IorT
Missing all instances
Ne*
methods and AliasesValidated
Type Aliases
Object Ops
Ops
Id Ops
List
Ops
Option
Ops
NonEmptyLazyList
Ops
Reducible
Ops
Syntax
The text was updated successfully, but these errors were encountered: