mitch10/12/2023, 12:48 PM
was godsend is because it doesn't have the nested nullability problems. We don't have to think about it when we write code.
Youssef Shoaib [MOD]10/12/2023, 2:21 PM
simon.vergauwen10/12/2023, 2:30 PM
T | Null
it'll probably open a can of worms with all existing code, and probably requires a bunch of special changes to support the current
syntax only for
, so does it really solve the nested nullability issue? Perhaps
T | Null | Null <~> T | Null
🤔 cc\\ @Alejandro Serrano.Mena Did you ever get to test that branch against Jackson, or Project Reactor @mitch?
(T | Null) | Null
Youssef Shoaib [MOD]10/12/2023, 2:32 PM
simon.vergauwen10/12/2023, 2:32 PM
in libraries now, and it's super ugly
val res: Any? = EMPTY
would solve some nullability issues when working with Java too though. Some libraries don't allow
A | None
as a value
Alejandro Serrano.Mena10/12/2023, 3:07 PM
simon.vergauwen10/12/2023, 3:10 PM
A | B
. > The more I look into this, the more I think that the problem is conflating nullable types with a potential missing element in the collection It goes beyond that, it's bitten me in non-collection generic code as well. The problem is always using
B | A
as an "error" signal in generic contexts.
mitch10/13/2023, 1:18 PM
. Boxing null into a value type
T | null | null == T | null
is also going to suffer the same fate i'm afraid... it means we would have an unrepresentable type when T is nullable I.e.
Option<T> == (T | null)
In other words, option as value class will make the Option type unsound for
Option<T?> == (T | null | null) == (T | null)
I.e. it breaks identity law for any nullable type... By contrast, swift and current arrow option uses tagged union of
which is well behaved for any T and T? E.g.
Option<T> = Some(T) | None
Observe how it nests elegantly as well
Option<T?> = Some(T | null) | None
which simplifies to
Option<Option<T>> = Some(Some(T) | None) | None
Some(Some(T)) | Some(None) | None