Forums Bug Reports math identifiers accept missing parm

From a typo, I stumbled across one of the math identifiers that returns a value in spite of having a missing parm. And from there I found that it's not alone. These are all supposed to have 2 parameters, but when only 1 parm is used they return the parm1 number instead of the 'too few parameters' error:

//echo -a $and(123)
//echo -a $bitoff(123)
//echo -a $biton(123)
//echo -a $isbit(123) returns 0
//echo -a $or(123)
//echo -a $xor(123)
//echo -a $round(123.456)

Thanks for your bug report. That is the intended behaviour. As you have noticed, it is common. There are many identifiers where parameters are optional. If a parameter is not specified, a default value/behaviour is used.

Yes, I agree there are defaults for many identifiers where the default for a not-used parameter makes since, like $sha1() assuming the string is text when the 2nd parm isn't given. But with a uniform return string across these bitwise identifiers, that's making the default setting different. Like $xor and $or defaulting to zero for the missing parm, and $and defaulting to -1 for it.
The 1 thing that can be used for this is - there are some scripts that need to strip text from the end of a number, and they use $abs or $int or $calc to do it. However $abs and $int evaluate $int(1d2stuff) as 100 in scifi notations, while $calc does not. However $calc doesn't strip off the fraction. However $xor(1d2stuff) $xor(1.2345stuff) is stripping off the fraction as well as not interpreting text as scifi notation.

If you come across an identifier that you think should be using a different default value, let me know. However, if the behaviour has been in place for a long time, it normally cannot be changed since that would affect backward compatibility.

This sounds like a different issue to your original post. The way numbers are parsed in commands, identifiers, and other features varies depending on the context and on the API or CRT function call being used. Some of these, for historical reasons, do parse scientific notation, others do not. Some of them will allow floating point values, others will not. And so on. If you think an identifier or feature should behave differently, suggest it. That said, unless there is a really good reason, I will rarely change the way a scripting feature has behaved for decades, as that would break backward compatibility.