Obvious things C should do

Original Article ↗ Hacker News Discussion ↗

D, Zig, and C’s Evolution

  • Several commenters say the wishlist for C matches existing features in D, and partly in Zig and C++.
  • A D-implementer argues D pioneered many now-common features (ranges, CTFE, labeled breaks, integer literal underscores, fixed-size ints), and sees C/C++ as too conservative.
  • Others counter that many of those ideas predate D (Ada, Perl, Algol 68, JS, C99), and that Zig had several features from the start.
  • Some think if you want these features you should just use D/Zig/Rust; others note large C codebases and org constraints make “just switch” unrealistic.

Compile-Time Evaluation and constexpr-like Features

  • Strong support from D users for compile-time function execution (CTFE) as “indispensable,” used for tables, enums, static asserts, etc.
  • Proposal: any constant-expression context in C should allow calling pure functions at compile time, without a constexpr keyword, and only the executed branch must be CTFE-safe.
  • Skeptics worry about:
    • Non-termination or very slow CTFE (e.g., pathological functions).
    • Debugging becoming brittle when adding print statements or hardware accesses.
    • Having de facto “red vs blue” functions even without a keyword.
  • Others point out C23 already moved toward constexpr and most compilers already do some constant folding.

Forward Declarations, Single-Pass Compilers, and Modules

  • One camp wants to remove forward-declaration requirements and allow order-independent top-level definitions for more natural “public-first” file layout and better aesthetics.
  • Opponents like the current “reverse topological” ordering; say it highlights dependency structure and discourages hidden cycles.
  • There’s debate over whether single-pass compilers are simpler or actually no faster in practice.
  • Multiple participants strongly advocate module/import systems over #include, citing:
    • Huge compile-time wins from not reprocessing headers.
    • Easier whole-program compilation and fewer precompiled-header hacks.
  • Others say C++ modules are clumsy, but D-style modules are praised as simple and effective.

Header Files and Interfaces

  • Many C programmers say headers are a feature, not a bug:
    • Clear public/private split.
    • Easy to read a library’s API without wading through implementation.
    • Natural place for focused documentation.
  • Others argue modern tooling (e.g., auto-generated docs, interface files) is strictly better:
    • Cross-references, search, examples, and “view source” in one place.
    • No manual duplication of declarations.
  • There’s a long subthread contrasting header-based documentation vs generated HTML/docs; consensus is split and highly preference- and tooling-dependent.

Compile-Time Unit Tests

  • Proposal: unit tests expressed as compile-time assertions, evaluated during compilation.
  • Proponents:
    • No need to build/run separate binaries for many tests.
    • Very fast when tests are small and pure.
    • Already used heavily in D’s own test suites.
  • Critics:
    • Fear slower dev loops if every build must pass all tests.
    • Want tests as an opt-in build step, not a hard compilation gate.
    • Point out many useful tests need I/O or side effects that CTFE forbids.

Minimalism vs Feature Creep in C

  • A vocal group insists C should stay small and conservative; adding “obviously nice” features risks C++-style complexity.
  • They prefer solving problems by writing more C, not evolving the language, and see many proposed features as “wrong language” territory.
  • Others note C has already accumulated complex and arguably marginal features (Unicode identifiers, generics, etc.), while still avoiding structural improvements like modules or better forward-reference handling.

Other Suggestions and Frictions

  • Requests for: slices, defer-like cleanup, better enums/union types, type introspection, safer type punning, standardized container_of, mandatory exact-width integer types, better Unicode/UTF-8 support.
  • Some want C to deprecate or sidestep the preprocessor; others see it as essential but archaic.
  • There’s recurring tension between people who value C’s predictability and low-level control vs those who want it to adopt modern abstractions already proven in other languages.