Polymorphic Types in C [pdf]
A proposal to add polymorphic types to the C language, via new constructs like `_Type` and `_Var`, has reignited long‑running tensions over how far C should evolve versus deferring to C++ or newer systems languages. Supporters argue that type‑safe generics, better arrays, and runtime type information would materially improve safety, reuse, and interoperability in domains like embedded and aviation, especially where C++ compilers are unavailable or unreliable. Critics counter that the design feels ad‑hoc and syntactically ugly, risks “bloating” C with half‑measures instead of cleanly borrowing proven ideas, and may undermine C’s appeal as a small, predictable core language.
Overall reception of polymorphic types in C
- Many see polymorphic types as genuinely useful, especially for generic libraries and safer replacements for
void*patterns. - The proposal is viewed as “brave” but also “patch-like” and awkwardly bolted onto C’s existing type system rather than a clean, first-class design.
- Some like that it aims beyond C++-style templates toward more powerful polymorphic/dependent typing, avoiding monomorphization and code bloat.
- Others criticize conditional semantic rules (“only valid in some contexts”) as echoing C++ complexity and making reasoning about code harder.
C vs C++ and other languages
- A recurring theme: “just use C++” for generics and polymorphism vs. “C++ is bloated and messy.”
- Several argue C should cherry-pick only the “good parts” of C++ in a simpler form; others think that’s not what is happening—new features feel half-committed and weirder than necessary.
- Some have explicitly moved from C++ back to C, citing complexity and misuse of advanced C++ features in real codebases.
- Alternatives discussed: Rust (seen as drifting toward feature bloat), Ada (strong but hard to sell), Zig/Odin/D with
-betterC, and C3 (withany*and a “no big ideas” philosophy).
Type safety, arrays, and void*
- Debate over whether C++ is inherently more type-safe than C:
- Pro-C++ side cites template generics,
std::array, stronger pointer type checking, andstatic_cast. - Pro-C side counters that modern C plus careful style (no decayed arrays, minimal casts, macros for safety) can reach similar safety.
- Pro-C++ side cites template generics,
- Multi-dimensional arrays: some praise C’s VLAs as nicer than C++ arrays; others call them a security risk, with counter-claims that stack protections mitigate this.
void*-based APIs (e.g.,qsort, PAM, Wayland) are cited as pain points; type-safe generics are seen as a key motivation.
Syntax, keywords, and aesthetics
- Strong dislike for
_Type/_Var/_Genericaesthetics; many note C codebases favor all-lowercase identifiers. - Explanation: leading-underscore-with-capital is reserved to avoid breaking existing code; later, lowercase aliases or true keywords may appear (as with
_Bool→boolin C23). - Concern that some keywords (like
_Generic) never got nicer aliases, limiting adoption; similar worry for_Typeand_Var.
Use cases and dynamic typing / FFI
- Proposed benefits include:
- Type-safe generic interfaces (e.g.,
qsort-like functions). - Easier construction of types and function calls at runtime for language interoperability, if
_Typeofcan provide inspectable runtime type descriptions.
- Type-safe generic interfaces (e.g.,
- Some question whether these needs justify complicating C instead of selecting a different language; others argue no existing language matches C’s combination of simplicity, portability, and control.