A few weeks ago in November, we had our last TC39 meeting for the year. At this meeting, Shu-yu Guo preesented a vision for concurrent JavaScript – a goal that Google is working towards in a number of proposals. One of the presentations supported this goal, namely JS Module blocks. This would allow you to create a module block in the following way:
let moduleBlock = module {
export let y = 1;
};
let moduleExports = await import(moduleBlock);
assert(moduleExports.y === 1);
The proposal looked at a number of issues regarding concurrency on the web and how it might be solved. If you are interested in this topic it is worth reviewing.
Another proposal that is worth getting familiar with is the Realms proposal. This will allow users to create their own JavaScript globals and may useful for tooling, or other applications.
This meeting was light on proposals that advanced to stage 3. The item() proposal, which
SpiderMonkey implemented and found to break webcompatibility was renamed to at(). This has already
been updated in our implementation.
Needs minor change:
Keep an eye on…
let moduleBlock = module {
export let y = 1;
};
let moduleExports = await import(moduleBlock);
assert(moduleExports.y === 1);
Normative Spec Changes
Handling of NaN and side effects in Date.prototype.set* methods
- Notes
- PR
- Summary: The date object JavaScript can represent an invalid time and the way that is represented is by having a time value of NaN, however many date operation algorithms do not make sense in the context of NaN. What this PR does is write down a “reasonable approach” largely following what implementations currently do to what is specified by the spec.
- Impact on SM: None
- Outcome: Consensus. Add tests and land.
Handling await in left operands of exponentiation
- Notes
- Slides
- PR
- Summary: At present, the ECMA-262 grammer forbids expressions such as
await 1 ** 2. The PR proposes a naive fix in order to allow await in the UnaryExpression part of the grammar. This is something handled by XS and TypeScript. - Impact on SM: None
- Outcome: Add tests, no consensus on change yet
__proto__ normative optional options
- Notes
- PR
- Summary: Last meeting, we discussed moving
__proto__out of annex B, as non browser implementations such as XS were forced to implement this as well. This continues the work to align implementations around annex B. During this work, it became clear that we need to move__defineGetter__out as well. It is unclear if__defineSetter__also needs to be moved. - Impact on SM: None
- Outcome: Consensus.
__defineGetter__,__defineSetter__,__lookupGetter__,__lookupSetter__should be treated as one “bundle”, meaning, an implementation must implement all or none of them.
Default constructors and spread operations
- Notes
- PR
- Summary: This is best shown via this example.
delete Array.prototype[Symbol.iterator]; new class extends class {} {}Running this code causes the default class constructor to be overriden by using Symbol.iterator. The change is to Stops delegating to Array.prototype[Symbol.iterator] in a default class constructor.
- Impact on SM: Requires an adjustment, but ultimately reduces the hoops we need to jump.
- Outcome: Consensus
Re-resolve unresolvable bindings in PutValue
- Notes
- PR
- Summary: Changes the spec so that it matches browser implementations in this case. Bug has been open for 10 years, with no signal from any of the implementers that they intend to change it. Committee members requested more time to see if there was another solution here.
- Outcome: Deferred
IntegerIndexedElementSet should always indicate success
- Notes
- PR
- Summary: Related to a normative change from last meeting to align ArrayBuffer with web reality.
- Impact on SM: No change,
- Outcome: Consensus
Give %TypedArray% methods explicit algorithms
- Notes
- Slides
- PR
- Summary: Another underspecified area of the specification. In this case, v8 and SpiderMonkey diverge in what they do. Shu has signalled that V8 will change their behavior to align with SpiderMonkey
- Impact on SM: No change,
- Outcome: Consensus
Proposals Seeking Advancement to Stage 4
None!
Proposals Seeking Advancement to Stage 3
JSON modules for Stage 3
- Notes
- Slides
- Proposal Link
- Summary: Introduces importable JSON modules that require the import syntax changes above. Whereas the above proposal is about the syntax, this proposal represents the module loading mechanism. The discussion centered around how developers would expect the import to behave, whether or not they would expect a singleton or a copy, and if they would want that copy to be mutable. There were arguments for both sides.
- Impact on SM: Requires implementation,
- Outcome: Requires further discussion
Stage 3 Updates
Realms
- Notes
- Slides
- Proposal Link
- Summary: Realms exposes a new global without a document for use by JS programmers, think iframes without the document. This is similar to functionality we have in Firefox and use internally. There are some applications, such as tooling, which could benefit from this but there are also concerns. For example, a concern was raised by google about synchronous apis on the web being a bad idea, and that we should rather focus on fixing the asynchronous things we have. This is at the moment unresolved. The work involved here would largely fall on to the DOM side.
- Impact on SM: For SpiderMonkey this is a low work load, but it may be a high work load for other parts of the browser
.item() rename + revisit inclusion on String
- Notes
- Slides
- Proposal Link
- Summary: Discussed in the last meeting. A TC39 proposal to add a .item() method to all the basic indexable classes (Array, TypedArray). This update revisits the inclusion of string, an issue raised by Tom. There will also be a rename to address the webcompat issue. New name is “at”, which was to shown to break web compatibility via the SpiderMonkey implementation.
- Impact on SM: Change already implemented
- Outcome: Stays at stage 3, with strings. Rename to
.at()appears to be a better naming choice.
Import assertions status update
- Notes
- Slides
- Proposal Link
- Summary: The Import Assertions proposal adds an inline syntax for module import statements to pass on more information alongside the module specifier. This updated suggested a new host hook, and further discussion on the cache key invariant.
- Impact on SM:
RegExp Matches Indices JSC Implementation feedback (Slides)
- Notes
- Slides
- Proposal Link
- Summary: Match Indices introduced expanded capabilities to RegExp in JS. This would allow you to still get index of the match, but also the start and end indices for individual capture groups. However, this proposal raise several issues for implementers. JSC highlights the same performance issues raised by V8, and recommends that this feature is reconsidered in it’s current form. Specifically, as a new regexp flag.
- Impact on SM: No change
- Outcome: Change to flag Accepted
Proposals Seeking Advancement to Stage 2
Standardized Debug for Stage 2
- Notes
- Proposal Link
- Summary: Introduces
Debugger.logandDebugger.break, but doesn’t clearly specify how and why these are different thandebuggerandconsole.log - Outcome: Blocked, waiting on clearer rationale.
Error Cause for Stage 2
- Notes
- Slides
- Proposal Link
- Summary: If the error were thrown from deep internal methods, the thrown error may not be straightforward to be easily conducted without proper exception design pattern. Catching an error and re-throwing it with specialized contextual data is a common approach to error handling. This adds a second argument to Error which provides the cause.
- Impact on SM: SpiderMonkey implements multiple arguments for Errors, but they do not appear to be used
- Outcome: Advanced to Stage 2
Stage 2 updates
Intl Enumeration API update
- Notes
- Slides
- Proposal Link
- Summary: List supported values of options in pre-existing ECMA 402 API. We are not yet convinced that there is a general usecase for users. Maintaining it will be disproportionately heavy. On a more meta-level, it is an api that goes in the opposite direction of intl, which is opaque. This is transparent, and allows people to treat the output of intl as non-opaque. On top of that, this one is a prime example of an api that I would love to get a privacy review on this. It is very difficult to get a review on this. This exposes a lot of data entropy. If our privacy people will want to harden or mock something to prevent this from fingerprinting, it will be very hard. The good news is ecma-402 agreed to get a privacy review.
- Impact on SM:
Tour of Temporal
- Notes
- Slides
- Proposal Link
- Summary: Walk through of the proposal, in anticipation of the proposal seeking stage 3 in January next year. The proposal itself introduces a new date/time library.
- Impact on SM:
Proposals Seeking Advancement to Stage 1
Extensions for Stage 1
- Notes
- Slides
- Proposal Link
- Summary: Similar to Bind proposal, it allows you to apply the methods of one object to another. For example:
const ::flatMap = Array.prototype.flatMap
this.querySelectorAll('div')::flatMap(e => // do something);
- Outcome: Advanced to stage 1
JS Module Blocks
- Notes
- Slides
- Proposal Link
- Summary: Introduces “inline modules”. The lack of inline modules in JavaScript has spawned some best practices that are really just workarounds and more often than not have negative performance implications. Sometimes, the lack of inline modules even form a hindrance to the adoption of APIs. This would allow you to create and load modules like this:
let moduleBlock = module {
export let y = 1;
};
let moduleExports = await import(moduleBlock);
assert(moduleExports.y === 1);
- Outcome: Advanced to stage 1
Grouped Accessors and Auto-Accessors
- Notes
- Slides
- Proposal Link
- Summary: Provides a shorthand for
get aandset a. This groups them visually, which may be a benefit for programmers. However, this proposal also results in some changes to how the current decorators proposal would work, raising concerns in the committee and requiring further discussion. - Outcome: Requires further discussion.