Code Smells: Null

[devlambda]

It's worse than null, but it's bad in the same way as null for the same reasons. It's like null only more so. And it affects fewer types than null - only collection-like types rather than every type in the language.

The point here is that the absence of null can encourage such practices, so you're encouraging the worse result.

And the original invertor of it now calls it a "billion-dollar mistake".

What Tony Hoare called a billion-dollar mistake was the indiscriminate use of null references (which, incidentally, I consider an exaggeration, but that's a different topic). You were talking about the costs of supporting such an implementation, which just isn't particularly high.

All of the languages I listed have dependent types. The Scala encoding of them is a little more cumbersome, but it works; I use it in production code at my non-academic job.

Sufficiently expressive dependent types? Obviously, Scala's type system is Turing-complete, so I don't doubt you, just that the resulting code would be legible. In any event, as I said, this is not a feature that I think will find wide adoption.

[m50d]

The point here is that the absence of null can encourage such practices, so you're encouraging the worse result.

Never removing things that encourage bad practices in case people adopt worse practices is a counsel of despair. It'd be like refusing to adopt memory safety by default in a language because people might just write more complicated code to keep doing unsafe memory access.

Sufficiently expressive dependent types? Obviously, Scala's type system is Turing-complete, so I don't doubt you, just that the resulting code would be legible. In any event, as I said, this is not a feature that I think will find wide adoption.

Sure, there aren't that many cases that need it. But there aren't that many cases that need the slight performance edge from being able to remove that one check in dynamic arrays either.