Why static analysis is the way to go

[monkyyy]

On Friday, 29 May 2026 at 00:25:53 UTC, H. S. Teoh wrote:
> You're missing my point.
> You're missing the point.
> your structure's assumptions without you knowing,
> obscure module somewhere in a 2M LOC codebase

> Void pointers are another frequent source of guffaws.  Last I 
> checked, the compiler doesn't even require a cast anymore when 
> assigning a void* to a typed pointer.

> I think the idea behind Rust's static checker is sound -- you 
> *want* something statically provable and enforceable by the 
> compiler

Im asserting I write smaller programs then most, without @safe, 
without and debugger, using compiler bugs, void* whenever I want 
and I do not have memory management issues that rust and c++ 
smart pointers and allocators and gc debates claim is a hard 
problem. Because I do one thing: I push the blame to the 
datastructure where it belongs. When I call opIndex on my data 
structures I ussally make a small hack to make it return 
something; then I use that opIndex to make a range.

My code is very very unsafe; but I just dont have these issues 
people keep claiming are very hard to solve around memory. By 
going in the exact opposite direction from rust.

> You're missing the point. C++ iterators, frankly, stink.  I 
> used to write a fair amount of C++, and iterators just suck so 
> hard compared to D ranges.

> But they're a step up from C++ iterators.

The *type theory* is the identical as far as I remember, only the 
api is different, and if you go full iterator you would get the 
same benefits of going full range.

Ideally with both you wouldn't even call for/each directly, so 
the ugliness of c++ for statements wouldnt matter, altho in 
practice of course you tend to need the escape. The main 
difference when I look at aa notes on ranges and c++ theory(they 
are both linked lists based thoerys and the first upgrade is 
"bidirectional" and "random access" is a ultimate but fragile 
one), that steponov had less power over the language day 1 so aa 
got to make a nicer api.

> (This doesn't mean I don't care about memory management -- 
> optimizing bottlenecks require you to take over the reins from 
> the GC sometimes, and I'm fine with doing that, and have done 
> it on occasion.  In fact I appreciate how D lets me control 
> memory management to the point I can call malloc/free myself if 
> I really wanted to.  But I shouldn't be *required* to think 
> about memory management left, right, and center every other 
> line of code I write.  That's just ridiculous.)

You should care even less.