One of the benefits of progress in programming languages is to help us sleep better. Static typing is one example. If you are using a statically typed object-oriented language you know that certain errors will never occur at run time: Once the compiler accepts a call of the following form (the fundamental operation of object-oriented programming):
x.f (args)
you have the guarantee -- almost as good as a mathematical proof -- that whatever happens to x at run time, even if x is polymorphic, the corresponding object will be equipped with an operation for f, able to accept arguments args. No more waking up in the middle of the night with visions of "Method not understood" failures. A whole class of nasty, unpredictable runtime errors goes away; so does, for sleep therapists, some of the programmer clientele.
Well, not entirely. To talk of "the corresponding object" is wishful thinking: in many cases the runtime value of x is not object but a "reference", which normally denotes an object but can also be null, or "void" (the terminology we'll use). If x is void, the call x.f (args) is a "void call" (or "null dereference"). A void call will fail, causing an exception and often a program crash.
However hard we try, testing cannot eliminate the specter of void calls. As a consequence, almost every program runs the risk of hitting a void call in some execution. This time bomb is not just ticking in object-oriented programs -- almost all C programs use pointer dereferencing and have the same risk.
Since testing can never be exhaustive, the only acceptable solution is to provide a static (compile-time) guarantee of "void safety", by tightening the rules on the programming language and equipping the compiler with the corresponding checks. That's what we have done with the Eiffel language, through the ISO-ECMA standard [3], and the EiffelStudio compiler. We took inspiration from earlier work by Microsoft Research on Spec#'s "nullable types" [2]. Our solution has some significant differences; in addition, we are dealing with a production language rather than a research language, and are facing a major issue of backward compatibility.
The initial design of the Eiffel "Attached type" mechanism was described in a 2005 paper [5]; making it practical, in particular making all existing libraries void-safe, turned out to require a considerable engineering effort. In this article we'll describe both the theoretical concepts and their practical implications.
As testimony to the critical nature of this issue it is interesting to note Tony Hoare's recent comment [4]:
I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
As far as we know, the solution we describe to the "one-billion dollar mistake" is the first one in a production language and environment. It was progressively introduced in releases of EiffelStudio beginning with 6.1, and is fully implemented in 6.4, released in June of 2009.
