null [re: spec#]

[steveh]

foobar Wrote:

> 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.

Sounds more retarded than the notorious 'retard' here. It's because of people like u that D3 might not come. If you disagree too much with AA and WB they have no interest to make D3. This nonnull question might be good place to give up.