Wouldn’t existing programs just continue working? What the author did was adding new types, not modifying or removing existing ones.

> Wouldn’t existing programs just continue working?

Only ones which don't have variables named `i8` or `b32` (which is common, but not for booleans).

I've seen many projects which used the pattern [a-z][1-9]+ as variables. Those programs with a variable called `i8` won't compile if the standard made a type called `i8`.

In particular, the standard reserves entire patterns to itself, so it cannot reserve the pattern of [a-z][0-9]+. They could, and did, reserve the pattern *int*_t for themselves.

But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work.

In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.

> But that problem exists for any C project that uses an external library. If the library defines something that the project already uses, then the project will not work.

For libraries, yes, but we're talking about why the standard didn't do it.

The standard did not want[1] to reserve keywords that current programs were already using.

A library that conflicts on keywords will only break with those programs that use it. A standard that conflicts on keywords breaks all programs in that language.

> In my mind that's not a problem with the decisions taken by the author of the article, it's more of a symptom of C's limitations.

One of the constraints of taking decisions is to work within the limits existing framework - if you're avoiding the alternatives that don't break, then it's the decision-makers bug, not the frameworks.

The framework has limitations, widely published and known. You make decisions within those limitations.

[1] Although, they do do it, it's only with relectance, not on a whim to avoid typing a few characters)

No program should every have variables names according to [a-z][1-9]+ pattern, except perhaps loop indices - and not even then.

> No program should every have variables names according to [a-z][1-9]+ pattern, except perhaps loop indices - and not even then.

What's that got to do with not breaking existing programs?

Those may be terrible variable names but they were understandable back in the 70s and 80s when disk space was at a premium and compilers only cared about the first 6 characters in a variable or function name. That's the downside of a 50 or so year old programming language: you have to worry about not breaking legacy code that did things based on the hardware limitations of that time.

Typedefs and variable namens don't live in them same namespace, do they?

> Typedefs and variable namens don't live in them same namespace, do they?

Depends. See this snippet: https://www.godbolt.org/z/5T5jz47q4

Cannot declare a variable called `u8` when there is a typedef of `u8`.

And even when you can declare a variable called (for example) `int`, that effectively "breaks" the program by not being even a tiny bit readable anymore.

Because those existing programs surely don't use the same identifiers for other stuff? Certainly there is no code out there using s8 for "signed char" instead of "utf8 string"? :-)