Why static analysis is the way to go

[H. S. Teoh]

On Fri, May 29, 2026 at 08:36:54AM +1200, Richard (Rikki) Andrew Cattermole via Digitalmars-d wrote:
> On 29/05/2026 7:41 AM, H. S. Teoh wrote:
[..]
> > https://www.zdnet.com/article/rust-will-save-linux-from-ai-says-greg-kroah-hartman/
[...]
> > 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.
[...]
> 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.

I wasn't thinking of these attributes in particular, but the general
idea of compiler-enforced static verification.  I think the last 50
years have taught us beyond all doubt that humans are fallible, and
that catching problems at compile-time is far better than discovering
them at runtime.

Compile-time guarantees are a big advantage, whatever form they may
take.  Not only do they help catch stupid mistakes early, they also make
it easier to reason about code, which is a boon for maintainability.
Often, knowing what the code *cannot* do is equally as important as
knowing what it can do.


> 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.

Just curious, which bug is that?


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

I'm not particularly attached to any of them specifically, but I would
warmly welcome more compiler inference and compile-time enforcement.
External static analyzers are all good and everything, but if something
is not enforced, it might as well not exist, because human laziness will
trump it and *somebody* *somewhere* will have the smart idea of
bypassing it (because an irate customer wants the fix by yesterday, and
fixing it the right way takes too much time), with the usual disastrous
consequences.


T

-- 
Why can't you just be a nonconformist like everyone else? -- YHL