Memory safe in D

[Don Allen]

On Monday, 18 March 2024 at 12:31:23 UTC, Nick Treleaven wrote:
> On Saturday, 16 March 2024 at 19:10:56 UTC, Don Allen wrote:
>> The compiler therefore forces you to handle the unusual case, 
>> so if it happens, the result will be something under your 
>> control.
>
> 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.

Yes, that's one choice. You can also call 'expect' and provide a 
specific error message about what happened, unlike 'unwrap' which 
only provides a boiler-plate message.

My point is that, in Rust, you can't forget to handle a return of 
None because the compiler forces you to do so. As opposed to 
dealing with a seg-fault because you forgot to test for a null 
pointer.

>
> ...
>> Related to the above, you may also process an uninitialized 
>> value, at which point anything can happen.
>
> It can't violate memory safety:

I didn't say it did. Perhaps I could have been more clear. My 
intent was to discuss the contrast between a language that makes 
certain that you handle unusual cases in way of your own choosing 
vs. getting an unexpected seg-fault and having to get out the 
debugging apparatus to find out what happened. Or worse, shipping 
code with this time-bomb and having it blow up in the face of 
your users.

>
>> Void initializers for variables with a type that may contain 
>> unsafe values (such as types with pointers) are not allowed in 
>> @safe code.
>
> https://dlang.org/spec/declaration.html#void_init