Forums Bug Reports $iif() bug or?

Today i've updated to 7.83 and my whole script that works perfect on older version now is broken..

Having this example:


When i perform /test gives the error:


Also,


gives:


I have to change many lines of code to change $iif() to if (%a == 1) %b = 2 | else %b = 3

if a bug or what?

P.S. Having:


works fine!

Hello, you already reported this issue in 2022 :
https://forums.mirc.com/ubbthreads.php/ubb/showflat/Number/270845/

Edit : As I mentioned in the above thread:

From an objective point of view, it doesn't seem like the fixes of the issues related to variable evaluation mentioned in the above thread should result in this new behavior (i.e $iif(1,% $+ test = 1) not assigning when executed as a command, but also $(%a = 1) no longer evaluating to 'set %a 1') aka I would like a clarification that this bit was also intentionally changed at that time with now '%var = value' assignment executed as a command only working when appearing plain text from the 'root' line, and no longer working if it results from an identifier evaluation

Huh.. I forgot about this.. i'm too old now :)) Thank you very much. So i reverted back to my old stable version.. i don't wanna loose my time to change more than 100 thousands lines of codes. In the end I didn't understand why Khaled made this change in $iif() where it affected many scripts, but it didn't bring anything good.

Take a look at this example, which you can execute in any mIRC's editbox:

//var %a 5 | echo -ag $+(test,%a)

This will echo, as expected, even by you, "test5".
This is because it is expected that under normal circumstances, all the parameters of an identifier are evaluaed once before that function is executed, so $+() will evaluated the first parameter to "test" and will evaluate the second parameter %a to 5, and the concatenation of the two results in "test5".

$iif() is not different from $+() or any other $identifier() taking parameters, the parameter passed to $iif are evaluated before the function itself does something with the parameters.
So when you do $iif(%a == 1,%b = 2,%b = 3) %a %b and %c are all evaluated because they appear space separated in their parameter. And only after they have been evaluated, $iif will check if the condition is true.
You may think that if the condition is false, evaluating the true part (the second parameter) of $iif is useless since that value won't be used, and you would be right, but then that's about how $iif was implemented in the first place, and it's important that it works the way it's documented: as a normal identifier.
The documentation is not so clear about this but it's a main rule of the scripting language that identifiers evaluate their parameter once and in order.
Some identifier like $regsubex don't follow this rule and are exceptions, but they are not documented as being exceptions because it's a technicality that most scripters don't need to know/understand to use the identifier.

It may not seem like it but fixing this issue brought a lot of good to the language, it made parsing faster, it made the source code cleaner. As a matter of fact the $iif identifier is internally coded by calling the /if conditional construct instead of being a copy of it, that makes the $iif identifier super slow.
Your original code:
%a = 1 | %b = 2 | $iif(%a == 1,%b = 2,%b = 3)
is much much better written by keeping $iif as
%a = 1 | %b = $iif(%a == 1,2,3)
and without $iif as
%a = 1 | %b = 3 | if (%a == 1) %b = 2
or with an else to avoid the extra assignment
%a = 1 | if (%a == 1) %b = 2 | else %b = 3

Thank you very much for your time and help. Of course, i know how to change to work, but the problem (as i said) i have thousands of lines of these codes with $iif() that where made a long time ago and works perfectly. So, i need a long time to change them if i want to update to the newer version and i consider remaining at my current version. I understand that Khaled did the right thing by changing these things, but unfortunately, he didn't think that this would break existing scripts that contain these script types. And although there are few people who script in mirc these days, but I'm still a fan of it, I don't really want to waste my time changing everything because someone chose that the correct syntax should be like this (which I think the given option didn't improve scripting at all) instead of maybe creating something new. And now I'm afraid that in the future someone will suggest something again, and the author will change the option without considering that it might break existing scripts.

Your reaction is typical and is unfortunate.
Khaled has been careful and tried very hard, over the years, not to break backward compatibilities, quite successfuly in fact.
But doing so come with a very high price of preventing the scripting language from evolving correctly for people who wanted to see it evolve. Almost any of the backward compatible change are about preserving 'incorrect' (scripters knew what they were doing is incorrect but kept doing it instead of reporting it as a bug) behavior just to prevent older scripts from breaking. Which means adding layer of layer of unecessary code to keep the support for weird stuff (exactly like this one). Which ultimately means a lot of useless bloat in the code, meaning that 1000 if statements are checked for various thing instead of 1. This makes the language slower, and impossible to maintain/evolve and I've been fighting hard against Khaled to force him to break these compatiblities for the language to be faster and possible to enhance. While the language doesn't need to be enhanced much structurally speaking, having thousand of lines to change/maintain instead of 500 ultimately makes Khaled warry of doing changes which sounds easy on the surface.

In this case, one might be using something like this:

if (%prefix == !) var %com msg $chan
else var %com msg $nick
$iif(%somevar,%com = param1,%com = param2)

and expecting the command 'msg $chan = param1' to be executed if %prefix equals ! and if %somevar is *set*, which is ENTIRELY how mirc scripting works, there's no debate about this, but it's not hard either to understand while someone less experienced with the language would want %com = in that $iif to be seen as a variable assignment because that would be starting the line and starting a line with such fomat DOES a variable assigment. For that I blame the help file for not explaining how mirc scripting is supposed to work as a whole, but the language is meant to be simple and easy to access so the help file is always too simple on purpose.

So rest assured that Khaled is extremely considering whether or not to break compatiblities (aka to break scripts or not) and almost always goes against breaking them, but this case is just reaching a limit where the behavior goes against a fundamental rule of the scripting language.

Let me finish on this note, yes it's great that 20 yo scripts are still working without a change, but does that compare to having no new script written in general nowadays because of what I've explained above?