If we call (*Future[T]).Then after Future[T] has completed, the Than-callback will never been called. And if we try to Collect a completed Future[T], it could cause deadlock.

for example:

func Test_Future(t *testing.T) {
	completed := make(chan struct{})
	fut := mo.NewFuture(func(resolve func(int), reject func(error)) {
		resolve(1)
		close(completed)
	})

	<-completed
	fut.Then(func(in int) (int, error) {
            fmt.Println(in) // will never been print
	    return in, nil
	}).Collect() // deadlock
}

Futures call next future once they have finished, so if we chain a callback on a finished future, the call chain would be broken.

And here is my commit to fix this commit.

I have only implemented Either5 so far.

@samber Could you do a quick PR before I duplicate the code for Either3 and Either4 ?

I was thinking of leaving the README.md and either5_example_test.go as it is and just add either3.go, either4.go, either3_test.go and either4_test.go.

I think that should be enough that way, WDYT?

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?

package main

import "github.com/samber/mo"

func main() {
	var x float64 = 2.0
	op := mo.Some(x)
	square := func(x float64) mo.Option[float64] { return mo.Some(x * x) }
	cubic := func(x float64) mo.Option[float64] { return mo.Some(x * x * x) }
	print(op.FlatMap(square).FlatMap(cubic).OrElse(-1))
}

This is an example of using this package, but I suppose function square should be

	square := func(x float64) float64 { return x * x }

This declaration of mapping functions is better, I think.

Consider change the FlatMap into

func (o Option[T]) FlatMap(mapper func(T) T) Option[T] {
	if o.isPresent {
		return Some(mapper(o.value))
	}
	return None[T]()
}

For aMap map[string]string, can I do Some(aMap["nonExistingKey"]).OrElse("FallBackValue")?

It seems to return empty string all the time.

Thanks.

Currently, the Either struct uses two booleans to represent what kind of value we have. Even though mo doesn't export these booleans, they allow for 4 different states instead of the desired 2. This PR removes the isRight boolean, enforcing only two possible states can be represented internally. This change has the benefit of simplifying some tests, albeit very minimally.

When size of T is not 8 bytes aligned, put isErr and value before err will save more memory

package main

import (
	"fmt"
	"unsafe"

	"github.com/samber/mo"
)

func Ok[T any](value T) Result[T] {
	return Result[T]{
		value: value,
		isErr: false,
	}
}

type Result[T any] struct {
	isErr bool
	value T
	err   error
}

func main() {
	fmt.Printf("mo(bool): %v\n", unsafe.Sizeof(mo.Ok[bool](false)))
	fmt.Printf("my(bool): %v\n", unsafe.Sizeof(Ok[bool](false)))
	fmt.Printf("mo(int8): %v\n", unsafe.Sizeof(mo.Ok[int8](0)))
	fmt.Printf("my(int8): %v\n", unsafe.Sizeof(Ok[int8](0)))
	fmt.Printf("mo(int16): %v\n", unsafe.Sizeof(mo.Ok[int16](0)))
	fmt.Printf("my(int16): %v\n", unsafe.Sizeof(Ok[int16](0)))
	fmt.Printf("mo(int32): %v\n", unsafe.Sizeof(mo.Ok[int32](0)))
	fmt.Printf("my(int32): %v\n", unsafe.Sizeof(Ok[int32](0)))
	fmt.Printf("mo(int64): %v\n", unsafe.Sizeof(mo.Ok[int64](0)))
	fmt.Printf("my(int64): %v\n", unsafe.Sizeof(Ok[int64](0)))
	fmt.Printf("mo(float32): %v\n", unsafe.Sizeof(mo.Ok[float32](0)))
	fmt.Printf("my(float32): %v\n", unsafe.Sizeof(Ok[float32](0)))
	fmt.Printf("mo(float64): %v\n", unsafe.Sizeof(mo.Ok[float64](0)))
	fmt.Printf("my(float64): %v\n", unsafe.Sizeof(Ok[float64](0)))
	fmt.Printf("mo(complex64): %v\n", unsafe.Sizeof(mo.Ok[complex64](0)))
	fmt.Printf("my(complex64): %v\n", unsafe.Sizeof(Ok[complex64](0)))
	fmt.Printf("mo(complex128): %v\n", unsafe.Sizeof(mo.Ok[complex128](0)))
	fmt.Printf("my(complex128): %v\n", unsafe.Sizeof(Ok[complex128](0)))
	fmt.Printf("mo([12]byte): %v\n", unsafe.Sizeof(mo.Ok[[12]byte]([12]byte{})))
	fmt.Printf("my([12]byte): %v\n", unsafe.Sizeof(Ok[[12]byte]([12]byte{})))
}

mo(bool): 32
my(bool): 24
mo(int8): 32
my(int8): 24
mo(int16): 32
my(int16): 24
mo(int32): 32
my(int32): 24
mo(int64): 32
my(int64): 32
mo(float32): 32
my(float32): 24
mo(float64): 32
my(float64): 32
mo(complex64): 32
my(complex64): 32
mo(complex128): 40
my(complex128): 40
mo([12]byte): 40
my([12]byte): 32

Hello,

If I run:

mo.NewFuture(func(resolve func(struct{}), reject func(error)) {
	resolve(struct{}{})
	reject(errors.New("oh no..."))
})

I get panic: close of closed channel.

This makes me write defensive code (e.g. return after each call to reject / resolve). I would suggest to recover from panics and reflect it as an error as part of Result[T]'s error.

At this moment we cant use monads to translate between different Result monad types.

Ex Ok(42).FlatMap(func(int) Result[string] { return Ok("wont work") })
because of the single type constraint introduced in the signature.

It wold be very useful if we can perform translations.

A way to do this is to detach FlatMap from result and make the signature like this

func [T, U any] FlatMap(func(T) Result[U]) Result[U]

Or maybe even

func [T, U any] FlatMap(func(T)(U, error)) Result[U]

I understand why this is not done here, it is because of the go generics restriction not to introduce new types in a struct methods. At the time being all types that are used in the struct methods must be declared in the struct definition.

Also func(T) Result[U] is not a correct functor interface, for go maybe func(t) (U, error) would be more appropriate but tbh returning result feels right. The cons is that it will be hard to define universal interface that will work across all of the monads.

Could we have a helper function like the following for Either?

func Map[T any](e Either[L, R], onLeft func(L) T, onRight func(R) T) T 

It would be useful to be able to Map an Either to another type.

As stated on the package doc:

The functions provided by this package are not methods of mo.Option due to the lack of method type parameters on methods. This is part of the design decision of the Go's generics as explained here: https://go.googlesource.com/proposal/+/refs/heads/master/design/43651-type-parameters.md#No-parameterized-methods

Providing these methods as a separate package also matches Go's primitives and standard library:

• The string type don't have methods, but there we have the strings package.
• The []byte type don't have methods, but there we have the bytes package.
• The io.Reader defines a single method, and all manipulations of a reader is done on packages io and ioutil.

This package includes:

• options.Map
• options.FlatMap
• options.Match
• options.FlatMatch

The FlatMatch function is to replace this pattern:

var thing ExpensiveThing
if opt.IsPresent() {
  thing = NewExpensiveThingFrom(opt.MustGet())
} else {
  thing = NewExpensiveThing()
}

// Can now be done like this:

thing := options.FlatMatch(opt, NewExpensiveThingFrom, NewExpensiveThing)

I would have this be the behavior of Match and return an Option when wanted, but since there is already a method that use the two return values I decided to have the same signature for the function with same name and create a new function for this pattern. I called it FlatMatch since it allows the same use case as FlatMap, where the given functions return an Option and the result is that same Option.

If you agree with this idea I can send a results package right away.

If m and n are two Option[int], I want to add them up. How can I finish this? I learnt haskell these days and it uses applicative (a special functor) to do this. Maybe an apply method is needed?