samber / mo

🦄 Monads and popular FP abstractions, powered by Go 1.18+ Generics (Option, Result, Either...)
https://pkg.go.dev/github.com/samber/mo
MIT License
2.61k stars 85 forks source link

Could we add EitherX ? #8

Closed CorentinClabaut closed 2 years ago

CorentinClabaut commented 2 years ago

I guess we could have:

type Either3[T1 any, T2 any, T3 any] struct {
    argId int

    arg1 T1
    arg2 T2
    arg3 T3
}

Constructors:

mo.CreateEither3Arg1() mo.CreateEither3Arg2() mo.CreateEither3Arg3()

Methods:

.IsArg(i int) .Arg1() .Arg2() .Arg3() .MustArg1() .MustArg2() .MustArg3() .Arg1OrElse() .Arg2OrElse() .Arg3OrElse() .Arg1OrEmpty() .Arg2OrEmpty() .Arg3OrEmpty() .ForEach() .Match() .MapArg1() .MapArg2() .MapArg3()

@samber If you agree that it could be useful I could add Either3/4/5 If this is added I'm wondering if we should then have Either2 instead of the current Either type for consistency? And maybe mark the current Either as deprecated?

samber commented 2 years ago

That's an interesting idea.

Can you store argId into a uint8? Can you rename CreateEither3Arg1 to NewEither3Arg1, in order to respect Go conventions?

I would rather keep the Either data structure, since methods are a bit different and closer to the monad naming.

Let's start with Either3/4/5. Either6/7/8/... will be added in the future if necessary.

CorentinClabaut commented 2 years ago

Sounds good, I'll add that