Originally Posted By: Wims
I'm just talking about scripts, the idea of a poorly written script sending a message to a channel involving a $calc(), resulting in a number with decimals, is real.


This is a misleading statement. Yes, a script may generate decimals with $calc, but only if the script was already generating decimals. Your statement makes it sound like the script would previously never have had decimals in the value. This would never be the case, even for a "poorly written" script.

It's important to understand what this change actually does: it increases precision for existing floating point values. It does not generate floating points for values that were previously only integers.

That's why this is compatible. Because if your script generates floats, you're already getting a certain precision-- this change simply adds more decimal places to an already existing float. It turns 3.131313 to 3.13131313131313 (or so). Scripters would not consider this broken unless they expected "exactly 6 decimals", but this wouldn't be a likely expectation-- in truth, they likely didn't care about the precision in the first place if they weren't using $round.

And again, this doesn't change anything functionally. If your bot all of a sudden prints out a few extra numbers to more accurately describe a value, it wouldn't have an impact on the ability to use the bot. The output might be "uglier", but it still works the same.

You're misrepresenting what "compatibility" means. With your definition, no change to mIRC could ever be made. Quite simply, this change is backwards compatible because all scripts will continue to function correctly (the correct result for the correct input).


- argv[0] on EFnet #mIRC
- "Life is a pointer to an integer without a cast"