The empire of C++ strikes back with Safe C++ blueprint

Error handling models

• Debate over exceptions vs explicit error returns.
• Pro-exception view: callers can catch failures at a higher level without understanding library internals; avoids repetitive “bubble up the error” boilerplate (e.g., Go-style).
• Anti-exception / explicit view: making errors part of function signatures (Rust Result, effect systems, checked exceptions) forces programmers to acknowledge errors, improving resilience.
• Effect systems (Nim, OCaml) are praised for separating error effects from return types and enabling opt-in enforcement.
• Some criticize Rust for error-handling verbosity and manual error-type plumbing; others counter that propagating errors can be nearly zero-cost (?) in simple cases.

C++ exceptions and noexcept

• C++ exceptions are described as making control flow hard to reason about, especially with dynamic linking; throw-specifications are effectively gone.
• There’s confusion and disagreement about noexcept’s performance impact: one claim that it harms performance vs others stating typical implementations impose no runtime cost unless unwinding and mainly affect code size.
• noexcept is explained as primarily enabling stronger guarantees for standard containers (e.g., move vs copy behavior).

Rust vs C++ features and OO

• Missing C++ features in Rust (overloading, inheritance, exceptions) are seen by some as positives that reduce complexity.
• Rust traits and generics are viewed as a healthier replacement for ad-hoc overloading, avoiding C++’s complex overload-resolution rules and ambiguous constructors.
• Others argue that richer OO/inheritance remains valuable, citing complaints from browser and game engine work; Rust’s delegation work is mentioned but status seen as incomplete.

Safe C++ blueprint and defaults

• Core criticism: safety is opt-in and code is unsafe by default, so many bugs will persist, especially given existing incentives and legacy code.
• Defenders note backward compatibility constraints; safety-by-default would break existing large codebases. Linters and tooling may enforce “safe” annotations in practice.
• Some suggest a “resyntaxed” C++ with new, safer defaults (e.g., safe and const by default) but identical semantics.

Fil-C / Fil-C++ as an alternative

• Fil-C++ is presented as a GC-backed, memory-safe, highly compatible C/C++ implementation that can already run large real-world codebases safely.
• Supporters argue it provides comprehensive memory safety (including stack and races) without unsafe escape hatches, unlike Rust or “Safe C++” proposals.
• Critics focus on performance: older docs report 3–20× slowdown; the author claims current overhead is usually <2× and improving, targeting ~1.2×.
• Discussion contrasts Fil-C’s concurrent GC with sandboxing approaches (WASM, RLBox) and hardware capabilities like CHERI, arguing Fil-C can be competitive or superior in practice.

Garbage collection vs reference counting and systems use

• Some argue GC is incompatible with high-performance, low-latency systems and cache-sensitive architectures; others respond that malloc has its own overheads and that GC can outperform manual allocation in many allocation-heavy workloads.
• Reference counting (as used by Swift/Objective-C ARC) is defended as “deterministic enough” and easier to reason about in practice, but others call it a “baby algorithm,” note its worst-case cascades, and point out that sophisticated tracing GCs generally have higher throughput.
• There is disagreement over whether GC-based safety (Fil-C, higher-level languages) is acceptable in domains traditionally dominated by C/C++, or whether only Rust-style static checks at zero runtime cost are viable for “systems” programming.