For arrow 2.0 will Option be deprecated?

# arrow

[Kristian Nedrevold]

For arrow 2.0 will Option be deprecated?

[simon.vergauwen]

We want to demote it, because nullable should almost always be preferred.

We're not sure how to do it best, perhaps we'll move it out of Core and moved to arrow-option separately so it's an explicit opt-in.

It will not be removed, since Project Reactor and Spring users rely on it quite often. Similarly for nested null problem, which is niche in domain code.

[Cody Mikol]

I've been using it to represent the existence of nullable query params. How else are people using it in Spring?

In my case

userAge: Option<Int?>

/user?age=null -> userAge = Option.some(null)
/user?age=33 ->   userAge = Option.some(21)
/user ->          userAge = Option.none()

It's been really useful to represent T? as something that may or may not be present.

If it gets moved into another package will support for it continue, or would you suggest moving away from relying on it?

[Kristian Nedrevold]

Can't you just use a value class for that?

[simon.vergauwen]

This is the nested null problem, so in this case it makes sense. Another reason to use it in Spring is Project Reactor, which doesn't allow for null inside of Mono or Flux.

[simon.vergauwen]

We're not 100% sure if we'll move it away but we want at least want to clarify it better in the documentation that it's only useful for the use-case you describe here @Cody Mikol or the generic null problem like Project Reactor has. Which is actually the same issue of nesting nulls. That's actually a great example for the documentation.

[Kristian Nedrevold]

This would work?

data class Person(
    val name: String,
    val age: Age?)

@JvmInline
value class Age(val age: Int?)

[simon.vergauwen]

This should also work

[Kristian Nedrevold]

Obviously now you are defining a whole bunch of value classes instead of using the same generic "container". I'm not sure which is better, but the value class maybe feels a bit more idiomatic to Kotlin

[Kristian Nedrevold]

there is also generic inline classes as an experimental feature. So maybe

value class NullableParameter<T>(val parameter: T?)

[simon.vergauwen]

I think this will have the same performance characteristics as Option, otherwise it cannot work on the JVM level 🤔 I.e. boxing will be applied almost always

[Kristian Nedrevold]

Yes, I think you're right.