Compatibility mode

[Henrik "The Developer" Lindqvist]

The new bigint value type isn't fully integrated yet since doing so would break existing flows, as they could get a bigint without being made to handle it. Automate needs a way to overcome such problems and fix some old bugs. A way to do so is by implementing a "compatibility mode" where existing flows can continue running with old behaviors without breaking, while new and properly updated flows use new behaviors.

This "compatibility mode" will be an option in the editor that the user can toggle once they've updated an existing flow to work with new behaviors, a warning will also be shown so other users are aware of a flow that's not. This warning may be annoying, so these kind of changes should be done sparingly. Therefor i want you to report any such breaking change you wish to see, so i can include them all in an upcoming update.

Proposed compatibility changes:

bigint

Only used as output from Content query and Database query blocks. It should be used as output for every 64-bit integer (Long) value, e.g. in Extras output variables, and every other external sources.

equal = operator

It compare arrays and dictionaries by reference, i.e. if they're the same instance. It should compared by value, i.e. if they have equal elements / entries. All current, by reference equal, operator = usage will be replaced with a new "identical" operator ==, and the = operator will do value equal instead. This change could be done without breaking compatibility but the Atomic Compare & store block should compare by value which could not.

negative zero -0

It's not equal to 0. It probably should be, like in JavaScript.

divide / operator

It returns Infinity for 0/0. It, and // operator, should probably return NaN like in JavaScript

concatenation ++ operator

It returns "null" for null++null. It should probably return "nullnull" or null instead?

subscript [index] operator

It return the first element when a negative index is out of range, i.e. [1,2][-9] = 1. It should return null.

bitwise operators

Operands are simply cast to signed 32-bit integers clamping them to an integer value between -2³¹ and 2³¹-1. They should probably be using (the lower) 32 bits of the (truncated) mantissa instead, like in JavaScript.

round function

It's buggy since it only round to integers between -2⁶³ and 2⁶³-1, a signed 64-bit (Long) value, it should round to an integer of any magnitude.

trunc function

If its parameter is Infinity or -Infinity it returns NaN. It should probably return the argument as is like in JavaScript.

ctz function

It returns 32 if a number has no one-bit, i.e. it's 0. This doesn't work with bigint since those can actually have a 32:nd one-bit. To be consistent it should probably return -1 instead?

Fork block

Only outputs child fiber URI in parent, and parent fiber URI in child. It should output both in both. That's no longer necessary with the new runtime function.

Anything else?!

Please let me know. All feedback welcome.