Current sentiment on Nullable.get

[aliak]

On Monday, 17 December 2018 at 09:39:12 UTC, Sebastiaan Koppe 
wrote:
> 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 :)

Yeah, that scala thing :( - you can guess which side of the 
argument I'm on :p Java null mixed in with scala optionals has 
bitten me numerous times - e.g. trying to get JSON data out of 
jackson. Most crashes have been because of java to scala and/or 
kotlin interop and because of java nulls. There was one SDK we 
were working on - kotlin version and swift version. Guess which 
one basically didn't crash, and guess which one crashed because 
of java nulls hiding in kotlin nullables.

I remember at some point swift allowed the same thing. And again, 
it was just a source of bugs. I don't think you can do that now 
in swift unless you really mess with reflection APIs and the 
objective-c runtime. But I'm not sure.

Anyway, I do agree that you need a way to represent null if it's 
a valid value. And IMO, null is a valid pointer value which is 
why I also argue you can't use pointers as optionals since null 
can be a valid value. And the cool thing about D is that we have 
pointers and classes. And I think an optional of T* should be 
sufficient for the uncommon use-cases you speak of (see: 
https://run.dlang.io/is/qh2OdQ).

I'm still not sure why you would want that with D classes 🤷‍♂️ But 
maybe there's code out there that does, which would be great to 
look at to see why it is doing that.

Cheers,
- Ali