Null references redux

[Chad J]

Walter Bright wrote:
> ...

Admittedly I didn't read the whole thread.  It is hueg liek xbox.

I'll try and explain this non-nullable by default thing in my own way.

Consider a programmer wanting to define a variable.  I will draw a
decision tree that they would use in a language that has non-nullable
(and nullable) references:

          Programmer needs to declare reference variable...
                               |
                               |
                               |
                      Do they know how to
       yes <--------    initialize it?     --------> no
        |                                            |
        |                                            |
        |                                            |
        v                                            |
 Type t = someExpression();                          |
                                                     v
                                    yes <--------- Brains? ---> no
                                     |                          |
                                     |                          |
                                     v                          v
                                 Type? t;               Type t = dummy;
                         (Explicitly declare)         (Why would anyone)
                         (it to be nullable)             (do this?!?)


So having both kinds of reference types works out like that.

Working with nulls as in current D is as easy as using a nullable type.
 When you need to pass a nullable type to a non-nullable variable or as
a non-nullable function argument, you just manually check for the null
like you should anyways:

Type? t;
... code ...
// If you're lazy.
assert(t);
func(t);

OR, better yet:

Type? t;
... code ...
if ( t )
    func(t);
else
    // Explicitly handle the null value,
    // attempting error recovery if appropriate.

I actually don't know if the syntax would be that nice, but I can dream.

But I still haven't addressed the second part of this:
Which is default?  nullable or non-nullable?
Currently nullable is the default.

Let's consult a table.

+---------------------+--------------+--------------+
|                     |  default is  |  default is  |
|                     | non-nullable |   nullable   |
+---------------------+--------------+--------------+
| Programmer DOESN'T  |   Compiler   | Segfault in  |
| initialize the var. |    error.    | distant file |
| ((s)he forgets)     |   Fast fix.  |      *       |
+---------------------+--------------+--------------+
| Programmer DOES     |  Everything  |  Everything  |
| initialize the var. |   is fine.   |   is fine.   |
+---------------------+--------------+--------------+
| Programmer uses     |  They don't. |  They don't. |
|    dummy variable.  |Nullable used.| Segfault in  |
|                     |  segfault**  | distant file*|
+---------------------+--------------+--------------+

* They will have hours of good fun finding where the segfault-causing
null came from.  If the project is non-trivial, the null may have
crossed hands over a number of function calls, ditched the police by
hiding in a static variable or some class until the heat dies down, or
whoops aliasing.  Sometimes stack traces help, sometimes they don't.  We
don't even have stack traces without hacking our D installs :/

** Same as *, but less likely since functions are more likely to reject
possibly null values, and thus head off the null's escape routes at
compile time.


I can see a couple issues with non-nullable by default:
- This:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=96834
- It complicates the language just a bit more.  I'm willing to
grudgingly honor this as a reason for not implementing the feature.