Annex F (informative) 이전 Edition과의 비호환성을 도입하는 추가 및 변경
6.2.5: ECMAScript 2015에서 Function call은 Reference Record를 반환할 수 없다.
7.1.4.1: ECMAScript 2015에서 String 값에 적용되는 ToNumber는 이제 BinaryIntegerLiteral 및 OctalIntegerLiteral numeric string을 인식하고 변환한다. 이전 edition에서는 그러한 string이 NaN으로 변환되었다.
9.3: ECMAScript 2018에서 Template object는 이전 edition에서처럼 Realm 안의 해당 template literal 또는 tagged template의 모든 occurrence 전체가 아니라 Parse Node(source location)에 기반하여 canonicalize된다.
12.2: ECMAScript 2016에서는 Unicode 8.0.0 이상이 요구되며, 이는 Unicode 5.1을 요구했던 ECMAScript 2015와 다르다. 특히 이로 인해 U+180E MONGOLIAN VOWEL SEPARATOR가 ECMAScript 2015에서는 Space_Separator(Zs) category에 있어 whitespace로 취급되었지만, Unicode 6.3.0부터 Format(Cf) category로 이동했다. 이는 whitespace-sensitive 메서드가 다르게 동작하게 한다. 예를 들어 "\u180E".trim().length는 이전 edition에서는 0이었지만 ECMAScript 2016 및 이후에서는 1이다. 추가로, ECMAScript 2017은 항상 최신 버전의 Unicode Standard를 사용하도록 요구했다.
12.7: ECMAScript 2015에서 IdentifierName의 valid code point는 Unicode 프로퍼티 “ID_Start” 및 “ID_Continue”의 관점에서 지정된다. 이전 edition에서는 valid IdentifierName 또는 Identifier code point가 여러 Unicode code point category를 열거하여 지정되었다.
12.10.1: ECMAScript 2015에서 Automatic Semicolon Insertion은 semicolon이 누락된 경우 do-while statement의 끝에 semicolon을 추가한다. 이 변경은 명세를 대부분의 기존 구현의 실제 동작과 일치시킨다.
13.2.5.1: ECMAScript 2015에서 Object Initializer 안에 duplicate property name이 있어도 더 이상 early error가 아니다.
13.15.1: ECMAScript 2015에서 FunctionExpression의 function name과 같은 immutable binding에 대한 assignment를 포함하는 strict mode code는 early error를 생성하지 않는다. 대신 runtime error를 생성한다.
14.2: ECMAScript 2015에서 token let으로 시작하고 그 뒤에 input element LineTerminator, 그 다음 Identifier가 오는 StatementList는 LexicalDeclaration의 시작이다. 이전 edition에서는 automatic semicolon insertion이 항상 Identifier input element 앞에 semicolon을 삽입했다.
14.5: ECMAScript 2015에서 token let으로 시작하고 그 뒤에 token [가 오는 StatementListItem은 LexicalDeclaration의 시작이다. 이전 edition에서 그러한 sequence는 ExpressionStatement의 시작이었다.
14.6.2: ECMAScript 2015에서 IfStatement의 normal result는 결코 값 empty가 아니다. Statement 부분이 평가되지 않거나 평가된 Statement 부분이 empty를 포함하는 normal completion을 생성하면, IfStatement의 결과는 undefined이다.
14.7: ECMAScript 2015에서 for statement의 ( token 바로 뒤에 token sequence let [가 오면 let은 LexicalDeclaration의 시작으로 취급된다. 이전 edition에서 그러한 token sequence는 Expression의 시작이었다.
14.7: ECMAScript 2015에서 for-in statement의 ( token 바로 뒤에 token sequence let [가 오면 let은 ForDeclaration의 시작으로 취급된다. 이전 edition에서 그러한 token sequence는 LeftHandSideExpression의 시작이었다.
14.7: ECMAScript 2015 이전에는 in keyword 앞에 오는 VariableDeclaration의 일부로 initialization expression이 나타날 수 있었다. ECMAScript 2015에서는 같은 위치의 ForBinding이 그러한 initializer의 occurrence를 허용하지 않는다. ECMAScript 2017에서는 그러한 initializer가 non-strict code에서만 허용된다.
14.7: ECMAScript 2015에서 IterationStatement를 평가한 결과는 [[Value]]가 empty인 normal completion이 결코 아니다. IterationStatement의 Statement 부분이 평가되지 않거나 Statement 부분의 최종 평가가 [[Value]]가 empty인 normal completion을 생성하면, IterationStatement 평가 결과는 [[Value]]가 undefined인 normal completion이다.
14.11.2: ECMAScript 2015에서 WithStatement를 평가한 결과는 [[Value]]가 empty인 normal completion이 결코 아니다. WithStatement의 Statement 부분 평가가 [[Value]]가 empty인 normal completion을 생성하면, WithStatement 평가 결과는 [[Value]]가 undefined인 normal completion이다.
14.12.4: ECMAScript 2015에서 SwitchStatement를 평가한 결과는 [[Value]]가 empty인 normal completion이 결코 아니다. SwitchStatement의 CaseBlock 부분 평가가 [[Value]]가 empty인 normal completion을 생성하면, SwitchStatement 평가 결과는 [[Value]]가 undefined인 normal completion이다.
14.15: ECMAScript 2015에서 Catch clause가 Catch clause parameter로 나타나는 같은 Identifier에 대한 var declaration을 포함하는 것은 early error이다. 이전 edition에서 그러한 variable declaration은 둘러싸는 variable environment 안에 instantiate되었지만 declaration의 Initializer 값은 Catch parameter에 할당되었다.
14.15, 19.2.1.3: ECMAScript 2015에서 Catch clause가 eval code에 Catch clause parameter로 나타나는 같은 Identifier를 bind하는 var 또는 FunctionDeclaration declaration을 포함하는 non-strict direct eval을 평가하면 runtime SyntaxError가 던져진다.
14.15.3: ECMAScript 2015에서 TryStatement의 결과는 결코 값 empty가 아니다. TryStatement의 Block 부분이 empty를 포함하는 normal completion으로 평가되면, TryStatement의 결과는 undefined이다. TryStatement의 Block 부분이 throw completion으로 평가되고, 그 Catch 부분이 empty를 포함하는 normal completion으로 평가되면, Finally clause가 없거나 그 Finally clause가 empty normal completion으로 평가되는 경우 TryStatement의 결과는 undefined이다.
15.4.5 ECMAScript 2015에서 ObjectLiteral 안의 accessor property의 [[Get]] 또는 [[Set]] attribute 값으로 생성되는 function object는 constructor function이 아니며 "prototype" own property를 가지지 않는다. 이전 edition에서는 이들이 constructor였고 "prototype" property를 가졌다.
20.1.2.6: ECMAScript 2015에서 Object.freeze의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.8: ECMAScript 2015에서 Object.getOwnPropertyDescriptor의 인자가 object가 아니면 ToObject를 사용하여 인자를 강제 변환하려는 시도가 이루어진다. 강제 변환이 성공하면 그 결과가 원래 인자 값 대신 사용된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.10: ECMAScript 2015에서 Object.getOwnPropertyNames의 인자가 object가 아니면 ToObject를 사용하여 인자를 강제 변환하려는 시도가 이루어진다. 강제 변환이 성공하면 그 결과가 원래 인자 값 대신 사용된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.12: ECMAScript 2015에서 Object.getPrototypeOf의 인자가 object가 아니면 ToObject를 사용하여 인자를 강제 변환하려는 시도가 이루어진다. 강제 변환이 성공하면 그 결과가 원래 인자 값 대신 사용된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.16: ECMAScript 2015에서 Object.isExtensible의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.17: ECMAScript 2015에서 Object.isFrozen의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.18: ECMAScript 2015에서 Object.isSealed의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.19: ECMAScript 2015에서 Object.keys의 인자가 object가 아니면 ToObject를 사용하여 인자를 강제 변환하려는 시도가 이루어진다. 강제 변환이 성공하면 그 결과가 원래 인자 값 대신 사용된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.20: ECMAScript 2015에서 Object.preventExtensions의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.1.2.22: ECMAScript 2015에서 Object.seal의 인자가 object가 아니면 own property가 없는 non-extensible ordinary object였던 것처럼 취급된다. 이전 edition에서는 non-object 인자가 항상 TypeError를 던지게 했다.
20.2.3.2: ECMAScript 2015에서 bound function의 [[Prototype]] 내부 슬롯은 target function의 [[GetPrototypeOf]] 값으로 설정된다. 이전 edition에서는 [[Prototype]]이 항상 %Function.prototype%로 설정되었다.
20.2.4.1: ECMAScript 2015에서 function instance의 "length" property는 configurable이다. 이전 edition에서는 non-configurable이었다.
20.5.6.2: ECMAScript 2015에서 NativeError constructor의 [[Prototype]] 내부 슬롯은 Error constructor이다. 이전 edition에서는 Function prototype object였다.
21.4.4 ECMAScript 2015에서 Date prototype object는 Date instance가 아니다. 이전 edition에서는 TimeValue가 NaN인 Date instance였다.
22.1.3.12 ECMAScript 2015에서 String.prototype.localeCompare 함수는 Unicode Standard에 따라 canonically equivalent인 String을 동일한 것으로 취급해야 한다. 이전 edition에서 구현은 canonical equivalence를 무시하고 대신 bit-wise comparison을 사용할 수 있었다.
22.1.3.28 및 22.1.3.30 ECMAScript 2015에서 lowercase/uppercase 변환 처리는 code point에 대해 작동한다. 이전 edition에서 그러한 변환 처리는 개별 code unit에만 적용되었다. 영향을 받는 유일한 code point는 Unicode의 Deseret block에 있는 것들이다.
22.1.3.32 ECMAScript 2015에서 String.prototype.trim 메서드는 Unicode BMP 밖에 존재할 수 있는 white space code point를 인식하도록 정의된다. 그러나 Unicode 7 기준으로 그러한 code point는 정의되어 있지 않다. 이전 edition에서는 그러한 code point가 white space로 인식되지 않았을 것이다.
22.2.4.1 ECMAScript 2015에서 pattern 인자가 RegExp instance이고 flags 인자가 undefined가 아니면, pattern과 같지만 pattern의 flag가 인자 flags로 대체된 새 RegExp instance가 생성된다. 이전 edition에서는 pattern이 RegExp instance이고 flags가 undefined가 아니면 TypeError 예외가 던져졌다.
22.2.6 ECMAScript 2015에서 RegExp prototype object는 RegExp instance가 아니다. 이전 edition에서는 pattern이 empty String인 RegExp instance였다.
22.2.6 ECMAScript 2015에서 "source", "global", "ignoreCase", 및 "multiline"은 RegExp prototype object에 정의된 accessor property이다. 이전 edition에서는 RegExp instance에 정의된 data property였다.
25.4.15: ECMAScript 2019에서 Atomics.wake는 Atomics.wait와의 혼동을 방지하기 위해 Atomics.notify로 이름이 변경되었다.
27.1.5.4, 27.6.3.6: ECMAScript 2019에서 await에 의해 enqueue되는 Job의 수가 줄어들었고, 이는 then() 호출과 await expression 사이의 resolution order에 관찰 가능한 차이를 만들 수 있었다.