Memory safe in D

[Alex]

On Wednesday, 13 March 2024 at 18:20:12 UTC, Steven Schveighoffer 
wrote:
> - The path D takes is, let the hardware solve it.
> - The path Java takes is to instrument dereferences on 
> possibly-null variables and throw an exception if it's null.
> - The path many other languages take is to force you to 
> validate it's not null before using it.

Rust doesn't allow null references at all (exclude unsafe code). 
It is one more alternative path.


> For the other languages, you are forced to validate something 
> is null or not null. This has the advantage that certain 
> classes of bugs can be avoided at compile time, and in many 
> cases, the code can be clearer where null pointers might exist. 
> But the cost is that you may be forced to validate something 
> that is obvious to the developer (but not the compiler). It 
> adds to the tediousness of the language.

On the other side with this approach developer can choose between 
nullable type and non-nullable. If he choose nullable type he 
really have to do checks. But for non-nullable type he can work 
completely safety without any checks. As I know Kotlin encourages 
using non-nullable types wherever possible.