Nullablity

[Burak Emir]

Shijun He wrote:

> All class should be non-nullable! If somebody want any option type, it
> should be declared explicitly (var a:MyClass?). Making things nullable
> by default and making T non-nullable by "T!" is a big mistake!

I agree with this point of view, because it makes the types system 
simpler and removes the need for remembering implicit assumption (type X 
is nullable by default, type Y is not).

It seems acceptable to mark explicitly all types that contain the null 
value, and to have a standard way to strip off the '?' of them. If you 
look at languages like ocaml, Haskell and Scala, you find a type like 
Option[C] that has to be pattern matched against. Suppose that type Foo 
has method bar, one can't call bar on Option[Foo]. It's rather:

def doit(x:Option[Foo]) = x match {//Scala syntax
  case Some(y) => y.bar
  case None => ...
}

My understanding of the Nullability proposal is that for purposes of 
calling methods,  T? and T are "the same", the former risking to throw a 
NullPointerException and the latter not. Still there is some piece 
missing, as one might need to convert T? to T in order to satisfy interfaces

fun foo(x:T) { ... }

fun baz(x:T?) {
   foo(x) // no, no, incompatible type
}

It seems to me that rather then messing with "if(x==null) " or pattern 
matching or whatnot, the cleanest way to achieve the above is to use the 
"to" operator described in the type proposal

fun baz(x:T?) { foo(x as T) } // throws NullPointerException at runtime 
if x happens to be null

cheers,
Burak

-- 
Burak Emir

http://lamp.epfl.ch/~emir