Hello Everyone, I’m working on implementing PATCH ...

# arrow

[P A]

Hello Everyone, I’m working on implementing PATCH support for an HTTP API. I’m considering using Arrow’s Option type rather than implementing my own. Under PATCH, the three cases to handle are value present(update), value present but null(update by removing the existing value) and value absent(no update). Below is a short snippet of how this would work.

data class Foo(val bar: Option<String?>)

Foo("the value".some())
Foo(null.some()))
Foo(none())

fun main() {
	when (val bar = Foo(Some("string")).bar) {
		None -> TODO()
		is Some -> TODO()
	}
}

The arrow documentation says “There are only a few cases where you should use Option instead of nullable types, and one is the nested nullability problem.” I’m wondering if this group consider this use case a valid one or if there other aspects I should be aware of (e.g., explicitly use the Some or .some() constructor).

[mitch]

We have the same use case and that's how we implemented that internally as well.

[mitch]

options nest well you can also model that as Option<Option<A>> as well. Although conceptually I think Option<T?> is probably more representative because null here is passed as a non-absent value

[P A]

Thank you for your insight!