On Wednesday, 13 March 2024 at 07:43:23 UTC, Alex wrote:

if (a != null) {
    a.run(); // ok, because type of variable 'a' is A (not nullable) in this branch.
}

I like this, can the compiler handle cases like this?

if (a == null)
	return;
a.run();

On Wednesday, 13 March 2024 at 20:34:42 UTC, Alex wrote:

No, Kotlin also performs a check at runtime. The same hardware runs the machine code, and the MMU is the same one that runs D code.

However, the check is not considered to cost anything. It's part of how the MMU works.

-Steve

On Wednesday, 13 March 2024 at 21:57:17 UTC, Jonathan M Davis wrote:

Thank you for detailed explanation!

On Thursday, 14 March 2024 at 00:32:47 UTC, cc wrote:

if (a != null) {
    a.run(); // ok, because type of variable 'a' is A (not nullable) in this branch.
}

if (a == null)
	return;
a.run();

Yes, sure, Kotlin compiler handle it. The analyzer controls variable type in each branch. After if type of a will be non-nullable type A.

On Thursday, 14 March 2024 at 02:09:15 UTC, Steven Schveighoffer wrote:

Yes, sure, you right. Checks will be in runtime too and thanks to MMU hardware checks are cheap.

To be clear:

• Kotlin compiler rejects code wthout all required null reference checks for nullable type.
• Null refrence checks will be performed in runtime (like in D).
• Kotlin compiler give 100% guarantee that null pointer exception never happend in runtime (exclude unsafe operations where developer take responsibility).

I give Kotlin as example because familar with it, but other languages with null safety do something like this.
And this powerful feature is possible thanks to language type system. The nullable type is special case of cool idea - the union type:
https://www.typescriptlang.org/docs/handbook/unions-and-intersections.html
http://web.mit.edu/ceylon_v1.3.3/ceylon-1.3.3/doc/en/spec/html_single/#unionandintersectiontypes

On Wednesday, 13 March 2024 at 19:58:24 UTC, Steven Schveighoffer wrote:

I haven't read this whole thread, but I've seen responses to the above, and I'd like to add my own comment. The difference between null and optional types in Rust is that the Rust compiler forces you to handle an optional type in order to obtain its value. You can't get at the value without processing the optional with a 'match' (or related constructs, such as 'if let'), which requires handling both possibilities -- Some and None. The compiler therefore forces you to handle the unusual case, so if it happens, the result will be something under your control.

Null and other unexpected values are simply not equivalent. You are not forced to provide code to handle the possibility of the unexpected value. When your code blindly forges ahead, you may get a seg-fault. Depending on how the code was compiled, you may or may not be headed for a session with gdb.

Related to the above, you may also process an uninitialized value, at which point anything can happen. To me, this is one of the weak spots in D, inherited from C. It can lead to an incorrect result returned without error. D's use of default initializers (as opposed to C's random garbage) does not fully protect against this. Rust does prevent this.

On Wednesday, 13 March 2024 at 19:58:24 UTC, Steven Schveighoffer wrote:

One important difference is that D makes the null check as late as possible. Often in code using non-nullable types, the check gets done earlier, nearer to where the problem is. E.g. when a function produces a pointer, but the pointer doesn't actually get dereferenced there but is stored and then some time later it gets dereferenced. Then it's not easy to find where the null pointer was actually produced. Having non-null pointers can save time debugging.

On Saturday, 16 March 2024 at 19:10:56 UTC, Don Allen wrote:

You can call unwrap on the Option which will panic if it's None. But that's fine, because that call makes it clear to anyone reading the code that the programmer is intentionally assuming the Option contains a value.

...

It can't violate memory safety:

https://dlang.org/spec/declaration.html#void_init