The null reference is both useful and harmful. Null is useful because it allows us to work with values that are only partially initialized. It is harmful because if a binding x has type T, then x can also be null, so operations that should succeed on values of type T might fail on x unexpectedly (i.e. the dreaded NullPointerException).
I will present our work in progress to make null references explicit in Scala. More specifically, I will show a version of Scala where all reference types are non-nullable by default. Nullability can still be expressed via sum types (“x has type T or null”). Because nullability remains implicit in Java, we must have a way for the explicit world of Scala and the implicit world of Java to interact. To this effect, we have designed a type translation from Java types to Scala types that accounts for the fact that Java types remain nullable. For example, in our translation, the Java type “String” is translated into the Scala type “String or null”.
Even if we have non-nullable types, class fields are initialized to null inside constructors. To deal with this case, we plan on integrating our nullability work with a sound initialization scheme in the style of Freedom Before Commitment.
Fri 28 SepDisplayed time zone: Guadalajara, Mexico City, Monterrey change
11:50 - 12:10 | |||
11:50 10mTalk | Julia Subtyping Lessons Scala Could Learn (Student Talk) Scala 2018 Artem Pelenitsyn Northeastern University | ||
12:00 10mTalk | Scala with explicit nulls (student talk) Scala 2018 |