"Infinity" is sometimes interpreted as a number in 3.0 where it is interpreted as a string in 2.0

[fsih]

Expected Behavior

Blocks in Scratch 2 and 3 behave the same except for intentional differences

Actual Behavior

The switch to costume block interprets "Infinity" as a number in 3.0, and switches to the first costume. In 2.0 it is always considered a string, and the costume does not switch unless there is a costume named "Infinity"

There are probably other blocks that are affected in a similar way. The root is https://github.com/LLK/scratch-flash/blob/646523e6846ad0dd993213a38b46fe2ea511d026/src/primitives/Primitives.as#L151
Items are only compared as numbers if they contain digits in 2.0. Since Infinity does not, it always gets interpreted as a string, whereas in JS the Number() cast recognizes the string "Infinity" as a number.

Steps to Reproduce

See #1754 (comment) for the original comment and context (@joker314)

1. Load the Scratch Cat sprite, which has two costumes
2. Switch to the second costume (e.g. manually)
3. Drag out a "switch to costume" block
4. Place a "join Infin ity" block as the argument to the "switch costume" block
5. Click on the block

In Scratch 2.0, Infinity is not considered a number (since it contains no digits), and is therefore considered a non-existent costume--remaining at costume 2. However, the current Scratch 3.0 implementation parses this as a number, which causes it to go to the first costume (1).

Operating System and Browser

all

[joker314]

There are probably other blocks that are affected in a similar way.

Maybe, but I don't think so. Anything using the Interpreter.asNumber would be detectable using

git grep Interpreter\.toNumber

The results I got were:

• Looks blocks (costumes and backdrops: hence, 2 matches)
• Operator blocks (comparisons take two inputs: 2 matches)
• Extension manager

The extension manager uses it to parse a response when polling an extension. I don't know exactly how it works, but I don't think it currently has an equivalent in 3.0 yet.

---

Even though this only affects a few blocks, a utility function called strictToNumber would probably be useful, in case we decide to change the behavior in future, or if we want to make performance fixes.

Previously, I was thinking new blocks which need to parse both numbers and strings could use it, but now I'm not so sure: from one perspective, consistency is good; but from the other, not allowing Infinity seems buggy.

---

Our current fix for the comparison blocks is to special-case infinity. Would it be better to use a RegEx/loop to match 2.0 behaviour of literally checking for a digit character? I'm quite sure from reading how numbers are allowed to be composed that only base 10 numbers can contain non-digits, and within those, only whitespace and Infinities can do it; so both the current method and a RegEx would likely have the same effect, and both resolve the compatibility issue.