Allow using any-case constants in Expression

[aaronfranke]

This is a general usability improvement for people using the Expression class with user-supplied input, such as the Godot editor inspector. This way, users will not have to capitalize things like pi/2, it will just work. Without this change, users would have to write PI/2, PI / 2, or similar.

This won't break user code unless they were using pi, tau, inf, or nan as variable names, but I doubt that.

EDIT: Updated the PR to support any casing. pi, PI, Pi, pI, true, True, TRUE, etc.

[kiroxas]

What about if (id.nocasecmp_to("pi") == 0) ? Would allow Pi, TaU or iNf as well, not sure if it's desired.

[aaronfranke]

Good idea! Actually, I think an even better option would be to support this for all constants / operators, so Python users will feel at home writing True and such, SQL users will feel at home writing AND/OR/NOT, C# users can write Tau etc, and users won't have to remember the capitalization.

[akien-mga]

I don't really see why Expression should be special cased like this. Its parser is meant to be as close to GDScript as possible, so allowing expressions which aren't supported in GDScript seems weird to me.

[aaronfranke]

Is that a stated goal of Expression? The docs don't explicitly mention that: https://docs.godotengine.org/en/stable/classes/class_expression.html

Expression is used by the Godot editor for user input in Range, in which case inf and -inf and so on should be allowed. Another option would be to fix it only in Range, which would add a step of searching for and replacing several substrings, such as replacing "inf" with "INF" before giving the value to Expression.

[Calinou]

This is likely best implemented at a local level in Range/SpinBox/EditorSpinSlider, as per Prefer local solutions.

I also agree with Akien that Expression should remain as close as possible to GDScript's behavior for ease of learning (and porting code from one to the other).

[aaronfranke]

True, it would be simple for SpinBox and EditorSpinSlider to capitalize the input text before parsing it with Expression.

[aaronfranke]

Re-opening because PR #105330 is infeasible and the problem still needs to be solved.