-
Notifications
You must be signed in to change notification settings - Fork 6
Description
Hi, I just recently adopted your library and while converting code I noticed some issues with cases where the Either contained a null value inside of it.
Example
// contrived example
fun findUserById(userId: Int): Either<String, User?> {
return null.right()
}
@Test
fun `findUserById returns right value when no user is found`() {
val actual = findUserById(1)
assertThat(actual).isRight()
}
will fail to compile with an error like Kotlin: Argument type mismatch: actual type is 'arrow.core.Either<String, User?>', but 'arrow.core.Either<LEFT, RIGHT>?' was expected.
Honestly, in my code base this mostly only occurs on the right side, and admittedly could be rewritten other ways to avoid it, such as wrapping the null as an Option instead, or encoding the null value as a non-null on the left side and then recovering. However, I think there are two good reasons to support this, Kotlin's strong compile time null checking and Arrow's support for Either's containing null values on the left or right side, so it would be preferable to bring this convenient assertion library (thanks again for your work and publishing this) into alignment, as Eithers withnull values can be used safely and idiomatically. It looks like null NonEmptyLists are already supported, so the gap I've noticed looks to just be with EitherAssert.
Please let me know if you see any potentially pitfalls in adding this support