Expectations around line ending behavior for U+2028 and U+2029

Waldemar Horwat waldemar at google.com
Thu Oct 25 22:10:55 UTC 2018

On 10/25/2018 09:24 AM, Logan Smyth wrote:
> Yeah, /LineTerminatorSequence/ is definitely the canonical definition of line numbers in JS at the moment. As we explore https://github.com/tc39/proposal-error-stacks, it would be good to clearly specify how a line number is computed from the original source. As currently specified, a line number in a stack trace takes U+2028/29 into account, and thus requires any consumer of this source code and line number value needs to have a special case for JS code. It seems unrealistic to expect every piece of tooling that works with source code would have a special case for JS code to take these 2 characters into account. Given that, the choices are
> 1. Every tool that manipulates source code needs to know what type so it can special-case JS it is in order to process line-related information
> 2. Every tool should consider U+2028/29 newlines, causing line numbers to be off in other programming languages
> 2. Accept that tooling and the spec will never correspond and the use of these two characters in source code will continue to cause issues
> 3. Diverge the definition of current source-code line from the current /LineTerminatorSequence/ lexical grammar such that source line number is always /\r?\n/, which is what the user is realistically going to see in their editor

The Unicode standard is the more relevant one here.  Choice 2 is the correct one per the Unicode standard.  Tools that do not consider U+2028/29 to be line breaks are not behaving as they should according to the latest Unicode standard.


More information about the es-discuss mailing list