> Why does Rust sometimes require program redesigns? Because these programs are flawed at some fundamental level.

I'm familiar with borrow checkers, as I wrote one for D.

Not following the rules of the borrow checker does not mean the program is flawed or incorrect. It just means the borrow checker is unable to prove it correct.

> D lacks the most important and hardest kind of safety and that is reference safety

I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem.

BTW, if you use the optional GC in D, the program will be memory safe. No borrow checker needed.

▲

Voultapher 2 days ago | parent [-]

> I look at compilations of programming safety errors in shipped code now and then. Far and away the #1 bug is out-of-bounds array access. D has solved that problem.

Do you have good data on that? Looking at the curl and Chromium reports they show that use-after-free is their most recurring and problematic issue.

I'm sure you are aware, but I want to mention this here for other readers. Reference safety extends to things like iterators and slices in C++.

> Not following the rules of the borrow checker does not mean the program is flawed or incorrect.

At a scale of 100k+ LoC every single measured program has been shown to be flawed because of it.

▲

WalterBright 2 days ago | parent [-]

No, I haven't kept track of the reports I've seen. They all had array bounds as the #1 error encountered in shipped code.

Edit: I just googled "causes of memory safety bugs in C++". Number 1 answer: "Buffer Overflows/Out-of-Bounds Access"

"Undefined behavior in C/C++ code leads to security flaws like buffer overflows" https://www.trust-in-soft.com/resources/blogs/memory-safety-...

"Some common types of memory safety bugs include: Buffer overflows" https://www.code-intelligence.com/blog/memory_safety_corrupt...

"Memory Safety Vulnerabilities 3.1. Buffer overflow vulnerabilities We’ll start our discussion of vulnerabilities with one of the most common types of errors — buffer overflow (also called buffer overrun) vulnerabilities. Buffer overflow vulnerabilities are a particular risk in C, and since C is an especially widely used systems programming language, you might not be surprised to hear that buffer overflows are one of the most pervasive kind of implementation flaws around." https://textbook.cs161.org/memory-safety/vulnerabilities.htm...

▲

Voultapher 2 days ago | parent [-]

Spatial safety can be achieved exhaustively with a single compiler switch - in clang - and a minor performance hit. Temporal safety is much harder and requires software redesign, that's why it still remains in projects that care about memory-safety and try over a long time to weed out all instances of UB, i.e. critical software like curl, Linux and Chromium.

Temporal safety is usually also much harder to reason about for humans, since it requires more context.

▲

IshKebab 2 days ago | parent [-]

What flag is that? Address sanitizer has a 2x performance hit so presumably not that?

	▲	Voultapher 2 days ago \| parent [-]
		-fbounds-safety [1] Based on their slides [2]. I was wrongly informed one does need to do some light annotation in function signatures and struct definitions for anything ABI relevant. Based on their slides: Ptrdist and Olden benchmark suites - LOC changes: 2.7% (0.2% used unsafe constructs) Much lower than prior approaches - Compile-time overhead: 11% - Code-size (text section) overhead: 9.1% (ranged -1.4% to 38%) - Run-time overhead: 5.1% (ranged -1% to 29%) Measurement on iOS - 0-8% binary size increase per project - No measurable performance or power impact on boot, app launch - Minor overall performance impact on audio decoding/encoding (1%) [1] https://clang.llvm.org/docs/BoundsSafety.html [2] https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...