Bug toNumber

This is not a bug.

It is treating the number as octal since it starts with a leading 0, and failing to parse beyond that. If you try to convert "0xAZ" you get the value 11, which is a correct interpretation of the hexadecimal integer 0xA. So there is consistency (the leading '0' or '0x' is interpreted as the radix specifier).

The documentation uses an example in hex, which confirms the intended behavior.

Travis

Thank for this fast answer.

I understand for 0x8 but for 08....
I prefer the new format 0o as define in Python3 or Perl,

Firstly, It's not on the documentation If a string is in numeric form, either “123” or “0x12AB”, convert it to a Number object with toNumber().
Secondly, It's not practical when we need to parse string.


I use, now, a bypass for this bug.

When parsing a string and you get the number, and strip leading zeros before using toNumber() to avoid this.

Yes, no choice... not elegant...

I understand for 0x8 but for 08....

You understand doing this for hex, but not for octal? If you were parsing an octal input string you would think it a bug if it were interpreted as decimal, no?

Firstly, It's not on the documentation If a string is in numeric form, either “123” or “0x12AB”, convert it to a Number object with toNumber().

Yes, it is just an example, not an exhaustive list of all parsed formats.

The problem is that the function is behaving exactly as it is supposed to, so it isn't a bug.

If you are asking for an enhancement, to parse an integer with a radix of 10, or some user specified radix, I'm sure that would be more well received than proposing that the function is broken. Especially when making the change you are proposing would break existing code that works correctly.

Travis

Thank Travis,

I understand and I agree with you about the non regression.

It's just a pity to keep vetuste behavior in a new language.

But I understand and I do with.

Thank again

I'm all for adding the ability to specify the radix when converting, I think it is a reasonable thing to ask for.

I'm for adding an exception and complet the documentation with all number formats.

Hey guys, in the first releases of CIQ, the conversion used under the hood for this, was not interpreting leading 0's as an octal prefix, but I believe it also did not work for hexadecimal numbers. The method was modified to use a less costly method, and inadvertently changed to support octal numbers along with hex. I think the AlphaMonkey is in favor of changing this back to the original functionality, and we may add an additional conversion operation that allows specifying the radix.

In any case, we want to update our documentation to properly reflect the functionality.