• he/him

programming, video games, dadding. I happen to work for Xbox, but don't represent them.


more blog
dev.to/knutaf
discord
knutaf
You must log in to comment.

in reply to @ThePhD's post:

Thank you for your hard work — also over on The Pasture, I enjoy reading your insightful articles —, it is appreciated!

That being said I do hope the standards committee takes it slowly. I have been programming in C for just over 30 years now, and the last thing I would want for the language is to have to succumb to death by feature creep in the future.

This is not to mean that the language may not evolve any further ever… but featuritis is a real thing—for me it killed C++ and Iʼm thinking about quitting Python (only used it for hobby projects)—and I wouldnʼt want it to happen to my favorite programming language.

Also, as someone who is versed in assembly language programming I do hope that C will stay true to its roots as a high-level assembler. Language constructs where it isnʼt at least somewhat obvious how they can be implemented on that level of the machine should never make it into the language.

And just so that itʼs said: the argument “if you don't need it, don't use it” is an incredibly weak one and can only really be uttered by people who have never worked in a team—while not everyone will have to know the ins and outs of every feature, one has to know enough to understand (and be able to adapt and change) other code. (Not knowing at least something about every feature other colleagues might use isnʼt really an option in the real world.)

Thatʼs exactly what got me worried. The (until now) usual 10/11 years between standards was a good time window to get accustomed to new language rules and features. I am not convinced that doubling the rate at which these are introduced is necessarily a good thing.

That being said, I realize that it depends on the kind of changes one is talking about. A new string type—like strb_t⁽¹⁾—wouldnʼt change the language, only make it easier/more failsafe to work with. Adding a ton of new keywords would however change how it feels to program in C.

I trust that the standards committee knows how far it can go without making us oldtimers too grumpy ;-)

⁽¹⁾ Although, notwithstanding what I said earlier, I think ‘strb_t’ is too modest a proposal in that any new string type that is seen to be fit for the standard should fully endorse the UTF-8 world we live in and give programmers—at least in a hosted environment—functions to work with grapheme clusters, Normalization Forms and all other Uɴɪᴄᴏᴅᴇ niceties (saving the pain from having to choose between utf8proc, libgrapheme, … and a myriad of other libraries).