safety.md

issue	c	zig (release-safe)	rust (release)	Nim (release)	Nim (danger)	D (@safe)	Swift	modern C++
out-of-bounds heap read/write	none	runtime	runtime	runtime	none	runtime	runtime	none³
null pointer dereference	none	runtime	runtime	runtime	none	runtime¹	runtime	none⁴
type confusion	none	runtime, partial	runtime	compile time	compile time	compile time	compile time	partial⁵
integer overflow	none	runtime	runtime	runtime	none	wraps	runtime (checked)	undefined behavior
use after free	none	none	compile time	handled by gc	handled by gc	handled by gc or rc	runtime (ARC)	none⁶
double free	none	none	compile time	handled by gc	handled by gc	handled by gc or rc	runtime (ARC)	none⁶
invalid stack read/write	none	none	compile time	handled by gc	handled by gc	compile time	runtime	none
uninitialized memory	none	none	compile time	memory always zeroed	memory always zeroed	memory always initialized	memory always zeroed	partial⁷
data race	none	none	compile time	none	none	compile time (WIP)²	compile time⁹	none⁸

1. D relies on the operating system to trap null dereferences.
2. D's type system distinguishes between shared and thread-local data. Compile-time checks for unsynchronized access to shared data are partially implemented and currently considered experimental.
3. C++ containers like std::vector provide bounds checking in debug mode, but not in release builds by default.
4. C++ introduced std::optional and nullptr, but dereference checks are not automatic.
5. C++ has RTTI and dynamic_cast, but they're not always used or enabled.
6. Smart pointers help, but don't completely prevent these issues.
7. C++ value initialization can prevent some uninitialized memory issues, but not all.
8. C++ has threading primitives and memory models, but doesn't automatically prevent data races.
9. Swift uses type checking and compiler analysis to prevent many data races at compile time, but runtime checks are also employed for complete safety.