References in D

Alex Rønne Petersen alex at lycus.org
Sat Sep 15 11:59:47 PDT 2012


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
alex at lycus.org
http://lycus.org


More information about the Digitalmars-d mailing list