Contracts for C

This Hacker News discussion explores various opinions on the evolution of C and C++, the merits of new features, and the philosophy behind language design. The core themes revolve around conservatism versus progress, the nature of complexity, and the role of standardization bodies.

The Conservatism of C versus the Evolution of Other Languages

A central point of contention is why C remains relatively static while other languages like Java, C#, and especially C++ have undergone significant transformations. Some users laud C's unchanging nature as a "refuge for the sane." They argue that people choose C because they like that C, and any changes should only address existing "holes" rather than introducing entirely new paradigms.

• "Because there must be at least one refuge for the sane" - dmitrygr
• "People chose C because they liked C. Of course they don't want C to change." - HexDecOctBin
• "Your question can be reflected back to you: if you want an ever changing languages, go to Java, C# or C++, why mess with C?" - HexDecOctBin
• "The same thing can be said for every other language, yet they change." - xboxnolifes

Conversely, others suggest this attitude is detrimental, arguing that languages, like software products, must evolve or "wither and die." They point out that many people used C because they had to, not necessarily by choice, implying that a more modern, user-friendly C could attract more developers.

• "pjmlp: No, many people chose C, because they had to."
• "pjmlp: Languages are software products like everything else in computing, either they evolve or they whither and die."

The Role and Perception of Complexity

The discussion frequently touches upon the perceived complexity of languages, with C++ often cited as an example. Some view its increasing complexity as a cautionary tale, while others argue that this complexity is a natural consequence of incorporating desired features and that C++'s popularity demonstrates the value of evolution.

• "The complexity of C# and C++ should be a warning, not something to strive towards." - nananana9
• "I think this talk about "complexity" is a red herring. C++ remains one of the most popular languages ever designed, and one of the key reasons is that since C++11 the standardization effort picked up steam and started including features that the developer community wanted and was eager to get." - motorest
• "I still recall the time that randos criticized C++ for being a dead language and being too minimalistic and spartan." - motorest

There's also a nuanced view that new C++ features can actually simplify coding, even if they increase the learning curve due to the coexistence of older styles.

• "npoc: I agree. A lot of new additions to C++ make coding with it simpler, not more complex. However it does mean there's more to learn, because the old style of the language still exists and is still accepted by the modern compilers as opposed to say, Rust which removes replaced language features when it releases a new edition."

The Desire for a "Reliable" C and the Need for Clarity

A significant portion of the discourse focuses on what C developers truly want and what the ISO committee (WG14) should prioritize. The consensus among some is that the focus should be on clarifying undefined behavior (UB), establishing a more robust memory and threading model, and documenting implementation-specific details, rather than introducing syntactic sugar or new ways to express existing concepts.

• "Most C developers don't want a modern C, they want a reliable C. WG14 should be pushing for clarifications on UB, the memory and threading model, documenting where implementations differ, and what parts of the language can be relied and what not." - nananana9
• "Nobody really needs a new way to do asserts, case ranges, or a new way to write the word 'NULL'." - nananana9
• "The only thing the ISO committee should be adding is stuff for filling in the holes in language (C23's Improved Tag Compatibility and __VA_OPT__ are good examples), not add features that were never part of C and were never supposed to be there." - HexDecOctBin

The idea of "contracts" (pre- and post-conditions) for C is also heavily debated. While some see it as a way to improve code safety and catch errors earlier, others express concerns about introducing "panics" or unexpected crashes, arguing that C's existing error handling mechanisms (like returning NULL) provide more control to the developer, especially in critical systems.

• "But regardless of the mechansim you're left with another far more serious problem: You've now introduced panic to C." - kstenerud
• "And panics are bad. Panics are landmines just waiting for some unfortunate circumstance to crash your app unexpectedly, which you can't control because control over error handling has now been wrested from you." - kstenerud
• "The author writes that contract_assume invokes undefined behaviour when the assertion fails: ... But this means that the compiler is allowed to e.g. reorder the condition check and never output the message. (Or invoke nasal demons, of course)." - 1718627440
• "safely at any time or a hard real time system where panicking could destroy hardware." - AlotOfReading
• "The stdlib function already have return values to indicate invalid arguments from the caller. These exist to allow the caller to decide what to do in this case. Replacing them by invoking UB or panicing, means the user looses control." - 1718627440

The Irony of C++ Implementation Diversity and the Rise of Rust

A brief discussion points out the irony that C used to pride itself on having many implementations, while C++ now has fewer, higher-quality implementations. This leads to a side-by-side comparison with Rust, with one user suggesting that if Rust offers a better developer experience, it should be allowed to compete and the results will be seen in 10 years.

• "As someone that remembers the t-shirts with 'my compiler compiles yours' that some C folks used to wear, it is kind of ironic having that turned around on them." - pjmlp
• "I can tel you that as a matter of fact a key reason why the likes of Rust took off was that people working with low-level systems programming were desperate for a C with better developer experience and sane and usable standard library." - motorest
• "So what's the problem? If Rust is gaining traction on C/C++, and people are excited about what it brings to the table, use it. We'll both do our thing, let it play out - we'll see which approach yields better software in 10 years." - babaceca

The Status of Other Languages and Features

Mentions of Eiffel and Ada surface, with users discussing their features like unsolicited tracing garbage collection and contracts, and questioning their current relevance. There's also a desire for improved features like slices/spans and array bounds checking, with a distinction drawn between C and C++ feature development.

• "Eiffel has unsolicited tracing garbage collection. For TGC-free programming there is Ada" - OCTAGRAM
• "Ada / SPARK has contracts, too, that can be proven at compile-time. In fact, Ada alone suffices, it has pre- and post-conditions. I think Ada has more libraries than Eiffel does. Does anyone even write Eiffel? I am really curious if it is still alive anywhere, in some form." - johnisgood
• "sirwhinesalot: Contracts getting proposed but still no slice/span type or even standardization of that new clang feature that makes f(int n, int a[n]) Actually do what it looks like it does. Sigh"
• "sirwhinesalot: C, not C++. Also span had no bounds checking until the introduction of .at() in C++26, which was a very silly thing to do so late in an age where the white house was asking people to use memory safe languages."