2015-03-24 Meeting Notes
Brian Terlson, Allen Wirfs-Brock, John Neumann, Jeff Morrison, Sebastian Markbage, Yehuda Katz, Dave Herman, Alan Schmitt, Lee Byron, Domenic Denicola, Kevin Smith, Andreas Rossberg, Brendan Eich, Erik Arvidsson, Adam Klein, Jordan Harband, Mark Miller, Istvan Sebestyen, Jafar Husain, Rick Waldron
4 ECMA-262 6th Edition
(Allen Wirfs-Brock)
Allen Wirfs-Brock: (presents slides)
Allen Wirfs-Brock: release candidates are intended to be complete subject to bugs so everyone could review them. RC1 was the review draft for the RF opt-out period.
Allen Wirfs-Brock: bug count fluctuates toward zero and back up; minor technical or editorial issues. Waldemar found some small issues in the grammar (unnecessary parametrization, Unicode regexp grammar, ...). Bugs that come up between now and June will be fixed as practical, or deferred to ES7 if not.
Allen Wirfs-Brock: any last minute issues!?
Brendan Eich: what about the things that are backward-incompatible?
Allen Wirfs-Brock: e.g. Brian has some issues around the function name property
Brian Terlson: i.e., the assignment of names when assigning a function to a var declaration
Allen Wirfs-Brock: Erik Arvidsson has an issue around [[DefineOwnProperty]] on module namespace objects...
Brendan Eich: built-in prototypes?
Allen Wirfs-Brock: in RC1 it became pretty clear that at least making Array.prototype not-an-array would break at least some peoples' code. So for RC1 I reverted Array.prototype back to an Array exotic object. There was similar discussion about RegExp.prototype. For RC1 I did an experiment with some hacks that I thought would maybe give us a middle path. But that got reverted back.
Brendan Eich: not sure there's any profit in trying to change it in the spec.
Brian Terlson: that's what IE has: RegExp.prototype is an ordinary object; the only prototypes that are not ordinary objects are Function.prototype and Array.prototype.
Brendan Eich: what about Object.prototype.toString on those prototypes? [Actually I was asking what RegExp.prototype.toString() returns. /be]
Brian Terlson: it gives [object Object]. We haven't come across any code yet that breaks because of these changes, and to put that in perspective we have 3 or 4 sites that break due to the function name thing.
Module Namespace Exotic Objects
Dave Herman: I think there was a minor issue with the module namespace objects...
Erik Arvidsson: my concern here is that we're introducing a new exotic object.
Dave Herman: that has been my intention for fully six years. (For some value of six.)
Domenic Denicola: I think the wiki said "Object.create(null) with getters"...
Dave Herman: yeah you're right, the exoticness is not the higher-order bit.
Allen Wirfs-Brock: let me run through the things you can do with a MNS exotic object. A get; no set; a get with a symbol; enumerate; has-own (name or symbol); and that's pretty much it. Everything else fails (false return or throw). So e.g. Object.getOwnPropertyDescriptor will throw on one of these.
Erik Arvidsson: a solution is to simply return a data property descriptor. Then code that uses Object.getOwnPropertyDescriptor, e.g. for mixins, will work.
Allen Wirfs-Brock: the reason I made it throw is that the MOP lets you define things that are neither data properties nor accessors, and this is one of those cases, and the MOP lets you throw in those cases, so we could.
Dave Herman: it is self-evidently possible to write the spec as it's written now, but the question is whether we should.
Mark Miller: I would find it more useful to not throw.
Allen Wirfs-Brock: even though it's not really writable?
Yehuda Katz: it is writable, but it's not writable by you.
Allen Wirfs-Brock: I worry that we're establishing a precedent that we're going to make [[GetOwnProperty]] behave that way.
Dave Herman: there's a lot of code out there that has expectations about objects you give it, and if you build an object that breaks those expectations, then that particular class of object becomes rounded up and treated as toxic and people say to never use these objects, or alternately it starts to poison the well of these common operations, which is even worse. For example we did a similar thing with enumerate. Module objects ought to behave as close to normal objects as possible. It's a much narrower diversion to have an object which says it's writable but you can't write to it, than one that throws when you try to get a descriptor for its properties. On top of that, there is precedent for property writes quietly failing...
Mark Miller: you could write something with an accessor that has that behavior, but it's not normal... non-writable properties normally throw in strict, fail silently in sloppy.
Allen Wirfs-Brock: being a data property means that if you get the descriptor you get the value of it. That means in [[GetOwnProperty]] I have to access the value, which could fail because of TDZ.
Dave Herman: this is the MOP. TDZ is part of the core semantics. How do we reflect TDZ in the MOP. We could throw, or we could have some special representation of TDZ state in the MOP (e.g. undefined). A throw seems better at this stage, in the case where you hit TDZ.
Andreas Rossberg: what happens when you do a [[Get]] in the TDZ?
Dave Herman: it throws
Yehuda Katz: why is it not just a getter
Andreas Rossberg/Mark Miller/Allen Wirfs-Brock: then you have to reify the getter, and it's annoying to implement
Conclusion/Resolution
- Change module namespace exotic object [[GetOwnProperty]] to reflect as a writable data property.
- [[Set]] continues to throw in strict mode.
Function Name Issue
Brian Terlson: we found several sites that are broken by the new function.name algorithm. One site we found is using function objects as maps, and so doing e.g. if (func[key]) { ... }. Since ES6 defines new semantics for func.name, this breaks the site. We have enough information such that we're not going to ship this. We could perhaps only infer for assignments to let and const, not var.
Allen Wirfs-Brock: we infer lots of places...
Brian Terlson: we've only seen problems for assignments to var.
Mark Miller: so if we removed it from var everything would work?
Brian Terlson: yes, but it seems a bit hasty to make that change without testing...
Mark Miller: at what point in the process can changes like this not go in.
John Neumann/Allen Wirfs-Brock: we're there now.
Domenic Denicola: it's not a big deal if we have a different function.name algorithm in ES7.
Dave Herman: no, really!? If we have something that pretty clearly needs to be fixed, we should be able to change right up until the GA votes.
Allen Wirfs-Brock: the GA needs the time to review it...
Dave Herman: in a 1300-page spec, a small change like this is not going to change anyone's opinion about ES6.
Allen Wirfs-Brock: it's a process thing. This is about a feature, and it's either in or not in.
Dave Herman: the feature is in. I'm saying this is at the level of bugfix.
Andreas Rossberg: in Chrome every function has a name property....
Brian Terlson: the problem is that it switches from falsy to truthy when it becomes a non-empty string.
Brendan Eich: why are we changing anonymous function names?
Mark Miller: we're not changing anonymous function names, we're changing which functions are anonymous :)
Andreas Rossberg: which is one of these webpages?
Brian Terlson: cheezburger.com, the comments won't load.
Brendan Eich: stop ship bug, then!
Andreas Rossberg: cheeseburger.com?
Adam Klein: no, cheezburger.com.
Dave Herman: we should at least have a GitHub errata page where we can enumerate these things...
Domenic Denicola: once the great tooling revolution arrives, there will be a live GitHub version of the spec that implementers consult.
Dave Herman: yeah, but until the Great Leap Forward arrives, we need something in place.
Yehuda Katz: let's put errata in tc39/ecma262.
Mark Miller: having this be an errata-managed issue seems fine to me.
Brendan Eich: what about a new property, instead of .name?
Allen Wirfs-Brock: on Twitter somebody suggested it should be a symbol
Mark Miller: we're standardizing the de-facto precedent. The reasonable backoff suggested by the data is to not infer the data from the var assignment.
Domenic Denicola: two options. Make the change now with no var; or, leave the spec as is, let Microsoft accumulate more data to see if no-var-assignment is sufficient; if so then use errata to officially recommend those.
Mark Miller: let the ES6 spec and Microsoft's implementation diverge, and use that to figure out exactly what the right fix is.
Erik Arvidsson: we should either do full inferencing or revert to ES5 semantics.
Mark Miller: what about concise methods?
Erik Arvidsson: that's fine; they're new syntax
Allen Wirfs-Brock: removing name inference would be a big deal.
Brian Terlson: there are going to be more issues like this; errata management seems like the way to go.
Allen Wirfs-Brock: indeed, the nature of the process is that we don't get this level of information until we're at this point in the process, with implementations.
Brian Terlson: honestly, this issue is small compared to sloppy mode const semantics, which we've found issues with as well.
(general consternation)
Mark Miller: did we have a resolution for the class bindings issue raised on list?
Allen Wirfs-Brock: probably leave as status quo...
Domenic Denicola: what about making them const?
Allen Wirfs-Brock: that was the other possibility...
Yehuda Katz: there was a reason we didn't do that... I remember feeling strongly at the time.
Dave Herman: global?
Yehuda Katz: in the global space, people want to replace things that are global.
Mark Miller: I retreat...
Allen Wirfs-Brock: OK, so, I don't think we should keep fishing on "is there anything else we should change"?
Conclusion/Resolution (for function.name issue)
- Leave the spec as-is
- Let Microsoft experiment with more web-compatible versions of the algorithm, e.g. not-for-
var - Have a public place to track and post errata regarding this issue, until the Great Tooling Revolution of 2015 arrives
Let's Ship This Thing
John Neumann: we need two votes; we vote to refer the spec to ourselves, then we vote to approve the spec.
(general confusion, slowly turning to incredulity and then acceptance)
Allen Wirfs-Brock: (presents slide titled "A Motion")
Dave Herman: (joking) I filed a patent for the Window object. It is a very unique design.
Mark Miller: (joking) if you get it granted, don't license it to anybody.
Allen Wirfs-Brock: we intend to approve the final draft here, but conditional upon completion of the RF opt-out period.
John Neumann: (conducts a vote)
the TC39 RFTG has approved referring ES2015 to the TC39 TC (unanimous)
the TC39 TC has approved referring ES2015 to the Ecma GA (unanimous: Google, Microsoft, Mozilla, jQuery, Facebook, Inria)
John Neumann: one last vote! should we recommend to the GA that they refer ES2015 to the GA for fast-track approval. During ES5, the Japanese national body of the ISO recommended a large number of changes which we incorporated as ES5.1. If we refer this document to ISO for fast-track, then we can assume Japan and others will make comments. Those comments will be approved.
Allen Wirfs-Brock: this is the complication of this fast-track stuff. "Fast" means "about a year." If we start this down the fast-track, it will interfere with ES7; about the time we exit the fast-track process for ES6, we will also have ES7.
Mark Miller: we do need to figure out how to get this working, but the entire thing is worth it if for no other reason than the high-quality contributions of that one reviewer at the ISO. I don't know how else to engage him.
(discussion of new text vs. old text, will reviewers look at the deltas)
Domenic Denicola: there may be sections that are untouched, but they are very few.
Allen Wirfs-Brock: there may be sentences that are untouched...
Istvan Sebastian: it would be very unkind not to refer this to them. My suggestion would be that we should go ahead for the fast-track but it should be a conditional go-ahead on myself and John sitting down with ISO management and discussing a way to find a solution to integrate the different cycles. It would be ugly if there was a large delta between ISO's version (~ES5) and ours.
John Neumann: it exacerbates the system right now. We have a four-year window between ES5 and ES6 and the plan is to have one-year windows. ISO may choose to wait until ES8 or ES9 to fast-track, bypassing ES7. They want to pick up the massive changes between ES5 and ES6. So I think it's important to do it this time and less important to do it next time.
Domenic Denicola: couldn't we just do this because it's good but not spend much time worrying about it?
Allen Wirfs-Brock: unfortunately it's not that simple. The manpower to publish documents is not free; it would take away resources from feature work etc.
Mark Miller: Allen what's your opinion?
Allen Wirfs-Brock: I think we need to do ISO. There is significance involved in that.
Mark Miller: so going forward with our new process do we do ISO every year?
Allen Wirfs-Brock: I don't know, I only did it once and it took a year.
John Neumann: it could take a longer this time, fast-track has changed.
Allen Wirfs-Brock: should we do a partition standard?
John Neumann: we don't want to go down that road...
Allen Wirfs-Brock: maybe it would help make this maintainable over time?
John Neumann: I'm not opposed, but it needs to be thought out...
Allen Wirfs-Brock: maybe a partition standard could be moved through the ISO process independently...
Istvan Sebastian: there should be minimal market confusion because most people download the Ecma version, not the ISO version...
Domenic Denicola: most people download the version on Jason Orendorff's personal web page...
Istvan Sebastian: download counts support many more Ecma downloads than ISO downloads ("much much much much smaller")
Allen Wirfs-Brock: that is probably why it is hard to get people in this room excited about ISO...
John Neumann: so I think what we want to do is fast-track this year, but future fast-tracks would be questionable.
John Neumann: so, let's vote (per company): do we approve submission to ISO for fast-track.
approve: Google, Microsoft, Mozilla, jQuery, Facebook, Inria, Netflix
opposed: (none)
abstain: jQuery
Istvan Sebastian: ECMA 402 can be an ECMA-only standard according to Patrick. ECMA-only standards can be used as normative standards, so it's up to us whether we want to fast-track. Doesn't seem critical. ECMA-404 is the more interesting one.
Allen Wirfs-Brock: Rick isn't here - are we also going to approve 402 right now?
Yehuda Katz: Is 402 aligned with ES6?
Allen Wirfs-Brock: I hope so, ES6 normatively references it.
Yehuda Katz: Will ECMA be upset if we normatively reference a non-normative spec?
Allen Wirfs-Brock: Yes.
Allen Wirfs-Brock: Istvan, do we need a opt-out period for ECMA-402.
Istvan Sebastian: Yes.
Allen Wirfs-Brock: My understanding is that Rick has created the final draft and it has been available for a month for people to review.
Istvan Sebastian: It would be nice if we could approve at this meeting, as far as I know this was the intention of the editor. So seems like we have a small problem.
Allen Wirfs-Brock: Check with Rick. If people here take the time to look at the draft, by the end of the week we could vote to refer 402 to GA.
Istvan Sebastian: We can't reference 402 edition 1 from ES6?
Allen Wirfs-Brock: No.
Conclusion/Resolution
- Everyone to review or do what is necessary to vote to pass along 402 on Thursday.
What to do with compact profile (ECMA-327) and E4X (ECMA-357)
Allen Wirfs-Brock: These are still active standards. E4X still gets downloads. We can withdraw the standards.
Brendan Eich: ActionScript 3 in Flash implements E4X.
Istvan Sebastian: We had this on the agenda when we did ES5. At that time the point was that even if it was out of date, if implementers wanted to implement the old one they could. Adobe may have wanted this. 357 is often downloaded. But I don't know how serious this is.
Allen Wirfs-Brock: E4X is not aligned with ES6 so it seems misleading for it to be out there.
Istvan Sebastian: Some people may have used it with edition 3.
Allen Wirfs-Brock: We had this conversation 5 years ago. Things have evolved. Maybe adobe still cares, or maybe they don't.
Brendan Eich: It can be withdrawn without breaking other standards.
Istvan Sebastian: We approved ECMA404 before we had the RF agreement. Should we start an opt-out period for ECMA404?
Conclusion/Resolution
- Istvan to follow up with Adobe and the CC to see if they would object to withdrawing E4X
ECMA404 RF?
Istvan Sebastian: We approved ECMA404 before we had the RF agreement. Should we start an opt-out period for ECMA404?
Allen Wirfs-Brock: Can we retroactively make ECMA-404 Royalty Free?
Istvan Sebastian: Yes
Allen Wirfs-Brock: We should have an opt-out period then.
Conclusion/Resolution
- Start an opt-out period.
Compact profile
Dave Herman: People who are interested in this can start doing work. Once there is actual demand work will happen. We shouldn't just make standards because someone might use it.
Allen Wirfs-Brock: I think there is consensus to kill 327.
Conclusion/Resolution
- Istvan to follow up with Adobe and the CC to see if they would object to withdrawing the compact profile.
Fast track ECMA-404
Istvan Sebastian: The actual standard document is not ready, maybe ready for this afternooon. Then we can publish it for fast track.
Conclusion/Resolution
- Revisit tomorrow.
6.1 ES6 Class Properties
(Jeff Morrison)
gist.github.com/jeffmo/054df782c05639da2adb
class Counter extends ReactComponent {
constructor(props) {
super(props);
state = {count: this.props.initialCount};
}
}
Counter.propTypes = {initialCount: React.PropTypes.numer};
Jeff Morrrison: React ends up with some boiler plate code because it wants to add an own instance property.
class Counter extends ReactComponent {
static propTypes = {initialCount: React.PropTypes.numer};
state = {count: this.props.initialCount};
Jeff Morrrison: Issues with storing instance values on the prototype. Reference types shared between instances.
Jeff Morrrison: Transpose initializer into the constructor has issues with the scope.
Jeff Morrrison: Wrap each initializer in its own closure from within the class-body environment.
Jeff Morrrison: Store the closure as an 'initializer' value in a property descriptor on the prototype.
Mark Miller: Hold on. Adding another field in a property descriptor is very heavy handed and has to go through the whole proxy design.
Yehuda Katz: This is needed by other proposals. Not in the MOP though. Opposed to add new features that are not reflected.
Allen Wirfs-Brock: Need to define when this happens. End of super()?
Jeff Morrrison: Wants to move passed where the initializer is stored.
Jeff Morrrison: Last step of construct. Immediately after calling super()
Allen Wirfs-Brock: Inconsistent. In a non derived you cannot access the own instance field.
Jeff Morrrison: That is by design. Sorry, it is the other way around. The initializer is executed in the base class before the constructor body is entered.
Allen Wirfs-Brock: It is important to create properties up front (with an unitialized state or undefined).
Yehuda Katz: It is important to put these on the prototype because it allows reflection.
Allen Wirfs-Brock: By putting these on the prototype they are visible to the application. If these have privileges then those privileges will leak.
Dave Herman: Not convinced that this is important. The important part is that we need to store the initializer behavior somewhere.
Mark Miller: Is it configurable?
Dave Herman: Not fundamental. Jaswanth Sreeram assignment creates the configurable writable enumerable.
Dave Herman: With decorators one can create non writable etc.
Mark Miller: I would think that non configurable would be good so that the shape is guaranteed.
Dave Herman: For backwards compat we should stick with the old behavior.
Allen Wirfs-Brock: This is about creating the instance shape. What new thing is this getting into. It provides, prior to construction, information about the shape.
Dave Herman: When we provide new syntax it is tempting to alter the semantics instead of following the patterns used today.
Allen Wirfs-Brock: It is possible that the shape is all about private state and this is all about classic prototype oop.
Mark Miller: Using a descriptor is very heavy handed.
Yehuda Katz: I want it to be pervasive so a descriptor is good.
Mark Miller: If you put it in the descriptor.
FM: You can use any object as a prototype.
Yehuda Katz: And if a class constructor uses that as a prototype then you can get own instance properties.
Allen Wirfs-Brock: What are the implications if every descriptor needs to have this new property?
Allen Wirfs-Brock: Are you assuming that the current design with property descriptor is a good model to extend for reflection mechanism.
Mark Miller: The concern I have is that there is a property with the same name on the prototype but its purpose is not the same.
Mark Miller: What you want is something whose value is the initializer function.
Dave Herman: What you want is some association with the name and the initializer function
Mark Miller: What you want is that your initializer function returns a descriptor. Then the decorator can operate on that descriptor.
Dave Herman: Some way to associate the initializer. You can use a symbol.
Domenic Denicola: The decorators already act differently. prototype or on the constructor.
Yehuda Katz: Wants to operator on more than the value. Same way for methods as for inst props.
Dave Herman: API like method decorators.
sidetable.myinstprop = {value: func () {}, configurable: ..., ...};
Yehuda Katz: It is important to distinguish these from value properties. For example there migh be a use for creating own instance methods. Therefore using initializer instead of value is important.
Allen Wirfs-Brock: When I create lots of objects I don't want to have to pay for all these internal MOP.
Yehuda Katz: The reified methods only come into play if you use reflection and decorators.
Allen Wirfs-Brock: What if someone modifies these descriptors.
Erik Arvidsson: It is important that the descriptor of these own instance properties is immutable, or at that you cannot change these afterwards because then the constructor function has to change its behavior after the fact.
Conclusion/Resolution
- Stage 0
- Do not use descriptors for initializer state.
6.2 Decorators
class {
@readonly name() { }
}
function readonly(prototype, name, desc) {
desc.writable = false;
return desc;
}
Object.defineProperty(Person.prototype, 'name',
readonly(Person.prototype, 'name', {
enumerable: false,
configurable: true,
writable: true,
value: <closure>
}));
Mark Miller: When defineProperty runs, does Person.prototype have an undecorated name property?
Yehuda Katz: No. The thing that you pass to the decorator looks like a descriptor, but is just an object.
Allen Wirfs-Brock: We need to think about what the built in ones should be.
Yehuda Katz: Things that update descriptors seem like good candidates.
Examples of things that Ember might do with decorators.
Yehuda Katz: Shows example of more complex decorator usage:
class Person {
firstName = “…”;
lastName = “…”;
@concat('firstName', 'lastName', ' ') fullName;
@concat('lastName', 'firstName', ', ') formalName; }
Mark Miller: Can create a read-only getter from a declared property
Allen Wirfs-Brock: Do you have a more plausible use case for more complex decorators
Yehuda Katz: (Shows ember gist. Shows @service which does dependency injection.)
Allen Wirfs-Brock: Why would I use a decorator instead of a property initializer?
Yehuda Katz: More complex
Jeff Morrrison: Decorators run once per class
Allen Wirfs-Brock: This is an own property?
Yehuda Katz: The decorator would attach a more complex getter. @service does a lazy lookup.
Domenic Denicola: When you return a descriptor does it return an own property?
Yehuda Katz: ?
Mark Miller: Since this is integrated into TypeScript, how does TypeScript type the decorator method?
Yehuda Katz: Another way to ask question is I would prefer a more immutable API so that I know what the type is. Decorators themselves are typed, but they can mutate.
Mark Miller: It's a functional transformation of a descriptor. There's nothing being mutated on.
Andreas Rossberg: This is reified as a first class value. How can you track that without a full blown dependent type system?
Yehuda Katz: (Shows examples of decorators with no mutating effect).
Dave Herman: Andreas Rossberg is saying that the set of properties that end of being in the class ends up depending on what happens with these decorators.
Mutation is a red herring. The issue is computably determining the class type. You're saying that there is an expressive subset of this
system for which this is not a problem.
Andreas Rossberg: To know what to reject you'd have to know the returned value at type-check time.
Jeff Morrrison: Andreas Rossberg is saying that the value is dependent on runtime. Enumerable true and enumerable false produce very different things.
Andreas Rossberg: Hard to forsee the implications, because annotations will want to spread.
Yehuda Katz: We should consider them on a case-by-case basis, but I am conservative. I'm not proposing targeting general declarations.
Use case is that with class syntax we aren't able to do things we could with object literals.
Mark Miller: Are you proposing that you can decorate fields in an object literal?
Yehuda Katz: I don't consider it fundamental but there is a symmetry concern.
Andreas Rossberg: Still missing the big picture. Don't you ever want to decorate parameters and other things?
Yehuda Katz: These are things we might want to consider.
Andreas Rossberg: Take modules, it seems like people will want to do some metaprogramming by annotating imports.
Yehuda Katz: Proposal is addressing an expressive hole introduced by ES6. There is not a way to do higher order things with methods.
Dave Herman: We're targeting the class syntax but we need to focus on the whole and not the part. The broad category is metaprogramming. What is our model?
In Scheme, it's static. In Ruby, it's dynamic. We should do a zoom out and look at what metaprogramming might mean for the language.
Andreas Rossberg: (Objects to saying that Jaswanth Sreeram implies dynamic metaprogramming.)
Dave Herman: (Mentions objection to staging.) With a first class class system, a lot of meta- programming stuff you just do at runtime. If you've gone down the path of dynamic metaprogramming, then it's probably best to keep going that way. Andreas Rossberg: I think class expressions are a red herring
Dave Herman: I just don't believe that we should do staging.
Brendan Eich: staging not seriously proposed but noted as possible accidental outcome of generalizing decorators across first- and second-class parts of ES6. We want a principled approach that's not just for classes.
Allen Wirfs-Brock: Say you had a decorator that was enumerable or non-enumerable...
Yehuda Katz: Users will want to apply descriptor decorators to object literals as well.
Yehuda Katz: Don't see why we should restrict class features to static
Dave Herman: Javascript is fundamentally a dynamic language and we shouldn't try to make it static
Andreas Rossberg: The dynamic stuff will remain, but we'll have these conflicts.
Andreas Rossberg: Original question was what problem are we solving?
Dave Herman: Need a more general system for "twiddling" knobs.
Andreas Rossberg: My question is how does this generalize?
Dave Herman: Current instinct is that first class things (classes, object literals) are easy to apply this to, but for second class things we'll fall off a complexity cliff. Agree that we should look at the bigger picture.
Andreas Rossberg: readonly is an example that we might want to have a more direct way.
Yehuda Katz: If readonly were built-in and you imported it, then the engine could do smarter things.
Dave Herman: Suggests stage 1, but audit the space which may lead to changes.
Conclusion
- Stage 1, Yehuda Katz will audit the space.
6.3 ReverseIterable interface
(Lee Byron)
Proposal: leebyron/ecmascript-reverse-iterator
Lee Byron: presents slides
[lots of discussion about how to extend iterators/iterables]
Conclusion
- More work to be done in breakouts to figure out path forward for iteration.