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.