[_8ljf]

“I can't believe the C standards committee is entertaining this.”

Hey, standards committee’s gotta eat.

'defer'? I occasionaly use it in Swift to clean up resources; s’okay there, I guess, though I’m not convinced it’s better than Python’s 'with' block. But in C?

One of C’s few distinguishing strengths is that the language is relatively† small and stable, and well understood. For that kind of cleanup there is already 'goto', which again is small, stable, and well understood. I just used it for that the other day: it works, it’s fine; I’m a grown-up.

Yeah, sure, 'defer' is “safer” and “more elegant”… did we mention this is C? That ship sailed fifty years ago. Don’t try to make C into something it’s not: that’s C++’s job so go fill your boots there instead.

I just posted Tony Hoare’s excoriation of ALGOL68 the other day, but clearly it’s needed again:

http://zoo.cs.yale.edu/classes/cs422/2011/bib/hoare81emperor...

Simplest solution: track down the ruddy C standards committee and beat them in the head with a leather-bound copy of Zawinski's Law (wrapped around a large gold brick), till either they’re dead or they leave C be. It does what it was designed to do, and that along is reason enough not to dick with it just because they’re bored and struggling to justify their continued existence.

The only thing C needs to do is keep on working. That will only get harder the more crap they pile on top. A good artist knows when to stop.

Which brings us to…

“panic/recover”

K&R give us strength! Tell these frustrated wannabe language designers to go make their own damn language, instead of screwing up someone else’s!

Okay, now I’m done. And get off my lawn!

[scottlamb]

This seems really strange to me. The C committee recently seemed pretty opposed [1] to adding fat pointers [edit: originally wrote bounds checking but that was a thinko] as eg WalterBright has called for. [2] Addressing that seems like it'd have a lot more benefit for a much smaller change to the language. I don't really agree with you on "the only thing C needs to do is keep on working" but if they're not willing to entertain that proposal, why on earth would they be talking about throwing in exceptions?

[1] https://news.ycombinator.com/item?id=22866288

[2] https://news.ycombinator.com/item?id=24454369

[sloyd]

I couldn't agree more and created an account just to second your thoughts.

This is exactly why everyone hates using modern C++. Their standards committee has run amok with every fancy feature that every new language comes out with in the past two decades. And what has that wrought? A huge language that no one fully understands and is hard to read unless you happen to be the guy that wrote it and time since writing < two weeks.

C is simplistically beautiful. I can write it and understand exactly what the assembly will look like on the backend of the compiler (with the exception of nasty macros). Don't mess with that. If it doesn't feel like it belongs, that's probably because it doesn't! Know when to stop.

[jcelerier]

> This is exactly why everyone hates using modern C++.

speak for youreself ?

> Their standards committee has run amok with every fancy feature that every new language comes out with in the past two decades. And what has that wrought?

given the amount of languages that reimplement C++ features (and sometimes have to be dragged by the feet to get them, e.g. generics and interface methods in java), I'd say that people who don't understand c++ are doomed to reinvent it :)

[cycloptic]

More features being added to a newer version of the standard doesn't prevent you from staying with the old version. Your trusty old C89 compiler will still continue to work.

Speaking from experience, GCC/Clang extensions are pretty useful when you can afford to use them and it would be nice to have some of that stuff standardized because a lot of code I see in the wild is already using them. The time for warning about C becoming a mess of incompatible extensions has already passed unfortunately, and the only group that can solve this is a standards committee.