2017-05-25 Meeting Notes


Allen Wirfs-Brock (AWB), Waldemar Horwat (WH), Brian Terlson (BT), Michael Ficarra (MF), Adam Klein (AK), Chip Morningstar (CM), Dave Herman (DH), Kent C. Dodds (KCD), Kevin Gibbons (KG), Tim Disney (TD), Daniel Ehrenberg (DE), Shu-yu Guo (SYG), Jeff Morrison (JM), James Snell (JSL), Keith Miller (KM), Myles Borins (MBS), Rick Waldron (RW), Mariko Kosaka (MKA), Stephen Murphy (SMY), Rob Palmer (RPR), Andrew Paprocki (API), Philippa Gardner (PGR), Sam Goto (SGO), Mark S. Miller (MM), Nathan Hammond (NHD), Masud Rahman (MRN), Henry Zhu (HZU), Sebastian Markbåge (SM), Joe Mordetsky (JMY), Franziska Hinkelmann (FHN), Caridy Patiño (CP), Myles Borins (MBS), Ron Buckton (RBN), Ashley Williams (AWS), Domenic Denicola (DD), Patrick Soquet (PST), Peter Hoddie (PHE), Leo Balter (LBR), Ben Newman (BN), Jafar Husain (JH), Yehuda Katz (YK), Sarah D'Onofrio (SDO), Kirill Cherkoshin (KCN), Andres Suarez (ASZ), Diego Ferreiro Val (DFV), Tzvetan Mikov (TMV), Brendan Eich (BE), István Sebestyén (IS)


7. Approval of the minutes from last meeting

(unanimous consensus)

8. Report from the Ecma Secretariat

IS: The minutes have two parts. One part is the "list of metadata" about the meeting. The second part is the technical notes.

IS: First time somebody asked for the complete minutes of those meetings. Intended to inform the people who are not involved in TC39 what is happening in TC39.

IS: There were questions around the process of the opt out for the latest ECMASCript standards.

IS: This is interesting as I always thought that for programming languages (and not e.g. about their compilers) it is hard to get patents therefore a "royalty-free opt out" that would be something that is new for this committee.

IS: As expected, we have received no comments during the opt-out period that we have started on February 14 and ended on April 14, and therefore we have approved the specification from the TC39 point of view. You may remember that at the March meeting the TC39 approval of ECMA-262 and ECMA-402 new editions were conditional based on the positive outcome of the "opt-out" for both standards.

IS: The standards have published internally on the Ecma internal website, and as ususal the New standard version will be available for public download immediately after Ecma GA approval, latest on June 28th. Congratulations on the excellent work you have done.

Administrative Items

IS: Just to remind. Anybody can add them via the reflector, at any time. We agreed to this a few meetings ago, in order not to steal time from the meetings

Public Relations

IS: Allens remark about 20 years of ECMAScript approval in Ecma is well-taken. This is always a good opportunity for PR. You may wish to organize some conference/press conference given the opportunities presented by the size of the community. (Presented as an idea.)

IS: Would like to bring attention to the work that this committee is doing, and the community built around the language and specification.

TC39 Leadership Status.

IS: Don't have a chairman for TC39 and are looking for a replacement. AWB has been acting chair.

IS: Chairman is often involved in other technical committees.

IS: Roles are distributed across membership.

IS: Ordinary members have first priority to take leadership roles, if they wanted to. So far they haven't expressed interest in taking a leadership role in TC39.

IS: Therefore now other members of Ecma (better TC39) may step forward and volunteer themselves, including non-profit members. Anybody who is an Ecma member in good standing can offer themselves.

IS: However, to lead such a big and intensive group like TC39 is a challanging job. So experience is required. Direct recruitment of people is the next step - if we can not find a good leadership among ourselves, I recommended Rex Jaeschke as an excellent candidate for that (details about Rex has publishedon Github), but this decision is entirely up to the committee (see tc39/Reflector#71 )

IS: Rex has been working with Ecma for 10+ years and is very experienced with standards committee work. Knows Ecma very well and has been working with several technical committees already. Very familiar with programming languages in general. Participating in TC49 (C#). Main position that he has held is that he has been chairing JTC1 SC22 (including C++). This is the place where we are fast-tracking also the TC39 standards. He was there recently when we discussed with ISO the fast-track of ECMA-414.

IS: ISO allows you only to be a chairman for 9 years. He has been the chairman of SC22 for 8 years, therefore he has availability forthcoming. He knows a lot of people on this committee very well and has worked with people in this committee previously.

IS: He also offered to provide some background information on himself, available on the Reflector.

IS: Could invite him informally to the July meeting for continuing relationship development.

IS: Re-emphasizes that this proposal is at the discretion of the committee.

IS: Size of TC39 is growing, therefore we need to do more planning in advance of the meetings.

Organization of the TC

IS: When we get > 50 people we will need to deal with hosting and organizing meetings in an different way

IS: No consensus around different models of working with subgroups or a combined plenary session.

DE: Leo expressed interest in being chairman?

LBR: Searching for somebody who would not be taking sides as a person who would act as a chair. Believe that it is good to have a conversation with Rex and let TC39 consider that as an option. I volunteered myself for something I don't have a lot of experience with. Rex has a lot of experience which we could use to be able to learn from. I would love be part of a vice chair group (although not official by ECMA)

LBR: There may be additional people who have interest.

DD: What exactly is the role of a vice-chair, and a "vice-chair group"?

YK: Single person who has the sole responsibility for setting the direction of the conversation. Better received if there is a working group.

LBR: The vision that I have is: Support the chair in all of their functions. There are a lot of things during the meeting. Supporting the hosts in the process of setting up the meetings. Supporting the process of followup after the meetings, sending the notes... Having a group of people to support these goals is valuable.

DD: Confirming: Vice chairs would not be setting direction of conversation in the meeting? But would instead be helping with administrative efforts?

LBR: Confirm.

AWB: There is a lot of stuff that a chair does that committee does not know: Primary layer between committee and ECMA. Months and months dealing with patents, documentation... Takes real time to interact with ECMA. Also helping the committee structure and organize technical work.

AWB: This also works to develop future leadership of the committee. A vice-chair could step forward to run a meeting in the event that the chairman is unable to be present.

IS: Its is very much how you define it. How we organize it is depends on Chairman, its very free.

DD: What I found clarifying that . The primary thing that person will own is not just the operating of the meeting, but there is also additional unseen work. The conversation that we need to have in this room is focused on determining the flow of meetings.

DE: I can help with the administrative stuff, but too involved technically. It would be desirable that the person running the meeting has a internal understanding and technical expertise to weight on the decision in an unbiased way.

LBR: I am tempted to not sign up for too much ("overloaded") and I want to be able to take sides. I am open to try and experience with Rex here.

LBR: To follow our vision goals, we should the use language Chairperson or just Chair instead of Chairman.

AWB: We will call it Chair going forward. Rex can be very helpful trying to figure out the structure. The recommendation is to try to get Rex to do this, but waiting until is here to come up to speed so he can help with advice and the administrative stuff. Give him a chance to show his expertise.

WH: Rex should be involved in this discussion, bidirectionally so those of us who don't know him get to meet him as well.

AK: We should all have an opportunity to have a conversation with Rex.

WH: How would the finances work?

IS: We would have to pay to bring him in as a consultant for the first little bit. Ecma has to champion finding a chair in the event that it is not handled internally.

Discussion about ECMA finances

LBR: Is there any alternative?

WH: Let's not worry about that for now.

AK: Would be happy to have Rex come have the conversation.

SDO: SHould specify what the roles are more concretely so that we know who these people are.

AWB: None of us are here because we want to be bureaucrats.

AK: Vice-chair is an important for growing skills. (assent from LB, AWB)

DE: Who is going to run the next meeting?

AWB: I could chair one last meeting, but come away with a new chair at that meeting.

DD: Doesn't like the idea of temporary chair?

FHN: Having an acting chair of Leo next meeting, with AWB as backup?

YK: Expressing concerns about Rex is being presented as a top-tier candidate with no familiarity to the members of the group.

BT: Had concerns, but everything I've had in terms of interactions or questions about working with Rex was very positive. He seems like a very good candidate. Likes non-paged standards, which BT loves. Seems to wish to evolve the standards process itself. Standards resume is something like 30 groups deep. Would be valuable to have somebody with that degree of expertise.

YK: My only concern is that the details in how we work in this committee requires a lot of history and past knowledge.

MM: We should make sure that he is enough informed to make sure that it is something that he is interested in.

BT: Has the necessary qualifications, but we can't make a decision sight-unseen, and he can't make the same about us.

Invite Rex to the next meeting.

General assent to Leo running the next meeting.

LBR: I'm willing to try.

AWB: I may not show, it would be valuable to have it, but he'll play it by ear.

LBR: Will need to define and document the role.

Conclusion/Resolution

  • Leo will be acting chair for next meeting.
  • We will invite Rex to the next meeting.
  • Ecma will cover the respective expenses for Rex

18i. Code of Conduct follow-up.

tc39/code-of-conduct-proposal#25

(István)

IS: Executive committee's reaction to the proposal was immediately positive and received broad support.

IS: Should this be all of Ecma or just TC39? Decision was to test it on TC39 and then possibly consider expansion to all of Ecma based upon the experience that we have here.

IS: Ecma General Assembly may eventually take it over as an Ecma-wide process (in the long run...).

IS: Ecma wanted to participate in the discussion about the final text. Have produced a new version and fed that in as comments here: tc39/code-of-conduct-proposal#25.

IS: Somehow this policy should be linked into the Ecma policies. Allowed to introduce these things as riders via the Ecma bylaws (possibly paragraph five?)

IS: Some of the execution points that you have created were too detailed in terms of management function which conflicts with the style of the Ecma bylaws and policies. Intentionally simple so that we don't have to micromanage the groups. Give more flexibility to the implementers.

IS: The changes the General Assembly has made, is linked in the current proposal. Is up to the committee to review them and start a conversation if there are disagreements. If agreement is meet before the July meeting it can be approved by TC39 in the JUly meeting and publish and implements it.

IS: By the way, for formal TC39 approval we need to publish the final version 15 days before the TC39 meeting. And this can become after approval the "experimental code of conduct policy for TC39".

BT: I really appreciate Isabelle Harper's help getting this through the executive committee.

WH: We can't do this without blessing of the executive committee. They are the ones responsible for modifying ECMA's rules.

YK: Physical danger has been removed which is odd, and should be revisited. By definition, CoCs are trying to provide more protections than the protections of law enforcement.

LBR: Code of conduct doesn't prevent anybody to seek for legal authority.

IS: Need to build consensus between us and the executive committee.

IS: Shouldn't have one-sided discussion

Need to ensure that we have a consensus on this side prior to the conversation with Isabelle.

AWS: Need to have consensus to progress the conversation further

MBS: Would it make sense to have an open group internally with internal stakeholders as a representative of this groups.

BT: We should do it weekly until we have a document ready. Coordinate it via the reflector.

Conclusion/Resolution

  • Start an issue on the reflector for building a working group internally.
  • That group will work with Ecma to ensure that we're all on the same page.

11. ECMA404 (JSON) ISO fast-track. Review/approve disposition of comments responses and 404 2nd edition draft.

Documents TC39-2017-016, TC39-2017-017 (pdfs of documents available in Reflector repository).

AWB: Questions on the fast track of Ecma404 (JSON specification).

AWB: Seeking consent that we don't want to review everything that comes out of Ecma 404.

AWB: Japan editor has asked for some changes (mostly editorial) that the committee has to revise before final approval.

MM: Retitling from "format" to "syntax". Historically we have had a lot of trouble explaining what JSON is not, i.e., that it is just a syntax with no standard meaning. Changing the title to "syntax" should help reduce such misunderstandings.

AWB: Changes are for clarifications and make things more explicit.

AWB: Has no objections to approving it sight unseen if we have consensus.

YK: No particular concern if there aren't user-facing changes. Happy to delegate to people who care.

Conclusion/Resolution

  • Editor to make changes/updates as necessary

17.ii Web compatibility issues / Needs-consensus PRs

(Brian Terlson)

- https//github.com/tc39/ecma262/pulls?q=is%3Aopen+is%3Apr+label%3A"needs+consensus" - https//github.com/tc39/ecma262/issues?q=is%3Aopen+is%3Aissue+label%3A"needs+consensus"

Prohibit async methods named 'function' #884

- https//github.com/tc39/ecma262/pull/884 - https//github.com/tc39/ecma262/issues/832

Why are restricting on two tokens?

YK: Would prohibit creating an async method called "function"?

BT: Correct

AWB: Unless quoted, this is allowed.

YK: increasingly its ok to use keywords, and this is an inconsistency.

MM: is two token lookahead concretely a problem for implementors?

KG: Seems ok since its already very complicated.

KM: non-issue

WH: Can get us unintentionally stuck in a corner, where we can't extend language in the future

MM: Acknowledging Waldemar , in the sense of implementation concern, YK points is valid: We should be careful with the inconsistencies for keywords.

DE: Can I withdraw this patch?

BT: If we don't get consensus for it, or against it, it will sit forever.

WH: I have not have time to consider the implications of this.

MM: Implementors should take a look and raise concerns when needed.

Conclusion/Resolution

  • Waldemar to further consider
  • Implementors will review

WH: (a few minutes later) Having looked at the implications of this in more detail, I'm fine with rejecting the issue with no action.

Normative: Specify RegExp malformed character class behavior #864

- https//github.com/tc39/ecma262/pull/864 - https//github.com/tc39/ecma262/issues/863

BT: Chackra teams agree with the conclusions for changing the behaviour for regexp.

DE: Andre specified several previously missing "\c" cases

YK: Whats the problem with the characters? Why Annex B?

DE: All the surrounding parts are Annex B

Conclusion/Resolution

  • Accept PR

Relax [[DefineOwnProperty]] on module namespace exotic objects. #858

- https//github.com/tc39/ecma262/pull/858

AWB: No way a define property could be use to exactly define a module export in the namespace object.

DH: why diverge on cases that match module invariants? no.

DD: Any objection?

DH: verify not the case that you can observably change an exported NaN via DefineOwnProperty (from the outside)

DD: You can see the mutations from outside.

AK: Spec doesn't let you change

DH: Just verifying.

YK: Writeable property that you can't write to? Seems weird.

MM: if thing you're exporting is const, does the property descriptor "non writable"?

AK: No, all descriptors marked as writable

DH: Without knowing the details we should not think that ES5 refection mechanism can describe all aspects we encounter.

AK: Shouldn't be able to tell how someone declared a binding in their module

MM: should be able to communicate that a value is stable. this is the descriptor "contract" guarantee

Is the module namespace object non-extensible?

Yes.

YK: There is a a new property that we define as writable that is not writable.

AWB: Not new.

AK: Since... Proxys!

YK: If you define object.define property with writable true, and you can't write on it...??

MM: Non-writeable provides guarantee. Writable provides no guarantee.

LBR: We need to provide tests before merging. Okay to mark as consensus.

Conclusion/Resolution

  • Accept PR

Normative: Define particular precision for toFixed and friends #857

- https//github.com/tc39/ecma262/pull/857

BT/WH/DE:

Discussion re precision for toFixed and others

BT: Why do the higher limit?

WH: This lets you print exact values of doubles. I implemented this in SpiderMonkey and have found it very useful to educate people on how doubles work.

?: The negative limit makes no sense

DD: It's well-defined.

WH: Yes. It rounds to multiples of positive powers of 10 instead of negative powers of 10. It's only sensible for toFixed, which is why toExponential doesn't support it. But I'm fine with negative numbers going away.

DE:

BT: We presently support 0 to 21. This is just changing the requirements to the range 0 - 100.

DE: Yes

YK: What do admins do if you put a number outside of the range? (after the patch)

RW: RangeError

BT: Can also change it to not throw for negative to

Conclusion/Resolution

  • Accept PR

Normative: Date.prototype.toString throws on non-Date receiver #850

- https//github.com/tc39/ecma262/pull/850

KM: The error is also thrown by typed arrays.

MM: We should be consistent across all of the occasions to not throw, or this is fine.

Conclusion/Resolution

  • Accept PR

15.i.a RegExp Legacy Features for Stage 3

(Mark S. Miller, by Claude Pache)

- https//github.com/tc39/proposal-regexp-legacy-features

MM: WH & DE objected to exempting subclasses from legacy features

DE/WH: Exempting subclasses doesn't serve positive purpose and is very confusing.

MM: Withdrawing restriction exemption for subclasses, keeping restriction exemption for realms

AWS: How is it identified by realm?

DD: New slot for realm, specifically for regexp

AWS: Legacy properties are on subclass constructor?

MM: No, they're only on the RegExp constructor.

MM: Explains how prohibition across realms works

WH: Another issue: for polyfilling, want to run regexp without polluting static properties. Possible future flag added to regexp to suppress legacy feature. In jest, I suggested "s" flag.

Conclusion/Resolution

  • Stage 3 acceptance

15.ii.f import.meta for stage 2

(Domenic Denicola)

- https//domenic.github.io/proposal-import-meta/ , following up from Tuesday's discussion which suggested this direction.

DD: Ready for stage 2; let me give an overview of the spec:

AWB: why not a map?

KG: Always use maps

DH: using a map will be too unergonomic

DD: using a map makes calling methods terrible

DD: Bradley Farias noted that using a null proto object discourages code from modifying the object prototype of module object

AK: Nice for consistency with namespace objects

AWB: ns objects are special case

Discussing polyfill story

BN: In node there is a Module constructor with a prototype, which is shared by all the module objects. In practice, it's a convenient place to put shared operations. import.meta could have a common prototype? Or not, and the host environment could choose to call Object.setPrototypeOf(...)?

YK: No longer worried about not sealing the objects because they're not shared.

MM: this object is the "system object". When discussions arise about what goes on the system object, this will be the place to put them.

DD: No, because this object is for hosts only.

MM: I just don't want Domenic to be blind sided

Conclusion/Resolution

  • Stage 2 acceptance
  • Reviewers
  • Adam Klein
  • Dave Herman
  • Yehuda Katz

15.iii.b Updates on class-field proposals (both public and private).

(Jeff Morrison)

JM: integrating public and private into one proposal to avoid proposals racing

JM: Address orthogonal class proposal

- https//github.com/erights/Orthogonal-Classes

(working through Orthogonal Class Conventions slide)

CP: q about "own" keyword

JM: without keyword indicates prototype, with keyword indicates non-prototype

(discussion re [[Set]] vs [[Define]])

YK: Ok with [[Define]] as long was we work on mitigations

(Working through rules and solution for future additions)

  1. Create new keyword for "proto" members, require this keyword for any future proto fields proposal and make it optional for methods.

  2. Include 2 categories in the framework design: "fields" and "methods". Within each category, say that the common-case form uses the no-keyword syntax, all ... (slide changed)

JM: want to choose one of the above this meeting to fix the orthogonality issue before we can proceed.

WH: In favor of 2

WH: What is the syntax for const fields?

JM: const fields, depending on what the mean...

WH: For the sake of discussion, let's say that they are initialized once, can be own or static

JM: would not be one of these mutually exclusive categories

RBN: no issue in TS, use "readonly" with accessibility modifier

KG: No own or proto keyword

RBN: No

JM: modifiers in languages that allow varying order are problematic, can be addressed with grammar

WH: In C++ you can write static const but not const static.

JM: concern that own keyword, interaction with decorator:

class C {
   @deprecated own foo = 42;   
}
  • @deprecated may choose to not to store foo as an own property
  • Syntax is now misleading: The user has intended to make an own field, but the decorator will violate that intention.

JM: The issue is the case where an own property gets turned into a getter/setter

JM: Possible solution:

  • Permit fields with a decorator to omit keyword if and only if the decorator makes a concrete determination of own/static/proto in the descriptor it eventually returns.

WH: (question about interaction with the two framework solutions shown earlier)

RW: Need to review those two options in the context of this solution

JM: applies in either case (still needs to work out specifics with YK, re: decorators)

YK: normal usage of property doesn't change: x.y is still the same whether own property or getter/setter, changing to static makes a difference

DH: evidence that we need a keyword for instance properties is weak, considering TS ships without keyword. A growing decision tree, accumulating

WH: need to address decisions in order

JM: hoping to find objective ways to find a solution, vs subjective "good" or "bad" discussion

DH: (some objection to the design process that I didn't fully catch before the next person spoke)

AK: We've been debating syntax for a very long time, he's offering ways to objectively work through design decision tree

DH: There was a slide that indicated some additional syntax for an uncommon case

(I'm way behind)

DH: problems in the reasoning that lead to the own keyword in the first place

JM: Two possible conclusions:

  1. Create a new keyword for proto
  2. Fields and Methods

DH: The own keywords is a trcit subset of option1 and option2. THey both map variants of proposal that dont "own" or "proto"

DD: feedback on having keyword?

JM: Typescript or Babel don't have keywords, thats all we know from the outside.

DD: when original unified proposal, community pushed back against required keywords

AWB: people who are not used to keywords, don't like keywords

JM: That is a tricky debate point, because people can be upset either way (for using it already or no have used it yet)

YK: Significant reaction for foo = 1 vs. own foo =1, reaction is often at "public", not specifically "own"

DD/RW: agree

MM: own vs. shared is a very intuitive contract...

AK: not shared

JM: say we used proto in front of

??: If you had an alias for own and shared will be easier to understand

AWS: I believe if the keyword was shared, it would be more likely understood

AWS: instead of focusing on how the language works from implementation details, focus on how it can be more easily understood/intuited

BT: Do you think own has similar problem, that begs the question what is it? what is for?

AWS: to introduce a not feature that doesn't map to another language, especially in a way that's not clear

MM: This argues against own

AWS: yes

MM: Also argue that declaration looking like an assignment is confusing?

AWS: Yes

DD: Yes

MM: Given those points, does it lead you to 1 or 2?

AWS: not sure of all the implications

JM: mentioned that assignment confusing and most people don't get difference between assignment and definition

AWS: (restating)

MM: Given those intuitions...

RBN: We also have assignments in function parameters (as another precedents)

AWS: Don't think people will think own as similar to let, const, var

DD: Looks more like static

MM: They'd learn

AK: There is evidence that says users have been working with "no keyword" and learned

D: What is the path for people to go from 0 to learn the language in a comfortable way. A keyword will bring one set of confusions. With assignment, people might not have clear the semantics. ^-- Who is this?

AWS: Adding own looks weird to learn, since there is not precedents to it.

AWS: Looks like assignment no matter what, confusion no matter what.

MM: So, additionally adding a keyword is more confusing?

AWS: Yes

AWB: "own" is already used in the language in getOwnProperty... methods

AK: Extends has the same context

AWS: Most people don't realize it exists.

YK: "own" is not the same thing as let, const. In some sense are declarative, but people experience it as assigment only, introducing own with that semantics can be confusing.

AWS: An assignment with a semicolon will be treated as in order (like statement list)

There is confusion that this looks like a statement list, own doesn't mitigate this

JM: The committee has to make a decision. New syntax might confuse somebody, but we need to walk that fine line.

MM: The case for own that we made, with the case stated, we are willing to give up "own".

JM: We have consensus for solution 2? We are agreeing to the syntactic specification that Dan has put together in thel ink proposal in teh agenda. which is a merge of a private fields and public fields proposal

Moving on to DE's ~https://littledan.github.io/proposal-class-fields/~ tc39.github.io/proposal-class-fields

WH: The proposed spec does not have an own keyword, but does not preclude supporting own to designate instance methods

DD: There are two small changes: Supporting private static fields: It feel very natural since the semantics are consistent. Also comma separated fields declaration for static and non-static.

WH: is there a no line break restriction on static?

KG: Methods already do not have that restriction, so can't really introduce it

DE: Kevin implemented this and it works

WH: own (or most other keywords) does not have any meaning (right now). If you add it later, it will need to have a line break restriction to avoid changing the meaning of

```own
foo() {...}```

which currently would declare a variable named own.

DD: own has to have it

YK: I only care about one scenario: coma separated private name scenarios. Im willing to restrict the grammar for those cases. We should not add arbitrary restrictions.

DD: If you have own methods, it will have to have the new line restrictions.

MM: Evewhere where you have an identifier name that means a new property/fields you can use the computed property fields for same name?

DD: Yes

MM: Including the computed property its ok.

JM: We have consensus en no own. The second things is, do we need the ability to make this keyword optional?

JM: What do we need for this proposal to be in stage 3?

(process discussion, lol)

Conclusion/Resolution

  • No own
  • Moving forward on DE's Integrated public and private fields proposal
    • This is the active proposal for class fields
    • This supercedes (by way of integration) all previous proposals - Reviewers
      • Waldemar Horwat
      • Kevin Gibbons
      • Kent C. Dodds
      • Rick Waldron
      • Diego Ferreiro Val
      • Yehuda Katz

15.iv.a. Revisiting async generator yield behavior

(Domenic Denicola)

- issue tc39/proposal-async-iteration#93 - slides docs.google.com/presentation/d/1U6PivKbFO0YgoFlrYB82MtXf1ofCp1xSVOODOvranBM/edit#slide=id.g223fba4116_0_235

DD: Got to stage 3, but then there was implementation feedback that we had some issues.

DD: As background: We don't want "promises for promises", but you could explicitly yield a rejected promise from an async iterator

Consider

async function f * () { yield 1; yield Promise.reject(2); yield 3; }

Because 'yield' does not unwrap, someone consuming the sequence manually will get a rejected promise but the generator will complete normally. This differs from sync generators, which stop if there's an exception.

If you iterate with for-await-of over an async iterator which returns a rejected promise, rather than throwing, the for-await-of will re-throw the exception from the rejected promise immediately, leaving the async iterator paused, which means it doesn't have the chance to clean up resources e.g. with a finally

MM: I don't like option 1 (don't unwrap rejection) WD: Would it be any different in yield and yield await?

RBN: When you yields a promise that is rejected, by the time it resolved it will be resolved.

DD: Proposal: yielding just stores the raw value of what you yielded (i.e. no unwrapping), and if you use 'next' manually you need to deal with it, but for-await-of unwraps. so manually consuming with 'next' gives you promises, but for-await-of gives you the values, and rethrows if it hits a rejected promise

DD: Problem: this means library authors can't use next without a lot of work. Also means that yield* is not like for-await-of and manually yielding each value

RBN: If I throw in a generator, it should go over the boundary. Does not hit finally blocks (?)

DD: The problem is yielding a rejected promise.

Adam: The special case is that for a iterator if next throws, iterator is not closed. If is a generator, thats fine, and im not totally combinced in the simmetry.

DD: To avoid the resource leak we can avoid calling return.

YK: Restated option 3: yield has the same semantics as yield await in an async generator

RW: Have you asked CaitP?

DD: Yes, she thinks it would be easier to implement and therefore likes it.

RW: Good, same.

MM: My favorite option is option3, despite previously liking one of the other options

WH: I also favor option 3.

(room in general): I favor option 3

Conclusion/Resolution

  • Go with option 3: yield has the semantics of yield await in an async generator

15.iv.b Updates on Cancellation Proposals

(Brian Terlson, Ron Buckton)

- https//github.com/tc39/proposal-cancellation - https//tc39.github.io/proposal-cancellation/CancellationPrimitives-tc39.pptx (triggers download)

RBN: (walking through slides)

Motivations

  • Clear and consistent approach to the cancellation of asynchronous operations
  • General purpose coordination primitive
  • Host API integration (fetch, module loading, etc.)

Goals

  • Separation of source and sink
  • Cancellation request can be observed synchronously, via property
  • Cancellation request can be observed asynchronously, via callback
  • Able to unregister callbacks
  • Composable for non-trivial cancellation graphs

Source/Sink

  • Source

  • „Owned by caller „- Can share entangled Sink with multiple callees „- Initiates cancellation signal

  • Sink

  • „Received by callee

  • „Can observe cancellation state

  • „Cannot initiate cancellation signal on Source

  • „Callee A cannot interfere with Callee B using the same Sink

...just look at the slides...

Promise As A Token

YK: When Domenic originally proposed, there was a ... (I didn't catch the rest of that)

RBN: Need to revisit

DD: Disagreed with explanation of whatwg/dom#437

(reached some slide with a callable constructor)

YK: I thought we were avoiding

RW: callable constructors can't be subclassed

CancellationToken API Slide

MM: (question about the phase that a callback is called, missed which, but RBN confirmed that it did whatever it was Mark asked about)

No time left, so not pushing Stage 1

YK: not sure if we should accept wholesale?

RBN: borrows heavily from the established .net APIs

Conclusion/Resolution

  • Look into cancel only when everything is canceled

15.i.h. BigInt for Stage 3

(Daniel Ehrenberg)

DE: Made the changes, ready?

WH: I reviewed it this morning, at which point I found that it did not have the changes reflecting our decisions.

DE: I made the changes during today's lunch.

Conclusion/Resolution

  • Still needs another round of review - Reviewers
    • Waldemar
    • Leo Balter

17.iii.a Observable proposal to Stage 2

(Jafar Husain)

- https//github.com/tc39/proposal-observable

  • request slides

JH: (working through slides, returned to original proposal)

... slides, slides, slides

AK: Why does this need to be in the standard library? No answer to that yet.

MM: Promises were popular and could be implemented in library code, but it was a high value to users

MM: This is going into Angular

YK: The way Angular is using observable is, in my opinion, wrong.

MM: Where does this fit in?

YK: The DOM

DD: There are also libraries where Observable has gone in and then out.

SM: Never fully integrated into React.

YK: Observables fundamentally push, where pull is proven to be more effective

KM: Are there use cases in Node.js?

API: Bloomberg data (more here, Andrew please fill in)

DD: (examples of DOM apis that make sense in DOM and Node, but not in language)

WH: Will there be risk of Observable identifier clashes, with scripts resolving it and picking up our implementation and thinking it's one of the external library ones which might behave differently?

AK: There is an interest in an Observable, but no one wants to deal with "which one"

JH: Believe this is fundamental

MM: Support that. Prior to Promises, we were designing a sequential iterative language; since Promises we're designing a language for asynchronous programming as well. We are figuring out what the toolkit is of basic asynchronous programming abstractions. Asynchronous iterators give us pull streams. Observables give us push streams. Both seem to be necessary, serving broad needs.

AK: Then why not Streams?

DD: async iterators

Stage 2?

YK: Concerned that this won't make past Stage 3. Similar issue to cancellation token?

AK: Not the only person with concerns

DE: Want to see more interaction with host environments

YK: Wondering if DOM will use this to replace event emitter in the DOM?

RW: As in literally replacing EventTarget?

DD: There is a better, backward-compatible path for that.

DE: Concerns about where it fits in host environments

AK: Stronger concerns: will this be the thing actually used in hosts?

RW: (shared experience with Observable "zealotry" in the case of Generic Sensor)

  • Want to see more of how this works with actual host interactions to analyze
  • Let's see if we can get hosts excited about the feature

Conclusion/Resolution

  • No Stage 2