I've been thinking this for a long while now. My only concern is whether this could be an issue for savefiles, which save const vars a little differently.

MrStonedOne wrote:

if people are trying to save and load directly into global const vars, something has gone horribly wrong.

What I mean is more like this: If you save a list that's defined as follows, it saves a var reference rather than a constant (or so I've been given to believe based on ExportText() results in Incursion's config saves):


So if that were to happen, then a savefile with that const would be suddenly unusable in a version compiled with no consts to work with. Since #define values are not kept with the code, nothing would handle that correctly. I suspect the goal of this saving was to allow the constant to be changed without causing problems, so if you changed the value of MY_CONST from "My const" to "My special const" the savefile would work just as well.

What I am wondering, however, is if I could add another keyword that would do the const var and the #define at the same time, effectively short-circuiting the problem. The only way for this to work is if the define is processed early, though.

Alternatively, perhaps a better way to handle Ter's suggestion is to simply fix the problem at hand, which is that expressions based on const vars aren't being viewed as consts themselves. I think that might be fixable.