Null references (oh no, not again!)

[Walter Bright]

Andrei Alexandrescu wrote:
> Reality seems to disagree. The rule is well understood in Java and C# 
> and I haven't heard of gotchas involving it. Here are the first two hits 
> on searching java gotchas:
> 
> http://mindprod.com/jgloss/gotchas.html
> http://www.firstsql.com/java/gotchas/
> 
> The first actually discusses construction issues, but the flow thing is 
> not among them.

Java and C# don't have templates or mixins generating code, either. 
Disallowing certain combinations makes it hard to compose things using 
metaprogramming.

> The code is bug-ridden. It's exactly the kind of maintenance nightmare 
> where you change one line and 1000 lines below something crashes.

It does occur in various forms. I know this from experimenting with flow 
analysis. The problem with saying it's "buggy" is then the programmer 
throws in a dead assignment to "fix" it rather than refactor it.


> Listen to the man. The point is to use non-null as default in function 
> signatures, but relax that rule non-locally so programmers don't feel 
> constrained. It's the best of all worlds.

But much of this thread is about tracking where a null assignment to a 
field is coming from. By doing only local analysis, that case is not 
dealt with at all.

>> I'll bet that they added this constraint when they got a bug report 
>> about that hole <g>.
> Link? Evidence?

No evidence. Just that's how these things usually work <g>.


> No. This is exactly the point at which the useless "out" storage class 
> can make itself useful. You can pass an uninitialized variable as an 
> "out" (not ref) parameter, and the callee has the modularly checked 
> obligation to assign to it. It's perfect.

I'll concede that one.

> You have no case.

Not so fast :-)