4 ms·

No, obviously not. Every domain having a Nil element is exactly the problem null references have introduced (at least for the call by reference parts of the af

• agumonkey 7y ago
  Null is a single nil for all, I meant having a null per domain would force people to think of what it means to have nothing in that field and handle it. Maybe I'm too naive.
  • augusto2112 7y ago
    Sometimes you don't want to allow a value to be null at all, but with null references you can't represent that at the language level.
    • agumonkey 7y ago
      But for numbers, a zero is not considered null, because it was handled in the operators rules.
      • fhars 7y ago
        Numerical zero has nothing to do with the issue discussed here. What you are proposing is to add another “number” to types like int and float that results in the program crashing whenever you try to add it to another number.
        • agumonkey 7y ago
          I think it does
        • strictfp 7y ago
          It does! It's the numerical "null object", just like the empty string and empty collection.
        • reificator 7y ago
          > What you are proposing is to add another “number” to types like int and float that results in the program crashing whenever you try to add it to another number. There's already division by zero and NaN to trip you up in IEEE754.
        • goatlover 7y ago
          Or there's NaN which just results in NaN and doesn't equal itself. No need to crash.
  • masklinn 7y ago
    > I meant having a null per domain would force people to think of what it means to have nothing in that field and handle it. In what way would it change anything? The "billion dollars mistake" is that because "nothing" is part of every type, any value you get could really be missing, and you have to either hope for the best (and die like the rest) or program ridiculously defensively. Having a magical sentinel per type would have the exact same issue, namely that "nothing" is part of the type itself, and so you can never be sure at compile time that you do have "something". That's what opt-in nullability (whether through option types or language builtins or a hybrid) changes, by default if you're told you have an A it can only be a valid A, and if you're told you might have an A you must either check for it or use "missing-safe" operations.
  • erik_seaberg 7y ago
    This is one of Go's weirdest features. When you cast nil to an interface, you pay for extra storage so the runtime can do method dispatch on what type of object you don't have, even though every implementation is likely to panic immediately.