tc39 / proposal-number-fromstring

{BigInt,Number}.fromString(string, radix)
https://mathiasbynens.github.io/proposal-number-fromstring/
65 stars 7 forks source link

BigInt.fromString: consider accepting trailing 'n' #13

Closed jakobkummerow closed 6 years ago

jakobkummerow commented 6 years ago

For BigInt.fromString, it might make sense to accept BigInt literal syntax with trailing 'n', e.g. BigInt.fromString("123n").

An argument in favor would be to create parity with literals.

An argument against would be that toString does not produce trailing 'n', and fromString is intended to be symmetric to that.

(I don't have a strong opinion either way, just wanted to raise this question for consideration.)

littledan commented 6 years ago

I don't quite understand why there should be parity with literals. This proposal doesn't seem to try to be similar to JS literals in other ways, e.g., omitting the prefixes that indicate base. Generally, I think BigInt.fromString makes sense for values that come from actual application logic, and I don't see why n would crop up there.

mathiasbynens commented 6 years ago

Parity with literals is indeed a non-goal. #15 discusses an exception I’m willing to entertain, which is ASCII case-insensitivity.

jakobkummerow commented 6 years ago

On further thought, another argument against accepting trailing 'n' is that it gets ambiguous/confusing when a radix is specified that's large enough to make 'n' a valid digit (e.g. would BigInt.fromString("1n", 32) parse as 1 or as 55?).

Personally I find this convincing enough: I now think that trailing 'n' should not be allowed. Given the lack of opinions in the other direction so far, I'm closing this issue. Feel free to reopen if you think there should be further discussion.