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.
> 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.
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 .?
}
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.