3 ms·
> The problem is not nullable references Disagree. If you don't PUT the nulls into the language, you don't need a brigade of PhDs to develop the static analys
by mrkeen 4y ago
> The problem is not nullable references
Disagree. If you don't PUT the nulls into the language, you don't need a brigade of PhDs to develop the static analysis to tell you whether you have nulls.
I'm sick of worshipping at the altar of backward compatibility. Just because we used to choose to include nulls doesn't mean we need to keep choosing to include them.
- MrBuddyCasino 4y agoYou still need to signal the absence of a value. This is not necessarily the same thing as a monadic Return<R, E> type as in Rust, which I quite like and would prefer over exceptions. I think the Kotlin solution is very elegant, considering the restrictions of the host platform of using exceptions as error signaling mechanism.
- dgb23 4y agoYou missed the point entirely. Nulls are just part of proper unions in Kotlin (and other languages). They are just part of the type and they are explicit. Instead of having to wrap an optional value, you just annotate the type as being the union of something _or_ null. You get the same guarantees, but it actually composes openly instead of having to create a closed, specific construct that enumerates variants.
- mrkeen 4y ago> You missed the point entirely. No.