null [re: spec#]

[foobar]

Jonathan M Davis Wrote:

> On Saturday 06 November 2010 19:05:32 Nick Sabalausky wrote:
> > "foobar" <foo at bar.com> wrote in messagend in a pointlessly roundabout way.
> > 
> > > 2. "null" is an a type-system attribute, hence should be checked at
> > > compile time and would have ZERO affect on run-time performance.
> > > Same as assigning a string value to an int variable.
> > 
> > I strongly agree with this.
> > 
> > On a related note, I *hate* that D silently sticks in a default value
> > whenever anything isn't properly inited. This is one thing where I really
> > think C# got it right, and D got it wrong. And waving the "It's not leaving
> > it with an undefined value like C does!" banner is an irritating strawman:
> > Yea, it's better than C, but it still sucks.
> 
> Well, it _is_ better than C. Going C# or Java's route forces the programmer to 
> initialize variables even in cases where they know that it's not necessary 
> (which is annoying but may or may not be worth it), but more importantly (from 
> Walter's perspective at least), it would require flow analysis, which he actively 
> avoids. Using default values avoids memory bugs like you get in C and results in 
> a simpler compiler implementation (and therefore a less bug-prone one) and makes 
> it simpler for other tools to be written for the language. Now, it may be that 
> Java and C#'s way is ultimately better, but unless you make a practice of 
> declaring variables without initializing them (which generally should be avoided 
> regardless), it generally doesn't matter.
> 
> Also, it's essentially D's stance that not initializing a variable is a bug, so 
> every variable is default initialized to the closest to an error value that 
> exists for that type. null is the obvious choice for pointers and references.
> 
> I'm moderately divided on the issue, but ultimately, I think that D's decision 
> was a good one. Java and C#'s may or may not be better, but I still think that 
> what D does works quite well.
> 
> > I also dislike that D's reference types being nullable by default is
> > inconsistent with its value types. (Yea, naturally reference and value
> > types are going to have inherent differences, but nullability shouldn't be
> > one of them.)
> 
> It's not at all inconsistent if you look at from the perspective that types are 
> default initialized to the closest thing to an error value that they have. Many 
> of the value types (such as the integral types), don't really have a value 
> that's an obvious error, so they don't fit in with that quite so well, but it's 
> unavoidable given that they just don't have an obvious error value.
> 
> And I don't understand why you think that nullability shouldn't be a difference 
> between value types and reference types. That's one of the _key_ differences 
> between them. Value types _cannot_ be null, while references can. And I'd sure 
> hate to _not_ be able to have a null reference. It's irritating enough that 
> arrays and associative arrays are almost treated the same when they're null as 
> when they're empty.
> 
> I can totally understand wanting non-nullable reference types. There are plenty 
> of times where it just doesn't make sense to a have a variable which can be null 
> - even if it's a reference - but there are plenty of cases where it _does_ make 
> sense, and I do find the fact that D default initializes to error values to be 
> quite useful, since I do consider it bad practice in general to not initialize a 
> variable when it's declared. Sometimes you have to for scoping reasons or 
> whatnot, but generally, variables _should_ be initialized when declared.
> 
> - Jonathan M Davis


Both the current D way and the C# way are ugly hacks. 
Ideally you should have TWO types: T and Option!T (ignore syntax for now).

Most of the time you would use:
auto variable = new T(params);  // no need for nulls here!
and for the situations where you actually NEED to have a non-initialized variable you'd use:
Option!T variable; // look ma, explicitly asking for a nullable variable

Simple, ain't it? And it supports Walter's convoluted examples AND is explicit about it so it prevents illegal operations at compile time.