I find the Erlang/Elixir treatment of null to be acceptable.
It (nil) is an atom (as are false, and true), definitely not conflatable with zero.
The only thing that is "dangerously" affected is "if", which fails on "false" and "nil" exclusively. Everywhere else you have to treat nil as its own entity.
Maybe something similar to this is the best approach?
Continuing with my idea of making all data N-dimensional matrices, nil or null would just be an empty matrix. Then a statement like if ([]) wouldn't make any sense because an empty matrix shouldn't be truthy or falsy. It should throw a compiler error.
Erlang and Elixir are dynamically typed languages. The million dollar mistake does not apply to dynamically typed languages. Guaranteeing that a variable cannot be null is not very helpful when you can't guarantee that variable's type.
I find the Erlang/Elixir treatment of null to be acceptable.
It (nil) is an atom (as are false, and true), definitely not conflatable with zero.
The only thing that is "dangerously" affected is "if", which fails on "false" and "nil" exclusively. Everywhere else you have to treat nil as its own entity.
Maybe something similar to this is the best approach?
Continuing with my idea of making all data N-dimensional matrices,
nilornullwould just be an empty matrix. Then a statement likeif ([])wouldn't make any sense because an empty matrix shouldn't betruthyorfalsy. It should throw a compiler error.Erlang and Elixir are dynamically typed languages. The million dollar mistake does not apply to dynamically typed languages. Guaranteeing that a variable cannot be
nullis not very helpful when you can't guarantee that variable's type.You can definitely guarantee variable's types in Erlang and Elixir.
By doing explicit checks. How do these differ from null checks?