Summary:
- Quite a bit of work on string methods and promise methods.
- temporal is now blocked on standard modules, adding pressure to do that
- dynamic import will move to stage 4 if all goes well with realms?
- Decorators minimal proposal with built in decorators was presented
- Decorators were also presented as a solution for numeric separators / literals
Stuff we are interested in or working on:
- WeakRefs was discussed, and agreed to not be optional? It will also not be a systems object
- Date.parse has not moved forward due to trying to standardize implementation specific behavior.
- error stacks have not moved forward either, needs more research
The following are normative changes, the behaviour in SM and the conclusions from the plenary.
CreateDynamicFunction early concatenates body
- Notes 1
- Proposes to not throw an exception in all browsers for
function("-->").toString();
- Proposes to not throw an exception in all browsers for
- Notes 2
- In SM behaviour, this is an html comment
- No consensus, special case doesn't warrent change on its own
Remove implementation-defined typeof behavior
- Definitions removed from typeof table
- object (Standard exotic and does not implement [[call]])
- Object (non-standard exotic and does not implement [[call]])
- Consensus reached
Make Async-from-Sync iterator object inaccessible to ECMAScript code
- Consensus
- SM Supports already?
Suppress GetMethod errors in IteratorClose
- Consensus
- SM behaviour - throws error Add export * as ns from "mod" to Export production and Module Semantic
- SM status
- Consensus
Require at least four digits in string representations of negative years
- SM status — currently ship
- Consensus
The following list is of proposals presented at TC39. Proposals are grouped by theme and are presented in stage order from 4 to 1
dateStyle/timeStyle for Stage 3
- Motivation: compact way to request the appropriate, locale-specific way to ask for a date and time of given lengths
Intl.DateTimeFormat.prototype.formatRange for Stage 3
- Motivation allow specifying date ranges without the use of a library
String.prototype.matchAll for Stage 4
- Motivation: need to iterate through all matches for a string
- Introduces matchAll method for doing this
String.prototype.replaceAll for Stage 2
- Motivation: similar to matchAll, users want to be able to replace all strings
BigInt function parameter overloading and Intl.NumberFormat.prototype.format
- Notes 1
- Notes 2
- Consensus to move forward on Intl.NumberFormat.prototype.format overloading with ToNumeric.
Promise.allSettled for Stage 3
- Motivation: Developers are sometimes interested in waiting for all promises to complete, regardless of whether they succeed or not.
- Introduce a new method to the promise prototype to allow waiting for all promises to settle
Decorator-based extended numeric literals status update, and numeric separators for Stage 3
- Generalizes bigInt
- Introduces a way to write about css numbers, ie px
Private declarations for Stage 1
- Motivation: allowing trusted code outside of the class lexical scope to access private state.
- Notes 1
- No conclusion
- Notes 2
- Stage 1 acceptance
- Unlike race, returns when the first promise is fulfilled, or if all fail — returns with an array of reasons why
- Accepted for stage 1
Promise.result (no longer for Stage 1) (Proposal)[https://github.com/pemrouz/proposal-promise-result]
Uniform parsing of quasi-standard Date.parse input for Stage 2
- Notes 1
- Time box ran out
- Notes 2
- Conclusion: The committee did not have consensus to accept a change to the Date.parse algorithm that still allows implementation-specific behavior.
- Conclusion:
- do the legwork to figure out what browsers do in terms of the contents of the stack.
- explicitly enumerate the similarities and the differences.
- to attempt to write a spec algorithm that can allow them all and mandate one of them.
- potentially Create a brand new structure including a preferred output.
- ask browsers and engines that would need to make changes, what changes they may need to make.
Function implementation hiding (Stage 2 update)
- Problem: hide information that is made available by Function.toString
- JavaScript's Function.prototype.toString method reveals the source text originally used to create the function. Revealing the source text of a function gives callers unnecessary insight into its implementation details. They can introspect on a function's implementation and react to it, causing what would otherwise likely be non-breaking changes to become breaking ones. They can extract secret values from the source text to compromise an application's attempts at encapsulation.
- Solution: The solution is to provide a way to modify the output of the above functions, to prevent them from exposing implementation details. This is done via a new directive, tentatively "hide implementation". Like "use strict", it could be placed at either the source file level or the per-function level.
- Proposal scope was expanded
- Does not have an impact on application-level memory saving
Yet Another Decorators Stage 2 update
- Problem: a number of libraries / framework etc authors are looking for a native implementation of decorators
- Summary: instead of custom decorators, we have predefined built in decorators. They are compassable to make js decorators. These are @wrap, @register, @expose and @initialize
- Summary:
- Now uses BigInt always, ToNumeric will be used for input types.
- Zoned: Zoned toInstance (or ZonedInstance?) was renamed to ZonedDateTime
- Standard modules are now a blocking issue for temporal
Dynamic import() for Stage 4 (in June?)
- Mechanism for importing a module later
- Next steps
- Research if import() is future-proof for Realms goals
- import() would not block for Realms advancing to Stage 3
- Spend next two months investigating implications
- Propose import() for Stage 4 in June
Top-level await with a vengeance
- Top level await
- JHD wanted to know if there's a flag to disallow top-level await within subgraphs (or describe why we will not allow that).
- WH had questions about partial bundles where you don't know your children.
- WH also had questions about the grammar and forbidding certain pieces of grammar that are ambiguous.
WeakRef update (currently a Stage 2 proposal)
- Sum up: finalisation api, and weak refs
- Covert channel - difficulty in that not all implementers can reliably identify cross realm channels
- All implementers are on board, no reason to be optional
Intl.Segmenter Stage 3 to Stage 2
- proposal is incorrect, demoted from stage 3 to stage 2
Secretarial:
Not summarised:
- TC402 update
- TC53 update
- Secretariat Update