5 ms·

The point is that option types let you explicitly state which values are nullable, but null references mean that every value is potentially null even if it does

The point is that option types let you explicitly state which values are nullable, but null references mean that every value is potentially null even if it doesn't make sense.

pryce 8y ago
And that having everything being 'implicitly nullable' is a categorically worse for maintainability, readability and comprehensibility than using explicit Option<T> types at the boundaries; such as the implementation in F# [1], with an expressive matching syntax. It is now common when creating a library to rely on manual checking and coders explicitly writing code to check and throw NullArgument exceptions for each object parameter in every public method, and then writing dozens or hundreds more pointless unit tests to ensure this null exception behaviour works as expected; this is totally unnecessary in languages that demand explicitly stated Option<T> when an Option is meaningful. Instead of requiring all the above for safety -an approach which will notably fail to report any errors if the null argument checks are partially or completely omitted- we have -and we should prefer- languages where the compiler or interpreter will not let us pass null into a function where null makes no sense, because that fact is encoded in the function definition. At the library boundaries, which are comparatively rare to internal code, we can simply use the explicit Option type. I should note I have one objeciton with the F# implementation - in that I think that ideally the properties { .IsSome, .IsNone, .Value } should not exist, as they promote bad programming practices. [1] https://fsharpforfunandprofit.com/posts/the-option-type/ https://fsharpforfunandprofit.com/posts/the-option-type/
- rkbjones 8y ago
  Not for readability. Checking for NULL becomes second nature after programming on a real world C project for a while. I cannot recall the last time I forgot it. On the contrary, I wish C had INT64_INVALID etc., which would facilitate some APIs considerably. Of course that's a dream that would require something like 72-bit words, where one byte is reserved for flags. This would also be a dream for GC flags... Also, since Hoare et al. the tooling has gotten much better. Valgrind catches really almost everything.
jcelerier 8y ago
That is only the case in reference-centric languages such as Java, C#, JS, etc. In value-based languages, "values" can't be null, while "references" can. For instance a `std::string` or a `double` in C++ can never be null ; a pointer to either can be but that's far from idiomatic.
- lmm 8y ago
  That approach doesn't really work, because C++ conflates where a value is stored with whether the value can semantically be null. Sometimes you want a nullable value that's on the stack. Sometimes you want a non-null value in the heap. Both these things are hard to do in C++.
  - TheCoelacanth 8y ago
    Neither of those is hard to do in C++. The first one is std::optional. The second one is a reference or a non-nullable smart pointer like https://github.com/dropbox/nn https://github.com/dropbox/nn
    - frabert 8y ago
      It's easy to do _since less than a year_
      - jandrese 8y ago
        And probably not in your compiler yet. Or if it is, you'll blow up on thousands of other compilers when people try to build it themselves.
      - jcelerier 8y ago
        boost::optional has been available since 2003. There's no excuse.
RX14 8y ago
You don't need option types for the compiler to enforce safety around nulls. Its possible to model null as its own type in the type system to enforce safety.
- coldtea 8y ago
  This means you need a different type system though.
  - RX14 8y ago
    Yeah, its a good option for new languages though.
    - lmm 8y ago
      It's the same mistake as checked exceptions all over again. If you make null a special case in the type system then anything that interacts with the type system has to know about null or will handle it wrong. Far better to have the type system work with plain (non-nullable) values, and implement a plain old library type like Maybe/Option for use in places that need absence semantics; that way your concerns are properly separated and you can spend your type system complexity budget in more generally applicable ways.
      - RX14 8y ago
        Just because null is a type in the type system doesn't mean it has to be a special type.
        lmm 8y ago
        That's the only way I've ever seen it implemented. If you're proposing some idea for having null in the type system as a normal type (that doesn't boil down to just being equivalent to Option/Maybe), can you be more concrete?
        8y ago

The point is that option types let you explicitly state which values are nullable, but null references mean that every value is potentially null even if it doesn't make sense.

pryce 8y ago

And that having everything being 'implicitly nullable' is a categorically worse for maintainability, readability and comprehensibility than using explicit Option<T> types at the boundaries; such as the implementation in F# [1], with an expressive matching syntax. It is now common when creating a library to rely on manual checking and coders explicitly writing code to check and throw NullArgument exceptions for each object parameter in every public method, and then writing dozens or hundreds more pointless unit tests to ensure this null exception behaviour works as expected; this is totally unnecessary in languages that demand explicitly stated Option<T> when an Option is meaningful. Instead of requiring all the above for safety -an approach which will notably fail to report any errors if the null argument checks are partially or completely omitted- we have -and we should prefer- languages where the compiler or interpreter will not let us pass null into a function where null makes no sense, because that fact is encoded in the function definition. At the library boundaries, which are comparatively rare to internal code, we can simply use the explicit Option type. I should note I have one objeciton with the F# implementation - in that I think that ideally the properties { .IsSome, .IsNone, .Value } should not exist, as they promote bad programming practices. [1] https://fsharpforfunandprofit.com/posts/the-option-type/ https://fsharpforfunandprofit.com/posts/the-option-type/

rkbjones 8y ago
Not for readability. Checking for NULL becomes second nature after programming on a real world C project for a while. I cannot recall the last time I forgot it. On the contrary, I wish C had INT64_INVALID etc., which would facilitate some APIs considerably. Of course that's a dream that would require something like 72-bit words, where one byte is reserved for flags. This would also be a dream for GC flags... Also, since Hoare et al. the tooling has gotten much better. Valgrind catches really almost everything.

jcelerier 8y ago

That is only the case in reference-centric languages such as Java, C#, JS, etc. In value-based languages, "values" can't be null, while "references" can. For instance a `std::string` or a `double` in C++ can never be null ; a pointer to either can be but that's far from idiomatic.

lmm 8y ago
That approach doesn't really work, because C++ conflates where a value is stored with whether the value can semantically be null. Sometimes you want a nullable value that's on the stack. Sometimes you want a non-null value in the heap. Both these things are hard to do in C++.
- TheCoelacanth 8y ago
  Neither of those is hard to do in C++. The first one is std::optional. The second one is a reference or a non-nullable smart pointer like https://github.com/dropbox/nn https://github.com/dropbox/nn
  - frabert 8y ago
    It's easy to do _since less than a year_
    - jandrese 8y ago
      And probably not in your compiler yet. Or if it is, you'll blow up on thousands of other compilers when people try to build it themselves.
    - jcelerier 8y ago
      boost::optional has been available since 2003. There's no excuse.

RX14 8y ago

You don't need option types for the compiler to enforce safety around nulls. Its possible to model null as its own type in the type system to enforce safety.

coldtea 8y ago
This means you need a different type system though.
- RX14 8y ago
  Yeah, its a good option for new languages though.
  - lmm 8y ago
    It's the same mistake as checked exceptions all over again. If you make null a special case in the type system then anything that interacts with the type system has to know about null or will handle it wrong. Far better to have the type system work with plain (non-nullable) values, and implement a plain old library type like Maybe/Option for use in places that need absence semantics; that way your concerns are properly separated and you can spend your type system complexity budget in more generally applicable ways.
    - RX14 8y ago
      Just because null is a type in the type system doesn't mean it has to be a special type.
      - lmm 8y ago
        That's the only way I've ever seen it implemented. If you're proposing some idea for having null in the type system as a normal type (that doesn't boil down to just being equivalent to Option/Maybe), can you be more concrete?
        8y ago