@raulraja @simon.vergauwen I’ve raised this PR to address some (not all) of the missing option extensions that we had to introduce internally https://github.com/arrow-kt/arrow/pull/2397 if we can get these (esp. the traverses) to be supported natively in arrow, that’s going to be massive for us!

Looks great @mitch, thanks so much for taking the time 🙂

Awesome thanks @raulraja, I've addressed your comments. Going to wait for others to review as well.

Nice job 🙂 I have a question/thought for @raulraja and @simon.vergauwen. It’s already reviewed so may not warrant any changes. Some of the Option operations can be expressed as

nullableOp.toOption()

, would this be better or worse than duplicating logic? Duplicates aren’t always bad 😅 Let me know what you think 🙂

I think given we accepted Option back and people use it in places where nullable types can’t be used we should accept it as first class citizen and offer the same set of apis as other data types.

Sorry @raulraja I think I didn’t explain myself well. I don’t mean to not have these but rather if we should, internally, define them as:

inline fun <C> traverseOption(
    fa: (B) -> Option<C>,
  ): Option<Either<A, C>> =
    traverse(fa).toOption()

or as extension functions: inline fun <A, B, C> Either<A, B>.traverseOption( fa: (B) -> Option<C>, ): Option<Either<A, C>> = traverse(fa).toOption() 🙂

I see, the general consensus was that whenever it’s possible regular members is favorable to users because it does not impose an additional import. Too many extension imports has been a problem to arrow and the only reason why we have in some cases extensions is due to the nature of contravariance and how kotlin treats it in members. For example it’s not possible to implement

Either.flatMap

as a member without using

@UnsafeVariance

or similar hacks but it’s possible to implement it as an extension because in extensions type arguments are invariant and spelled out in the function.

Ignore the extension fun 😅 Shouldn’t have mixed matters hehe. The first snippet is the important one

you mean that in your example

traverse(fa)

returns a nullable value and the you convert it to option?

So, to the end user would be the same but we save some code on our side. Nullable is “inlined” i.e. has no wrapper. But, as I said, it’s not always better to remove duplicates, depends on the case