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.
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...
Temporal safety is usually also much harder to reason about for humans, since it requires more context.
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/...
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.