Hacker News Reader

Comment by dymk | Hacker News Reader

You've made a few comments like this; care to explain your thoughts rather than just say a bunch of variations on "nooooo!"?

View on HN

The C language is finished and great as it is.

Many programmers like myself have no problem with it whatsoever.

Change in a key infrastructural component like this is only destabilizing.

The ISO C people should have the decency to disband and work on their pet language research projects in private.

You are free to stay on C89 or C99. They are not going away anytime soon, too much code relies on it.

If you think if standard-driven changes to the compiler will never break your C89 code, because you're using the -std=c89 switch or whatever, you are pretty naive.

The only guaranteed way your compiler won't break your code is if it's left alone.

That can happen due to changes unrelated to new standards too. So if you are worried about compiler changes, then definitely freeze the compiler version you use. Alternatively invest in in quality assurance to verify that your code still works with a new compiler version.

The standard is versioned. You can always use a modern compiler targeting an older standard. You don't have to use C11. Or C21.

And then there is this activity called "working with other people".

Also, gratuitous changes to the compiler can break things that affect C90 operation. There is a risk.

Or go back to K&R, for that matter.

The C language (and the C++ language, for that matter) basically _never_ make backwards incompatible changes. This is a first class priority for the standards committees.

Adding simple abstractions which don't hide complexity in the underlying assembly is a huge productivity and correctness boost. Not that it matters anyways; modern optimizers are always going to do things that absolutely bend your brain.

Wouldn't that be nice if you could use a `scope(exit) {}` instead of accidentally missing two or three `goto cleanup_7;` which result in an RCE?

I would absolutely love a standards-compliant way to scope-guard sections of code. It'd make huge swaths of C code simpler; it's even in enough demand that Clang and GCC implement as their own extensions.

Better go through the standards then, both of them have introduced breaking changes in their revisions.

I can gladly provide a couple of examples.

Please do provide examples. Revisions to the C and C++ have almost never broken meaningful backwards compatibility, at least at the language semantics level.

C's variable-length arrays are one example. They were introduced in C99, and downgraded to 'optional' in C11. So that's one place where a newer C compiler could refuse old C code and still be language compliant.

Also the draft C2x standard does away with K&R declarations, which will be another compatibility break.

Besides what nrclark has written on his/her comment, C11 dropped gets() and the introduction of the new memory model in C11 might break code that was relying on CPU specific semantics not in synch with it.

Regarding C++:

- auto changed its meaning on C++11

- export templates were removed in C++11

- exception specifications were deprecated in C++11, removed in C++17 and might do a come back in C++23 with value based exceptions

- gets() got removed in C++11

- declspec and auto had a small semantic difference, settled in C++17

- initializer lists introduced in C++11 changed their auto deduction type in C++17

- the required implementation semantics for std::string in C++11 broke COW in compilers like GCC.

Just a small list, there are a couple more.

> The C language is finished

There's no evidence of this. There's just existing code. Ok. There's existing code in lots of other languages with different syntax (large and small differences). So what?

The latest video about Oden was a fantastic primer on QoL changes that should be standard, but there are people who always think what they learned is optimal. These are the same people who trivialize evidence to the contrary, in defense of their particular viewpoint.

Here is a counterpoint: The C language is not finished, and many programmers like myself would like to see the language continue to evolve and grow in reasonable ways, especially given the fact we'll keep on writing it for a while to come. The ISO C people should be commended for doing their hard work.

Alright. Glad we cleared this whole thing up.

> we'll keep on writing it for a while to come

Nope; I will be writing in "it". What you obviously want is to be writing in something other than "it". You basically want to be able to write Rust, Go or D into a file that has a .c suffix and is passed through a preprocessor.

Reply on news.ycombinator.com