Firstly I just want to say that I love this library and has allowed to me to largely remove my own custom implementation of a lot of these types. However I was wondering what the reasoning behind the signature and behaviour of (mo.Option).Map?
func (o Option[T]) Map(mapper func(value T) (T, bool)) Option[T] {
if o.isPresent {
return TupleToOption(mapper(o.value))
}
return None[T]()
}Generally speaking Map called on a Some should always return a Some which is a sentiment you also shared here. The ability to return false within the mapper makes Map behave more like FlatMap. It also makes passing point-free functions a little awkward as you have to "lift" the mapper into that signature. e.g.
// Error function signature requires returning an additional boolean
mo.Some("ExampleString").Map(strings.ToLower)
func lift[A any](fn func(A) A) func(A) (A, bool) {
return func(a A) (A, bool) {
return fn(a), true
}
}
mo.Some("ExampleString").Map(lift(strings.ToLower))I propose that (mo.Option).Map's signature should be changed to remove the boolean argument, if someone wants the old behaviour they can use FlatMap and TupleToOption.
Firstly I just want to say that I love this library and has allowed to me to largely remove my own custom implementation of a lot of these types. However I was wondering what the reasoning behind the signature and behaviour of
(mo.Option).Map?Generally speaking
Mapcalled on aSomeshould always return aSomewhich is a sentiment you also shared here. The ability to returnfalsewithin themappermakesMapbehave more likeFlatMap. It also makes passing point-free functions a little awkward as you have to "lift" the mapper into that signature. e.g.I propose that
(mo.Option).Map's signature should be changed to remove the boolean argument, if someone wants the old behaviour they can useFlatMapandTupleToOption.