BigInt shouldn't be considered experimental#28456
Conversation
|
CC @bterlson @RyanCavanaugh @calebsander for thoughts |
|
I would agree that |
|
ok. You need to update baselines and also remove experimentalBigInt from bunch of test cases |
| let bigintNegativeLiteralType: -123n; // should not error when used as type | ||
| const bigintNumber = 123n * 0b1111n + 0o444n * 0x7fn; // each literal should error No newline at end of file | ||
| const bigintNumber = 123n * 0b1111n + 0o444n * 0x7fn; // each literal should error | ||
|
|
There was a problem hiding this comment.
I think you added 2 newlines here, but probably only meant to add 1
| var bigintType; // should not error | ||
| var bigintLiteralType; // should not error when used as type | ||
| var bigintNegativeLiteralType; // should not error when used as type | ||
| var bigintNumber = 123n * 15n + 292n * 0x7fn; // each literal should error |
There was a problem hiding this comment.
Shouldn't these warnExperimentalBigIntLiteral.* baselines be removed?
There was a problem hiding this comment.
You removed warnExperimentalBigIntLiteral.errors.txt but not the .js, the .symbols, and the .types files
3 participants
I know that in #25886 we discussed that we should gate the functionality behind a flag, but we have a degree of confidence that the BigInt proposal is relatively stable.
Additionally, we haven't hidden features like object rest/spread behind a flag, even when that feature had no browser implementations, so it's not clear why we need it here.