You don't just not use nulls, you replace them with something like Optionals. With a bit of language support, they can compile down to nulls but provide a layer of type safety and convenience functions.
Allowing nulls explicitly, like with a "String?" type, is the way to go in languages where Option is not an option.
1. Option is a regular data type/object that represents "a collection of at most one value". It's similar to a list, set, heap, tree or whatever other collection types you have, except it can not contain more than one value.
2. With explicit nulls I guess any data type (e.g. Integer) will automatically get a clone of itself (a different type named Integer?) where also null is a valid member.
From a purely theoretical standpoint, I like #1 better.
Here's a Java example where I want the type system to enforce that a method in `ClassB` can only be called from `ClassA`. However, the fact that `null` circumvents the type system makes this pattern just wishful thinking.
class ClassA {
private static final Witness witness = new Witness();
final static class Witness {
private Witness() {}
}
void callClassBMethod(ClassB classB) {
classB.onlyClassACanCallThisMethod(witness);
}
}
class ClassB {
void onlyClassACanCallThisMethod(ClassA.Witness witness) {
// ...
}
}By encoding `null` in its type system, Kotlin lets you manipulate these values directly which leads to code that is much less noisy and just as safe.
The main strength of the first approach is that Option is only one type out of many error-handling structures.
Not every error is handled appropriately by Option/?.
If you have a language like Kotlin where they hard-coded one way of handling errors, it feels very unidiomatic to pick a better fitting error handling type, while in languages where errors are handled by library code, it's a very natural approach.
Which is expected since these two constructs are not aimed at handling errors: they manage missing values.
> If you have a language like Kotlin where they hard-coded one way of handling errors
No, no. `?` is not for handling errors.
Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
> Which is expected since these two constructs are not aimed at handling errors: they manage missing values.
Which is a very small part of handling errors in general. As Kotlin offers special syntax for only this case, developers tend to shoehorn many errors into the "missing-value" design to get the "nice" syntax even if a different approach would have been more appropriate.
> Kotlin is as agnostic as Scala for managing errors: you are free to use exceptions, dumb return values or smarter ones (`Either`, `\/`, `Try`, ...).
That's not true in practice:
Just have a look at funktionale: Despite providing almost the same as Scala's error handling types (partially due to the blatant copyright violations) almost nobody uses it. This is a direct result from having a "first-class" construct in the language: It turns library-based designs into second-class citizens.
That's the thing Scala got right, and many of the copy-cat languages got wrong.
Missing values are not errors.
If you look up a key on a map and that key is not present, it's not an error.
> partially due to the blatant copyright violations
Uh copyright what? On an API?!?
Call it whatever you want. ? only covers a small subset of interesting "conditions" while tremendously hurting "conditions" which could be handled in a better way.
> Uh copyright what? On an API?!?
Implementation. The copying of slightly buggy exceptions strings makes it even more obvious that files were copied verbatim with just enough syntax changes to turn Scala code into Kotlin code while replacing the original license and authors with different ones.
PS: Feel free to comment on actual the points I made.
Sure.
I think the idea that API's (or implementations as you said) can be copyrighted is completely insane and I can't believe any software engineer would be okay with it. Which makes me think you're not a software engineer, and that's okay, but please read up on the issues, this is super important for our profession.
I can't belive the US made that a law and it makes me sure that I will never want to move there.
I think you are super confused here. This is not about APIs. Copyright is what allows software developers to enforce a license of their choice. Without copyright, the license is just a text file without meaning. I suggest you read up on the FSF's position on this if you want to have an example.
> Sure.
(Still waiting for you to comment on the points I have made.)
Option[Option[String]] != String??It might not be very interesting in the Option[Option[String]] case but imagine Try[Either[String, Int]] or List[Future[Double]].
It's a very important distinction.
Collapsing cases is one of the primary thing why exceptions sometimes get a bad rap, and Kotlin (and Ceylon) do the same with ? (and |, &) at the value level.
https://www.eiffel.org/doc/eiffelstudio/Differences%20betwee...
Storing None for an Option<&T> as a null and Some(ref) just as the reference is an special optimisation that the rust compiler does. Usually you have a selector which tells you which variant of the enum it is.
Tree *a = new Leaf();
Tree *b = new Leaf();
Tree *c = new Node(a, b);
a.parent = b.parent = c;
data Tree = Leaf Tree | Node Tree Tree
a = Leaf c
b = Leaf c
c = Node a b
Tree *a = new Leaf();
Tree *b = new Leaf();
Tree *c = new Node(a, b);
a.parent = b.parent = new Some(c);