Partially Matching Zig Enums

Zig comptime enums and comptime unreachable

• Discussion centers on using Zig’s inline and comptime unreachable to partially match enums and statically prove some branches impossible.
• Multiple commenters stress this is not an optimizer trick: it relies on Zig’s defined lazy compile‑time evaluation, similar to C++ templates or if constexpr.
• The compiler instantiates each inline enum case with a comptime-known value, so only the taken branch is compiled; unreachable branches can therefore be enforced at compile time.

Comparisons to Rust, C++, D, and others

• Rust examples show roughly analogous behavior with const { ... }, but there’s debate over how close the correspondence really is, especially when mixing const and non‑const control flow.
• D and C examples demonstrate that similar patterns are possible via templates/macros and static if, but often with more verbosity and less clarity.
• Some praise Zig’s syntax and legibility for these tricks; others think such patterns are too “cute” and prefer straightforward exhaustive switches or simple runtime checks.

Memory safety, correctness, and tradeoffs

• Large subthread debates Zig vs Rust vs C++ (and occasionally Go/Java/Ada):
  • Zig: bounds-checked slices by default; optional runtime safety modes; manual memory management with defer; no data‑race guarantees.
  • Rust: strong compile‑time guarantees against UAF and data races in safe code, but with higher complexity, “false positives,” and ergonomic pain.
  • C++: RAII and smart pointers can drastically reduce leaks/UB, but the language itself offers few hard guarantees; many pitfalls remain.
• Some argue simplicity plus runtime checks (Zig) can yield very good real‑world safety; others counter that without strong static guarantees, humans and large codebases inevitably re‑introduce serious bugs.
• Disagreement over whether features like RAII/destructors vs explicit defer are net safer or just different tradeoffs; no consensus, but strong stated preferences.

Zig’s role as a systems language

• Supporters highlight: powerful yet simple metaprogramming (comptime, inline else), good C interop, clear generated code, and ergonomic zero‑cost abstractions as Zig’s real advantages.
• Critics argue Zig sidesteps “hard problems” (ownership, lifetimes, concurrency models, formal invariants) and mostly reimplements C with nicer syntax and better tooling.
• There’s ongoing tension between viewing Zig as a pragmatic, lower‑ceremony alternative and seeing it as underpowered for long‑term, large‑scale, safe systems work.