diff --git a/es7/2016-05/may-23.md b/es7/2016-05/may-23.md new file mode 100644 index 00000000..0c82b4fb --- /dev/null +++ b/es7/2016-05/may-23.md @@ -0,0 +1,590 @@ +May 23rd 2016 Meeting Notes + +## Attendees + +Brian Terlson (BT), Dave Herman (DH), Michael Ficarra (MF), Jordan Harband (JHD), Waldemar Horwat (WH), Tim Disney (TD), Shu-yu Guo (SG), Mark Miller (MM), Kevin Smith (KS), Michael Saboff (MS), Eric Faust (FST), Chip Morningstar (CM), Daniel Ehrenberg (DE), Leo Balter (LB), Yehuda Katz (YK), Jafar Husain (JH), Andreas Rossberg (AR), Ben Smith (BS), Thomas Wood (TW), Alan Schmitt (AS), Brad Nelson (BN), István Sebestyén (IS), John Neumann (JN), Domenic Denicola (DD), Yang Guo (YG) + +on Google Hangouts we've had some local Google folks: Michael Hablich, Yang Guo, Taon Ver Naest, Daniel Clifford, Nikolas Papapyrou, Ben Titzer. + +## Discussion of the agenda and timing + +PTC/STC on Tuesday morning/afternoon for MS employees to call in +9 hours differences between CET and US Pacific time. Only afternoon works... +First YK/BT class evaluation order, then PRs, then features for advancement, then other features + +## Class evaluation order (YK, BT) + +[_Presentation (with slides)_] # __TODO: add link to the slide__ + +BT: We need consensus, as this comes up with decorators and other new language features. + +YK: Resolves question that committee asked + +BT: [_slide ES6 Class Evaluation order_] Mostly not observable. + +MF: Some of those steps are observable + +YK: The interleaving is not all observable + +EF: What matters is that the evaluation steps are in order and that you get the TDZ right + +BT: The observable effects are that the class is in TDZ while the extends clause is evaluated and then the computed property names are evaluated + +BT: [_slide In-order Evaluation: Unrealistic_] Hard to add additional features to classes while maintaining these constraints + +YK: [_slide Impossible scenarios with in-order evaluation_] There are a number of dynamic things, and it'd be really hard to do them all in textual order for new features + +DH: Can I make that slightly more rigorous? A number of new features include evaluation of expressions + +... + +YK: __TODO: provide gist link__. When should static field initialization be evaluated? Seems like it would be nice to have the class not in TDZ and fully initialized when static initializers run. Glimmer actually uses this. + +MM: This is really bad, like Java; we shouldn't have the class defined until all of the statics are there. + +DH: This is one of the most common, natural use cases of statics. + +YK: What should be done instead? + +WH: In C++, you can do this, statics are defined later. Worked fine until constexpr, which exposed badness with phases. Now it exposes lots of badness that no one understands — can't even call constexpr functions statically and textually defined earlier in the same class. + +MM: I want to register that exposing this is disturbing + +YK: Here's an @integrity decorator. It freezes all the things. If we want to have statics evaluated later, outside of TDZ, but it had ordinary imperative semantics, then we couldn't do it in conjunction with the @integrity decorator, because the freezing should happen later. + +YK: If you have a @nonconfigurable decorator, then you need the getter/setters to be put together, otherwise "adding" the second one would fail + +YK: Forward references: the static initializer should be able to call all kinds of methods, even using computed property names, which are declared textually *after* the initializer + +WH: What if Symbol.iterator referred to a static initializer? Example: + +```js + class Args { + static LIST = [... new Args()]; + static PI = 3.14; + ... iterator code refers to PI ... // In turn, LIST refers to the iterator code, creating an order of evaluation dilemma + } +``` + +YK: You're assuming this is imperative. We'll see in the proposal. We'll come back to further example later. + +BT: Instance initializers have to be run as part of the constructor, so they are not subject to in-order evaluation + +WH: I was talking about static. + +BT: [_slide Out-of-order Evaluation_] + +WH: Is the order purely syntactically defined, or does it vary depending on what's in the values being defined? + +BT: Syntactically defined. + +BT: There is actually an intuitive order, which runs in non-textual order, found in other languages. You may think it's good or bad (Java example); there are ES supersets which are very popular +which have this sort of semantics. + +YK: We can use semantics similar to Ruby, though it has more imperative class semantics, where ES is more static. Babel and TypeScript made independent choices here which are out-of-order and seem to meet user expectations, though at the same time, the semantics may be incidental based on the implementation of transpilation + +BT: These are not edge cases; they are core features. Instance and static initializers are very very popular features and we in TypeScript have not received any bug reports of users being confused about the evaluation order. + +BT: [_slide Class.next Evaluation Order Strawman_] Aligns what is implemented in Babel and TypeScript (modulo a TS bug that they are on-board to fix). + +BT: Difference starts with step 4, about making an intermediate list of all of the methods + +YK: The spec could've been written this way, and the difference is unobservable + +BT: Evaluate decorator expressions (to find out which decorator it is, not to call the decorators) and computed property names. + +WH: What scope are decorators evaluated in? + +BT: In the same scope as computed property names. + +WH; So they cannot see any of the class properties? + +BT: Correct. + +EF: What happens when decorators are not in the picture? Seems like it just means that statics happen at the end. Let's tweeze these two things apart. + +YK: It will be clarifying to think through the complete picture with decorators, but you are right. A lot of this is spec factoring, but this is very important to expose to decorators. + +BT: Slide edit to insert step 11 where decorator transformations are run after static elements are installed onto the class in order by evaluating initializers + +WH: Isn't it problematic that you have static element initializers run, with access to the class, when the constructor is not in TDZ? What if an exception is thrown in step 10? To be more concrete, + +MM just now gave an example of a decorator that freezes the class. If one of the static initializers in step 10 throws and someone catches it, the class will be defined but never be frozen. + +DE: E.g., what if the initializer saves the constructor somewhere and then an exception is thrown? Then you'll see that the decorators have not run and the integrity is not inserted. + +DH: There is a distinction between the ability to write something silly that doesn't work and a full argument against a proposal. It's more important that you should be able to meet important user cases. It might not be so important that you could leak a class that hasn't fully been initialized. + +YK: FWIW I think it's good to reduce the number of bad cases. We should try to figure out the actual cases and what the issues look like. + +DH: There is imperativeness inherent in the space. + +YK: I think we can make it declarative modulo static initializers. + +MM: To clarify, do these steps (sub-steps of 4) run member-by-member in textual order through a few of them, or does it run across all members in order? + +YK: In textual order, each member will do those four steps, though we could consider another way. + +EF: You can decorate the getters and setters separately? + +MM: What does that mean? + +YK: Run textually bottom-up per get/set. + +WH: Seems like the order in which decorator functions are evaluated in step 6 is not statically decidable because of getters and setters that use computed property names. One can't statically tell which getters will match up with which setters if they use computed property names, and the pattern of these matches will change the order in which decorator functions are evaluated in step 6. + +DE: Seems like the getters and setters get evaluated first, and coalesced, and then the decorators run + +KS: Could this be factored a bit differently? + +YK: Up to spec editor + +KS: Seems like no changes to current class semantics, right? + +YK: Right, maybe a small amount of changes to class literals, but otherwise the same. + +KS: So mostly a constraint on future additions? + +YK: Yes, it gives guidelines + +JHD: What is the division exactly between step 6/7 and step 11? + +YK: Decorators should not be able to see the in-progress class, so they will get access to some sort of representation to something instead. Step 6 produces modifications, and step 11 actually applies them. + +JHD: So 6/7 produces property descriptors and 11 applies them? + +YK: Basically, though we need more power than just property descriptors; for ES2015 property descriptors are everything. + +WH: Why don't the decorator functions in step 6 get evaluated in textual order? + +YK: Wouldn't be opposed to running them in textual order. + +MM: What is the difference between this and TS? + +BT: TS does step 10 and 11 in reverse. So if you have a static initializer referring to the class, you get an instance which isn't decorated. You need to make a tradeoff: does the decorator see the static fields of the class, or switched? + +DH: It's important for a class integrity decorator to be able to apply to the statics and make them affected as well. + +BT: Babel with the decorators plugin aligns entirely with this. + +JHD: If you have a static initializer which creates a class instance, don't you see the partially constructed class? + +```js +class Foo { + @incrementByOne + + static A = 3; + + static B = Foo.A; // is B 3 or 4? +} +``` + +_Discussion about how decorated properties work using thunks. It's similar to TDZ intuition_ + +MM: Can a decorator on a property see the class? + +YK: No + +EF: Sounds like people are swayed that we want out-of-order evaluation. What else besides decorators is up for discussion here? Maybe we could come back to these things in the decorators proposal. + +YK: There's also something with computed property names, but I want to come to consensus on the basics here. + +MM: question + +YK: You should't have access to the class in a dangerous case. + +MM: For the sake of concreteness, the overall picture you have in mind is that step 11 only applies to class decoration, right? + +DE: Do we have consensus on a staged order? + +MM: It needs to be clearly and unambiguously defined, and follow least surprise; this seems pretty good to me. + +WH: One comment: for step 6, I would suggest textual order. + +EF: At the last meeting, people had a lot of trouble with class initializers. Has this concern been resolved? + +MM: yes, for me. + +DE: So, consensus? + +__*Yes*__ + +EF: what is the concern with object literals? + +BT: Because the right hand side of object literals are evaluated in order with computed properties, it is basically impossible to apply the same scheme to objects, unfortunately. + +YK: Today, object literals are still used a lot as partial classes. Because that's a thing people do, you may want to use decorators (e.g., @nonconfigurable) as part of objects. The issue is that computed property name evaluation is interleaved with the property values. Seems like specifying a different ordering would create subtle bugs, so it's very hard to define well. + +DH: I want to be able to have a @nonenumerable decorator for all property definitions, and it seems like a huge loss otherwise. + +YK: Why did we get rid of duplicate property names anyway? + +DE: computed property names? + +MM: rest and spread properties (FB proposal) became more useful if textually later properties could override earlier properties. + +YK: I don't think that was the reason. + +MM: That was the reason. I was insistent that the dynamic error parallel the static error, so we got rid of the static error as well. + +JHD: Although it would be a breaking change, maybe it would be reasonable to evaluate all computed property names of object literals before their values + +MM, WH: Agree. + +AR: You could have arbitrary side effects in computed property names or property values! + +MM: If the feature was recently deployed, then the code that's using the feature is generally code that's still being maintained. + +YK: I think web developers assume that new features are still in flux to some degree. + +JHD: Cases 1) Babel 2) Web but not caring about compat 3) Node, and then v8 changes in a major version bump. None should be a problem. + +KS: Prototype in Babel? + +AR: I don't like this change because I think left-to-right is a good thing to have. + +EF: I'm also vaguely uncomfortable, but not being able to write decorators in object literals anyway seems + +DH: It might be that people take arguments that they use as computed property names, but probably aren't all that stateful + +DE: Domenic has mentioned a use case for this where people may even refer to properties of objects as computed property names. + +YK: It was a mistake to make getters/setters non-enumerable + +DH: I remember getting consensus on it being enumerable + +DE: But doesn't Object.assign only refer to own properties, so making it enumerable wouldn't fix rest/spread properties? + +YK: Regardless, the room somehow believed getters/setters would be included in rest/spread params (included in "snapshot") + +MM: ... uses own/enumerable/Get, follows Object.assign semantics + +YK: But a getter on the prototype is not an own property. + +YK: It's urgent to reconsider this because people have implemented it. + +JHD: Sounds like this is unrelated to the topic at hand. + +YK: Just mentioning all potential breaking changes. + +EF: Seems like coalescing get/set was better in the old world than the new world. Should we explore alternate syntax so that it's grouped? + +DH: Syntax is very expensive to add. It would be unfortunate to add new syntax that doesn't "pay for itself" and flattening is very ergonomic. Coalescing is nicer for the metaprogrammer. + +YK: Linters should enforce get/set being adjacent. + +YK: Maybe there should be a dynamic error if you decorate both the getters and setters separately + +MM, YK, EF, DH: All agree, better than decorating them separately. + +_Do we have consensus on everything?_ + +DE: I'm still uncomfortable with static initializers running before the class decorators have had their effect on the class, similar to WH's concern + +### Conclusion/Resolution + +- Consensus on a general staged model +- Provisional consensus towards a proposal to evaluate all object computed property names before the values +- Interest in seeing more development towards how getters/setters will interact with rest/spread properties, including reconsidering whether they should be non-enumerable +- Consensus that decorating getters and setters separately should be a dynamic error; you are decorating the pair, not individually. + +## Updates from Istvan + +_Record all members present, including on VC, in the notes_ + +Do we have consensus on adopting the minutes of the March meeting? + +Besides Github notes and ES discuss notes we need to prepare the official Ecma version of the minutes that annexes the "Technical Notes". This is needed not so much for TC39 as for the other Ecma Membership on what is going on in Tc39, and this goes also into the long-term archive of Ecma. + +_Consensus_. TC39 approved TC39/2016/019 Rev1 minutes of the March 2016 San Francisco meeting. + +We cannot have any more technical changes for ES2016. As requested by Ecma Rules the 3 TC39 standards up for voting at the June 2016 GA have been published. Only small Editorial changes are allowed. ECMA Secretariat is working with the editors of 262 and 402. In ECMA 414 (ECMASCript Suite) + +__NOTE__: Allen Wirfs Brock suggests also to include ECMA-404 (JSON) into the normative references (I have forgotten to say verbally in the meeting). This is an editorial addition as ECMA-404 is already included as Normative Reference in ECMA-262. + +The ECMAScript Suite (ECMA-414) for ISO fast track up for approval, going to be presented to ECMA GA. The ECMA Management are all very impressed with the ability to release ECMAScript 2016 so quickly. To avoid getting out of date with frequent updates, we will not submit future ECMAScript "components" (like ECMA-402, ECMA-262) updates for ISO fast track and just submit the one suite standard as the new Edition of IS 16262. Unclear whether this will work practically (actually ISO secretariat suggested this, but some national bodies may object to it - one never knows), but it is very important to ECMA that the annual version be standardized and published. + +ECMA 404 (JSON) will be up for ISO fast track from the 2013 version, aligned with IETF standard, unlikely to change in the future. Actually we have a go ahead from the Ecma GA this from 2014, but only now we are submitting the fast track. The only reason for the JTC1 fast-track of JSON to demonstrate the world that JSON is stable and there is no intention to change it. When there will be a similar IETF Standard (not FRC) we will issue a new ECMA-404 Edition when we will take up that and get it synchronized with ECMA-404. + +__Brian Terlson__ and __Rick Waldron__ has been proposed to the Ecma Management and the CC by Istvan for the GA ECMA award of recognition at their June 2016 meeting. Caridy Patino (as ECMA-402) Editor may also be proposed for an award (this was seconded by TC39). We are also open to nominating other TC39 committee members for ECMA recognition awards for any outstanding TC39 related contribution. This occurs twice a year at the GA. E.g. Allen W-B. or Waldemar H. has received this award in the past. + +__NOTE__: The ECMAScript standards currently contribute to about 2/3 of all Ecma downloads of standards. Constantly we have about 5000-7000 downloads of ECMA-262 per month. That is the record holder standard. The HTML version has about 100000 visits in 2016 so far. +Another point only mentioned here but not in the verbal report: He (Istvan) gets a great external interest for ECMAScript Security Projects and how to speed up ECMAScript performance (e.g. by parallel processing) for Media Codecs running in ECMAScript. + +## [Standardize a RangeError for call stack overflow](https://github.com/tc39/ecma262/pull/319) (Mike Pennisi) + +BT: Leading discussion on this proposal. This would help write tests to see if resources are exhausted for stacks. + +WH: This seems like a special case of out-of-memory. How could you even signal such an out-of-memory failure? You could make the same case about writing tests to make sure weak maps garbage collect. + +DE: It is not possible to detect memory exhaustion on Linux reliably. + +DE: On Linux it just picks a process and kills it, not necessarily the one that exhausted memory. + +BT: yes, for this reason I oppose this proposal. It does not seem possible for us to reliably detect the out of stack condition and recover with a RangeError. + +MM: The ECMAScript spec can only "correctly" be implemented on an infinite memory machine. We don't acknowledge failure. Java preallocates VM errors. Erlang OTOH terminates the process. Let's do that in ES. + +BT: Although that would be ideal, it sounds web-incompatible. + +_Chakra, JSC and SpiderMonkey throw exceptions on out of memory, but V8 just crashes_ + +DE: Sounds like we need more web compatibility evidence. Maybe we should recommend to browsers to collect data on how often out of resource exceptions are caught and handled. + +SG: Games may try to allocate a bunch of memory in a try block + +_General discussion about the unimplementability of throwing correctly all the time._ + +DH: We have to do good science here. + +DE: The test262 tests are parameterized, and there are both positive and negative tests + +DH: Recommendation to test262: write a routine to experimentally determine the maximum stack size, and run this at the beginning, rather than starting at 100k. + +BT: Isn't it possible for this to come to a variable outcome? + +MS: I wrote this routine, and it's very hard to do it correctly determine the exact outcome. It required growing exponentially, then backing off, etc + +LB: After a lot of research, this was the best we found. It is not the happiest solution, but we couldn't find anything better. We just wanted to offer some form of tests on test262 for each feature of the spec, and that's what we did for tail call optimization. You already have to have a $PRINT function that implementations support, and this is similarly parameterized. + +BT: It's a pragmatic solution + +MF: Proper tail calls are unobservable and should not have a test262 test + +BT: But it is very useful and works on all implementations + +### Conclusion + +- Consensus to not standardize RangeError (impossible to implement reliably) +- Continue discussion on a GitHub bug about possible reorganization of test262 to take into account that the PTC tests are implementation-specific/not technically correct + +## [\w and \W semantics in case-insensitive Unicode RegExps](https://github.com/tc39/ecma262/pull/525) (MS) + +WH: This is the exact same problem that I solved in ES3 by adding the prohibition to case-canonicalization of non-ASCII Unicode characters into ASCII characters. Without that, the same \W weirdness would have appeared in ES3. + +MS: Recap of very strange semantics caused by Unicode case folding (MS please insert link to slides). \W includes K because the kevin symbol case-folds to something in \w, so K is case-insensitive in the set of things that aren't a letter. + +MS: Proposal: make \W be the inverse of \w, and change \b and \B to be consistent. An alternate proposal would be to stick to ASCII-only as Waldemar did for ES3. + +WH: [_explaining the rationale for how ES3 regexps were specified_]. Character classes evaluate into sets of allowed characters and an invert flag. Used an invert flag to make [^...] be an exact negative of [...]. It would have been tempting to use an invert flag to make \W into an exact negative of \w, but that wouldn't work when combining \W or \w with other things in a character set: [abc\w], etc. That's why \W inverts the set manually instead of using the invert flag. + +YK: Would it be web-compatible to do a change? + +WH: Having k and s match \W is clearly a spec bug. + +YG: Chrome shipped this in 50, with the spec's semantics. + +DE: It should still be web-compatible, though, as it is very recently shipped. The bug reporter was someone who was writing a conformance test, rather than finding this in actual usage. + +BT: Edge actually ships MS's proposal, so we don't need to worry about web compat. + +MS: Should we change \b as well? + +YG: Yes, they should change together? + +WH: Isn't it strange that what's contained in the class is dependent on the i flag? + +YG: But they should change together and be consistent. + +MS: There is currently an inconsistency between \b and \w due to this issue as well. Proposal flips this, and makes \w\W or \W\w be \b. It's necessary for + +YG: I was suggesting bringing in Unicode because it seems ad-hoc to bring in just small long S and kelvin symbol + +MS: Or, we could make it not cross the ASCII boundary, and not do Unicode case folding with respect to the evaluation of this character class. + +JHB: But seems like we should be aligned with Unicode. + +MS: My proposal just uses UnicodeCaseFolding.txt and will be future-compatible + +YG: It seems rather ad-hoc to not follow UnicodeCaseFolding.txt, so let's keep it if possible. This all applies only with /ui, right? + +MS: Yes + +DH: What Unicode changes affect this? + +WH: Unicode defining new characters which case-convert into ASCII letters. + +_discussion: Good to follow Unicode going forward, as it has changed over time, both in adding new characters and revisions to existing characters_. + +### Conclusion + +Consensus on MS's pull request, and working out \b and \B as he indicated. + +## [Function names](https://github.com/tc39/ecma262/pull/575) (MS) + +MS: Proposal: When the inferred name is a reserved word, use "" rather than the current name. The problem is that the .name property won't eval. + +MM: What is the problem with the .name property being not an identifier? + +MS: The problem is that math.js puts type decorations in the name when they put the property of the function into the object. + +DD: Later, they eval it, concatenating the .name onto it + +MM: That's what broke in Chrome 50 on SES, which was wrong due to bound functions and getters/setters. + +MS: but you can't call getters and setters + +EF: Yes you can; get the property descriptor, find the getter, and call it + +DD: the issue is how should we balance compatibility with the clean semantics of the current spec. + +DE: V8 has shipped this in Chrome 50 and does not see a huge flood of bug reports + +JHD: Function name property is not something that you can eval in general + +DE: There are a lot of ways that we could handle compatibility issues. Collect qualitative or quantitive information, contact large users, etc. Where does this sit when comparing to TypedArray methods (Microsoft contacted Turbulenz; it was fixed and we all managed to ship the methods) and RegExp feature testing (too widespread; made a spec workaround)? + +MS: Seems like this is probably not as bad as the RegExp issue. + +MS: Proposal: "" name only in object literals, when the name is not an identifier + +YK: Compatibility is important + +BT: good to have an evidence-based overturning of previous decisions + +MS: Hard to do telemetry for this + +### Conclusion + +No change in the spec; MS says Safari will likely ship their compat workaround for now, and see if it can get more information for the next meeting or the one after that to consider the decision + +## [TypedArray/ArrayBuffer/DataView constructor changes](https://github.com/tc39/ecma262/pull/410) (LB) + +LB: [_Presented bug comment showing behavior across browsers_] + +MM: What does n/a mean? + +LB: not providing that argument + +MS: JSC gives somewhat changed and more standards-compliant behavior for some cases listed here, more in line with all other implementations + +JHD: Seems like some of these have multiple browsers throwing, but your PR makes it not throw, in alignment with only V8. Why? + +LB: I'm trying to make a canonical approach + +DE: We should consider web compatibility also for things that are not strictly at the intersection + +YK: E.g., Mobile web + +MM: When there's no hard rule applicable, about intersection semantics, then we can rely on soft factors. Another factor here is consistency among approaches. + +LB: Some of the real motivation is also web compatibility. For example, throwing errors for things which are not integers, or some other things, which did not throw in any browser but throws in the spec. + +MM: Is a particular -0 value correct? + +BT: We have had some -0-related bugs in the past; not sure if this is that. + +LB: What I have here is a new abstract operation, ToIndex, to uniformly treat all of these arguments. + +_MM, LB: Going through the details of the spec_ + +LB: The new semantics for ToIndex are ToInteger, then check that it equals toLength of that (which asserts the range basically), allowing -0. + +YK: Point of hesitation that in some cases, almost all browsers throw, but one browser does not throw and the resulting semantics do not throw. + +MM: Seems like this is representing the length, rather than the index + +LB: Sometimes, it represents an offset index, e.g., the TypedArray byteOffset argument has ToIndex applied to it. I've bikeshedded a lot of different names! + +CM: Question: How does ToIndex differ from ToLength? Are there places where ToLength is used which don't go through this? + +JHB: There are many uses + +LB: Many cases use ToLength that I cannot apply this check for ToIndex to. + +DE: e.g., all of the Array methods + +CM: OK, compatibility seems like a decisive argument + +MM: Why not just use ToLength? + +JHD: Because then it wouldn't throw a RangeError. + +MM: Although I prefer errors to no errors, I prefer smaller specs to larger specs. Why not just use ToLength? + +DE: I think Allen wanted to make TypedArrays as strict as possible. This PR seems like a good compromise. + +LB: It's also nice that we have stricter infinity behavior. + +MM: This sounds OK then + +LB: From TC39 philosophy, we could change later for throwing to not throwing, right? + +MM: Let's throw the error because want to throw the error + +YK: But we could go from throwing to not throwing, right? + +MM: We can, but let's get a good decision here. + +CM: Some of these things seem like weird cases that should throw an error, and some browsers do throw errors for some of these cases. Part of that is using a consistent rule everywhere, which i like, but if it's gonna be sloppy, I'm in favor of being more particular on edge cases. + +DE: One thing I really like about this proposal is how it's consistent between the different callsites. Some callsites cast to 0 in all browsers on NaN + +LB: I'm not totally stuck one way on NaN. Maybe we could throw. But I believe this proposal is the most consistent way. One historical reason Allen mentioned was to make it compatible with WebIDL. It's true that this is not exactly the same as WebIDL, but I also consulted with developers who use TypedArrays every day, and they liked this proposal. + +MM: there are cases where it's an error to make a 0-length array? + +LB: I found all kinds of cases of inconsistencies here. This PR makes things more regular. + +MM: If the PR is adopted, then for all kinds of arrays, can you make zero-length arrays? + +LB: You will be able to create empty ArrayBuffers. TypedArrays may have additional checks. + +MM: any objections? + +MS: Were you concerned about compat, DE? + +DE: No, I was concerned about compat for other proposals. I think this will probably work. + +### Conclusion + +_Consensus!_ + +## [Revisiting "Duplicate Function Declarations in Blocks"](https://github.com/tc39/ecma262/pull/453) (DE, SG) + +SG: Should our Annex B 3.3 legacy duplicate function in sloppy block behavior do an assignment for each function declaration, or just the last one? + +DE: I thought we were executing the assignment for each one. This is observable if you break out of the block in the middle. I'm fine with only doing the last one. + +SG: I'm fine with either also, but thought we had consensus on just the last one + +YK, MM: Seems like it'd be more intuitive that each function declaration does the assignment, + +### Conclusion + +Consensus on DE's PR to do an assignment for each function + +## [Throwing an error for returning primitives from base class constructors](https://github.com/tc39/ecma262/pull/469) (Claude Pache) + +DE: I'm concerned it wouldn't be web-compatible to change this. We've apparently always supported returning non-object from a construct leading to returning this + +DH, others: Concern from various members of the committee about returning primitives leading to breaking long-held invariants + +Realizations: + + - Broader concern: ES2015 and this proposal both ensure that objects are always returned from new; the question is just does a primitive return this, or throw a TypeError + - DE: Web compat may not be so big of an issue since this only applies to ES2015 class syntax, not ordinary function constructors + +### Conclusion + +Yes on the PR, though we will have to take web compatibility feedback into account as implementations attempt this + +## [Always update object properties if property descriptor is applicable (NaN issue)](https://github.com/tc39/ecma262/pull/353) (DE) + +DE: This PR makes writes of a new NaN value to an existing writable property in an ordinary object take effect. That way, a non-canonicalizing implementation like V8 does not have to do a check on ordinary property sets to meet correctness. It continues to prevent information leaks on nonwritable properties by making those writes not change which NaN is there, though return success. Seems like a great change towards web reality while keeping both implementation constraints and desirable language properties in mind. + +MM: Sounds good to me + +DH: I'm uncomfortable with making this sort of change; the semantics for NaN observability and canonicalization seem weird + +DE: The spec text is weirdly written; it warrants a refactoring. + +BT: Didn't you promise to do that at your first meeting? + +DE: Sorry I haven't done this yet; it's something that I was planning on doing if/when SIMD.js reaches Stage 4. + +DH: I'm not sure if your refactoring makes sense either. + +### Conclusion + +Discuss more later. Agreement between DH and DE that this is lower priority than many other items on the agenda. diff --git a/es7/2016-05/may-24.md b/es7/2016-05/may-24.md new file mode 100644 index 00000000..c7dc195c --- /dev/null +++ b/es7/2016-05/may-24.md @@ -0,0 +1,1031 @@ +May 24th 2016 Meeting Notes + +## Attendees + +Brian Terlson (BT), Dave Herman (DH), Michael Ficarra (MF), Jordan Harband (JHD), Waldemar Horwat (WH), Tim Disney (TD), Shu-yu Guo (SG), Mark Miller (MM), Kevin Smith (KS), Michael Saboff (MS), Eric Faust (FST), Chip Morningstar (CM), Daniel Ehrenberg (DE), Leo Balter (LB), Yehuda Katz (YK), Jafar Husain (JH), Andreas Rossberg (AR), Ben Smith (BS), Thomas Wood (TW), Alan Schmitt (AS), Brad Nelson (BN), István Sebestyén (IS), John Neumann (JN), Domenic Denicola (DD), Jeff Morrison (JM), Louis Lafreniere (LL, via Hangouts, part-time), Dean Tribble (DT, via Hangouts, part-time) + +In the morning we've had 22 Face-to-face participants but Hangouts is not switched on yet. + +After 11:00 the Hangouts was on: + +- Louis Lafreniere (LL) from Microsoft Redmond. +- Dean Tribble [tribble@e-dean.com] also joined part-time + +From Google local experts as observers: Hannes Payer, Jakob Kummerow, Ross McIlroy, Michael Hablich, Yang Guo, Taon Ver Naest, Daniel Clifford, Nikolaos Papaspyrou, Jaroslav Sevcik, Deepti Sharma (all part-time) + +## [Always update object properties if property descriptor is applicable (NaN issue)](https://github.com/tc39/ecma262/pull/353) (DE) + +DH: Summarizing issue + +In order to be able to talk about a bit pattern of NaN in a reliable way we need to know where canonicalization. Canonicalization is a chaotic operation. In order to reliably predict the bit pattern of a NaN, we need to know all the places we can go from a known bit pattern to an unknown bit pattern. + +YK: If you would like to assert that if you write a NaN and want to read the same NaN back…? + +DH: Every place where data is transferred through the semantics you have a source and a sink, anywhere where data is flowing, if you have an input that is a bit pattern and there are one or more outputs or ways to read the outputs the output operations need to know you have the same bit pattern as input. + +WH: Storing into a variable is not of those things. Storing into a variable does change the bit pattern. + +DH: We need to enumerate this. IS the only place we allow canonicalization is reading/writing from a float64array + +DE: More pedantically: per 754, the NaN payload is unspecified so it's not canonicalization in that sense. + +DH: Plus does not guarantee any of its inputs. It's making a new value. Anywhere a new value is created out of thin air we can simply say it's allowed to pick a bit pattern. A sensible way to spec this is eveyr NaN value carries with it a bit value. + +AR: I don't think that's true + +DH: We need to enumerate the places where a value is passed into an operation and is required to be preserved. We can say we have these traces where bit patterns are stable, but otherwise NaN is completely unpredictable. + +WH: An implementation that does NaN-boxing must have canonicalization on every possible path between bit patterns and variables. If it contains a path that doesn't normalize NaNs, then it's buggy. Thus in some sense it's moot where canonicalization happens — its exact location (whether on reading from a typed array vs. later on storing to a variable or passing as an operand) should be unobservable on a non-buggy implementation. + +YK: Are you saying you want canonicalization allowed at any point in the system? + +WH: There must be a canonicalization somewhere in every possible path between arbitrary bit patterns and variable storage.... + +YK: There is only two places where this can happen. The fact that there is a canonicalization for something like the plus operator doesn't mean we have to spec it. + +DH: Comes down to this: you can think of NaNs as having one extra bit for whether its trusted. If an impl wants to allow an untrusted NaN in variable storage to flow through the program, then we need to disallow canonicalization. But we don't want this. We want to canonicalization in places where we can get an untrusted NaN. + +DE: Can we scope this issue to the PR? + +YK: In the absence of explaining what is appneing with the untrusted NaN in the first place, the change is not saying anything. + +DE: I would be ok with waiting on andre bargull's PR until we have time to address the NaN canonicalization, but since we don't have spec text we don't know what is being proposed.... + +WH: SIMD doesn't do canonicalization. + +DH: We were trying to propose that two different implementation strats were valid. We want to understand how both these strats should work.Non-determinism is sufficiently tricky topic that we should try to understand it. Fine to accept the PR but it's worth rying to understand it. We have enumerated 3 of 4 places where untrusted NaN's can flow in. + +YK: In the absence of nailing down the trusted and untrusted NaN thing, we can't nail down what the PR is saying. + +DH: Technically true. But we want to unblock v8 from doing the improvement they want to do. But I worry. We think it should hang together but we don't know. We should do the work. + +YK: I think trusted vs. untrusted semantic is pretty close to what we want.... + +DH: I Don't think you want trusted vs. untrusted in the impl, it's a model of the implementation that allows us to think about it. Spec shouldn't talk about an untrusted bit for NaN. + +DH: Canonicalization exists because a NaN might look a pointer. + +WH: You could make an implementation where canonicalization happens when reading into a typed array or storing in a variable or passing as an operand and they would be indistinguishable +DH: The job we have here is to define the spec. Spec is incoherent. We can draw no conclusions (or any conclusions)/ + +WH: Spec was written with the conscious decision that NaN's were indistinguishable... + +DH: That was 7 years ago. Ship has sailed. Says in one place that NaN's are indistinguishable, and says they are distinguishable in other places. + +DH: We can reason from spec or reason from implementation. Impls are OSS, if you can know where all the canonicalization occurs, you can simply avoid them. + +WH: There are so many of these places you might not be able to avoid them. + +YK: If an impl is required to canonicalize in these places, WH is correct. But we're not saying that. + +DH: The spec doesn't give us the answer to this question of when you can canonicalize because the spec doesn't say when you can canonicalize. + +MM: The important point is that eveyr point we don't state you are allowed to canonicalize that we are demanding you are not allowed to canonicalize. + +DH: Right, Dan suggests that each NaN value carries with it a bit pattern. And unless otherwise explicitly stated, that bit pattern remains consistent as it flows through the system, and there are a fully enumerated set of places canonicalization can happen. We should define those points. There are Math operations. Synthesized NaN values out of the blue === they can choose whatever bit pattern. There is reading from a float32Array or float64Array. SIMD. + +WH: The spec says that there is only one NaN value. We have had this discussion before and the solution that we reached when we introduced TypedArrays, we don't say what bit pattern you get when you write a NaN into a typed array. + +MM: I remember doing that, but it was in a later meeting that we were talked out of that and instead we were talked into the position that SameValue is no longer a test that NaNs are the same value but it's an equivalence class such that all the NaN values are in an equivalence class but a particular NaN value is preserved. + +WH: This doesn't seem well-defined so I'm not sure what that means... It won't be coherent. Then you have to define in the spec where you preserve the value or not. It's infeasible where you start introducing stuff like sort or other higher order algorithms since those algorithms rely on SameValue being identity. For example, for a set, if you insert a NaN into a set, is it the same NaN or not? + +DH: That's just reality. TA's allow you to distinguish NaN. + +MM: Sets are a great example because sets already use a larger equivalence class (SameValueZero), and set semantics are trying to be deterministic. +/- zero are distinguishable in the language, but sets treat them as equal, so is using a larger equivalence class. + +MM: Two successive observations of a value across steps that just shuttle along a value should not observe different bit patterns. + +YK: I agree with this invariant and we should specify it. You are just saying a more rigorous version of what I am saying. People assume it is true, so we should specify it. In the absence of having said what you suggest the point is moot. + +WH: This is incoherent in the case of idempotent canonicalization. It's unobservable. + +MM: Reading a bit pattern into a number, I'm expecting to allow the implementation to create any bit pattern it wants. It's not subject to the rules that I've described. Reading a variable is a place where I want to preserve identity. + +WH: How would you observe the canonicalization of storing one variable into another? It would be shadowed + +MM: Take a NaN value, serialize to a bit pattern, remember said bit pattern, then take that variable, pass it as a parameter, store it to another variable, do all these other opaque steps of conveyance, then we serialize it again. If the two bit patterns are different, then this demonstrates that an implementation fails to conform to what I want. + +WH: it would be good to always canonicalize. On the other hand it may be the case that your arithmetic primitives might produce a new NaN value. + +MM: I am perfectl yhappy to say that unserializing a bit pattern into a NaN may give us a different NaN. Not willing to have conveyance steps produce a new NaN. + +WH: If you read it into a typed array and write it into a typed array, you might get a different bit pattern. + +MM: That's fine. When you usserialize a NaN you can get whatever bit pattern. + +DH: PR is good. As long as we all agree we want to specify that NaNs carry a bit pattern with them and is by default stable and we want to enumerate places we can do canonicalization. + +MM: It's not an issue of canonicalization. We want to let them use a different bit pattern. + +DH: Agree. Canonicalization is the wrong word. + +DE: Volunteers to write spec text about how NaN's flow. Also known as "scrambling semantics". + +WH: MM's proposal would preclude important optimizations for implementations that do partial NaN-boxing. Example: + + f64 → v → f64 // Copy an f64 from one place to another in a typed array + + We want to be able to do this without canonicalization or scrambling or NaN-boxing conditionals + + But now if someone copies v → w → f64, the implementation might want to fall back to NaN-boxing and store a canonicalized value into w. + +MM: Yes, optimizations like that would be precluded. + +DE: Don't want to preclude optimizations + +## Syntactic Tail Calls (BT) + +BT: Summary of existing PTC issues: elided of Error.stack frames, lack of obvious developer intent for tail calls, (see details in proposal). + +... [_discussion about syntax_] + +YK: let's discuss syntax after we've agreed to do STC + +BT: this is the gist of the proposal: continue in expression context; static semantics that leverage existing "is in tail call" spec semantics to precisely define the places where you can make a tail call. Thus, you get a syntax error if you try to make an invalid tail call. `return continue` is the easiest option/smallest modification to the grammar we've thought of. We also considered `return.tail` or similar. + +[_reminder to ignore any statements about specific syntax, for now_] + +CM: rephrase: STC allows the programmer to mark specific calls that are in tail position, to convey intention and desire for PTC, and the implementation is required to apply PTC. If they omit the affordance, the implementation can still choose to apply PTC, or not. Simply to provide a marker of programmer intention which impls must honor, and relax the requirement where unmarked? + +BT: correct. + +AR: worth noting that v8 has an implementation of this (only PTC is in Canary with "experimental JS" flag, command line flag is required for STC) + +YK: I dont understand why we ... . It seems like there is a coupling of the relaxing of the PTC feature with the STC feature, this concerns me. + +DH: we were concerned about honoring the consensus process and not lightly pulling things back that were already in the spec. Instead of pulling back PTC for some "future STC", we wanted a concrete STC approach first. Maybe at some point it makes sense to separate them. + +YK: Are you propsosing stage 0 today or stage 1? + +??: It was already moved to stage 0 at last meeting. + +BT: I think this proposal is good for stage 1. + +YK: To whatever extent consensus requires for stage 0, I think this does not exist yet. I don't like that we're trying to bus relaxing PTC with STC. STC needs to be considered on its own merits. My positions on PTC and STC are unrelated. + +AR: I don't think it makes sense to discuss these things in separation. I think the right way to look at this is as an erratum to ES6. + +DH: I would never be ok with new syntax as an erratum. New syntax is a high bar. + +YK: I don't think STC is strictly better than PTC. I don't think it has strictly less problems than PTC. + +DH/AR: I don't think anyone thinks that. + +DH: PTC is one option, STC is one option, and none of the above is on the table. + +MS: Another option is that PTC and STC can coexist. + +YK: Status quo of reality is none of the above, but there are real world requirements for it. + +AR: V8 is blocked on decision from this committee to ship. + +YK: PTC/STC or none of the above? If none, there's nothing to ship. + +AR: I don't think there will be consensus for such an option. + +MS: Can we eliminate no tail calls? + +DE: it may be that we're not settled on a particular syntax for STC, but that we really see the disadvantages for PTC. v8 is not announcing any particular shipping plans - we want to consider the entirety of this discussion - and we're eager to see consensus. + +YK: I think this claim misses the empirical story. STC requires consensus. In the absense of STC , if any implementation refuse to ship PTC, then reality is that essentially no web reality for PTC. + +MS: I did not sense that this is the case. + +AR: We want a decision, whatever the decision is. + +DH: I agree to the consensus to accept PTC, but I don't accept the requirement to ship PTC. + +YK: some implementations are refusing to ship PTC. If vendors agree to ship PTC then this would change my view. + +DE: If there were a broad consideration from the committee that we don't want PTC then implementations would take that into account. + +YK: How does Microsoft feel about PTC? + +FST: There is a war on between implementers over spec compliance. + +YK: Pragmatically is is true that implementers can just not implement the features. + +CM: Is anyone advocating none of the above? + +YK: I have more concerns about STC than PTC. + +YK: Stack traces are a problem, it affects analytics, you can try hard to use PTC but not get feedback from it. Concerned that can make mistakes with it but not know. + +DE: Is Error.stack used by glimmer? + +DE: What would be the impact of missing stack frames? + +YK: I think the problem with Error.stack is about analytics tools that are expecting to inspect the entire stack, and they get confused by missing stack frames. + +YK: Ruby has PTC, but off by default, which I'm happy with. I am allowed to champion none of the above. I'll have trouble. I'm persuadable on STC, but don't want S0/S1 STC to means S4, which I think some people want. I want to be able to object to S2. + +BT: Thread on Github: https://github.com/Microsoft/ChakraCore/issues/796 + +On x64, we currently use windows ABI, has some constraints, if we do not relax them, we wouldn't be able to implement this feature faithfully. We can't grow stack frames, if we can't we have to use call to increase size of stack and there's a pathological case of argument number growth and run out of stack space. + +From a perf standpoint, perf would not be better as JSC has found, maybe slightly worse. You could change callling conventions, but louis can say more about that? + +MS: How does STC solve your problem? + +BT: it doesnt, but scopes problem to specifically one case. + +YK: In the sense you;re note able to implement PTC then you're not able to implement STC. + +DE: One strategy is to implement a large stack frame to allow for it to grow. An intervening return will give more stack space anyway. + +MS: It's the same thing as “is in tail call position”. + +DE: Explicit tail calls don't exist in existing code that don't intend to recieve a tail call. So you can do more risky things. + +BT: I'm not sure your implementation strategy would work in the progressively growing stack trace. + +DE:: How do yoy know what's big enough. JIT? You can always construct programs to progressively abuse larger stack frames. + +MM: Would you expect to faithfully implement STC? + +BT: Potentially not, but It changes the tradeoffs + +DH: I've just transiitoned closer to the none of the above option. + +MM: I really don't want to transition to yet another consensus that we don't implement. +If you can state the way you're not expecting to implement the feature faithfully, please put it into the proposed spec. + +DE: I don't think there's any impl that passes 100% of test262 performance tests for PTC. + +MM: we don't go into the process of proposing things we don't expect to implement. + +DH: We started with the aim to give some perf/space guarantees, but then we decided that's not going to work so we decided to give a syntactic guarantee, but now we've decided we don't want to give that gurantee? + +BT: I want to give the guarantee. + +MS: We should not consider proposal that we don't want to implement. + +FST: But we can't faithfully implement what we've got. + +BT: Our x64 implementation can't grow our stack frames due to the Windows ABI. Performance is not good, and syntax help in that case. + +LL: The main thing on perf is the only case it could be a perf win is tail recursive case, in all others we have to check a call is a jump to a function with a jump to callback(?) need a test at the bottom for parameter count. In terms of stack space, if calling out with same number or less then fine, but more will cause break, no way to change return address of caller , breaks unwinding mechanism of window. Rely heavily for excp handling , stack locks(?), telemetry etc. + +SG: is it the windows stack unwinder? The stack that is outside the scope of JS? + +LL: Yes, windows stack walker, we follow the ABI for telemetry, the windows stack walker. There's also downsides in code size, because we don't know # parameters, we have to handle this every time there's a tail call. + +YK: Is this the same thing as saying we're requiring all JS impls to have their own stack unwinding mechanism? If the windows team says they're willing to change their implementation, then it'll just be future implementations. + +DE: I think it's relatively hard to change an ABI that is used by many compiled programs. Are there are more implementation issues that may be interesting to us? + +LL: No. + +DE: How might STC change this? + +LL: it does not remove the problem, but it helps a bit. We could allocate some stack space when we see a tail call, and allocate less than required by frames. + +DE: Spec guranrtees asymptotic stack size, so provided the bounds of the growth are better than linear, then it's reasonable. + +MM: if there is no asymptot that is approached, it is not compliant. + +MS: Log growth is not spec compliant, but not useful for the sorts of programs this is intended. + +SG: for the spec, there is no such thing as half compliance. + +DH: has a programmer, are you going to use these features that sometimes work, or will you fall back to a loop? + +SG: It is useless to talk about anything with space, the spec assumes infinite stack space, is this a well defined spec question? + +DH: Perfect is the enemy of the good. Literature on this requires a complete cost model with a lots of complex formal semantics detail. We don't want this in ecma262, too complex. We can specify this morally. We don't have to be mathematical here. + +MS: if the spec is written in such a way that recursion can continue indefinitely and Chakra cannot do it, then it is not compliant. + +DH: I agree, there has to be human judgement to do this. + +YK: The alternatives are manual versions of the same thing, stack data structure or tramoline, these things have guaranteed space. I would be happy if these data structures are specced then I would be happy with STC over the engine's choice. + +AR: Those space gurantees don't apply to the general case. + +YK: Once I notice I have unbounded input, I do a data structure version of the same problem. In all cases, I do know the cost model. I do not understand the cost model of PTC. + +DE: We heard last tinme that tail calls are hard to implement from SG and Eric, this would be good to recap. (Cross-realm) + +SG: we reached consensus on this + +MS: A cross realm growth for the stack is fine. + +YK: I assume it is not the case you can observe something from the same realm. + +MM: By construction you can. + +YK: what guarantees am I getting from the implementation? + +MM: if you call something that allocates stack, that itself make a tail call, altogether there is allocation even if I tail call that. + +YK: If i write mutually recursive code, and someone reogranises my code so that some of my functions now in different realm? + +MM: This becomes no longer a tail call. + +MS: if it's cross realm, it's not tail call and it's fine. + +YK: Manual techniques vs tail calls, manual are easy to gurantee the cases TC less easy. + +MM: Over cross realms, it is possible to cross a membrane boundry, the fact it is no longer asymptotic space, it is not a problem? + +YK: What is surprising is that if you write a program is TR, and a membrane is introduced is is unsurprising . You need to consider whether someone can introduce a membrane. + +FST: the difference between proxies and cross-realm is that membranes are actively inserted + +YK: Given the options, the fact that introducing a membrane makes it no longer TR, it makes this technique less appealing. + +MS: this is considered rare. It's not perfect but it's acceptable. + +YK: I am the target audience because TC is a rare benefit, and being uneasy about the choice between TC/manual data structures, I will opt for manual. + +JM: Do we agree that exceptions are cross realms and membranes? + +YK: One also has to structure their program to use TC. + +MS: Lets move on. Slides +As the first implementer of tail calls, we think there's lots of invalid fear. BT asked for data, so here it is. . + +AR: (Google Search is mostly sloppy mode, hence only 29 TC calls compiled.) + +MS: The reason for showing this, today we're looking at 5% TC. We're talking about 1/20 missing things from stack frames etc. In terms of % of performance loss, my understanding of perf loss is only for TC? + +LL: That is correct. + +MS: I'd like to approach each. We have seen no issue with TC perf. Most work was Calling convention changes (6 weeks). + +DE: v8 perspective: a lot of optimisations in various compilers, not enough implementing in certain compiler tiers -- all tiers required changes. + +MS: Zero-sum game for general web? + +YK: Any time spec chanes compilation tier, there's a significant cost? + +DE: Yes + +CM: you're measuring accidental tail calls, not calls that were meant to be there. If people are aware, this percentage is going to go up. + +MS: In general the concern about tail calls in general web going to hurt .5%? I don't think it's a valid concern, hard to measure that level of perf degredation. + +YK: A 10% slowdown is significant enough to beat with manual code. + +MS: We describe late where we get performance wins. + +YK: What do implementations think the actual slowdown is? + +MS: We think 0%, according to our experience and the Chrome experience. + +DE: Except micro-benchmarks. + +YK: 5% of calls are acidentally used? if we made STC opt in, would people use it? + +MS: STC does not resolve the performance issue, and if PTC is used, all browsers will want to optimise it. + +YK: Firefox people: given you have not implemented PTC, would you implement STC optimised to a level equivalent to PTC? + +FST: yes. + +DE: For v8's part, we have considered whether it was required in all compiler tiers, if it were with explicit syntax then you could say you have opted into a particular compiler tier. + +AR: But you can do that with PTC too. + +DE: STC has a lower implementation load to ship it. + +DH: If implementers say it's going to be easy, we don't need to optimise, it's going to be competing with loops for developers standpoint. If it's not performing well, then people won't adopt. Since 2 browsers have aggressive optimisation, there'll be competition over it. + +MS: we did not do aggressive optimisation, we just implemented it. + +DH: The things to compare are people writing loops manually vs TR, not PTC vs not-PTC. Do you think you'll get compariable perfomance for current TC implementation vs loops? + +MS: we don't know the answer yet. + +DE: Within an impl, you can do things like alloc registers for a whole extent of a while loop rather than TR loop. Some can, but in a naieve implementation you don't often have enough info at all tiers. Engines prioritise optimisations based on whether we think these will be used. + +DH: it's a relevant concern for developers, they should not think it will slow down their code. + +YK: relevant comparison is with loop + stack. STC feels like a perf regression for me if I switch to it. + +MS: the more relevant concern about TC and performance is whether developers will adopt it. + +YK: I agree that is the goal. + +DH: That's not what got consensus, more ad-hoc, code generators won people over, not styles of programming. Transpilers can do their own data structures if they need. + +AR: necessary for compiling languages that use this + +DE: the trampoline pattern is already used on the web (js_of_ocaml, closure compiler). + +AR: ...and its performance generally sucks. + +MS: Lets move on . We have to swallow loss of perfomance + +FST: we could not implement the feature with cross realm without API changes. Microsoft could not implement this feature with no performance cost. + +MS: Not ability to implement, but how it slows me down. + +DE: I don;t think this will be revisited for much more ES2015 features. All have implemented much of these features. Some Es2015 Compat things such as TypedArrays need revisiting + +MS: if performance is a reason to re-consider something in the spec, it is not a valid concern. + +YK: PTC is targets at making a power-user pattern more ergonomic, and it actually makes it slower is a serious concern. + +FST: Implementers have been able to bridge Class performance gap with transpilers etc, but we cannot do this with PTC. + +DE: To continue the point of limited features to revisit, those couple of things may. We don't consider S4 until feedback from 2 impls, we shouldn't worry about features going in and being removed, we need to get S4 ratification from implementations. + +BT: There is precedent: we removed Reflect.enumerate for performance reason. + +MS: High bar to remove stuff, I worry the bar is being lowered. + +YK: Almost everyone has implemented almost everything of ES2015, except PTC, the bar is high here. + +JM: reality leads, not the spec. Nobody shipped TC yet. + +AR: Can we all agree that performance is not an issue? + +MS: 2.6x speedup for some benchmarks, possibly x86 CPU caching/returned stack. We did not expect this, and got this. +Implementation perfomance is not an issue. + +DE: Was there other Chakra perf issues raised? +BT: x64 perf likely not good in many cases, simple mutual case about even, but initial concerns over x86 perf have been addressed. Was that it? +DE: Yes + +MM: I understand reason why a faithful impl seems impossible is unable to predict max size of stack frame. What if threshold size stated such stack frame that would need more space than threshold only allocated on the stack, but further space is allocated on the heap and subject to GC. I think you would achieve the asymp space complexity required by spec. A large threshold would make this a rare case, so GC overhead wouldn't make slowdown in practice. + +BT: you're trading off the same thing, either you get an out of stack space error, or the program slows down substantially. + +DE: Wouldn't this be a different ABI? + +BT: it would also have implementation constraints. Many tools would have no idea about the stack spillage sitting around in the heap. + +MM: if the total number of arguments and local variables is over 1000 … + +DE: Math.max.apply ([_large number of things_]), in v8 that works up to 16k. We don't do somehting different for apply from normal. + +MM: Choice of large number of arguments + locals, such it is rarely hit to exempt from TC vs completely giving up on normative TC vs accepting some kind of TC unfaithfully implemented. + +DE: at this point we are adding more concerns for programmer: are they using a cross realms, are they using the good number of arguments? Should we throw an exception or silently drop out of TC for STC. + +YK: if we have a syntactic feature that does not throw an exception, I have deep issues with it. + +FST: No intuitive knowledge of membrane use inside SpiderMonkey by programmers, so same code may throw under different engines. + +DE: The argument ceiling seems very random +MM: I wouldn't have suggested it except for Chakra. You're not obligated not to allocate. + +YK: If i write code using STC using V8 or JSC and I don't know about the restriction, but it blows up without my knowlede on Firefox? + +MM: I write call using STC, and you're calling across a membrane that is not using STC. If the implementation is good enough to do tail call optimization, it might still work. + +YK: if you write STC syntax, you don't have guarantees that it will be in tail call. + +BT: In practice number of locals + args for TC would have to be pretty small. We wouldn't want to allocate the max amount of space all the time. Not feasible option. + +DH: I want to understand the Firefox issue. There is a practical difference between PTC and STC for security proxies. We can't reject statically a cross-realm call, even if we explicitly asked for it (STC). + +BT: Depending on "ask for", some people think the point of PTC was this if they use explicit tail call position. + +DH: this is a question of predictability. + +__*LUNCH BREAK*__ + +MS: [_PTC debugging concerns_] + +JSC has implemented ShadowChicken, it is enough to create a shadow stack for the developer. We save only the deleted frames in ShadowChicken, we save 128 elided frames. We chose 128 because it is a good balance, users don't want to see all the elided frames. we synthesise the elided frames by reinserting them into the existing stack. This is only in debugging for now, no Error.stack. Not in the tech preview but in nightly. + +MM: I thought there was some GC non-determinism? +DE: This was only my misunderstanding. + +MS: If we run over 128, we save only the last ones. + +YK: does this apply when the developer tools are not opened when the exception happen + +MS: If the inspector is open, the frames are collected. + +DE: the developer tools have to be open for frames to be collected. + +YK: I think this is probably fine. + +??: Also the webkit remote inspector exists, so streaming of debug is possible. + +MS: Shadow chicken is invoked when remote inspector is connected, not familiar with developer tools internals though. An alternative is to turn off tail call to debug. + +YK: Disabling PTC is not an option as you'll then not catch errors at the end of a long TC. + +MS: We don't think that debugging issues are a show stopper, we can do it with tools open. + +JM: if we find concerns with dropping frames, then we can compile away the tail call for that code. + +MM: Lets say PTC & STC, if the syntactic marker is taken to do 2 things: static error if not a tail position, in addition I'm not interested in accumulating the tail stack frame for debugging purposes. Say the ShadowChicken elided frames are only for PTC and not the marked STC, then we get close to the reliable stack frame that people are expecting. + +WH: Difference with plain STC? + +MM: you get stack frames up to 128 only for PTC. + +DE: What's the advantage over doing this for both? Once we have syntax there seems no advantage in not using syntax. + +MS: you still need to save the frames in STC for the error stack or for debugging. + +MM: The kind of stack traces you're collecting for promise, is that only after 128 frames you loose elided tail calls, which seems good to me. + +MS: are you assuming you would not lose any frame with STC? + +MM: they would always be lost. The PTC tail frames that are not STC marked would be all kept in a pure STC system, and only the 128 more recent frames would be kept in a PTC + STC system. + +MS: Our intention is to never use ShadowChicken when the webinspector is closed. Performance overhead of 8-10%, also a memory user. Scope chain copies keep live locals that could be collected. + +MM: I'm only concerned about PC rather than variables. + +MS: Main advantage of tailcalls is that locals can be collected after the call. + +YK: any modern testing framework will report the stack frame when there is an error. It is important to understand the path taken through the code at the error. You don't want to lose frames, even with STC. + +FST: comment about debugging intent for code authors vs code users: user may need stack frames when author doesn't. + +MM: Just in the same way the author of the code makes the decision to use a loop rather than a call without considering the user. + +WH: If you write a while loop, you'll always have one frame of your library. If the library uses tail calls to callbacks, it's possible for the library to wipe itself off the stack completely. + +MS: Error.stack is not dependable. It is inadequate if we're arguing about telemetry concerns today. +[_Simple Error.stack test_] There are already concerns about using Error.stack for telemetry today. + +DE: we should see about improving these things. + +MS: So, we shouldn't be using this as an argument to not implement TC. + +MM: the current behavior of Error.stack is non deterministic, it differs between browsers. + +MS: And between releases too. + +MM: It is good to have in mind what we want Error.stack to be for the co-design for TC. + +MS: It is telemetry in general, not just Error.stack. It may be worth considering speccing something especially for telemetry. Not just who-called-who. + +DE: I would rather not have to regress what we have, because we already shipped these different methods to get information about the stack frames. + +MS: [_PTC Telemetry concerns, last point_] Just speculation that telemetry will be broken if TC are implemented. + +YK: Don't use TC is not suitable answer for broken telemetry with TC. + +_General agreement._ + +MS: But, we have no known breakage. + +YK: Error.stack used in a bunch of ways, one is telemetry, reporting errors to console when promise rejected or async, stack trace for thing that has happened. One problem that will happen is when you have a library that uses STC and then the library will be hidden from the stack trace. + +DE: Error.stack used by Google in application frameworks, collected and bucketed, looked at by devs to resolve bugs. Not a website breakage concern. + +MS: you won't be able to aggregate. + +YK: Native frames are never the source of your bugs. + +Multiple: Not true + +YK: Are we adding more cases to when frames are elided. It is not speculative that a developer does not want more elided frames in their stack traces. Some companies may begin to avoid using libraries with STC because they need the telemetry from calls. + +BT: F# has tail call. You can deploy F# to windows store. There is an app insights tool that does telemetry, and that was impacted by F# apps. The solution was to say that you don't get stack traces for these tail call using apps. + +SG: Do people who put apps on the app store always opt for the telemetry? Or is this thing just that exists? + +BT: We have sufficient evidence that telemetry is impacted by eliding frames. + +MM: VMs have a very minimalistic instruction set, explicit loop construct which is the only difference from a normal set. The designers wanted a very explicit contract with the user when they want to see stack frames. Calls should always generate frames, loops not, they wanted to be explicit about this. User experience through the debugger is an important part of language design. + +MS: there is tail call in C++. We get telemetry with frames elided, we deal with these. + +FST: By turning off the optimisers. + +MS: Even so, we are able to just from the telemetry, without necessarily recompiling. + +DE: you reason about which things are inline, and which things are tail called. + +MS: typically you care about the last 5 frames. That is sufficient to get the job done. + +YK: we dont necessarily want the c++ debug experience to be that for Js developers. You aren't necessarily able to do this reasoning all the time. + +WH: Lots of experience with lisp debugging, and in most cases turning off TC worked. However, it didn't work when I was using libraries that were deeply recursive. In those cases getting the last 128 shadow chicken frames is not enough — it shows all the frames near the leaves, but I often needed the information elided in the base frames. + +YK: Sometimes the error occurs in the base frames, sometimes in the middle, sometimes in the leaves. + +MS: In nightly since October. + +BT: Regularly open the dev tools after error occurs, not always able to refresh to reproduce bug - don't want to lose state. + +JHD: JSC used to have different optimisation levels with debugger open or closed. Very awkward to debug in this circumstance. + +_Etherpad went down for a ~minute_ + +_Discussion about an API to get better debugging_ + +YK: imagine you have a library that wants to use STC … you will want to see all the frames to debug your code. + +DE: A more reasonable usecase is not to see your loops but to see nested stack frames, A callback into user code could be problematic. + +YK: It is not always the case that you need to know that you need to turn ShadowChicken 'mode' on in order to collect STC frames. + +DE: I would encourage library authors not to do a tail call into a callback provided by the user. + +YK: Some coordination about turning on ShadowChicken is something that everyone has to consider, whether QUnit does it, or telemetry apis do it etc. + +DE: does shadow chicken change the behavior of Error.stack? + +MS: not implemented yet. + +YK: 128 frames not sufficient + +MS: arbitrary chosen constant, can be changed. no imlementor wants shadowchicken on all the time due to overheads. + +MM: Regarding Error.stack and telemetry, the only thing relevant is the program counter. If you had a 128 cycle buffer with just the PC in it, it may have little overhead. Depending on the detail of Error.stack + +YK: how can the user decide whether to use the feature, if they're not sure it's going to work as expected. This is more the case for PTC than for STC. + +MS: Last two points on slide are the crux of it for me and JSC. + +YK: there are at least two implementations with problems. + +MS: If we are willing to say the spec has less value because of the process in place at the time stuff went into the spec it is disconcerting. JSC didn't get the memo saying that other implementations weren't doing this. We implemented this because it was in the spec. + +FST: It is not my motivation to state that we're trying to ditch this feature because we're not planning to implement this. + +YK: Why did you say that cross realm does not require a state change? + +MM: I don't believe the spec change that cross-realm requires has the controversy that others do. + +YK: I disagree. The spec has to be changed to say that tail call does not work across realms. + +DE: I think the change has consensus to say that TC doesn't work across realms. + +FST: Web developers don't know that TC doesn't work across realms, even if we do. + +AR: there are many other things that do not work across realms. + +KS: I think there's consensus to changing the spec regarding cross-realm, the spec should not change from PTC to STC, or to remove PTC. + +YK: Basically this feature cannot make stage 4 because it cannot be implemented by 2 browsers. + +MS: It is. + +CM: v8 has it behing a flag. Chakra have not started it, but they have a strategy that could work for me as a user. + +YK: they cannot implement it in SpiderMonkey because of cross realms issues. A serious change is needed no matter what. + +BT: Why was the PR rejected then? + +MS: The reason the standard exists is to agree on behavior. I agreed on Firefox request because it allows them to participate. + +_etherpad down, 30s_ + +YK: I think that if people use realms/membranes much more then I find that it does damage to STC/PTC, and this is not good. + +CM: motivation to get tail call and motivation to get cross realm are orthogonal to each others. + +YK: I think people will use realms by abstraction, the decision about where computation will be placed may be handled abstractly. + +MM: when you package things with abstractions, you put intermediaries between the caller and the caller. A tail call into the abstraction is a tail call into the packaging, so you don't get guarantees. + +YK: I agree, this is the essense of why I disagree with CM. These abstractions may be brittle, I suspect it will be a problem. + +MM: would you opinion be different if we said normatively that there is always a membrane between realms, but that it may be optimized away. The call site that is doing the call to cross realm is tail, but you don't get the asymptotic behavior as the guarantee is not preserved. + +YK: v8 has to fake that, + +MM: Eliminating the membrane is TCO. If you're doing an STC tail call into a non-... + +YK: the problem is that such cross realms tail call may work in V8, but would not work in Firefox + +FST: Back to MS point, we've heard from implementers and users, and we still stand at an impasse. + +DE: I think when safari ships release, when google has users in number largers, we're more likely to see missing frames and dev impact. + +YK: Web compact does have an impact. Telemetry will start to work less well, and we'll not immpediately notice a webcompat issue. + +DE: there is no way to collect data right now. + +YK: I disagree it is purely speculative, TC inside of a promise, you'll miss frames. + +KS: We're past that point now, that's a stage 2 concern. + +DE: more developer flow compat than webcompat + +YK: people rely on Error.stack, and it's not clear how people will deal with it not working. + +DE: Can we talk about value of STC over PTC. Use cases that are important solved by STC not PTC. Leaving aside surface syntax being objectionable. 3 presented on GitHub, but I disagree. + +DE: The performance optimisation starts being valuable after a certain point. + +JHD: To confirm, you're looking for any use cases that are PTC works and STC does not work? + +DE: are there other cases than the 3 we considered where PTC works and not STC? + +YK: Is there a production implementation of something where someone would use STC in preference over PTC? + +DE: are there cases where STC would not work? + +YK: I agree that STC satisfies transpilers, but there are questions about the syntactic cost. + +MS: STC doesn't really solve the issues that have been raised. It doesn't take care of the telemetry and debugging issues. + +These issues have already been tackled though? + +FST: Broken realms worse with STC due to intent, but the brokennes is also horrific due to PTC. + +YK: I don't have a mental model to write a PTC program. I can imagine how to do it with STC. + +DE: To respond to performance of debug not being resolved by STC: when user expresses STC intent, user doesn't want to see elided frames as they're looping. "return contunue" doesn't expect a shadowchicken stack. I would advise against calling out to user code with STC. + +AR, MS: I disagree with that, there are libraries that need to do exactly that. + +AR: for instance when you have a continuation as a parameter + +FST: I'm unhappy about implementation specific type errors, MM says he is unhappy with implementations that are being forced to throw implementation specific type errors. + +DE: for debugging and telemetry, the intent to do a loop or continuation means that we don't have to implement shadow chicken. It doesn't affect existing code that didn't intend to use PTC. + +MS: The point about STC, the user wants it but I can't do it, do I throw an exception? + +FST: If someone wrote a module loader with each module in its own realm. This would impose problems. + +SG: what things do not work cross realms? + +MM: For identity of continuity, I would like cross realms to be as little surprising as possible. + +FST: cross-realm tailcalls violates the least surprise for me. + +MM: There are sufficiently strong engineering reasons for inter-realm membranes, certainly since one browser is using them. I want all surprises resulting from it needs to be specced carefully. + +YK: This is one such surprise, existing in ES2015 and unspecced as such. A solution to that problem is to remove the thing that creates the surprise. + +BT: STC would allow real tail calls in sloppy mode. + +DE: It defines proper tail calls in sloppy mode. The user has expressed intent that tail calls should be used so we do not have to update caller and argument. + +JHD: Why is a benefit to enable new features in sloppy mode code? + +MM: It's an old debate. We should have left sloppy mode alone … + +YK: let's not open this discussion, but everyone would agree that make tail calls available in sloppy mode would not be good. + +BT: There is no additional spec, function.arguments and caller will be null when you try and access a frame that tail-called to you. This is the same as currently with strict mode calling into sloppy mode. + +YK: I am skeptical that you can do this and it is an easy change. + +WH: But we solved those problems already in the existing spec, which allows a strict function to tail-call into a sloppy function. + +BT: Strict calling sloppy gets a normal sloppy arguments object. + +MS: what is arguments.caller going to be? + +BT: arguments.caller in sloppy mode when called with Tail Calls in sloppy mode, null. The mental model is that: Tail Call to a function is equivalent to Strict function calling a sloppy function, regardless of mode of the calling function. + +BT: if it's trivial to do (enabling tail call in sloppy mode), what would we not do it? + +MM: I don't want any more investment into sloppy mode where it is not required. + +DE: Current spec text is strict only, for better or worse. + +YK: what is the next step? + +DE: enough arguments for stage 1? + +YK: no. Stage 0. + +DE: Stage 1 = committee has interest in it? A single person not having interest in a feature is not the committee as a whole. + +MM: STC clearly qualifies for Stage 1. Does not mean that I'm in favour of it happening, does imply I'm interested for us to continue exploring it. And that the proposal as stated is a good foundation for this exploration. + +WH: I think we've done as much exploration of the problem space as we can. And I think we're going to find it hard to change opinion here. + +DH: my current opinion of STC is that we're better off without it. If we want to advance something to stage 1 even with several members disagreeing, I'm fine with it. + +FSC: Do you think we could get stage 1 for proposing to remove PTC? + +YK: I don't think that's unavoidable. Considering that we've heard a lot of concerns regarding STC, I think we still need to discuss this parallel proposal for revising/removing PTC. + +MS: I will not support further stages for STC and do not want to waste time by not stating it. + +JHD: there is no point to moving it to stage 1 as we don't seem to want to discuss it further at the moment. + +WH: The thing that flipped STC for me was it not working cross-realm. I was interested in it but not if it sometimes doesn't work. + +MS: there is no proposal to remove PTC. + +DE: I think we have spec materials for the issues with PTC and spec text is quick to produce. + +CM: Removing PTC for the way it was before, or to adapt to address the implementation concerns? + +DE: totally removing all mentions of tail call from the spec + +CM: I would be completely opposed to that + +MS: I would be opposed to that. (inferred) + +DH: We know we would need some changes to fix the cross-realm issue and arguments issue. Either eliminate it, or make fixes to make it implementable in the real implementations. + +DE: What are the fatal flaws? Cross-realms or others? Make the cross-realm a silent failure or exception? + +DH: hearing from Microsoft that they won't be able to implement it … you're eliding the difference between syntactic opt in and syntactic guarantees. + +DH: the thought burden for tail call is large in both case. They're more binary for STC as they are closer to guarantees. + +(discussion & disagreement about whether one would use tail call) + +FST: there are many reasons why calls are not in tail position + +DE: STC is simpler to use than PTC because you get an early error if you request a tail call at a place where it's not possible + +WH: Removal of PTC would have to go through all of the stages. + +MS: the consensus is not about whether we want to keep PTC but if we want to remove it + +MM: discussion needs to continue, and to change we need a consensus to change + +YK: Can't lean on the process without it blowing up in our face. + +KS: If debugabillity of the language in the future is put at risk by this feature, then we should be careful about this change. + +FST: I think this feature violates the hyppocratic oath, I don't believe it has done no harm. + +BT: is the fact that it cannot be implemented with interoperability a harm to the language (cross realm, number of arguments)? + +several: We have agreed on the cross realm exception + +BT: in practice, developer will not be able to rely on tail calls even for calls in tail position + +WH: Number of arguments issue: The spec does not require any particular tail call to be elided. Only the asymptotic behavior matters, so I'd consider Chakra to be compliant with the existing spec. + +MM: The chakra issue can be fit given careful wording of the asymptotic wording. In each call, if the number of arguments does not keep growing, reaches an asymptote, the enlargement of a frame reaches an asymptote. + +FST: we're bending backward to allow some lack of interoperability. + +WH: No need to change the wording for the number of arguments issue. + +YK: I think the cross-realm issue is more serious than the chakra/arguments issue. + +MM: can we take the Chakra off the table as a gating concern? + +BT: So we can interpret the Chakra solution as being compliant with the spec, even though it contradicts the wording of the specification? + +MM: the observable requirement only has to deal with asymptotic behavior + +YK: I agree we can take it off the table, but I don't think that it's a good reason if its only to take it down to one implementation with issues. + +MM: the cross realm issue is an acceptable violation + +BT: The spec currently says "The tail position call must release.... before invoking the target function, or reuse those resources" How is explicitly not doing this, doing this? + +CM: The reason you need to do this is because the arg list got bigger, when it does you need to allocate more resources, the spec does not say by how much. You've increased your resource consumption, but because everyone has to grow frames. + +BT: when we grow our frame we're not reusing the older frame + +AR: but this is not observable + +WH: Releasing resources only matters (i.e. is observable) in the asymptote. If you have a function that calls itself n times with a constant number of arguments, then using Ω(n) space resources would definitely be observable. If the arguments are growing, say you allocate frame sizes in powers of 2 and reuse them until you cross the next power-of-2, eventually you'll reach a max function frame size s, and, important, the total size of all frames will be O(s). You can then do amortized analysis and pretend that the original frame had size s. If you do increase the number of arguments without limits, you're going to run out of memory anyway, with or without tailcalls, because you won't have enough resources to hold even one frame. + +BT: Substantially less in this than other impls. + +WH: You'll be off by a constant factor, which is not a concern as they're not defined by the spec. The amortized/asymptotic calculation of resource use. When you have a chain of frames, each of which grows, you can use amortized logic to pretend the first one has the same size as the last. + +FST: Daniel Slater has written a slew of papers on this, the constants don't matter in the end. + +MM: does this criteria work here? + +WH: Yes. + +BT: I'm convinced that the spec does in fact not require that we have constant space use. If we always reuse the same space when the # of arguments is constants, and increase it linearly when there are more arguments, then it seems that we satisfy the spec. + +WH: My amortized analysis critically relies on implementation frame sizes growing exponentially past some constant threshold. If you allocate a new frame every time the number of arguments grows by 1 from the previous frame, then you will indeed violate the spec because the total size of frames (1+2+3+4+5+6+ ... + n) is proportional to n², which exceeds O(n). On the other hand, if you allocate frames using power-of-2 sizes past some constant threshold, and reuse prior frames when they fit, then you will use amortized resources (1+2+4+8+ ... + n), which is O(n) — in fact, it's less than 2n. + +YK: Summary of the major points: several issues reported during implementation. Arguments should be fine. The cross realm issue needs spec change. There was a debugging concern related to the dev tools. Apple did a good job showing ways to address this. There is the impact on the error object, with web compatibility issues. And the general question of is it possible to use this feature at all. + +_Yes/no response_ + +MM: does TCO give the same problem? + +DE: It's relatively non-counter-intuitive given other forms of TCO where you do a program transformation and a call ends up in the tail call position. + +KS: The reason the cross-realm issue is not a killer for me, any time you mix objects between realms, you're already dipping your toes in complex waters, and this is another facet of this. + +DH: realms will become more common. As a Java dev, I have some debugging experience where some weird bugs came from using different class loaders. I don't think cross realm bugs will be rare. + +YK: How do you figure out how to use the feature. For PTC, it's quite tricky, and any new exception added to tail call position is making it more tricky. + +DH: Throwing in PTC because you're doing a cross realm tail call is crazy, as you may not know you're doing it. + +DH: the alternative we have not yet talked about is to actually require all the implementations to allocate the stack frames to remove the interoperability problem. + +CM: I don't buy the interop problem, if you have an implementation doing PTC, at cross-realm bounds or not, you have two things: 1) incidental resource usage benefit, reduction in memory pressure, similar to amount of RAM on a computer, 2) I am writing some specific code, to gain a deliberate resource consumption benefit, using CPS in my code, where I'm controlling the environment my stuff is executing in. I'm not concerned about the cross realm case here, because I'm not intending to use cross-realms. I'm going to rely on it in the single realm. I don't want to throw the baby out with the bathwater. + +YK: this is true if you can do this reasoning. + +DH: Discussion about liklihood of cross-realm mutual recursion, likely if code modularised. Given increasing size of algorithm and increasing usefulness of realms, the more likely of mutual recursion over the boundary. + +CM: I take your point, but from an architectural position, getting into the situation of having that level of inter-module cooperation arranged in advanced by potentially loosely coordinated parties, and have those parties in the situation requiring mutual recursion to work seems unlikely to me. + +DH: example is a plugin style for an algorithm + +FST: If cross-realm is not an issue for PTC, then STC could be put back on the table for cases when we do care about tail calls across realm boundaries. + +DE: I don't see how PTC vs STC changes anything regarding the cross realm issue. + +_discussion about putting STC back on the table_ + +YK: procedural remark: STC has to gain consensus to be on the table. + +MS: I don't want both PTC and STC, as it makes PTC optional. We would have compatibility issues. + +DD: If the limits are not made explicit, then there will be compatibility issues. + +YK: there are other concerns, like Error.stack. + +DE: The spec is a place to have behaviour consistent across browsers. + +YK: this is true. Apple is saying is they have shipped PTC, and if V8 does not have to ship PTC there will be compatibility/functionality issues with Error.stack. The converse argument could be made: by shipping PTC there could be loss of functionality of Error.stack. + +MS: I don't think there is consent for STC to reach stage 2, and I don't think it's worth the committee's time to progress it to stage 1. + +YK: there is a norm question here. + +MS: there isn't support for STC, so I would like to remove that from the table. + +DH: we haven't even talked about the syntax. Adding syntax for this feature is not warranted. Introducing syntax comes at a high cost, for the cognitive model of the language, for the ecosystem. I do not believe that tailcalls are common enough to deserve syntax. + +WH: full agreement with DH. Don't want to subject users to constant style wars about whether they should be writing `return f()` or `return continue f()`. + +FST: Can we make progress in the last minutes? + +YK: the fact that there is disagreement on the usefulness of the feature should be taken into account. + +FST/BT: agree + +YK: Spec should follow reality, if engines aren't implementing PTC then the spec should be amended to reflect it. + +YK: this time, several engines have tried and failed to implement the feature. It should be OK to say that this feature in the spec could be removed. + +CM: several users have been surprised to see that tail call did not work + +BT: proxies were requested, were hard to implement (one man year), but they were implemented early because of the requests. There were no such requests for PTC. + +DH: I championed putting PTC in the language, but I have come to the realization that I don't need them that much. + +JHD: I don't know what a proper tail position is. + +_discussion about using trampolines vs CPS and tail calls for code generators_ + +AR: one stated goal of Harmony was to make JS a good target language for compilation + +YK: for that use case STC is acceptable + +DH: my understanding of the world has changed because of asm.js and webassembly. JS as a target language is not as important now. There are performance issues for tail calls when compiling to JS right now, but is it a reason to add syntax to improve it? + +DH: my preference is to remove PTC. + +DE: How do we decide? + +DH: this is the one significant feature of ES6 that is causing the most trouble, and it was agreed before we had a process. + +BT: the probability of this happening again is very low. + +DH: if PTC was proposed today, it would have 0 chance to make it. + +DE: should consensus be the basis to remove PTC? + +YK: what will the implementors do? + +DH: they don't want to ruin their relation with the committee + +CM: as someone who wants to keep the feature, I'm still open to discussion. We tend to emphasize arguments that talk about benefits instead of cost. Many arguments about cost went beyond the implementation and were about the feature itself. + +DH: the main issue is predictability. + +FST: where is the bar to continue the debate + +MS: we have not heard anything compelling to remove the feature. Web compatibility would be a compelling reason. + +YK: if you leave PTC in and others don't put it in, there will be a web compat issue + +MS: if we leave it in, other vendors will end up implementing it. + +FST/YK: you're strong arming the committee + +MS: I'm not the only one who wants to keep PTC + +CM: I'm agnostic on STC, it's the underlying language semantics that I care about + +DE: which issues should we reconsider? + +YK: What the stack trace looks like in PTC, What happens in the dev experience? I agree apple has done good work on the second issue. Nothing done to nullify concerns about the first. + +### Conclusion + +- No consensus on removing PTC +- No consensus and no rejection to advace STC to stage 1 + +Meeting ended 17:30. + + + + + + + + + diff --git a/es7/2016-05/may-25.md b/es7/2016-05/may-25.md new file mode 100644 index 00000000..9433e721 --- /dev/null +++ b/es7/2016-05/may-25.md @@ -0,0 +1,642 @@ +May 25th 2016 Meeting Notes + +## Attendees + +Brian Terlson (BT), Dave Herman (DH), Michael Ficarra (MF), Jordan Harband (JHD), Waldemar Horwat (WH), Tim Disney (TD), Shu-yu Guo (SG), Mark Miller (MM), Kevin Smith (KS), Michael Saboff (MS), Eric Faust (FST), Chip Morningstar (CM), Daniel Ehrenberg (DE), Leo Balter (LB), Yehuda Katz (YK), Jafar Husain (JH), Andreas Rossberg (AR), Ben Smith (BS), Thomas Wood (TW), Alan Schmitt (AS), Brad Nelson (BN), István Sebestyén (IS), John Neumann (JN), Jeff Morrison (JM), Domenic Denicola (DD) + +Over Hangouts (part-time): Dean Tribble (DT), Nikolaus Papaspyrou + +## Agenda + +??: Unfortunately we will not able to cover all topics. There is a priority for proposals that have to advance in this meeting. The target is for each topic one hour of discussion maximum. We will see how that will work out... + +__NOTE from Istvan__: The formal Ecma rule is that any proposal that has to be voted upon formally (i.e. one vote per member company present in the voting) in an Ecma TC is a publication at least 15 days before the TC meeting. Anything shorten that that can be introduced, discussed, move forward for further discussion, consideration, etc... but a "formal" TC decision is not possible. + +## [Decorators](https://github.com/tc39/proposal-decorators) (YK, BT) + +[_slides_] __TODO:__ link to slides + +AR: the fact that classes are declarative is a feature + +WH: adding a link to the proposal to the agenda 30 min before presenting a proposal looking to advance is unreasonable + +DE: agreed + +WH: links should be posted to the agenda the week before + +WH: what is the signature of the enumerable decorator? + +JM: it takes a descriptor and returns a list of descriptors + +DH: the decorators feature is an extensibility feature that allows you to transform something in the source into 0 or more alternatives + +DD: is the value property a method or a function? + +YK: it is an uninitialised closure that errors on invocation + +SG: what if the list has multiple entries with the same name? + +YK: we may want to validate + +YK: [_presentation finished_] + +DD: many abstract ops in current spec text are undefined + +YK: initial spec text has left out trivially-defined abstract ops; I can clarify them + +DE: this exposes objects in an intermediate state; how does the constructor relate to the resulting class? + +YK: intended semantics: it is the original function; invoking before class is initialised is an error + +DE: then you couldn't have a decorator that replaces the constructor with another function? + +YK: it is possible + +DE: which one has the identity of the class? always the one you return? + +YK: decorators that replace the original constructor will incur some cost + +DD: you have to produce a wrapper for all decorated classes + +BT: we could also not ahve them be SameValue + +DE: I would prefer we have no runtime overhead from a class that has been decorated + +FST: classes already have additional cost (derived class constructors' this value) + +YK: the set of functions and values conveyed in this proposal is quite small + +DD: I had hoped to see ore formal semantics; how does the array get converted into ClassElements? how do the property descriptors get used? + +DD: do you pack them up into spec objects and unpack them, or are the same objects re-used? + +WH: if the first decorator creates a getter that matches up with a setter somewhere else in the class? + +YK: syntactic merging when a decorator is attached to a get/set pair; non-syntactic when a decorator adds one half of get/set pair + +YK: coalescing gives us syntactic merging; semantics of defineProperty hold for non-syntactic case + +JM: why are decorators run bottom-to-top (closest first)? + +YK: BT: it's like function application + +WH: Do decorators ever appear after the thing they are decorating, rather than before? + +YK: No, they only have access to what comes after. + +BT: We considered other things too + +YK: Such as object literals, maybe they will come, but it will still come before. + +DE: how would private state interact with decorators? + +BT: and how about initialisers? + +YK: Property declarations would work by reifying the initializer in a thunk and making an analogous object representation + +DE: And how about private state? + +YK: Make a getter/setter for the private state for the slot which is exposed to the + +YK: depends on the particulars of KS's proposal + +YK: what part of the proposal is insufficiently precise for stage 2? + +JM: To put words in your mouth, sounds like you are saying, for fields, there will be a separate type of object which is made, right? + +YK: Right + +DD: my concern is that this has a *lot* of unspecified behaviour; was submitted very close to the meeting + +WH: agreed + +YK: Spec text for Stage 2 is allowed to contain holes + +BT: the things that are missing are not interesting + +DD: the case for uninitialised functions is super interesting + +YK: not needed for stage 2--this is already something that the spec implies exists + +WH: disagree, that is a core issue + +YK: stage 2 expressly does not require complete spec text + +DD: I can't tell if this is 10% or 90% of full spec text because I had 1 minute to review; best guess is 30% + +YK: I assert that the API surface is very small + +WH: I disagree. I think you need to figure out what an uninitialized function is before this advances + +YK: extrapolate what that would mean for other proposals + +YK: I have told you what the semantics are + +DD: still open questions: does it have a prototype? lots of others + +KS: This is a core semantic change to the basic language and exposes something that's not there right now + +DH: it happens to be written "make a function that is unintialised"; question remains what is the difference between an initialised and unitialised function? + +DH: can be a single it that marks the function as uninitialised + +FST: then it should specify it that way + +JHD: can it be a live binding to a different function that always throws, that's updated later? + +WH: What happens when you call toString on it? What happens if you start walking its prototype? + +BT: The only difference is that when you call it it throws. Otherwise it's just normal. + +DD: what about construction? these are open questions + +JM: is it the same as if you had a function that throws an error? + +DH: this is uninteresting + +DD: no, it is core to the semantics + +DH: it is a minor issue because, for stage 2 proposal, should not be concerned with such details; consider if it is a feature that is good for the language + +KS: We can't evaluate that yet. One of the things Yehuda said is that this is a 20% feature. But the solution to the 20% feature is requiring some core semantic changes. That makes it hard for us to reason about the cost/benefit changes. + +KS: not comfortable finding edge cases on the spot + +YK: If we are talking about edge cases, we are not talking about the core semantic features + +DH: This is an important feature. People are over-focusing on certain things. This 80/20 thing is about, if you have a feature that solves some cases but not others, users have no choice but to step outside of the declarative feature and use an imperative way to define classes. Then people don't feel that the actual feature is worth using. If I have to keep falling off the common path, it is not a complete enough abstraction. People feel that the max/min thing falls off a cliff. It'd be nice to have a general solution like this rather than special cases. + +YK: There might be alternatives, but none seem to be really done/in use. So ecosystems are depending on this being a feature. + +DH: The spec was presented too late to advance today. But I don't think it's acceptable to block this on a technical issue in the next meeting. That is reason to note that it has more work to do. + +DD: The issue is whenever we get fully specified semantics, hopefully sooner than two months from now, it would be useful for evaluating the proposal. If you look at Stage 2 proposals so far, they have full spec text. + +YK: other proposals have hit stage 2 with similar spec text + +DD: disagree, most proposals reach stage 2 with full spec text; we have frequently gone well beyond the requirements + +JM: Sounds like there's no stage 2 and we are out of time + +YK: I disagree that I need full semantics. This is just a map operation + +DD: I think KS and I disagree on how core the things that you've elided are + +MF: I agree with DD, previous stage 2 proposals have often had full spec text. + +MS: Seems like spelling them out would help, and giving + +### Conclusion + +- Proposal does not reach stage 2 yet + +## Private Fields (KS) + +KS: consensus last meeting was stage 1. overall approach: non-reified WeakMap per-field. + +YK: appreciate a review? + +KS: _review, pulls up slides_: + - design goals + - basic syntax and semantics + - throws when attempting to access field on object without it (ie, if the non-reified WeakMap doesn't have the object as a key) + - example of non-reified WeakMap potential implementation + - Derived Classes + +YK: when would private initializers happen in relation to public ones? + +KS: Interleaved + +YK: Are you proposing initializers? + +KS: Yes + +YK: What about those initializers controversies? + +KS: [_deferred til later section of proposal_] + +KS: what about static shape? [_overview of edge cases_] return override issue seemed to resonate with the committee: "just works" + +KS: other features: shorthands. `this.#bar` vs shortcut of `#bar`. Agreement was that `#bar` is simple sugar for `this.#bar`. + +YK: `#bar` is always syntactic shorthand for `this.#bar`? + +KS: Yes. + +NB: Previously there was some uncertainty about which `this` would be appropriate, and the resolution is that the current `this` value is always fine. + +KS: Early errors are unspecified atm. For example, nonexistent field names or shorthand that is nested within an inner non-arrow function - I'd like those to be early errors. + +DE: There are early errors for this.#foo where foo is not a private data at all, right? You're just missing the extra additional tighter checking for #foo to not look at the outer lexical fields, right? + +KS: right + +YK: i think the rule you have in mind is that it is syntactically allowed in method bodies wherever the "this" value is defined to be the same as the class? + +BT: it might be the same as where `super` is allowed? + +KS: moving on for now + +KS: last time i didn't present initializers, because of max/min, but obv they are an important feature. + +KS: My preferred semantics for initializers for private fields is that they execute in the lexical env of the class body, but would not have access to the newly created instance via `this`. + +KS: after talking things through with Jeff, it doesn't bother me to allow access to `this`, `super`, `new.target`. + +EF: `new.target` is a dynamic call-site specific value + +JHD: `this` is also pretty dynamic + +KS: It is a bit weird to have it there, but I wanted the environment to be as close as possible to the constructor, except without lexical access inside of the constructor. + +EF: And all of these operations run right after super + +KS: right + +WH: can these fields refer to each other in their initializers? + +KS: yes. + +WH: so there's a TDZ if it's not yet initialized? + +KS: yes, they run in textual order. + +_many_: Does it return undefined if you access a private field before its declaration? + +KS: [_overview of spec text_] InitializePrivateFields. + +YK: When would the initializer fail because the private property already exists? More about return override? + +KS: You can construct crazy scenarios where-- + +WH: a super constructor can return an existing instance of a subclass + +MM: I feel very strongly that an error should be thrown when adding the same private field redundantly + +KS: If an initializer is missing, it sets it to undefined; otherwise it sets it to the value of the initializer + +YK: We were asking what happens when reading from a private field which is not initialized, for accesses that happen before, during and after construction. + +KS: You'll get a TypeError if accessing a missing field + +YK: Access to private fields require an initialization check + +JM: This is the same check as needed for accessing a field on an object when you apply the method which uses private state to the wrong kind of object + +YK: Maybe return undefined? + +MM, WH: There should be a type error + +MM: Seems like the access checks could use the same machinery as returning undefined for missing fields anyway + +YK: What about fixed shape? Why did we get rid of that? + +KS: I did earlier have preinitialization to undefined, before any initializers run. I was attracted to the idea thinking that it would be more performant, but then I didn't receive feedback that it would be more performant. I was initially hopeful that this would help, but it didn't seem justified. + +WH: I would prefer that we don't do that earlier preinitialization. This would preclude any possibility for those to be const. + +KS: If you leaked out a partially constructed object, your invariants are going to be hosed anyway. It would be preferable to fail loudly. + +YK: I'm concerned this could have cost for real implementations. + +DE: It seems like it would work to me, based on how we do hidden classes today. + +AR: We already have to do this same kind of check exactly the same way for existing property accesses. It happens whether you return undefined or a TypeError. + +MM: can we agree that if while implementing it we run into perf issues, we can revisit, since right now all implementors in the room seem comfortable with it? + +KS: _continuing with slides_ + +KS: shorthand syntax is added to the spec. i would prefer more early errors than fewer; not added to the spec yet; not my area of expertise yet. + +KS: Current status: spec complete except for static rules and early errors, and will need refactoring to merge with public properties regardless. + +YK: I feel concerned about not advancing them together. + +JM: We're in close communication with each other. Only things left for public properties are configurability, and `super` + +DH: Concerned about `new.target` across the different proposals - cross-cutting like "class evaluation order" but hard to evaluate in the context of one proposal. + +YK: I think there is disagreement about those answers. + +DE: _describing differing opinions about what should be available and what should not_ + +JM: most compelling case for `this` is helper functions that are on the class hierarchy, others as well. + +MM: i have expressed hesitation, but at this point I agree [about `this` being available] + +DE: re `new.target`: i'm sympathetic to kevin's argument to keep it consistent with the constructor. + +KS: seems weird, but motivation for including was to avoid weirder differences. + +DD: new.target feels more like arguments + +MM: But really super is the only thing that's not argument-like. The fact that this, super and new.target are special forms, makes me happy with including them and not arguments + +YK: I'm more interested in hiding values that shouldn't be present than exposing only the minimum that are present + +JM: An intuition here is to say that these evaluations happen at the last step of super, which happens inside of the constructor + +JHD: We discussed `arguments` at the last meeting and agreed that it would be an early error in initializers. + +KS: If you wanted to censor lexical things, right now you could create poison in the scope. + +YK: How should function.sent work? + +KS: I haven't reviewed exactly how function.sent should work. + +WH: The # is part of the same token as the private name. Is it intentional to make it into one token instead of having the # and private name be two tokens? + +KS: Yes. + +WH: About the choice of what follows the #, the grammar permits #0. Is this intended? It uses IdentifierPart + +MM: I would prefer that after the # we insist on IdentifierStart + +MF: Identifier or IdentifierName (ban reserved words?) + +KS: IdentifierName. This looks to me like _blah, so I don't see why not IdentifierPart since you can do _0. But I'm fine with IdentifierStart at first. + +WH: IdentifierName. This would allow things like #if. + +YK: So what is the precise scope chain of the initializer? + +KS: In the specification, it is a new lexical environment which inherits from the outer one which adds this, super and new.target. There is no additional censoring, but we could add this if we decide to. + +JM: I think last time on public properties, we had consensus on censoring arguments. + +KS: I'd be fine with censoring arguments + +YK: It's uncontroversial that normal lexical scope works. But for special values, which of them are banned? + +_many_: arguments throw, and nothing else + +JHD: ie, anything available in the *default* constructor, immediately after `super()`, except for `arguments` which is an early error. + +YK: Why ban arguments? + +MM: Because it's confusing, whether you include the outer or inner ones. And arguments is a mess left over for ES3. There is no reason to include it for new programs. + +YK: For new.target, maybe it should be banned because you may assume it refers to the outer lexical binding. + +EF: I'm sympathetic to that actually + +MM: It does make sense to ban confusing constructs + +DD: I share Domenic's concern about including a new scope without curlies. All of the other forms could be referring to the surrounding construct that also has that exact same hazard. But I would prefer if we would have a discussion about whether this is included. + +JM, WH: This spec meets Stage 2 because the spec is clear and makes a concrete proposal towards an outcome. + +YK: This is a concern that I think needs to be resolved before Stage 2, as it is a major semantic issue. + +DH: Agreed; this is an ad-hoc decision-making process; there should be a cross-cutting presentation first + +JM: If we had spec text for poisoning arguments, would that be sufficient? + +YK: There needs to be more discussion about new.target + +DE: There are a lot of open bugs and technical discussion on the GitHub for both property declarations and private state, with issues for coming to a technical agreement on these issues. I would encourage more committee members to participate if they have time. + +YK: There should be a cross-cutting presentation first. + +JM: I had prepared a cross-cutting presentation and it is on the agenda but we have not gotten to it yet. + +YK: This proposal is being treated differently from the decorators proposal and being held to a higher standard. + +WH: As I repeatedly said, the decorators proposal was made available a few minutes before the presentation, which was too late to read and evaluate it. That's why it didn't advance to stage 2. + +WH: There is complete spec text here and not in your proposal which lays out the details + +YK: The answer was given and committee members did not believe it. + +### Conclusion + +- No consensus on stage 2 yet due to barring process issues + +## JSExplain (AS & TW) + +AS: [_presenting slides_](http://ajacs.inria.fr/files/2016-05-25-jsexplain.pdf) + +AS: equip JS with a formal spec, logic and tools for verification, formal proofs of security properties + +_show more slides_ + +MM: because of the very close textual correspondence between the reference implementation and the prose spec language, the coverage results are very close to corresponding implied coverage of the spec itself. + +AS: _show more slides_ + +BT: Would like to be able to set a conditional breakpoint on the ref interpreter to test if test262 hits it. + +WH: A similar "reference implementation" previously attempted in ES4 + +SG: This seems very familiar, did I request this of the authors a couple of years ago? + +AS: Yes, you were the direct inspiration for this! + +YK: Less sofisticated tools would like to make use of this, eg linting. A more accessable language is good. Lots of people would +find that JS is the easiest to write in. + +MM: Tradeoff: ML is familiar to a smaller audience, for the same executable spec as written in subset ML vs subset JS, +how readable is it, given familiarity? If ML's readability is sufficiently great, then it may be a suitable tradeoff. + +MM: More useful: spec right now has lots of internal asserts - invariants for the spec, if any of the asserts are false, a +static spec bug. A tool like this would be good to prove asserts hold over the portion of spec formalised. As more spec +formalised, to continually recheck. Would set the ground to writing more spec checks. +When the language is evolved that breaks an invariant, it is good to know that as an evidence point to +justify/rationalise the breakage. + +YK: Agreed + +### Conclusion + +- will continue iterating + +## String.prototype.pad{Start,End} (JHD) + +JHD: implemented in all major browsers; stage 4? + +all: yes + +### Conclusion + +- stage 4! + +## Object.getOwnPropertyDescriptors (JHD) + +MM: what order? + +DD: the well-defined one. + +MM: which keys? + +DD: own property keys and ... + +DD: I wish it was shipping in 2 stable browsers + +YK: why rush? + +DE: waiting until 2 implementations ship causes chicken-egg problem + +JHD: some browsers say they won't ship things that are not stage 4 + +YK: I'm fine with stage 4 in this situation + +### Conclusion + +- stage 4! +- __*TC39 needs to schedule a discussion in the next meeting to review the stages process document*__ + +## Template Literals (http://slides.com/disnet/template-literal-problems-7) (TD) + +TD: _presenting_ + +YK: there's a hazard for the HTML thing + +YK: if you are not trying to do the raw thing (treat it as a string), could be a hazard + +YK: could have had an API for getting cooked value from raw + +MM: this is my mistake; E does this differently using $ + +WH: explain where tagged flag comes from in grammar + +MM: I volunteer to review this + +WH: Me too. + +### Conclusion + +- stage 2 +- reviewers: MM and WH + +TD: Also, relatedly: + +```html + + + + "; + let s = html`` + + + +``` + +MM: We can't escape this + +YK: why do we care? + +TD: MF: it's just an interesting related case because problems with templates/raw are not fully fixed by this proposal alone + +## Observables (JH) + +JH: _presenting slides_ + +JH: we're not sold on the name "closed" right now for the Subscription interface + +JH: I would prefer "unsubscribed" to "closed" + +CM: "unsubscribe" and "unsubscribed" are too typographically close + +MM: considering DD's cancellation proposal, I may want to fold this into general cancellation framework + +DD: if we add a new data structure, it should have consumers in the web platform + +DD: concerned about not returning Promises? + +_discussion about meaning of stage 2, in particular the effects of cancellation proposal on this proposal_ + +WH: A flaw of the stage process is that it doesn't deal well with dependencies. + +_more discussion about meaning of stage 2_ + +### Conclusion + +We agree that this is a feature that we have consensus on and hope to eventually include in a version of the standard, but we have out worked out major semantics with respect to cross-cutting concerns with cancellation, promises and the async iterable symbol. So this meets some of the Stage 2 criteria and not others, and __remains Stage 1 for now__. This is an advancement on previous concerns, where we were not convinced that we wanted to eventually include this feature. + +## [Cancelable Promises](https://docs.google.com/presentation/d/1V4vmC54gJkwAss1nfEt9ywc-QOVOfleRxD5qtpMpc8U/edit?usp=sharing) (DD) + +DD: _presenting slides_ + +DD: Cancel needs to be a third state. Bluebird tried using just a normal exception, but people had to do catch { if (is cancel) { ... } } which is not so ergonomic and doesn't work well, so now they use something more like a third state. This needs to be reified throughout the language, both asynchronously in Promises and synchronously, for analogous use in async functions. This happens when you await a canceled promise. + +WH: Why does cancellation carry a reason? + +DD: Maybe it doesn't need one, but it seems nice and analogous to exceptions. + +MM: Cancellation should be as fast as normal control flow and should not collect stack traces. It doesn't collect stack traces. + +SG: try-catch is not slow because it is an exceptional event, it is slow because of the non-locality itself + +FST: motivation? + +YK: XHR has an abort feature; fetch API is Promise-based and cannot have a similar feature + +BT: this is especially important if you await one of these promises + +DD: key distinction between error state and canceled state is top-level ignores canceled promise + +JM: If you have a promise that defers to another promise, and the inner promise is canceled, then the outer promise is canceled since it was waiting on the inner one. + +MM: No reason to introduce CancelReason; that's unrelated + +DD: Yeah, you could just use strings as the cancel reason + +DD: Canceling async operations. First, any Promise can call its cancel function and get cancelled that way. But what is our standard library mechanism for triggering/manipulating cancellations? + +DD: Naive async function integration doesn't work. If you have a callstack of async functions, how do you reach down into the "current" one and go and make the await become a throw cancel? Seems somehow non-compositional. Also, making two separate classes (e.g., a subclass) would be messy, and seems like we shouldn't make Promises mutable by consumers either. + +DD: Alternative: Cancel tokens. Kevin Smith wrote up a proposal; I would like to add the "third state" changes to that. For web APIs, let's establish a precedent of passing an options object argument with a cancelToken. You pass cancelTokens explicitly, and call .cancelIfRequested() if needed at certain points. Users can insert these wherever they want. + +MM: Cancel tokens could be passed around through zones, though I don't really like this. + +DD: It would be unergonomic to base the feature on this pattern. + +BT: People use this pattern in C# and we shouldn't discourage it, but we don't need to build this in + +YK: Ergonomics still seem disconcerting + +BT: C# uses a pattern default argument value of CancellationToken.None() which is a dummy and lets you not worry about undefined being passed in. + +YK: There is a global coordination problem related to composition here. We have to work out how things are threaded through. + +BT: Do you have an example of how Promise.all and Promise.race should be updated. + +DD: Oh, yeah, this could be where we establish our precedent of how to take a cancel token as an argument! This would parallel fetch's options bag. + +MM: As combinators over promises, Promise.all and Promise.race also have to figure out how to deal with their array Promises canceling. I think they should be separate. + +BT: Agreed, cancel should just drop out of the race. + +WH: Promise.all should cancel if any of them cancels. Promise.race should ignore cancelled promises and wait for the rest; it should cancel only if they all cancel. + +DE: Analogous to Promise.all for rejection then? + +WH: Yes + +MM: To be clear, a cancelled promise is settled, right? + +BT: Concerned that people will reuse options bags and pass them into various places with options not suitable for those contexts. + +AR: The synchronous third state freaks me out. This needs more discussion. We are suddenly adding a totally new continuation across the whole language. + +DD: Want to fast-track this through the stages + +WH: I like this a lot but am concerned about the ergonomics of practical use patterns and possible syntax issues. These will take a bit of thought, so racing for stage 2 at the next meeting seems worrisome. + +#### Conclusion/Resolution + +- Stage 1! + +## [Definitive decision for test262 python runner](https://github.com/tc39/test262/issues/647) (Mike Pennisi) + +LB: TC39 agreed to deprecate the python runner in 2014, we want to remove it from test262 as it demands extra energy on a deprecated tool while implementing new features. + +FST: We can work it out. It does not need to move it to a new TC39's repository. + +_many_: let's remove it. + +#### Conclusion/Resolution + +- Already deprecated; just delete it.