Jonathan M Davis Wrote: > On Saturday 06 November 2010 19:05:32 Nick Sabalausky wrote: > > "foobar" <f...@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.
