Closed glandium closed 1 year ago
Hi there. Option<EitherOrBoth<L, R>>
is isomorphic to (Option<L>, Option<R>)
, and the latter is arguably more straightforward.
We now have left_and_right
which converts an EitherOrBoth
to (Option<L>, Option<R>)
. As such, I'd like to close this, because all the proposed can be implemented in terms of Option
-combinators:
filter_{left|right|any}
: Call Option::filter
on the respective tuple elements.filter_map_{left|right|any}
: Call Option::and_then
on the respective tuple elements.I know that calling the Option
-combinators on the respective tuple elements may involve creating a temporary, but that could be mitigated by implementing methods on tuples (T0, T1)
so that one could e.g write tuple_containing_two_options.map_first_element(Option::filter)
.
Would your use-case prohibit (Option<L>, Option<R>)
instead of Option<EitherOrBoth<L, R>>
? I.e. could you use left_and_right
in your case?
In my case, Option<EitherOrBoth<L, R>> is more straightforward to use because ?
can be used, which leaves me with an EitherOrBoth<L, R>
, which is ultimately what I needed.
I'll add that since I submitted this PR, I've... actually stopped needed these methods, so they might very well be very niche-y.
I see, thanks for the explanation.
I close this for now and will come back to it if there seems to be more need for them.
Note to myself: Maybe we can implement ‘EitherOrBoth<Option, Option>‘ to have a method ‘ filter_out _none‘, returning the suggested type. Might compose well enough to cover the use cases.
map, filter and filter_map on EitherOrBoth<T, T> might be more easily useful, though, to apply the same closure to both sides.
These are methods that I found useful for my use.
I also have a
that is not part of this PR because it seemed really too niche. (My own real usecase is starting from
EitherOrBoth<Either<A, B>, Either<A, B>>
)