Because |WhiteSpace| is defined to include «_any code point in general category “SpaceSeparator”», it is not guaranteed to be stable over time and therefore neither are the behavior of String.prototype.{trim,trimStart,trimEnd} or even parseInt/parseFloat/StringToNumber (e.g., the addition of a code point to general category Space_Separator in some version of the Unicode Standard means that implementations incorporating that version will consider it trimmable whitespace while implementations incorporating an earlier version will not). I think this merits an editorial note at the definition of |WhiteSpace| and at the functions and methods it affects.
Along the same lines, we would ideally also refactor StringToNumber to explicitly trim and then delegate to a lower-level operation shared with parseFloat (which already trims and should have the aforementioned note) and with GetSubstitution/ParseTimeZoneOffsetString/etc. (which don't trim and don't need the note).
### StringToNumber ( _str_ )
It converts _str_ to a Number, ignoring leading and trailing white space and treating the empty String as 0.
1. Let _trimmed_ be ! TrimString(str, START+END).
2. If _trimmed_ is the empty String, return **+0**𝔽.
3. If StringToCodePoints(_trimmed_) satisfies the syntax of a |StrDecimalLiteral|, return DecimalStringToNumber(_trimmed_).
4. Let _nonDecimalLiteral_ be ParseText(_trimmed_, |NonDecimalIntegerLiteral[~Sep]|).
5. If _nonDecimalLiteral_ is a Parse Node, return 𝔽(MV of _nonDecimalLiteral_).
6. Return **NaN**.
### DecimalStringToNumber ( _str_ )
It converts a decimal string to a Number.
1. Let _literal_ be ParseText(_str_, |StrDecimalLiteral|).
2. Assert: _literal_ is a Parse Node.
3. Return StringNumericValue of literal.
Because |WhiteSpace| is defined to include «_any code point in general category “SpaceSeparator”», it is not guaranteed to be stable over time and therefore neither are the behavior of
String.prototype.{trim,trimStart,trimEnd}or evenparseInt/parseFloat/StringToNumber (e.g., the addition of a code point to general category Space_Separator in some version of the Unicode Standard means that implementations incorporating that version will consider it trimmable whitespace while implementations incorporating an earlier version will not). I think this merits an editorial note at the definition of |WhiteSpace| and at the functions and methods it affects.Along the same lines, we would ideally also refactor StringToNumber to explicitly trim and then delegate to a lower-level operation shared with
parseFloat(which already trims and should have the aforementioned note) and with GetSubstitution/ParseTimeZoneOffsetString/etc. (which don't trim and don't need the note).