String parsing behavior is inconsistent between float() and int() in gdscript

[UserAB1236872]

This probably can't be fixed due to a breakage of incompatibility but I've noticed that the functions int and float behave subtly differently in strange ways:

int("456") # yields 456
int("asdfjaldsgja;lsdgj456") # yields 456
int("dfkj4dkfjj5dkjf6dfkjdk") # yields 456
int("4.56") # yields 4
int("4kgjsdjkfhglskd.b56") # yields 4
int("4.5.6") # yields 4
int("1e3") # yields 13

Essentially, int seems to do a left-right parse ignoring any character except [0-9] and ".". After it hits the first "." it will terminate.

Compare this with float

float("456") # yields 456
float("asdfjaldsgja;lsdgj456") # yields 0
float("dfkj4dkfjj5dkjf6dfkjdk") # yields 0
float("4.56") # yields 4.56
float("4kgjsdjkfhglskd.b56") # yields 4
float("4.5.6") # yields 4.5
float("1e3") # yields 1000

The float parser appears to abort the second it sees a non [0-9] or "." character except e. I expect this is due to the handling of exponentiation. It'll also terminate upon hitting a second decimal point, e, or a "." occurring anywhere after an "e".

You probably shouldn't have arbitrary text in the strings you're trying to convert to numbers anyway, but I think this should at least be documented in case someone hits it. To me, the most dangerous one is the difference between int("1e3") and float("1e3") which is a difference that could theoretically occur even in seemingly well-formed parse strings.

[Avantir-Chaosfire]

The int functions in general lead to really unexpected results - "dfkj4dkfjj5dkjf6dfkjdk" is not a number, so why does it result in 456? It should fail to convert. Now everywhere I need to convert a string to an int, I'm going to have to remember to check if every character is a numeric character before doing the conversion, instead of just doing the conversion and checking the result. Furthermore, this requires me to implement string parsing logic that should already be in the library - I can't even use string.is_valid_integer, because that checks if the string contains an integer, not is a valid integer, making its name just flat out misleading.

[Avantir-Chaosfire]

I think this issue should be re-opened. Clarifying how this works in the documentation is great, but it doesn't solve the issue. The methods should actually be changed to give sensible and consistent results.

[akien-mga]

I think this might have been fixed in 4.0. Can anyone confirm?

[vnen]

The behavior is still the same in 4.0. A bit difficult to change now since it breaks compatibility.