Closed jakobkummerow closed 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.
Parity with literals is indeed a non-goal. #15 discusses an exception I’m willing to entertain, which is ASCII case-insensitivity.
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.
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', andfromString
is intended to be symmetric to that.(I don't have a strong opinion either way, just wanted to raise this question for consideration.)