On 15-09-2012 19:52, Jonathan M Davis wrote:
On Saturday, September 15, 2012 19:35:44 Alex Rønne Petersen wrote:
Out of curiosity: Why? How often does your code actually accept null as
a valid state of a class reference?
I have no idea. I know that it's a non-negligible amount of the time, though
it's certainly true that they normally have values. But null is how you
indicate that a reference has no value. The same goes for arrays and pointers.
Sometimes it's useful to have null and sometimes it's useful to know that a
value can't be null. I confess though that I find it very surprising how much
some people push for non-nullable references, since I've never really found
null to be a problem. Sure, once in a while, you get a null pointer/reference
and something blows up, but that's very rare in my experience, so I can't help
but think that people who hit issues with null pointers on a regular basis are
doing something wrong.
- Jonathan M Davis
People are humans. Humans make mistakes. In D, you can trivially get
null references because references and pointers are default-initialized
to null.
Anyway, in a type system where there is no nullability on types by
default, you can simply say that the tail type constructor '?' indicates
nullability. So, for example:
int* = pointer to int
int*? = nullable pointer to int
Foo = reference to Foo
Foo? = nullable reference to Foo
int[] = array of int
int[]? = nullable array of int
and so on. It's fairly trivial to set up a sane type system this way,
and you make it explicit where null is acceptable. This is how type
systems should be done IMO - things should not be allowed to have some
arbitrary invalid state unless the programmer allows it.
--
Alex Rønne Petersen
a...@lycus.org
http://lycus.org
