Missing escape/unescape ?

[John0King]

TypeScript Version:

1.8
Code

var a = escape("&#");
var b = unescape(a);

Expected behavior:
no error

Actual behavior:
can not find name 'escape'
can not find name 'unescape'

by the way, typescript playground experience is terrible when use Microsoft Edge (input chinese charactors , click a new line , select code)

[mhegazy]

The global escape and unescape are deprecated, please use encodeURI instead. see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/escape.

If you want to use them, just add the definitions:

declare function escape(s:string): string;

[k8w]

The global escape and unescape are deprecated, please use encodeURI instead. see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/escape

@mhegazy It seems nothing refer to that they are deprecated ?

[kitsonk]

@k8w those pages used to refer to it being deprecated, and it was. It does not appear to be deprecated in the current standard though, and I can't find a specific reference to why the change was made. I suspect they were retained in the specification to not break code, but you shouldn't be using them for new code as they don't handle Unicode URIs properly, and so IMO they are best to leave out and people can add them back in if they are supporting old code.

[mhegazy]

those pages used to refer to it being deprecated, and it was. It does not appear to be deprecated in the current standard though, and I can't find a specific reference to why the change was made.

That is my recollection as well.. good that i am not crazy :)

I checked with @bterlson, and seems that back then there was a proposal to deprecate Annex B (where all previous mistakes have lived), but then that did not happen. i am assuming that why the deprecation notice was added, then removed.

That said, i do not think we should be in the business of policing ppl's use of APIs. the library should be an accurate model of the JS engine at runtime.. reopening.

[RyanCavanaugh]

Reading the Annex B header

This annex describes various legacy features and other characteristics of web browser based ECMAScript implementations. All of the language features and behaviours specified in this annex have one or more undesirable characteristics and in the absence of legacy usage would be removed from this specification. However, the usage of these features by large numbers of existing web pages means that web browsers must continue to support them. The specifications in this annex define the requirements for interoperable implementations of these legacy features.

These features are not considered part of the core ECMAScript language. Programmers should not use or assume the existence of these features and behaviours when writing new ECMAScript code. ECMAScript implementations are discouraged from implementing these features unless the implementation is part of a web browser or is required to run the same legacy ECMAScript code that web browsers encounter.

It really seems like this should not be in lib.d.ts. People are going to find this, use it instead of a working escape function like encodeURIComponent, and be sad because TypeScript offered up a manifestly broken API.

[mhegazy]

That is the intention of Annex B, but node supports it as well as all main browsers.. so it is really a standard..

we can have a @deprecated message on it in a comment.

[bterlson]

A pragmatic viewpoint is better than one informed by the letter of the standard IMO. I came down on the side of supporting escape/unescape in lib.d.ts because in practice these APIs are supported universally across script engines and used heavily across the web and, despite what Annex B hoped, aren't going anywhere afaict. On the other hand, not having these APIs in lib.d.ts is likely to cause friction and may not prevent people from using it, and may not be effective at driving people toward better APIs.

I also note that we have other things from Annex B in lib.d.ts already, including my best friend String.prototype.blink! I feel like encode/decode should be in too unless we really want to stand on the principle that these APIs are just so bad they should not be used. Annex B shouldn't really factor in to this decision.