Why static analysis is the way to go

[H. S. Teoh]

On Thu, May 28, 2026 at 11:38:05PM +0000, monkyyy via Digitalmars-d wrote:
> On Thursday, 28 May 2026 at 22:58:33 UTC, H. S. Teoh wrote:
> > 
> > Remember, string = immutable(char)[].  That "tiny" decision to stick
> > "immutable" on it is what makes D strings so straightforward to use.
> 
> I cast that away anytime it gets in my way, the biggest thing is that
> the os is picky about me modifying strings from the executable, the
> run time couldve just handled that case and char[] wouldve been better
> for me

You're welcome to redefine your own string type as char[] and see how
that goes.  It's fine when you're in your own app and you get to dictate
how and when things are used.  Not so nice when you're writing a library
and you can't control what user code does or doesn't do.  Then you start
having to worry about aliasing and stuff getting modified that isn't
supposed to be.


> > Remember back in the day when somebody had the bright idea to make
> > AA's more "user-friendly" by allowing const or even mutable arrays
> > as keys?
> 
> no I dont, lets allow mutable keys :)

Sure, be my guest.  Let me know how it goes.  We could have a
competition, whoever gets the most segfaults per LOC wins. :-P


> > The  *idea* of ranges elevated our thinking to a whole 'nother
> > level,
> 
> the *type theory* of iterators; steponov was probaly being too mathy
> when he defined it and aa copied the hierarchy from stl. But it was a
> bunch of uml boxes and thinking about some variants of linked lists
> and he was trying to imagine what could be made to work with c++
> operator overloading.

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.  They're essentially thinly veiled disguises of pointer
bumping, no different from having to write a thousand for-loops and
manually bumping the loop counter (and suffering from tons of off-by-1
errors).  D ranges are different; by sacrificing some amount of
expressiveness (which we got criticized for by C++ folks), we have a
much cleaner, robust abstraction that lets us express iteration in a
nice, non-leaky way.

Now I'm not saying D ranges are perfect -- they have their own warts
(ask me about transient ranges sometime).  But they're a step up from
C++ iterators.  "We are not the same." :-P


[...]
> > Besides, segfaults are only a tiny part of what D eliminates by
> > design.
> 
> **But you linked a pro-rust article and called for static analyis**,
> and rusts solution to memory management is to make a proof engine. And
> like no, no, just no. Poor little rikki here thinks d needs some math
> prover thing, rust is such a bad influence ;__;

You're missing my point.  I'm not arguing for Rust-style memory
management, we honestly don't need that in D thanks to the GC.  What I'm
saying is that statically guaranteeing things at compile-time makes a
huge difference to the code clarity, maintainability, and frequency of
bugs.

Take mutable strings, for example.  C and C++ both have mutable strings.
Which means that every time you get a string argument, you cannot assume
it won't be modified afterwards.  This is no problem if you don't need
it after you return, but if you're storing it in a data structure
somewhere, it's a big problem.  Some unrelated code later can come
modify it later and break your structure's assumptions without you
knowing, and good luck finding the problem because the trigger and the
location of the fault are widely separated.  As a result, most C/C++
code will copy like mad -- that's the only way to ensure things don't
change behind your back.  Add to this the lack of string length in C,
now you're calling strlen() all over the place.  Schlemiel would be
proud.  Of course, once you copy, you need to clean up afterwards.
Which means more chances for bugs and forgetting to free stuff, or your
dtor being overzealous and freeing stuff it shouldn't, or some genius
keeping a reference to the string somewhere longer than he should --
dangling pointer bugs.

In D?  Thanks to the immutable guarantee, it's just a single pointer
assignment.  Job done.  No needless string copying, no silly strlen()
Schlemielisms, GC cleans up after you -- no memory leaks or dangling
pointers.  We reduced hundreds of CPU instructions into literally the 1
or 2 for the pointer assignment.  Huge win.

//

Then there's the C/C++ culture of programming by convention. Everyone
assumes that a const char* means your string won't mutate -- but the
language doesn't stop you, and the compiler will barely emit a groan
about it (and you can shut it up with a simple switch).  All it takes is
for ONE function in some obscure module somewhere in a 2M LOC codebase
to do the wrong thing (because the guy who cast away const was under
pressure from an overdue release deadline and the customer threatened to
sue), and your entire project is ruined.  Your assumptions are broken,
and who knows where the symptoms will manifest.  Probably long after the
fact in totally unrelated code.  Have fun tracking down where in 2M LOC
the bug is.

Const is just one of many examples.  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. (Decades ago
that used to be an error. Guess people got tired of writing
`needlessly_long_name_t *p = (needlessly_long_name_t *)voidPtr;` and
decided to let things slip.)  You can literally assign void* to anything
you wish, and code will happily dereference it, the compiler won't bat
an eye, and the code will crash spectacularly at runtime.  In D, the
compiler will complain loudly and refuse to compile the code until you
write out the ugly cast in full -- taking responsibility for problems
when it crashes later.  In @safe code, you can't even perform the cast;
you have to find a type-safe way of performing the assignment, meaning
the compiler can actually check that you didn't screw it up.  Static
enforcement == win.


> If you let them say shit theyll rewrite history that rust should
> replace all other languages, lets waste 10000x programmer time to make
> the bower checker happy citing perfect mathematical safety.
[...]

I've heard lots of Rust hype since the day it was inflicted upon the
world.  Hasn't convinced me yet, I'm still writing D whenever I can.

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

But the way Rust did it is too user-unfriendly; it requires you to jump
through too many hoops.  Most non-Rust coders can't swallow that.  The
incentives are all wrong; you're forced to learn to fly an airplane
before you can unlock the door to board the plane in the first place.
What they should have done is come up with a design where the most
obvious way to write code is the right way.  Not something where writing
the most obvious code elicits pages of complaints about how you did it
wrong and you need to shape up.

Besides, being *forced* to reason about memory management is exactly the
thing I've come to hate about C/C++.  I want to focus on my problem
domain, dangit, stop getting in my way and telling me I borrowed this
pointer wrong or assign that pointer wrong.  Let me do my job and solve
the danged programming problem first; hire the GC to clean up any messes
afterwards, thank you very much.

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


T

-- 
Being forced to write comments actually improves code, because it is easier to fix a crock than to explain it. -- G. Steele