Algebraic data types are not direct support "no data found at the type level". Algebraic types are really just a fancier enum/union type. It just so happens that inventing special sentinel values is awesome when you have an algebraic type system to check your work.
That means several things:
* T (non-nullable) and T? (nullable) are different types. T? = T | null
* Where T is expected T? is not accepted, but where T? is specified T is also accepted
* T? is automatically cast to T in the places where it's asserted to be not null, e.g. within an if(x != null) branch
* Method calls are not allowed on T? (unless the function specifies it can handle null)
* There's syntax for providing a value in case of null. (x ?: fallback) in Kotlin, (x || fallback) in Typescript.
Typescript goes even further and has the best enumeration support I've seen any language have. T | U is a fully valid type, and if T | U is asserted to be one of them it is automatically cast to T/U. It is a very natural and efficient way of building ADTs [1]
† Typescript 2.0+ with --strictNullCheck on
[1] https://www.typescriptlang.org/docs/handbook/advanced-types.... , Discriminated Unions header
macro! unwrap(x, fallback) {
match x {
Some(n) => n,
None => fallback
};
}
That's pretty cool. It seems like refinement types. [1]
[1]: https://en.wikipedia.org/wiki/Refinement_(computing)#Refinem...
Having worked with both Scala, Haskel, Kotlin and Typescript I disagree, the dev experience for Kotlin/Typescript is miles ahead for optionality. It seems like a small difference vs something like do notation or for comphrehension but it really adds up.
It hard to explain until you've tried it. The most succinct way would be to say that optional code looks and feels nearly identical to non-optional code, instead of unwrap/do-notation which makes a very large syntactical difference.
Take a look at a piece of async Kotlin co-routine code v.s. Java/Scala (Completable)Future, same effect.
(Previously said T?? rather than T?, thanks to corrections in replies)
Huh? T?? would always be the same type as T?. `T | NULL | NULL == T | NULL`.
But T?? is always identical to T?.
More generally, with unions you always have this behavior but I've never seen this be a problem. If your function accepts T | U and you pass (T | U) | U it simplifies to T | U and in my experience the code that handles U is always the correct thing to do for U.
So does that mean you can't call generic methods with ? types? Because there's an excluded middle here: either something like String? is a first-class type, in which case you can invoke a <T> T ... method with T=String? and then any T?s inside that method have the potential to misbehave, or you can't, in which case String? becomes an awkward second-class type.
If a generic function f accepts a covariant Dog and Animal is a supertype of Animal you cannot call f with Animal because it requires a Dog. if f accepts a covariant Animal you can call it with a Dog because Dog is a subtype of Animal.
Now replace Dog with T and Animal with T? and you can see it is perfectly fine.
Can I have a Map<String, Dog?> ? If no, then Dog? isn't a first-class type. If yes, we have all sorts of nasty surprises, because code written in terms of Map<String, T> will assume that if map.get(someKey) is null then that means someKey isn't in the map, and this code will work fine until someone uses a ? type for T and then break horribly.
yes
> because code written in terms of Map<String, T> will assume that if map.get(someKey) is null that means someKey isn't in the map
And it can safely assume that. Map<String, T?> isn't a subtype of Map<String, T>, so passing Map<String, T?> to a place requiring Map<String, T> will not compile.
T is a subtype of T?, not the other way around. Map is defined as Map<K, out V>, meaning V is covariant.
So you can pass a Map<String, Dog> where a Map<String, Dog?> is required, but not a Map<String, Dog?> where a Map<String, Dog> is required.
Well, uh, unless T can be falsy. 0 || fallback === fallback. A proper ?? operator a la C# would be great, but they've pushed back against it because it doesn't entirely mesh well with nulls in the JS world.
JS is still probably my favorite language to work in despite stuff like this. But that's one footgun that everyone should be aware of.
I strongly disagree.
You don't need pattern matching syntax to use option types effectively. All you need are the right methods - map, flatMap, getOrElse etc etc. Any language with inheritance and dynamic dispatch can implement a good option type.
Even in languages with pattern matching, I never reach for it when dealing with options.
No, but they serve a superset of the semantic functions of nulls, better than nulls do.