because someObj is null? Is there nothing more vague and irritating than a segfault?

D already checks for out-of-bounds array indices in debug builds by doing an implicit assert, which is something like this:

assert(index >= 0 && index < array.length); int x = array[index];

This throws an exception in the debug build if the array is accessed out of bounds. This vastly helps with debugging, mostly because it doesn't cause a vague memory access violation which you have to track down.

I propose that this be extended to accessing members of class instances, such as:

assert(someObj !is null); someObj.someMethod();

This would help immensely in finding so many coding errors, and without the need for a third-party debugger. This also has the nice side effect of all but eliminating segfaults in D (at least when debugging) except when using pointers (which are, by their nature, unsafe).

It has been suggested that I just use a debugger to break on memory access violations to see where they happen. My response: why bother implementing the array out-of-bounds check, then? They could be tracked down with a debugger as well, but it's far easier to just have the language check for it. Checking for null references doesn't seem like it would be a feature of debatable value. Other languages (Java, .NET) do it. It improves the useability of the language, period.Report this item for cleanup