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
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