3 ms·

Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under th

Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under the sun. What Kotlin & cie are saying is that if your parameter is a RandomGenerator, null should not be allowed there because null is not a RandomGenerator. Null is null and that's it. If you search something in a map, your value will be of type "String?", that is "String | null" and that's completely fine, the compiler will assist you with that too.

wizofaus 4y ago
I'd even question whether a function whose job it is to "find" something should be able to return a Nullable value - or at least, it shouldn't be possible to just force such a value to be treated as an actual value (as is allowed by Swift/Kotlin/C# etc with "force unwrap" type operators). I'd rather see a language with built in support for functions that can either return one type or another, whereby the caller must provide two code paths to deal with each. And yes this would imply you could never simply call such a function and store its return value in a variable.
- tadfisher 4y ago
  That was the initial intent behind Kotlin's Result<T> type; it was only allowed to be a return value from compiler-blessed functions (runCatching and friends) and was not allowed to be stored in a property. The problem became this additional function color; also, no language construct can prevent users from implementing "fun Result<T>.unwrap(): T" and crashing the program in the failure case. OK, you could also restrict functions that accept Result<T> (as a receiver or parameter), but now you force resolution of that type by the direct caller of the function returning Result<T>. So really this becomes a worse version of checked exceptions, which (thankfully) don't exist in Kotlin.

3 ms·

Nobody is removing null because null itself is not the mistake. The mistake was to say like in Java that null is a valid value for every possible class under th

by anonyme-honteux 4y ago

wizofaus 4y ago
I'd even question whether a function whose job it is to "find" something should be able to return a Nullable value - or at least, it shouldn't be possible to just force such a value to be treated as an actual value (as is allowed by Swift/Kotlin/C# etc with "force unwrap" type operators). I'd rather see a language with built in support for functions that can either return one type or another, whereby the caller must provide two code paths to deal with each. And yes this would imply you could never simply call such a function and store its return value in a variable.
- tadfisher 4y ago
  That was the initial intent behind Kotlin's Result<T> type; it was only allowed to be a return value from compiler-blessed functions (runCatching and friends) and was not allowed to be stored in a property. The problem became this additional function color; also, no language construct can prevent users from implementing "fun Result<T>.unwrap(): T" and crashing the program in the failure case. OK, you could also restrict functions that accept Result<T> (as a receiver or parameter), but now you force resolution of that type by the direct caller of the function returning Result<T>. So really this becomes a worse version of checked exceptions, which (thankfully) don't exist in Kotlin.