Obvious things C should do

Original Article ↗ Hacker News Discussion ↗

Proposals to modernize the C language—such as compile‑time function evaluation, built‑in unit tests, forward‑reference support, and module-style imports—are drawing both enthusiasm and pushback from systems programmers. Supporters point to languages like D, Rust, and Zig as proof these features can greatly improve compile times, metaprogramming, and API design, while critics argue that C’s value lies in its simplicity, predictable tooling, and stable headers, and that large changes introduce complexity, performance risks, and ecosystem churn. Underneath the feature debates is a broader question of whether C should keep evolving to match newer languages or remain a minimal, stable “portable assembly” that other languages build upon.

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.