Nullablity in ES4

原创 2006年06月21日 13:54:00
cite from


Almost all types are nullable by default. The only types that are non-nullable by default are:

  • Boolean
  • all numeric types (see numbers)

This convention is consistent with historical precedent for boolean and numeric types. These are the only special cases; in all other cases, types are nullable by default.

Classes can be defined to be non-nullable by default via a special declaration syntax:

class C! { ... }

This annotation does not imply anything about subclasses of C; they are still nullable by default unless declared non-nullable.

Type constructors for nullability

For any type expression T, the expression ?T means the nullable version of T, and T! means the non-nullable version of T.

Redundant annotations

For any non-nullable type T, T! is allowed and is identical in meaning to T.

For any nullable type T, ?T is allowed and is identical in meaning to T.

My response:

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!

Why we introduce nullablity? I believe it is because nullablity makes type finer and safer. We all know that many JSers don't like static type though they may use java/c# on server-side. So it's clear that if somebody want to use static type in ES4, that means he/she might like to have more strict and precise type system. For them, it is more common for it not to make sense for a type to include the null value. After I learn  nullablity by Nice<>, I found it's rare to write a nullable type. I use nullable most in the case of method declarations, which a parameter with null value for special meaning. Then I'd like to write function f(v:T?) to indicate such special usages.

Some reasons are given to make nullable default, but:

1. ES4 is still in process, isn't it? So compatibility with existing implementations such as AS3 should not be the reason!! Never!

2. It is said it seems to be “the way of the world”. NO! It's totally mess of cause and effect. “The way of the world” is not nullable by default, but no nullablity mechanism in mainstream OO languages such as Java/C#/C++ (until C# 2.0 introduce nullablity with generic type). So it's not users expected, but being forced. If we introduce nullablity, we must do the right thing.

3. I don't think it's too draconian, if I want static type, which means I want a strict type system. Code should be as clear as possible to indicate whether it is nullable or not! The bad example is C# 2.0 which seperate type into reference type and value type, the users have to  recall whether a type is ref type or value type. C# 2.0 has no choice because it must compatible with C# 1.0, but ES4 have no such burden.

There are many issues in current proposal:

1. It makes nullablity useless. Most developers do not know the benefits and usage of nullability, so they will ignore it at all. At least in the early days...

2. If all non-nullable, compiler or verifier can force users write null checking branches when use nullable type ( var a:T? ... if (a==null) {...} else {...} ) to eliminate NullPointerException. It's reasonable because the users write "T?" and know it's nullable. But it's hard to force the developers write such codes if nullable by default, especially because of issue 1, there will be more nullable classes than should, All will say why i must write such boring code. Things becoming worse, should I write null checking for Complex ? it depends on the author of Complex ! It is said "there are very few special cases to remember", but what about libraries?

3. It's inconsistent, not only Number and Boolean, but also user-defined class such as Complex. To make Complex seems like a value type, it is suggested to use class Complex! {...}. But that means authors will get burden to make the decision whether the class should be nullable. I can imagine most libraries will full of nullable class though non-nullable is more proper. Ok, they will change class Complex to class Complex! in next release, as a result, all client codes must be rewritten (change a:Complex to a:Complex? or review all codes to ensure a:Complex is ok). Of couse we all agree Complex should be non-nullable, but what about Date? Should Date be nullable or non-nullable? C# treat DateTime as value type and non-nullable. Such things (decide if it is nullable and remeber the decision) will drive lib developers and users crazy.

What I expect is straightforward. When I say a:T, I mean non-nullable, when I say a:T?, I mean nullable. When I see a:T, I know it's non-nullable, when I see a:T?, I know it's nullable. As a library developer, I can be free from the metaphysical issues (should this or that be nullable?). As a user, no need to guess default nullablity, no need to search documents, no need to worry about nullablity will change in the future. And there is no need to use ugly "T!". a:T!=x and a:(t!=x) and a::t!=x is too confused.

Advances in OpenGL ES 3.0

  • 2014年05月29日 14:08
  • 11.37MB
  • 下载

Node.js Async Await in ES7

原文 of the most exciting features coming to Java...
  • offbye
  • offbye
  • 2016年09月30日 07:01
  • 2043

ES任务管理器 v1 4 2 0 79 MB

  • 2015年01月04日 01:21
  • 790KB
  • 下载

h264 ES流文件通过计算first_mb_in_slice区分帧边界

本人由于最近在读取h264文件的时候,遇到如何读取完整一帧数据的问题,通过使用elecard stream analyzer工具,以及结合《新一代视频压缩编码标准--H264/AVC》(第二版)书,并...


  • 2013年03月22日 08:55
  • 61KB
  • 下载


  • 2017年04月18日 16:02
  • 77.29MB
  • 下载

ECMAScript 2015 (ES6) in Node.js(译)

ECMAScript 2015 ES6 in Nodejs译 有哪些特性在Nodejs中是默认开启的不需要设置运行时标志位 Which features are behind the es_stagi...


  • 2014年04月27日 11:02
  • 1.63MB
  • 下载
您举报文章:Nullablity in ES4