Every year, a new version of ECMAScript is released with the proposals which are officially ready. This means, that the proposals which have been accepted and reached stage 4 by the TC39 committee would be included in the specification of that year (assuming it hasn’t been published), and the others - are postponed to the next year.
So, here we go - the approved proposals for 2019, as of today.
Note: In case you haven’t tasted the features of 2018 yet - go over it here.
Just to clarify, these are the proposals that have been reached stage 4.
Optional Catch Binding
Until this proposal, the specification forced us to bind an exception variable for the
catch clause whether it’s necessary or not:
Sometimes, as we see above, the exception variable that’s bound to the
catch clause is absolutely redundant.
The proposal enables us to simply omit the variable including the parenthesis in such cases:
According to ECMAScript specification, an ECMAScript JSON is a superset of JSON, by all means:
After parsing, JSON objects are realized as ECMAScript objects. JSON arrays are realized as ECMAScript Array instances. JSON strings, numbers, booleans, and null are realized as ECMAScript strings, Numbers, Booleans, and null (source).
But in practice, that’s not entirely true. Whereas JSON strings accepts unescaped
U+2029 characters, ECMAScript strings don’t accept:
U+2028 represents LINE SEPARATOR and
U+2029 represents PARAGRAPH SEPARATOR.
In simple words, this means there’s an inconsistency between valid JSON String and valid ECMAScript String, which could lead to potential bugs and specific handling in order to patch these gaps.
The proposed solution extends the ECMAScript strings so these will accept
Symbol Description Accessor
During the creation of a
Symbol, it’s possible to specify a description which could be used later for debugging. In case we want to access the specified description, for instance, to reconstruct the symbol or just to log it - we’ve to extract it indirectly out of the
toString value. 😕
The proposed solution adds a new read-only property, called
description, which returns the optional description of a
Function “toString” Revision
As we know, the
toString method of a
Function object doesn’t inherit directly from
Object.prototype.toString, but overrides it.
In ES2015, when
toString was invoked on a function - one of the following occurred:
- It returned a string source code representation of the function, depending on the ECMAScript engine.
- In case the engine couldn’t produce a valid source code string - it returned an
evalstring that would throw a
The proposed solution distinguishes between the following cases in order to determine the result of
- In case that’s a user-defined function object, which means, part of the source code - it returns a string containing the code which was used to define the function.
- In case that’s a built-in function object or bound function object (a function which is created by
bindmethod) - it returns a
- In case that’s a callable function object which isn’t user-defined - it returns a
- In case that’s a dynamically generated function object, through the
GeneratorFunctionconstructors - it returns a synthesized string of the appropriate code, which is created by the ECMAScript engine.
- In all other cases, it throws a
Let’s demonstrate each case:
These are the proposals that have been reached stage 3 and probably will be included in the specification - right after these will be approved completely.
Here’s attached a list for the proposals in this stage:
- Private instance methods and accessors
- Class Public Instance Fields & Private Instance Fields
- Static class fields and private static methods
- Well-formed JSON.stringify
- Hashbang Grammar
We covered today all the proposed which have been approved, at present, and will be included as part of the ECMAScript 2019 specification.
Take a look at the examples:
The sample project is available here.