It's more work. Not only to put all the annotations correctly, but only because it causes some real headaches. It's easy (implicit) to transition from non-const to const 1 pointer level deep. But the other way around -- it's really awkward to "remove" a const.

The strstr() signature is probably the shortest example / explanation why. To implement strstr(), you have to hack the const away to create the return value. Alternatively, create a mutable_strstr() variant that does the exact same thing. This is the kind of boilerplate that we don't want in C (and that C is bad at generating automatically).

Think about it this way: Real const data doesn't exist. It always gets created (written) somewhere, and usually removed later. One way where this works cleanly is where the data is created at compile time, so the data can be "truly" const, and be put in .ro section, and automatically destroyed when the process terminates. But often, we have situations where some part of the code needs to mutate the data that is only consumed as read only by other parts of the code. One man's const data is another man's mutable data.

In C, the support for making this transition work fluently is just very limited (but I think it's not great in most other languages, either).

You want to avoid promoting or casting away the const. If you start using const, you almost inevitably wind up with a mismatch.

This introduces flaws in the type system. I wish I had a better breakdown on the impact of these concerns, but I'd rather not worry at all.

Anyway, if you don't use const, this goes away. Bear in mind the minor amount of "safety" it provides, because you can just ignore it later, as you arguably tend to be doing anyway when you pass a const to non-const or visa versa.

Inevitably, outside of really small insular project (and often times even then), there's something down the line that winds up being non-const that you don't want to change.

C developers of this mindset tend to just come to the conclusion that you will immediately break the type system, just give up on the whole game.

Edit adding at least on example:

Example: You define as const and remove the const later. If anything writes to the non-const, this is undefined behavior

Example: I believe the above is actually true for const promotion if you modify the non-const version... I think this is only after the call (edit. ie after it become const, really interest in the answer).

No Undefined behavior

/* I imagine this would be okay */

si_non_const = si_non_const + GetMagicValue();

/* Const is promoted here */

const int fparam = si_non_const;

/* Writing to fparam is undefined past here */

f_const(&fparam);

Undefined behavior

/* I imagine writing, after using as const is also not defined, but is fine at this point */

si_non_const = si_non_const + GetMagicValue();

/* Here we now have a constant value that will never be written to */ const int fparam = si_non_const;

f_const(&fparam);

/* I think this would also be UB, even though it's accessed through a different symbol */

si_non_const = si_non_const + GetMagicValue();

Interested in other opinion, maybe will think on later... would it be valid for the compiler to remove that last assignment?

Edit: Sorry, this is unreadable, if you put a space between the not undefined, and undefined it's easier