FYI, when I initially implemented new
as an operator, the very first real world script I ran failed, because I had used "old" and "new" as variable names. I then changed the implementation, with the intention of reserving "new" as an operator in v2.0.
... reserving between, is, in, and contains as expression operators.
I won't be implementing between..and
as an operator, so it will not be reserved. As with and/or/not, is/in/contains/new won't be disallowed as variable names (for code size and performance reasons), but they will be interpreted as operators when appropriate. I see little value in specifically disallowing those variable names. (However, documenting them as reserved is a different matter.)
EDIT2: Perhaps ErrorLevel should be reserved?
I don't quite get your meaning. It's essentially already reserved, as are all names of built-in variables.
this (...) can lead to weird bugs.
How? It's perfectly legitimate to write:
if = foo
MsgBox % if
... without any ambiguity, but who would actually do it? It has to be supported for commands like "Control" or "Input", which are more likely to be used as variable names.
I think it would make sense to introduce the concept of reserved words to AHK at some point.
I don't disagree, but it's unlikely I'll do anything about it myself any time soon.