If you are working off the hg repo, be aware that I've turned on the runtime checks for coercion to non-null. This means that if a nullable type is coerced to a non-nullable type (either with an explicit cast or an implicit cast) then the runtime will now throw a NullErr if the value is null:

fansh> Str? x := null
null
fansh> Str y = x
sys::NullErr: Coerce to non-null

Successful checks are executed in two JVM opcodes - a dup and an ifnull branch. So I think the check shouldn't add any noticeable overhead. There was no impact on any of my performance tests - in fact I think things actually may run a little faster (I'm sure since there is enough jitter in large tests that it could just be noise).

In some ways fixing all the runtime exceptions was a bit annoying - but it was trivial and the result was typically code which was using incorrect type definitions. The nice thing is that now null errors fail fast at the location where the real problem occurs. So I think this may work out well. We'll have to see.

If you are working off the hg repo, you will need to bootstrap yourself as follow:

1. pull changeset 414: da5a866635fa
2. build it
3. update your bootstrap rel with the build from changeset 414
4. pull changeset 415: f296d7b7485d (or later)
5. everything should compile successfully

Does this handle nulls within a List of Map correctly?

Does this handle nulls within a List of Map correctly?

I'd more argue that should be at the type level. For example:

Int[] a := [1, 2, 3];
Int?[] b := [1, 2, 3];
Int?[] c := a; // Okay, in my opinion.
a = c; // Okay.
c = b; // Okay.
a = c; // CastErr or something.

That is, for Lists, I'd say it's not the individual items that matter but the types of the Lists.

Does this handle nulls within a List of Map correctly?

In some cases yes, in some cases no - I'll have to look at the fcode tonight. In general although list and map maintain their type, they don't actually check add/set/insert at runtime. Potentially we could generate a cast/coerce opcode before any generic method call on those classes to enforce that (in fact we kind of do that today with value types to ensure they are boxed).

Anything coming out of a List or Map is already cast and will be checked appropriately.

That is, for Lists, I'd say it's not the individual items that matter but the types of the Lists.

We don't currently do any type checking on generics as you suggest. Although the fcode does define the proper coerce opcode, the JVM and CLR runtimes don't do anything beyond boxing/unboxing, normal casting, and null-checking.