this might have been posted before since it is quite a noticeable bug, but damned if i know how to search for it :p

if (v1 op v2) will have v1 and/or v2 interpreted and negated as code if either start with ! and are followed by a % or $



- $true



-



* /if: invalid format

and so on. i can only assume this is a side effect of having if (!v1) support, but perhaps a modification could be made to not perform any negation if there exists a conditional operator?

As far as I can tell the results are correct. The ! prefix negates the values of $identifiers and %variables when used in comparisons - this is by design. It has worked this way ever since it was added in 2001. Is there some reason that you want it changed? I don't think it would be possible to make such a change without breaking existing scripts.

nah, no reason, it just seemed like a peculiar result ;P

By design ! should negate anything that follows it. !(1) for example. It shouldn't limit itself to just identifiers and variables. W/O consistent behavior ppl like myself don't like using this as testing if something is false since it's unpredictable.

Prior to adding the ! negate syntax I used to have an identifier $not which would negate whatever was enclosed. Then you added the bitwise identifier $not and it totally broke my identifier. I changed it too $isnot but your reason that making a change will break existing scripts just isn't going to fly high with me over this. No matter what you do you are going to break something.

No, that is not practical, since !sometext is more likely to be plain text than something that needs to be evaluated. That is why mIRC specifically applies ! only to $identifiers and %variables in the if statement.

And there is a difference between adding a new identifier or feature, which may possibly require some users to change their scripts, and breaking a core aspect of how an if statement works, which will likely break large numbers of scripts for everyone.

In fact, v6.34 was released specifically to address a minor change to the "if" statement that had wide repercussions that were not noticed until after the release of v6.33.

It is important to make sure that basic, core scripting behaviours are consistent and reliable across versions and I make significant effort to make sure that is the case.