Better error message for invalid bigint literals ending with n

[JoshuaKGoldberg]

Search Terms

bigint literal error message identifierstart numeric

Suggestion

@DanielRosenwasser's comment in #28857:

!!! error TS1351: An identifier or keyword cannot immediately follow a numeric literal.
This could be better if you want to send a follow-up PR to see if you have a length of 1 and the identifier is named n.

Use Cases

This seems like a good low-hanging fruit for a more specific error message per type of syntax error.

Examples

The parseBigInt.ts baseline test has the following cases:

• { const legacyOct = 0123n; }
• { const scientific = 1e2n; }
• { const decimal = 4.1n; }
• { const leadingDecimal = .1n; }

How about in order...

• A bigint literal cannot start with a zero.
• A bigint literal cannot be a scientific number.
• A bigint literal cannot be a decimal number
• ☝

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

I can quickly send this in as an addendum to #28857 so they land in the same release.

[DanielRosenwasser]

I think

A bigint literal cannot be a scientific number.

should be

A bigint literal cannot use exponential notation.

and

A bigint literal cannot be a decimal number

should be

A bigint literal must must be an integer.

[fiso]

May I ask why a bigint literal cannot use exponential notation? const foo = 2e50n; seems like it should be perfectly valid to me. What am I missing?

[DanielRosenwasser]

Because they're not specified to support that notation in the ECMAScript spec.