> Well, try to minimize the usage of nulls in your programs then :D
I am a java guy since 1.1 and it seems to me that a lot of problems in Java come down to it being designed for a time when a application mainly consisted of in-house / in-org / self-written code. In $currentYear, however, we mostly plug libraries into frameworks and it's just a pain to check every call and every return value for the possibilities of null. Yeah, it can be done but I just don't like having to read library source code to find out if it will return a null in some cases.
Open-source libraries were much less common when Java first arrived, but third-party C / Fortran libraries were very common in many domains much before Java arrived.
Nulls, arrays degenerating into pointers (losing size information), and accidentally crossing enum types across libraries were all huge sources of bugs. Java doesn't have much of an excuse for its treatment of nullability, other than they were trying to court C/C++ developers.
When I first got into Kotlin I thought that null safety was a matter of getting rid of null, like some try to do in their Java code.
Now I know that actually it gives me liberty to safely use null wherever I want and not have to worry about it blowing up in my face later.
The keys to this is that the language makes it obvious what can be null "Type?" and by giving me ergonomic tools to handle nulls such as ? and :? and compiler non-null inference. I wonder how this pattern of
make X visible and give ergonomic tools to handle X
could be applied to improve other aspects of programming.
basically that's how it works in Kotlin (and Dart and others) already. String? is String|null and it's a compiler error to reference a member without a prior null check.
In Kotlin (and others) it's extremely ergonomic, too. You just say foo?.bar and coalesce with ?: so
val baz = foo?.bar ?: "foo or bar is null"
In certain cases the Kotlin compiler will infer non-nullable type after an explicit null check just like in your example such that
fun bestFunction(foo : String?) {
if(foo == null) return
foo.baz <- //now legal to call without .?
}
Not really. The gp is complaining about the lack of semantics about what a missing value means. `String?` still doesn't tell me what not having a string means. `String|NotProvided` or `String|NotFound` or `String|InvalidInput` all have the same functionality as `String|null` but tells me something about what the missing value is indicating.
I mean, generally I would love (more) union types, unfortunately so few languages have them.
For Ops requirement I think it's too specific for a language level feature. In Kotlin you'd just use a sealed type in the cases were you really need to know why function can't produce a value. Works like a charm.
I am a java guy since 1.1 and it seems to me that a lot of problems in Java come down to it being designed for a time when a application mainly consisted of in-house / in-org / self-written code. In $currentYear, however, we mostly plug libraries into frameworks and it's just a pain to check every call and every return value for the possibilities of null. Yeah, it can be done but I just don't like having to read library source code to find out if it will return a null in some cases.