Jeremie Pelletier: > I don't remember > the last time I had a segfault on a null reference actually.
I have read that null deference bugs are among the most common problem in Java/C# code. I have no pointers... > I can see what the point is with nonnull references, but I can also see > its not a bulletproof solution. ie "Object foo = cast(Object)null;" > would easily bypass the nonnull enforcement, resulting in a segfault the > system is trying to avoid. That's life. > What about function parameters, a lot of parameters are optional > references, which are tested and then used into functions whose > parameters aren't optional. It would result in a lot of casts, something > that could easily confuse people and easily generate segfaults. By "optional" I think you mean "nullable" there. Note that some of those casts can be avoided, because the nonnull nature of a reference can be implicitly inferred by the compiler: Foo somefunction(Foo? foo) { if (foo is null) { ... // do something } else { // here foo can be implicitly converted to // a nonnullable reference, because the compiler // can infer that here foo can never be null. return foo; } > Alls I'm saying is, nonnull references would just take the issue from > one place to another. Like Walter said, you can put a gas mask to ignore > the room full of toxic gas, but that doesn't solve the gas problem in > itself, you're just denyinng it exists. Then someday you forget about > it, remove the mask, and suffocate. No solution is perfect, so it's a matter of computing its pro and cons. It's hard to tell how much good a feature is before trying it. That's why I have half-seriously to implement nonullables in a branch of D2, test it and keep it only if it turns out to be good. Bye, bearophile