Current sentiment on Nullable.get

[Sebastiaan Koppe]

Oops...

When creating a PR to update the docs on Nullable, I was checking 
the semantics of Scala's optional type.

 From what I can gather there was a lot of discussion in the Scala 
community about the very same topic:

---
var a: Option[String] = Some(null)
a.isDefined   // returns true!
---

They settled for this because Scala is build on top of Java and 
code written in Java could use the null value to signify 
something other than None. Often something like "present, but 
uninitialised".

It is something that they very much like to see different, and a 
lot of Scala developers cringe when they see it. Also, they have 
the Option constructor that corresponds with the semantics aliak 
and I argued for:

---
var a: Option[String] = Option(null)
a.isDefined    // return false!
---

I am slowly understanding why you would need some version of 
Nullable where isNull needs to return true for null values. It is 
for that uncommon case where null has semantics beyond not being 
a value. For instance, a library could use null to signify that a 
key is present but has no values assigned to it. Or some code 
could assign a difference between an array with a null item and 
an empty array.

---
[null].head() == Nullable!T(null);
[].head() == Nullable!T.init;
---

Thanks for your perseverance Jonathan :)