SpiderMonkey Small SpiderMonkey Logo
SpiderMonkey Large SpiderMonkey Logo piderMonkey

TC39 meeting, September 21-24 2020

•

In the September 2020 TC39 meeting, a few smaller proposals moved into the mature stages. Display names (implemented in 78 by André Bargul) moved to stage 4 in this meeting. Import Assertions moved to stage 3, as did .item.

The .item proposal provides an ergonomic method for accessing array elements positionally, allowing one to get the last item via -1. We have an implementation for this proposal (implemented by Tom Schuster), but it has been backed out due to web compatibility concerns for both strings and array.

A new ArrayBuffer proposal which introduces ResizableArrayBuffer and GrowableSharedArrayBuffer is currently being discussed at committee and advanced to stage 2.

A new Decorators proposal was also presented, with a new design. The new design looks quite good, and we are optimistic about it.

Need Review:

Needs implementation:

  • Import Assertions - May not make sense to do right away, as the initial use case, JSON modules, is still being discussed

Needs minor change:

Keep an eye on…

Normative Spec Changes

Set function name and length in CreateBuiltinFunction

  • Notes
  • PR Link
  • Summary: Name and length were defined in prose, this moves them to be explicitly defined in the steps, and ascribes an order to them.
  • Impact on SM: We need to update our implementation, in spite of the evidence found by the autors, as we do not ensure this.
  • Outcome: Consensus

Align detached buffer semantics with web reality

  • Notes
  • PR Link
  • Summary: Attempts to align detached arraybuffer behavior across browsers and align the spec to web reality.
  • Impact on SM: There will be some changes, notably in the configurability of GetOwnProperty.
  • Outcome: Consensus

Move proto out of annex b

  • Notes
  • PR Link
  • Summary: See title: will make proto normative optional.
  • Impact on SM: None,
  • Outcome: Consensus

Explicitly specify order of operations in MakeTime

  • Notes
  • PR Link
  • Summary: MakeTime is underspecified, it does not specify in which order to perform the additions. This is observable when using IEEE double-precision floats.
  • Impact on SM: Proposed change aligns with SpiderMonkey’s behavior.
  • Outcome: Consensus

Arbitrary module namespace identifier names

  • Notes
  • PR Link
  • Summary: See title. Usecase is for allowing WASM names that may not conform to JS identifier names.
  • Impact on SM: Requires implementation.
  • Outcome: Will be changed to isValidUTF-8, with no unpaired surrogates, unclear outcome.

Proposals Seeking Advancement to Stage 4

Intl.DisplayNames

  • Notes
  • Slides
  • Proposal Link
  • Summary: API to get localized names of language, script or region.
  • Impact on SM: None, already implemented in 78.
  • Outcome: Advanced to stage 4.

Proposals Seeking Advancement to Stage 3

.item()

  • Notes
  • Slides
  • Proposal Link
  • Summary: A TC39 proposal to add a .item() method to all the basic indexable classes (Array, String, TypedArray). It allows negative positioning like -1. We had some concerns about this feature in relation to strings, however they were non-blocking.
  • Impact on SM: Implementation in progress. Currently there are with webcompat, and it has been backed out. See bug for more details.
  • Outcome: Advanced on stage 3.

Import Assertions

  • 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. For example, if you want to import a JSON module as JSON, this proposal would allow you to do this.
  • Impact on SM: Requires implementing assertions regarding the document type that is being loaded by the module loader. This takes the form of replace the moduleSpecifier string with a moduleRequest object. Not a major change.
  • Outcome: Advanced to stage 3.

Ergonomic brand checks for private fields

  • Notes
  • Notes p2
  • Slides (unlinked)
  • Proposal Link
  • Summary: Support proper ergonomic brand checks for classes. This proposal aims at improving the integrity of code and ensuring you can trust that an object is what an object says it is. This was blocked from advancing in last meeting due to syntax overloading. It has been blocked again, roughly for reification, syntax overloading of the in operator (though no counter proposal) and process issues which did not have time to be discussed.
  • Impact on SM: No consensus on stage 3, but we have an experimental impelementation ongoing,
  • Outcome: No Consensus on stage 3. To be worked on for the November meeting.

Proposals Seeking Advancement to Stage 2

Class static initialization block

  • Notes
  • Slides
  • Proposal Link
  • Summary: Class static blocks provide a mechanism to perform additional static initialization during class definition evaluation. In addition to making it easier to evaluate statements during initialization, it also provides an opportunity to evaluate statements in the context of the current class declaration, with privileged access to private state (be they instance-private or static-private).
  • Impact on SM: Will require implementation at stage 3,
  • Outcome: Advanced to stage 2.

Resizable and growable ArrayBuffers

  • Notes
  • Slides
  • Proposal Link
  • Summary: Introduces two new arrayBuffers. They must be implemented separately from our current array buffer implementation. The two new buffers are around resizing. The shareable array buffer can only grow, while the other can be resized. The implementation closely follows the webassembly implementation for GrowableSharedArrayBuffers. We have a concern that this might slow down TypedArrays due to the extra bounds check when a ResizableArrayBuffer becomes detatched. This is not a concern with GroableArrayBuffers as they cannot be detatched. This may not be a significant concern as we are considering changing this anyway.
  • Impact on SM: Would require potentially significant changes.
  • Outcome: Advanced to stage 2. We have volunteered as reviewers.

Builtin Modules

  • Notes
  • Slides
  • Proposal Link
  • Summary: Introduces builtin modules as a mechanism for a standard library in javascript. This would provide a way to implement proposals such as Temporal, rather than attaching them to the global object. However this would also mean splitting the global namespace in a somewhat arbitrary way from the perspective of the developer. Currently, both Google and Mozilla have raised a concern about this and are unwilling to implement it.
  • Impact on SM: None, did not advance
  • Outcome: Did not advance.

Class Access Expressions

  • Notes
  • Slides
  • Proposal Link
  • Summary: There is no easy mechanism to access class statics in a class that has no name (for example, when you export default in a module or have a factory class). Class access expressions seek to simplify access to static members of a class as well as provide access to static members of a class when that class is unnamed.
  • Impact on SM: None, did not advance.
  • Outcome: Blocked due to very limited benefit given the proposal.

Intl Enumeration API

  • Notes
  • Slides
  • Proposal Link
  • Summary: Enumerates the supported options on the ecma-402 api.
  • Impact on SM: Will require implementation,
  • Outcome: Advanced to stage 2.

Proposals Seeking Advancement to Stage 1

Error Cause

  • 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 patterns. The proposed solution is adding an additional parameter cause to the Error() constructor, and the value of the parameter will be assigned to the error instances as a property.
  • Impact on SM: We support two additional proporties which may be a webcompat risk. However this is fine to investigate.
  • Outcome: Advanced to stage 1.

Unused Function Parameters

  • Notes
  • Slides
  • Proposal Link
  • Summary: Introduce syntax similar to rust and other languages for unused parameters, for example function foo(_, _, something) {...}. However, the available options all have issues, included elisions. Additionally, there is a refactoring risk for users of the feature, that while it may be popular, may make code more error prone, especially given the dynamic nature of JavaScript.
  • Impact on SM: None,
  • Outcome: Blocked, may be revisited if new information comes to light.

Standardized Debug

  • Notes
  • Slides
  • Proposal Link
  • Summary: The proposal is unclear of its goal, but it seems to try to implement logging inline using the debug keyword. The champion is flexible about how this is addressed. We are against introducing a new keyword for this purpose but are fine with a method.
  • Impact on SM: This may require implementing a method,
  • Outcome: Advanced to stage 1.

String.dedent

  • Notes
  • Slides
  • Proposal Link
  • Summary: Tries to make printed messages and console logs appear nicer, without having to either manually dedent a template string, or without using a library. Introduces a triple “```” syntax. There are concerns around the new syntax as this will introduce parsing difficulties. The method is generally favored by the committe.
  • Impact on SM: May require implementing a method,
  • Outcome: Advanced to stage 1.

Modulus and Additional Integer Math

  • Notes
  • Slides
  • Proposal Link
  • Summary: Introduces integer math and true modulus (rather than remainder) to the language.
  • Impact on SM: May require implementing 6 methods,
  • Outcome: Advanced to stage 1.

Double-Ended Iterator and Destructuring

  • Notes
  • Slides
  • Proposal Link
  • Summary: Allows the following to be possible: let [first, ...rest, last] = iterable. There is some contention on how useful it will be.
  • Impact on SM: Currently unclear.
  • Outcome: Advanced to stage 1.

Intl.DisplayNames V2

  • Notes
  • Slides
  • Proposal Link
  • Summary: Extending what Intl.DisplayNames covers.
  • Impact on SM: Will require modifying our display names implementation,
  • Outcome: Advanced to stage 1.

Intl Locale Info API

  • Notes
  • Slides
  • Proposal Link
  • Summary: A proposal to expose Locale information, such as week data (first day in a week, weekend start day, weekend end day, minimun day in the first week), hour cycle used in the locale, measurement system used in the locale.
  • Impact on SM: Will require implementation,
  • Outcome: Advanced to stage 1.

Updates on Ongoing work

Status update for class fields, private methods, static class features

  • Notes
  • Slides
  • Proposal Link
  • Summary: Merges three class proposals into one, as they are all mature and getting ready for merge.

Record & Tuple Stage 2 update

  • Notes
  • Slides
  • Proposal Link
  • Summary: At a high level, record & tuple introduces immutable data structures to JavaScript. The champions presented two changes. The first was an investigation into “Objects without Identity” rather than implementing this as a Primative. This has no impact on the user’s experience of this feature, but it has an impact on engine complexity and spec complexity. We are in favor of this investigation. The other part of the update was related to how objects might be referenced from immutable types. They found a way for boxing to work, and that is also being investigated.

Temporal Stage 2 update

  • Notes
  • Slides
  • Proposal Link
  • Summary: Introduces a new date/time library. They will be seeking stage stage 3 in November, and we have to make sure we are comfortable with it by then. The champion group has been collecting feedback, and our team did an inital review. It looks like there will be more changes forthcoming, and we will revisit this later.

Decorators: A new proposal iteration

  • Notes
  • Slides
  • Proposal Link
  • Summary: Decorators can be thought of as process hooks which do not fundamentally change the meaning of the code they are attached to. Decorators are functions called on class elements or other JavaScript syntax forms during definition, potentially wrapping or replacing them with a new value returned by the decorator. This appears to be the most exciting version of decorators yet.

JSON Modules update

  • Notes
  • Slides
  • Proposal Link
  • Summary: This proposal introduces importable JSON modules that require the import assertion syntax changes above. Whereas the above proposal is about the syntax, this proposal represents the module loading mechanism. The discussion at committee focused on the issue of how these modules should be instantiated: Should a new JSON object be created each time it is imported, or should the instance be shared. Since modules are generally sharing a single module, it would make sense to do that for JSON as well. However this might be confusing as one might expect it to work like JSON.parse, and recieving an object that you can modify arbitrarily rather than a mutable global. An alternative is to freeze the object so that it cannot be modified. Discussion continues in the proposal repo.

Numeric literal suffixes.

  • Notes
  • Slides
  • Proposal Link
  • Summary: Allows to write different suffixes for numbers. For example with suffix $ = Decimal. Suffix begins in the first non-number character. Non a-f or O or X. Generallity proposed has an unclear use.