So I'm curious about D as a programming language, especially as it compares to C++.

One problem that C++ made a partial effort to solve was that normal pointers in C++, and references in languages like Java and C# essentially aren't type safe.

Consider that null can always be assigned to a pointer or reference to type T in those languages, and null is clearly *not* of type T, thus operations on a variable denoted of type T, are doomed to fail.

T *myObject = null;
myObject->myMethod(); // fails, despite the fact that myObject is of type T
                                         // and myMethod is defined for type T.

Null is a holdover from C and has no place in a typesafe language. The designers of C++ knew this, and so introduced the c++ reference type:

T &myObjectRef = ...;

which cannot be null.

T &myObjectRef = null; // fails at compile type
T &myObjectRef = *ptr; // if ptr is null, operation is "undefined".

The designers of Java and C#... copied C's typesystem largely for marketing purposes and never really thought through these issues (although I read an interview where Anders Hejlsberg admitted this was a mistake with C# that occured to him too late to fix).

This is obviously a problem. Everyone knows that null pointer exceptions in Java/C#, or segmentation faults in C and C++ are one of the biggest sources of runtime errors. Furthermore, there's no reason whatsoever that these problems can't be caught by the compiler in a strongly typed language like C++ that has the idea of a non-nullable pointer. The whole point of type annoations is to catch these errors before runtime after all. Otherwise it's just a lot of useless typing. C++ partially solves the problem partially with references, and truly static safe typed language like ML solve this problem by making variables typesafe by default, and using an Optional type to wrap nullable types.

So my question, is, as the successor to C++, how does D solve this problem? 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.

Brendan

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

Bye,
bearophile

On Tue, 04 Nov 2008 00:10:29 +0300, Brendan Miller <catphive@catphive.net> wrote:

> So I'm curious about D as a programming language, especially as it compares to C++.
>
> One problem that C++ made a partial effort to solve was that normal pointers in C++, and references in languages like Java and C# essentially aren't type safe.
>
> Consider that null can always be assigned to a pointer or reference to type T in those languages, and null is clearly *not* of type T, thus operations on a variable denoted of type T, are doomed to fail.
>
> T *myObject = null;
> myObject->myMethod(); // fails, despite the fact that myObject is of type T
>                                          // and myMethod is defined for type T.
>
> Null is a holdover from C and has no place in a typesafe language. The designers of C++ knew this, and so introduced the c++ reference type:
>
> T &myObjectRef = ...;
>
> which cannot be null.
>
> T &myObjectRef = null; // fails at compile type
> T &myObjectRef = *ptr; // if ptr is null, operation is "undefined".
>

Unfortunately, you can have null references in D:
Object o = null;

> The designers of Java and C#... copied C's typesystem largely for marketing purposes and never really thought through these issues (although I read an interview where Anders Hejlsberg admitted this was a mistake with C# that occured to him too late to fix).
>

Yes, I agree this is a mistake and D could learn a lesson from C#/Java.

> This is obviously a problem. Everyone knows that null pointer exceptions in Java/C#, or segmentation faults in C and C++ are one of the biggest sources of runtime errors. Furthermore, there's no reason whatsoever that these problems can't be caught by the compiler in a strongly typed language like C++ that has the idea of a non-nullable pointer. The whole point of type annoations is to catch these errors before runtime after all. Otherwise it's just a lot of useless typing. C++ partially solves the problem partially with references, and truly static safe typed language like ML solve this problem by making variables typesafe by default, and using an Optional type to wrap nullable types.
>
> So my question, is, as the successor to C++, how does D solve this problem? 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.
>
> Brendan

Nullable types have been proposed several times by many people, but I don't recall any respond from Walter or Andrei :(

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.

Thomas Leonard wrote:
> 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.

It could be done if non-nullable pointers/references would be allowed in addition to nullable ones.

A note however - although I agree it's nice to have non-nullable types, the argument is a bit overstated as type safety has little to do with it. Null checks are easy and cheap to check for deterministically.


Andrei

Andrei Alexandrescu:
> Null checks are easy and cheap to check for deterministically.

I think some languages add something to help that because:
- Sometimes you may forget to add those checks manually if you ned.
- If you don't need to put those checks the code results a little shorter and cleaner. Some kind of programmers like this. C++ programmers probably care less of this.

Bye,
bearophile

Brendan Miller wrote:
> This is obviously a problem. Everyone knows that null pointer
> exceptions in Java/C#, or segmentation faults in C and C++ are one of
> the biggest sources of runtime errors.

Yes, but those are neither type safe errors or memory safe errors. A null pointer is neither mistyped nor can it cause memory corruption.

On Tue, Nov 4, 2008 at 3:32 PM, Walter Bright <newshound1@digitalmars.com> wrote:
> Brendan Miller wrote:
>>
>> This is obviously a problem. Everyone knows that null pointer exceptions in Java/C#, or segmentation faults in C and C++ are one of the biggest sources of runtime errors.
>
> Yes, but those are neither type safe errors or memory safe errors. A null pointer is neither mistyped nor can it cause memory corruption.

Dereferencing a null pointer is *always* a bug, it doesn't matter how "safe" it is.  Don't you think that eliminating something that's always a bug at compile time is a worthwhile investment?

Jarrett Billingsley wrote:
> Dereferencing a null pointer is *always* a bug, it doesn't matter how
> "safe" it is.

Sure. But I'm interested in creating a safe subset of D, and so the more correct interpretation of what constitutes "safety" is important.

> Don't you think that eliminating something that's
> always a bug at compile time is a worthwhile investment?

Not always. There's a commensurate increase in complexity that may not make it worth while.

My focus is on eliminating bugs that cannot be reliably detected even at run time. This will be a big win for D.

On Tue, Nov 4, 2008 at 5:31 PM, Walter Bright <newshound1@digitalmars.com> wrote:
>> Don't you think that eliminating something that's
>> always a bug at compile time is a worthwhile investment?
>
> Not always. There's a commensurate increase in complexity that may not make it worth while.

Have you looked at Delight at all?  I wouldn't call the impact of nullable types on D "commensurate."  It's probably far less than const, invariant, pure, and escape analysis.

> My focus is on eliminating bugs that cannot be reliably detected even at run time. This will be a big win for D.

Can you expand upon this a bit?  What exactly are some bugs that can't be reliably detected at runtime other than memory corruption?