null and type safety

[Thomas Leonard]

On Mon, 03 Nov 2008 17:04:48 -0500, bearophile wrote:

> Brendan Miller:
>>Null is a holdover from C and has no place in a typesafe language.<
> 
> In a (system) language I want to be able to create tree data structures
> that contain a cargo plus true pointers, and those pointers to structs
> can be null in leaves. Having a safe language is good, but I want 1
> language that gives me sharp tools too.
> 
>>I'm looking through the D docs, that are a little sparse, but I'm not
>>seeing any references to pointers that can't be nulled.<
> 
> You may like the Delight language (it compiles to D2):
> http://delight.sourceforge.net/null.html

Note that the maybe types in Delight are independent of the syntax 
changes (apart from the ? type annotation) and you could easily enable 
them when compiling D code too (basically, just remove the code that 
disables this feature when it detects it's compiling D syntax source).

The basic problem is that it's hard to integrate a language with non-
nullable types with libraries written without them (e.g. when auto-
generating bindings with BCD). This would likely be a big problem for D, 
since integrating with existing C and C++ code is a major feature.

Even if you add the annotations manually to an existing library, you 
often get a poor API. e.g. this GLib function for copying a string:

  char*? g_strdup(const(char)*? s)

If you pass NULL in, you get NULL out. That's a useful convenience in C, 
but in Delight it forces you to check whether the result is null before 
you can use it. If the API had been designed for Delight in the first 
place, it wouldn't take or return a nullable type.