This article is strongly influenced by the following articles.
I wrote this article for the purpose of organizing null safety as described above from a slightly different angle, but if you understand the above article, the following may be a slapstick.
The name of the concept corresponding to null is slightly different depending on the language (example: Scala → None, Swift → nil), but in the following, it is written as null.
The following defines and describes three types related to null safety to help a common understanding of null safety.
It has the following features:
This includes Java primitive types, TypeScript default types, and so on.
int a = 10; // OK
int b = null; //Compile error
a: string = 1; // OK
b: string = null; //Compile error
It has the following features:
Java reference types are examples of this.
MyClass a = new MyClass(); // OK
MyClass b = null; //This is also OK
a.method1(); // OK
b.method1(); //NullPointerException occurs
It has the following features:
These include Kotlin's nullable types and TypeScript's nullable types.
val a: String? = 1 // OK
val b: String? = null // OK
b.length //Compile error
if (b != null) { b.length } // OK
Model name | Null allowed | Without null check Access attributes and methods |
Run-time exception Risk of occurrence |
Typical example |
---|---|---|---|---|
Null non-nullable type | do not do | n/a | Absent | Java primitive types TypeScript |
Nullable unsafe type | To do | it can | is there | Java, C#Reference type |
nullable safe type | To do | Can not | Absent | Kotlin nullable type TypeScript null shared type |
Null is usually treated specially in the language specification. This is because it is most natural for a language processing system to allow assignment of only values of the declared type (that is, null-free type). It can be said that [^ 2], which dares to implement the nullable type as the language default, is an extension considering the convenience of programmers [^ 3]. In Scala, Haskell, etc., null is expressed as just one value or type by devising the type hierarchy. That way, there is no need to treat null specially according to the language specifications.
[^ 2]: The language default is selective like the nullable type when declared as usual like TypeScript, and the nullable type when declared so that null can be taken using union. Because we can also provide
[^ 3]: By the way, the first person to do this was [Antony Hoare -Wikipedia](https://ja.wikipedia.org/wiki/%E3%82%A2%E3%83%B3%E3% 83% 88% E3% 83% 8B% E3% 83% BC% E3% 83% BB% E3% 83% 9B% E3% 83% BC% E3% 82% A2), and later this was 100 billion yen Says it's a failure
Until around 2012, nullable and unsafe types were the default type in many industrial languages. C, C ++, C #, Java, Objective-C, etc. However, due to the widespread recognition of the dangers of using nullable and unsafe types, a language was developed around 2012 in which the default type was nullable and safe, and gradually became widespread. .. Typical examples are Kotlin, Swift, TypeScript, etc.
The short answer is to stop using nullable unsafe types and eliminate the risk of running-time exceptions. However, in Java, Objective-C, C #, etc., it is impossible not to use the nullable and unsafe type because the language default type is the nullable and unsafe type. Therefore, as of 2019, the transition to languages such as Kotlin, Swift, TypeScript, etc. where the language default type is nullable and safe is in progress.
[^ 1]: Since there is no unified name across programming languages, we will call it tentatively in this article. Please let me know if you have a more canonical name.
Recommended Posts