I just assume that any extension of the already complex D type system will be met with a lot of resistance. I remember the all-out wars about const and immutable (a.k.a invariant). Even those extensions are still half-assed: the construction of immutable objects and const polymorphism issues remain.
My impression is that theoreticians and very advanced programmers love elaborate type systems. Nine-to-five programmers, which are in the majority, prefer simplicity even if the cost is reliability. Just look at the comments to my blog post. I know we have to do something about null references in D, but I'm still on the fence about how we should accomplish that. Denis Koroskin Wrote: > On Mon, 09 Feb 2009 01:19:55 +0300, Bartosz Milewski <bart...@relisoft.com> > wrote: > > > I also believe that non-null should be the default. Most references in a > > typical program are assumed to be non-null. > > > > Oh, that's true! > > > Like for every default, there should be an escape mechanism from it. > > However, adding "nullable" to the type system might be controversial, > > especially because it requires special treatment of constructors and > > polymorphism (hence additional type modifiers, raw and poly-null, and I > > haven't even mentioned wildcard annotations). > > > > Common opinion is that this is worth the trouble these days. More and more > people discuss, write articles on non-nullable types and incorporate them > into languages. Main C# architects has stated that absence of non-nullable > types by default is his greatest mistake that is too late to be fixed. > > > So some time ago I came up with a more modest proposal. The compiler > > should catch nullable references at their source. It should enforce what > > I call "declaration is initialization" (DII). For instance, the > > following is correct: > > > > Foo foo = new Foo; > > > > and the following is not: > > > > Foo foo; // error > > ... > > foo = new Foo; > > > > Obviously this rule is too strict, so there must be a way to override > > it. Here's the simple syntax: > > > > Foo foo = null; // not an error! > > > > And what about value types? Why special treatment for reference types only? I > don't like rules like that in a language: > > Foo foo; // error > int i; // okay? > > If not, and this is an error, too, then this defeats the whole purpose of > having T.init in D, because it will never be used per your proposal: > > int i = 0; // initialized explicitly > char c = char.init; // would you use that? > > > Notice that the programmer explicitly states that one should be careful > > when using foo, because it might be null. > > > > Since this solution doesn't involve the type system, the nullability > > doesn't propagate across function calls. But it might be a tradeoff > > worth taking, if only for the simplicity. > > > > Naah.. The whole purpose of having non-nullable types is that given a pointer > you are sure it is not null: > > string toString(Object o) > { > // is it null or not? Should I check for null or not? What if it is null? > // Should I throw? What kind of exception? > // But was going to make it nothrow! So what, no checks? > // Just fail with access violation? Is this the best D can do? > > return o.toString(); > } > > As an end user, you neglect and avoid null checks in your code ("I'm sure I > won't pass null here"). And then you run your program half an hour, it > segfaults with access violation and you don't have any clue where did null > dereference take place. I have came across this situation so many times that > I hate it. > > As a library designer, you end up having null checks everywhere in your code > which is some kind of a paranoia because in 99% of cases the pointer will be > not null. But why put so many special case and checks if it is *disallowed* > to run code with null pointer in first place? So people decided - let's > enforce that at compile time! That's the whole point of the feature - > disallow invalid use cases at compile time. You get cleaner code (no > unnecessary null-checks and throws) and small performance improvement as a > bonus. > > I would like to write code as this as be sure that it will never fail: > > string toString(Object o) // non-nullability is enforced at compile time > { > return o.toString(); > } > > This is D style - do as much as possible at compile time - and I believe > non-nullable types fit D type system very well. > > > Constructors still need some special treatment. Every class member > > variable must be initialized in the constructor. Again, the escape is to > > _explicitly_ initialize it to null. This might seem redundant, since the > > variable is already default initialized to null, but the compiler can > > easily eliminate such redundancies. > > > > I also found out that Java's editor, Eclipse, enforces DII--a very > > useful feature that paid off for me in the first 100 lines of code I > > wrote after a long period of inactivity in Java ;-) > > > >> Michel Fortin Wrote: > > > >> In fact, I'd even argue that non-nullability should be the default for > >> pointers and class references, because it is either safer (if the > >> compiler doesn't do the null check for you) or less troublesome to use > >> (if the compiler forces you to check for null everytime). Another > >> reason being consistency: value-types can't be null by default and so > >> should be class references and pointers. And making pointers > >> non-nullable by default can only be done at the language level, so > >> obviously it's better in the language than as a user-defined type > >> modifier. > > > >