Memory Safe Programming

[Kapendev]

On Tuesday, 18 August 2026 at 00:17:36 UTC, GB wrote:
> On Monday, 17 August 2026 at 16:21:39 UTC, libxmoc wrote:
>> On Sunday, 16 August 2026 at 08:50:38 UTC, GB wrote:
>>> It's primarly about memory safety in C, but D gets a mention 
>>> in the Appendix I.
>>>
>>> But it raises the question: why isn't @safe not the default 
>>> in D?
>>>
>>> https://strawberry9.github.io/the-wrong-memory
>>
>> Memory safety is best when it is intentionally, forcing it 
>> everywhere by default usually achieves the opposite of its 
>> goal by adding unnecessary friction
>>
>> D shouldn't try to replicate Rust, its real strength is 
>> ipragmatism, giving the flexibility to opt into safety where 
>> it matters without imposing it where it doesn't
>
> C: the programmer must maintain the invariant. The result?
> See: 
> https://strawberry9.github.io/the-wrong-memory/Appendix_02.html
>
> D safe subset: the programmer must stay within a subset whose 
> rules maintain the invariant.
>
> A stronger design: the language's semantics make the invariant 
> unavoidable, except at explicitly identified escape boundaries.
>
> 'Safe by default' is not the same thing as 'safety is a 
> language property.'
>
> C++ made the mistake of trying to have a 'safe subset' without 
> making the subset's invariants fundamental to the language 
> itself. Did D make the same mistake?

Depends :TM: + safety is more of a skill issue than a language 
mistake.
Even for C, you could write code in a safe subset + follow a 
style guide. Most people don't do it because it's not fun or they 
learn the wrong things from random C projects. From my experience 
D makes safety fun. Slices are part of the language, for example.