I would say that “good” is a exaggeration here. I haven’t used that construct once, in six years of full-time Scala, and in practice I’ve rarely seen it used. IIRC, we don’t even teach its existence in any of Artima’s Scala courses. So I don’t think it’s “good” – IMO, it’s a very-rarely-needed evil, that exists for some edge cases.
Also, I’d be careful not to misinterpret @sjrd’s words. As I understand it, he’s arguing against conflating
null too closely. But the fact is,
null is often used to mean “optional value” in idiomatic Java code – that’s why it is so common (and idiomatic) to say:
val f: Option[Foo] = Option(javaFuncThatReturnsFooOrNull())
I’m pretty strongly of the opinion (and I don’t think it’s unusual) that
null should not usually be allowed to leak into Scala code. It’s occasionally necessary, but in most cases I’ve encountered, unless you specifically need to leave the
nulls for performance, they should be converted to and from
Option at the Scala boundary.
Hence, I’m in favor of the proposal personally – if a
null ever shows up in my company’s code, I want that to be an error…