this-related changes + new String.normalize overload in core.d.ts and es6.d.ts

[Arnavion]

1. Array, TypedArray, Map and Set methods that are specced to return the this-object now return this instead of explicit type.
2. The callbacks in Array, TypedArray, Map and Set methods that pass the this-object to that callback now pass this instead of explicit type.
3. Added an overload for ES6 String.normalize's that has form parameter as union of the allowed string literals.

tests/cases/compiler/implementArrayInterface started failing until I updated it, since it is now an error to implement array methods with old callback that accepted T[]. Breaking change?

tests/cases/compiler/duplicateOverloadInTypeAugmentation still passed (with just baseline update for the types). But I've changed the overloads it defines from T[] to this anyway.

jake runtests passes.

[mhegazy]

this is going to be a breaking change, and not sure it adds much value here.

[mhegazy]

//CC @RyanCavanaugh, thoughts?

[Arnavion]

You mean just for ReadOnlyArray or all of them?

[mhegazy]

i mean the use of this type in the call back argument type.

[Arnavion]

Yes, I'm asking if it's a problem just for ReadOnlyArray or all the other Array classes as well where I did the same change?

[jods4]

Impact is very low because support for fully subclassing Array is very recent and narrow (stable: only Edge). See Kangax:
http://kangax.github.io/compat-table/es6/#test-Array_is_subclassable_Array.prototype.filter

Only people who subclass Array and override one of those methods with callbacks (find, some, etc.) are impacted.

But in the future you can expect several frameworks to "hack" arrays for their own special purposes... At which point the annotation will become a tiny bit relevant (only a tiny bit because I never see the third parameter used in practice).

I will also say that TS has had breaking changes by way of tightening its type checks or fixing incorrect declarations at several occasions in the past.

I'd say: now is the right time for the change -- otherwise never.

[mhegazy]

sorry for the delay. i meant all of them.

[Arnavion]

(I can update this PR for the es6.d.ts split in master once I get confirmation for mhegazy's comment.)

[mhegazy]

sorry for they delay. if you can update the PR with the new file structure that would be great. thanks!

[Arnavion]

So you don't want the change to make the callbacks have a this parameter right? i.e. you don't want the changes in the second and fourth commits?

[Arnavion]

See #8515

[mhegazy]

thanks!. do we still need this one then after #8515 is merged.

[Arnavion]

No.