Align tonumber with current Luau number syntax

[gaymeowing]

Rendered

[jackdotink]

imo the backwards compatibility loss isnt worth the change here

[alicesaidhi]

what backwards compatibility will be lost here?

[jackdotink]

today, a string passing tonumber means that every character is an ascii digit - this breaks that guarantee

[gaymeowing]

imo the backwards compatibility loss isnt worth the change here

I haven't found any code that this would break, and majority of the cases where I've seen people ensuring a string is valid ASCII uses the string library to do so and not tonumber. Albeit my search wasn't that comprensive, but if its had any significance I would expect it to appear in a github search.
https://github.com/search?q=(language%3ALua+OR+language%3ALuau)+is+ascii+tonumber&type=code

Also I don't think hexadecimal strings are made up of solely digits? As this is valid today:

print(tonumber("0xFFFF")) --> 65535

[jackdotink]

that code is not valid today - you have to pass a second argument to tonumber to make it parse hexadecimal. just because you cant find code that would break doesnt mean that a case this simple doesnt exist somewhere

[jackdotink]

the idea that breaking changes only matter if they affect significant customers is a bad one

[alicesaidhi]

today, a string passing tonumber means that every character is an ascii digit - this breaks that guarantee

this is definitely not true. to number for example supports "nan", "inf", "1e3", "nan(...)", "1.4". ascii digits are only 0-9, and tonumber already supports scientific notation and numbers not normally represented through mere digits.

[jackdotink]

okay sure, its still breaking backwards compatibility without adding significant value - use gsub first if you really want this. as is frequently the case, the solution to your problem is not more language features, but is instead writing more code

[alicesaidhi]

what backwards compat is it breaking?

[alicesaidhi]

tonumber also supports hexadecimal, without specifying base, like lynn posted right now already. aligning it would only make sense.

[gaymeowing]

that code is not valid today - you have to pass a second argument to tonumber to make it parse hexadecimal. just because you cant find code that would break doesnt mean that a case this simple doesnt exist somewhere

what do you mean i ran that with the luau cli

[vegorov-rbx]

It is pretty common in programming languages to have literals in the source code and runtime number parsing differences.

tonumber relies on the underlying host implementation of double number parsing and supports many forms that are not valid as Luau number literals (nan, inf, hex floats, decimal separators if locale is changed from C).
This RFC doesn't achieve alignment.
Since all C99 features have to be supported for backwards compatibility, we will have to reimplement number parsing to preserve all C99 features to add additional forms. Approach taken in the current parser with temporary string construction while filtering '_' will negatively impact runtime performance.
Even if manually implemented, many of the valid C99 strtod/strtoul strings will remain to be invalid literals in Luau.