3 ms·

That hasn't been the case in JS for almost a decade. parseInt('0700') returns 700. But parseInt('0x700') will be parsed as octal, so now it's just a more subtl

That hasn't been the case in JS for almost a decade. parseInt('0700') returns 700. But parseInt('0x700') will be parsed as octal, so now it's just a more subtle gotcha. Loose parsers (such as parseInt(), and Date.parse() in JS) are one of the worst ideas ever. Nothing like tracing a bug, and finding that a junior dev is trying to parse DD/MM/YYYY strings using Date.parse(), except that instead of throwing on trying to parse an incorrect [non-RFC] format, the parser makes a best-guess and propagates an incorrect date because it was parsed as MM/DD/YYYY.

alkonaut 5y ago
Not sure why any api ever had functions like float.parse(s) or date.parse(s). Even more modern ones like .NET (circa 2000) had it. And it's literally never a good idea. Not even for a one off script is it convenient or ergonomic to omit the information about what format you expect (or try to suck it out of thin air such as a static locale on the thread). It's just a bad.idea. If it does accept date parse(s) it has to be with a fixed format (e.g. iso) unless specified. Not "system local format" or something. The same applies to number formatting. I haven't met one single person who prefers automatic string formatting to switch decimal point and decimal comma due to the system language.
- olliej 5y ago
  Why would you not have a parseFloat/float.parse/whatever? Parsing floating point values correctly is not a trivial amount of work - to the extent that there have any been security vulnerabilities in implementations.
  - matsemann 5y ago
    They are not arguing about the stdlib including them, but the api they choose. Instead of parseFloat(str) that tries with a system dependant comma or period, have the decimal type be a parameter or have two explicitly named functions. Same with dates. Don't try lots of formats on an arbitrary string, force the user to specify the expected format somehow.
  - alkonaut 5y ago
    Of course it should be a api but it should be either explicitly requiring a format OR (more likely) default to an invariant format. That is, if I do this float f = 123.456; Console.WriteLine(“value is “+f); The output shouldn’t vary depending on whether it’s run in France or the US (which it does by default). For parsing, the argument should even be explicitly required I think. So float f = Float.Parse(“1,23”, frenchLocale); So that it’s not ever forgotten or the reader has to wonder if the author forgot it.
    - olliej 5y ago
      JavaScript’s numeric parsing is locale independent. People write too much code blindly to make any kind of locale inference anywhere. Otherwise I agree with you whole heartedly - I have been stung by absurd locale dependent behaviour in the past (windows’ font loading APIs inexplicably translate the font variant in the programmatic api)
- toomanybeersies 5y ago
  I wonder how much of that has to do with the fact that ISO8601 was relatively newer back then (published 1988), and date formats were much less standardised 20+ years ago. For instance, RFC 1945 (HTTP 1.0) specifies three acceptable date formats. Add ISO dates, and now you're writing software that needs to handle 4 different formats. Easier to just use a heuristic parser that's capable of accepting HTTP, email, Usenet, and ISO timestamps. Fortunately, these days it's generally considered a bad idea to use anything but ISO timestamps, with the exception of a former colleague who tried arguing that DD/MM/YYYY was an acceptable format to be transmitting and storing dates in.

alkonaut 5y ago

Not sure why any api ever had functions like float.parse(s) or date.parse(s). Even more modern ones like .NET (circa 2000) had it. And it's literally never a good idea. Not even for a one off script is it convenient or ergonomic to omit the information about what format you expect (or try to suck it out of thin air such as a static locale on the thread). It's just a bad.idea. If it does accept date parse(s) it has to be with a fixed format (e.g. iso) unless specified. Not "system local format" or something. The same applies to number formatting. I haven't met one single person who prefers automatic string formatting to switch decimal point and decimal comma due to the system language.

olliej 5y ago
Why would you not have a parseFloat/float.parse/whatever? Parsing floating point values correctly is not a trivial amount of work - to the extent that there have any been security vulnerabilities in implementations.
- matsemann 5y ago
  They are not arguing about the stdlib including them, but the api they choose. Instead of parseFloat(str) that tries with a system dependant comma or period, have the decimal type be a parameter or have two explicitly named functions. Same with dates. Don't try lots of formats on an arbitrary string, force the user to specify the expected format somehow.
- alkonaut 5y ago
  Of course it should be a api but it should be either explicitly requiring a format OR (more likely) default to an invariant format. That is, if I do this float f = 123.456; Console.WriteLine(“value is “+f); The output shouldn’t vary depending on whether it’s run in France or the US (which it does by default). For parsing, the argument should even be explicitly required I think. So float f = Float.Parse(“1,23”, frenchLocale); So that it’s not ever forgotten or the reader has to wonder if the author forgot it.
  - olliej 5y ago
    JavaScript’s numeric parsing is locale independent. People write too much code blindly to make any kind of locale inference anywhere. Otherwise I agree with you whole heartedly - I have been stung by absurd locale dependent behaviour in the past (windows’ font loading APIs inexplicably translate the font variant in the programmatic api)
toomanybeersies 5y ago
I wonder how much of that has to do with the fact that ISO8601 was relatively newer back then (published 1988), and date formats were much less standardised 20+ years ago. For instance, RFC 1945 (HTTP 1.0) specifies three acceptable date formats. Add ISO dates, and now you're writing software that needs to handle 4 different formats. Easier to just use a heuristic parser that's capable of accepting HTTP, email, Usenet, and ISO timestamps. Fortunately, these days it's generally considered a bad idea to use anything but ISO timestamps, with the exception of a former colleague who tried arguing that DD/MM/YYYY was an acceptable format to be transmitting and storing dates in.