Proposals for modifying the spec

This subdirectory is to contain discussion of proposed changes until they are agreed-upon. Once agreed-upon, the body of the proposal can be incorporated into the spec document.

• Proposals that are accepted are marked with a leading .
• Proposals that are accepted but with clarifying questions are marked with a leading .
• Proposals that need revision before further consideration are marked with a leading .

Proposals should eventually be marked .

Once accepted, proposals should be available for public review and edited into the base specification. The public review structure involves splitting the page into a minimal proposal and a linked “discussion” page in the discussion: namespace. The emphasis here is on presenting the state of our consensus clearly, where it exists.

See inactive proposals for proposals which have been retracted, deferred, or made irrelevant.

See clarifications for pages discussing possibly unclear aspects of the existing spec and proposals, or general cross-proposal concerns of the committee.

We need to define various notations used to define the language.

• grammar, the notation used to describe the syntax of the language
• semantics, the way we express the verifier (type system) and evaluator
• built-in objects, the language for describing the core objects
• descriptive prose, the style used for English text

These issues really need to be decided before anything else; if we change our minds on these issues, much if not all of the language needs to be revisited and revalidated.

• type parameters, the proposal to permit unbounded, invariant type parameters
• builtin classes, an attempt to write the ECMA-262 builtin classes using our new language features
• structural types and typing of initializers, the way we handle object and array initializers and union types
• is as to, the question of which type annotations and which type operators are in the language
• nullability, the proposal to discuss when the value null is and isn’t included in a given type
• numbers, how the various numeric types work together
• strict and standard modes, a proposal for phrasing the two “modes” of the language as two translation paths from a single surface syntax with annotations, to a single core language
• normative grammar, a complete surface grammar for ECMAScript Edition 4
• intrinsic namespace, a proposal for a namespace containing intrinsic bindings for types and functions.

These have broad but reasonably orthogonal implications across the language.

• enumerability, the proposal to define enumerability as a single DontEnum bit set by Object.p.propertyIsEnumerable(name, flag)
• switch class, the proposal to permit type unions and safe type switching.
• block expressions, the proposal to add a lexically scoped expression form that is not hoisted and that can serve as a “better var”.
• proper tail calls, the proposal to enforce bounded control behavior for function calls in tail position
• type definitions, syntax and semantics.
• syntax for type expressions, what is it.
• local packages, a lightweight private package form to ease web programming
• namespace shadowing, reference ambiguities are resolved by the block order of use namespace and import pragma
• iterators and generators, the proposal to copy python’s iterator and generator system.
• name objects, which follow from existing for-in iteration semantics combined with namespaces.
• expression closures, a proposal for function syntax where the body is an expression.
• remove the arguments object, a proposal to deprecate and replace arguments by better mechanisms
• resurrected eval, somewhat misnamed, a proposal to reform eval by limiting indirect calls and (in strict mode) binding effects
• arrays, gathering various attempts to make array objects more array-like and therefore useful
• program units, a proposal to allow declaring compilation unit dependencies
• generic functions, a facility for multimethods with type dispatch

These are (possibly) easy to change at the “last minute” without really affecting much else.

• getters and setters, the proposal to specify named get, set, and method initialisers within object initialisers.
• catchalls, the proposal to specify “catchall” get, set, and method-call accessors.
• destructuring assignment, a proposal for syntax to pick apart arrays and structures in assignment and binding forms.
• reformed with, the proposal to extend with statement syntax to support precise object typing and lexical scope.
• decimal, the proposal to add IEEE754r-style decimal floating point to the language.
• typeof, what is the result of typeof when used with some new fundamental types?
• syntax for pragmas, what is it.
• reserved words, a proposal
• update unicode, the proposal to incorporate unicode v4 escapes (and possibly more) as lexemes.
• bug fixes, a proposal to make a few small, “easy” fixes to ECMA-262 Edition 3.
• globals, the proposal for providing access to the global environment as an object.
• triple quotes, the proposal for multiline string literals.
• slice syntax, a proposal to support slice and splice syntax, for both conciseness and early binding optimization
• line terminator normalization, a proposal to interpret CRLF and CR in source text as LF for purposes of multiline strings and regexps, as well as determining line numbers
• versioning, a proposal to detect the supported version of ECMAScript

• meta objects, proposals to extend the language with standardized reflective meta-objects.
• date and time, improvements to the standard Date class.
• String.prototype.trim, new method for stripping whitespace
• JSON encoding and decoding, functions for handling JSON data
• extend regexps, the proposal to add something like perl’s /e and /x qualifiers to regexps.
• hashcodes, the proposal to provide objects with a mechanism for producing integral ids.
• static generics, a proposal to expose Array, Function, and String generic methods via static methods (split from bug fixes)
• dictionary, proposal for a built-in class for value → value maps
• vector, proposal for dense monotyped arrays that aren’t Arrays

Whatever we do, we intend with the right package and other facilities to support a standard library ecology. This may require embedding-specific features (e.g., a way for browsers to avoid reloading the same .js file even though it is hosted at multiple URIs). But Edition 4 should, if possible, help ECMAScript grow a standard library via a community, not through the narrow bandwidth and costly iteration cycle of ECMA TG1.

• stack inspection, the proposal to allow introspection of the runtime stack