Why static analysis is the way to go

[Richard (Rikki) Andrew Cattermole]

On 29/05/2026 7:41 AM, H. S. Teoh wrote:
> Preaching to the choir here, but this again shows why static analysis
> and compiler-enforced checks at compile-time is the way to go:
> 
> https://www.zdnet.com/article/rust-will-save-linux-from-ai-says-greg-kroah-hartman/
> 
> The Linux kernel is a pretty large C codebase, and I also work with a
> pretty large C codebase in my day job.  At that scale, the weaknesses of
> C persistently come up: forgetting to free a pointer after use,
> forgetting to release a resource (often in a rare path not often or
> never tested), buffer overruns, dangling pointers, etc..  After decades
> of working on a large complex C codebase, I've grown weary of debugging
> these same old problems over, and over, and over again.
> 
> D made a lot of right choices in this area: statically-verifiable const,
> compiler-enforced nothrow, pure, etc., arrays that always carry length
> and out-of-bounds deference causing a runtime exception instead of
> overwriting arbitrary memory, GC eliminating an entire class of pointer
> bugs, etc..  These make D a huge pleasure to work with, as opposed to
> the constant stream of pointer bugs, memory leaks, and
> programming-by-convention that has been proven to be ineffective decades
> ago, that you have to put up with when working in C.
> 
> 
> T

Aw, no wish list?

Also please note that nothrow @nogc and pure all rely on inference to 
work correctly, and dmd is unable to do this. As a result I would 
suggest to think of them as being on the chopping block at a future 
point in time.

We keep finding problems with them, nothrow in particular had a bug 
report within the last couple of months that we have yet to find a 
solution for.

I will be wanting a replacement however, so no need to worry about any 
removal, just the solution will have to be different ;)