Type safety in Nice

Java allow casts of the form: (T) e. At compile time, this assumes that the expression e has type T. At run time, if e does not evaluate to a value of type T, a ClassCastException is thrown. In this case, there is usually nothing that can be done to recover from the situation: the code that follows relies on the fact that e has indeed type T. Therefore ClassCastExceptions are usually not caught before the very top level of the program, making at least a whole feature to fail. It would be great to ensure that no cast can fail. Even better, not to have casts at all.

So why does Java allow casts? It needs them, because its type system is too limited. Nice has a powerful type system and no casts. So let us look at the different uses of casts in Java and their cast-free equivalent in Nice.

interface Stack
{
  void push(Object element);
  Object pop();
}

Stack st = new StackImpl(); // we want a stack of strings
st.push("Element A");
st.push(new Object()); // invalid code, but not detected
...
String s = (String) st.pop(); // throws a ClassCastException

interface Stack<T>
{
  void push(T element);
  T pop();
}

Stack<String> st = new StackImpl();
st.push("Element A");
//st.push(new Object()); // type error
...
String s = st.pop(); // no cast needed

class Person
{
  String name;
  int age;

  boolean equals(Object that)
  {
    if (!(that instanceof Person))
      return false;

    return 
       name.equals(((Person) that).name)
       && age == ((Person) that).age;
  }
}

class Person
{
  String name;
  int age;

  boolean equals(Person that)
  {
    return 
       name.equals(that.name)
       && age == that.age;
  }
}

Component c = ...;

List children;
if (c instanceof ContainerComponent)
  children = ((ContainerComponent) c).getChildren();
else
  children = null;

In current imperative languages, references (or pointers) can hold a special value meaning "reference to nothing". This value is called null in Java, NULL in C and C++. At run time, however, dereferencing this value results to a runtime error (NullPointerException) or a run time crash (bus error, segmentation fault, protection fault, ...).

To prevent this error, a reference must be tested before use. However it is easy to forget to do so. Furthermore, there are references that are never null, or rather that should never be. Testing such references clutters the code. Every variable should therefore be documented as being possibly null or not. Every method should document whether each of its argument can be null or not, and whether it can return a null result. But then remains the task of checking that the code indeed is correct and indeed conforms to the documentation. Correctness requires for instance that if a variable is possibly null, it should always be tested before dereferencing. It also requires to match arguments of a method to its documented behavior regarding null arguments. All these checks are rather simple but very tedious. The situation is even much worse when code evolves: this checking must be done all over again.

Here obviously comes our motto: all this checking should be done automatically. This is exactly what Nice does. One documents whether a type can hold the null value by simply prefixing it with the ? symbol. Thus: ?String name; is the declaration of String variable that might be null. To get its length, one must write int len = (name == null) ? 0 : name.length();. Calling name.length() directly is a type error. It would only be possible if name was defined as String name = "Some non-null string";.

In Java arrays are covariant: a String[] array can be passed to a method that expects an Object[] argument. But what happens if the method writes a Picture into the array? No error is detected at compile time. At run time, an ArrayStoreException is thrown.

This shows that arrays should not not be covariant. So why are they covariant in Java? Once again, mostly because of its limited type system. Object[] is often a poor replacement for T[] where T is a type parameter. Another reason is that covariant arrays are sometimes safe: when they are used in a read-only way.

In Nice, arrays are not covariant. Therefore run time errors like ArrayStoreException never occur. Moreover, it is still possible to use arrays covariantly while only reading from them. This requires Nice's powerful type system: constrained type parameters: <java.awt.Component T> void read(T[]); can be applied to arrays whose component types are subtypes of java.awt.Component. Type checking guarantees that the array will not be written to by this method, so that there will be no run time failure.

A run time error occurs when a program tries to access an element from an array with an index outside its bounds. Solving this issue is still an open problem. Partial solutions exist, notably using dependent types, but they are not ready for widespread use because of their high complexity.

Nice offers a much simpler and limited contribution, but it can be very useful in practice. Code using arrays contains a few idiomatic patterns that occur repeatedly: iterating through the elements of an array, finding an element matching a certain criterion, ... These are typically done using loops. Besides being a little tedious, these patterns open the opportunity for mistakes in the indexes, which leads to run time errors. These errors will often be discovered soon while running the program, but it is still better if they can be detected by the compiler. And if they are seldom executed, and the indexes go out of bounds in rare circumstances, detection becomes more hazardous. Moreover, if a loop misses the incrementation step, it will loop forever, which gives no information on the location of the problem. It becomes then necessary to use a debugger and takes some time to spot what was but a minor mistake.

Using two features of Nice, genericity and higher order functions, it is possible to use and write functions that perform the most common tasks on arrays, and more generally collections. For instance, a simple iteration on the elements

for (int i = 0; i < a.length; i++)
  doSomething(a[i]);

can also be written in Nice

a.foreach(doSomething);

Using methods like foreach makes the code clearer by avoiding the repetition of the loop code over and over. Moreover, it removes the risks of wrong indexes, forgetting to increment the index, ... It is important to note that foreach is not a built-in operator but a normal method defined in the standard library. Therefore, given a user-defined data structure, a new looping function can be written and only has to be checked once.