Symmetry with `toString` — exceptions?

[mathiasbynens]

Making fromString be symmetric to toString makes sense. How strict do we want to be about this, though?

One special case might be non-[0-9] digits which are ASCII case-insensitive in literals and in parseInt. For example, 0xbeef === 0xBEEF.

However, if we make fromString strictly symmetrical to toString, Number.fromString('BEEF', 16) would throw. Is that what we want?

@domenic @ajklein

[mathiasbynens]

a29f339980abb55d93f50c650294eedf071363d5 makes fromString symmetrical to toString, with the exception that the input string is ASCII case-insensitive, making Number.fromString('BEEF', 16) === Number.fromString('beef', 16). Please take a look and let me know of any issues.

[littledan]

I'm happy with these semantics. Seems appropriate to be case-insensitive and otherwise symmetrical.

[domenic]

I'd weakly prefer case-sensitivity/throwing, at least until I heard what the use case for allowing uppercase is. Given the design of the rest of the function, I'd really expect it to be used for "deserializing" use cases where the output is from toString; I'm not sure where you'd get an uppercased version.

[ajklein]

I don't have a strong argument for @domenic, only intuition that case-insensitivity here "makes sense". @jakobkummerow might have opinions here too.

[mathiasbynens]

I don’t have a very strong argument either, but here’s what I had in mind when I created this issue:

• Number.prototype.toString() is specified as being implementation-dependent and could potentially produce uppercase letters as digits. (I haven’t checked if this actually occurs in practice, though.)

• The parseInt algorithm explicitly calls out both lowercase and uppercase letters from a to z. This is not an argument though, as fromString is intentionally different.

• Speaking of serialization/deserialization, one analogy is JSON.parse(string) which accepts strictly more than what JSON.stringify(value) produces. E.g.

  JSON.parse('"a"') === JSON.parse('"\\u0061"')

[Jamesernator]

If there's no difference in implementations then I'd rather see fromString be strictly limited to lower case sequences (one can trivially call .toLowerCase before passing to fromString) and the spec to specify .toString more precisely.

The reason for this is it might also be desirable to be able to parse Infinity and NaN values in any base without ambiguity, because if case sensitivity is not considered then Number.fromString("Infinity", 36) couldn't be the inverse of Infinity.toString().

[mathiasbynens]

@Jamesernator The way this is phrased in the current spec text enables case-insensitivity while still supporting the Infinity and NaN cases you mention.

[littledan]

@mathiasbynens I don't really understand how the current logic supports things like Infinity. Is this interpreted to be handled by "represents a mathematical number value"?

[mathiasbynens]

Is this interpreted to be handled by "represents a mathematical number value"?

I’d think so. I agree this is too hand-wavey, just like parseInt’s specification: #16

More specifically, the current phrasing specifies that a-z and A-Z are used for digits. Infinity does not contain digits.

[littledan]

I don't understand the resolution of ambiguity. In base 36, aren't all the characters of Infinity digits? I agree with @domenic that more explicit wording would be best here.