>>45
No. Manually freeing memory inherently creates unsafe code.
Whoa, back up. I thought the object was to tell the GC to piss off? In any event, analysis can ensure that inserted deallocations, which are exactly equivalent to manual deallocation except that they are automatically inserted, are perfectly safe. (And at some point you have to concede that if manual deallocation is inherently unsafe it doesn't improve the GC case either, which is ultimately informed by a programmer as to when it can free memory. Pedantry, I know, but the point keeps things in perspective.)
As far as the general case goes, annotations don't work either. Where analysis fails, annotations can't inform the compiler or GC very well at all--this is what I was trying to bring up. If you have a paper that says otherwise I would really like to see it.
The compile does not automatically insert any checks whatsoever.
After rereading I see I've misread your comment about this. You wouldn't really have to perform the checks, your code could just crash at roughly the same time and place, for a slightly different reason--unless it does actually force you, in which case it either forces you to do it at every dereference or performs some amount of analysis to alleviate the need for it, in either if these cases it might as well insert the checks. For my purposes, your
?var example simply informs analysis.
Honestly it's pretty mind boggling to me that you are defending null pointers. It's the famed "billion dollar mistake".
I know this is a topic that has been debated back and forth forever, but it's not a big safety concern for me--nullables have simply not posed a significant problem to me, and they usually exist in languages that have far more dangerous facilities. My only strong feelings about it are a) it's not nearly as big of a deal (either way) as people tend to make of it, and b) I don't prefer it because it usually relies on exception handling to deal with eg. failed initialization.
As an aside, Go's solution to exceptional cases is a nice try (
http://blog.golang.org/2010/08/defer-panic-and-recover.html). I don't think they quite got it, but it does get exception handling out of my face. Combined with the multiple return facility, you can choose to treat errors exceptionally or you can anticipate them. The very best decision Go has made, in my opinion, is not to propagate exceptions out of the standard library. Sadly they used the qualifier "convention" and not "standard" or "requirement" or something even stronger. Personally I would never let an exception escape, be it the standard library or supplied.