Hi guys. We’re replacing our custom made Optionnal with Arrow’s and I’m having a struggle chosing a ...

# arrow

[Jérémy CROS]

Hi guys. We’re replacing our custom made Optionnal with Arrow’s and I’m having a struggle chosing a syntax. What do you think? Both are the same? Or is there a prefered syntax? Or even a third option? (also, I have a few more like that 😄 hopefully, it has not already been answered a billion times 😄)

Untitled

[raulraja]

You could do option.map(::doSomething), but really unless you are using polymorphism for Option nullable types is preferred and we have plans with in time deprecate Option

[ibcoleman]

Hey @raulraja, do you have link to a longer piece on why Arrow’s dropping Option in favor of nullable types?

[raulraja]

Option and Nullable types are isomorphic. Since the Lang embeds option in the type system it eliminates the need to map, just, flatMap etc because all those operations only make sense in wrapped types. For that reason nullable types are more efficient at runtime and offer exactly the same type safety as Option. Option was the first data type ever created in Kategory before it got merged with Funktionale into Arrow. It was as an exercise to see if ADTs were possible in Kotlin and we we're stuck with it for a long time.

[raulraja]

In the case of IO it's different because despite the Lang having suspend it lacks cancellation in the std lib intrinsics so certain IO operations need to be wrapped to guarantee resource safety on IO or suspend ops.

[raulraja]

Option incurs in allocations and does not benefit from smart casting since we have no experimental contracts enabled

[ibcoleman]

Thanks, I read up a bit on this last night, but your answer was much more concise!

[Jérémy CROS]

Big thanks Raul for the detailed explanation, it has given us food for thought!

[raulraja]

👍

[raulraja]

I'll make sure to post all new features and changes for the Arrow Road Map the moment we get the features in meta stable and we are able to commit to them. Currently working on that