Skip to content

Conversation

@gaymeowing
Copy link
Contributor

@jackdotink
Copy link
Contributor

imo the backwards compatibility loss isnt worth the change here

@alicesaidhi
Copy link
Contributor

what backwards compatibility will be lost here?

@jackdotink
Copy link
Contributor

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

@gaymeowing
Copy link
Contributor Author

gaymeowing commented Dec 25, 2025

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
Copy link
Contributor

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
Copy link
Contributor

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

@alicesaidhi
Copy link
Contributor

alicesaidhi commented Dec 25, 2025

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
Copy link
Contributor

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
Copy link
Contributor

what backwards compat is it breaking?

@alicesaidhi
Copy link
Contributor

alicesaidhi commented Dec 26, 2025

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

@gaymeowing
Copy link
Contributor Author

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

makes the motivation section focus more so on `tonumber`'s current odd behavior
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants