[w3ctag/design-reviews] JavaScript WeakRefs (#321)

こんにちはTAG！

I'm requesting a TAG review of:

  - Name: JavaScript WeakRefs
  - Specification URL: https://github.com/tc39/proposal-weakrefs/

  - Explainer, Requirements Doc, or Example code: https://github.com/tc39/proposal-weakrefs/blob/master/specs/Weak%20References%20for%20EcmaScript.pdf

  - Tests: Not yet available
  - Primary contacts: @dtribble, @erights, @tschneidereit

Further details (optional):

  - Relevant time constraints or deadlines: A review before mid-January 2019 will be appreciated, to ensure that we have this feedback before asking TC39 for Stage 3.
  - [x] I have read and filled out the [Self-Review Questionnare on Security and Privacy](https://www.w3.org/TR/security-privacy-questionnaire/). The proposal doesn't introduce any of the security concerns discussed in the questionnaire.
  - [x] I have reviewed the TAG's [API Design Principles](https://w3ctag.github.io/design-principles/)
Note that this proposal directly impacts [§ 1.3 of the Design Principles(https://w3ctag.github.io/design-principles/#js-gc). See below for further discussion.

You should also know that...

The proposal champions as well as TC39 overall, are well aware of the concerns that exposing GC timing information raises. The proposal is carefully designed to mitigate these issues by reducing the amount of information exposed, as well as the bandwidth with which it is exposed. In particular, the proposal contains mitigations against slight differences in GC timing breaking code. The champions as well as TC39 overall are confident that these mitigations are sufficient to prevent reduced interoperability and constraints on changes to engines' GC implementations.

We're particularly interested in the TAGs opinion on how the introduction of WeakRefs should influence the design of other web APIs, and what kinds of support for interop on the spec level the Ecma262 spec should provide.

Finally, note that while the crucial aspects of the proposal's semantics can be considered final, the API will change between now and January 2019, when we hope to advance it to stage 3. We don't expect these changes to impact other specifications, however.

We'd prefer the TAG provide feedback as (please select one):

  - [ ] open issues in our Github repo for each point of feedback
  - [x] open a single issue in our Github repo for the entire review
  - [ ] leave review feedback as a comment in this issue and @-notify [github usernames]

--------------------------

_Please preview the issue and check that the links work before submitting_

For background, see our [explanation of how to write a good explainer](https://w3ctag.github.io/explainers).


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/321