January 26th 2016 Meeting Notes

# Rick Waldron (8 years ago)

January 26th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Leland Richardson (LM), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), Mark S. Miller (MM), Paul Leathers (PL), Sebastian Markbage (SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)



Approval of the minutes from November 2015

WH: what sort of changes?

JHD: some editorial cleanup


  • Minutes approved.

5. Proposals for Future Editions

5.i Zones

DD: Misko is presenting, zones.


MH: Writing async code is hard, specifically book keeping of (begin/end of async tasks). Specifically for framework authoring, and cooperation between various components. In other langauges, this may be "domains" or "contexts".

MH: some existing implementations, Angular Zone.js, Zone, Dart Zones, Node.js domains/continuation local storage/asyncwrap, c# logical call context etc.

MH: this has been around for some time, but the lack of standarization prevents interopt and may also prevent more ideal solutions.

MH: Frameworks often what to know when work has begun and completing, this allows for batching.

WH: Can you clarify the example?

MH: In a typcial application, a whole orchistration of async tasks occurs

YK: browser do this already, flush work -> calculate changes -> paint.

MH: by annotating different context, prioritizaing is possible. One example would be animation context vs ..

WH: thanks

MH: another example is testing, existing solutions result in test "flickering", but using zones would enable some determism.

BT: test262 would benefit from this, existing solutions require manual book keeping and tracking. No way to tell in the browser when a set of async operations have completed.

SP: it adds determism

MH: another use-case, is for measuring and instrumentation.

SP: you may also have interleaving plans, this helps group them and mitigate some common related issues

MH: good error handling, with zones you get the error handling for free. Global error handling lacks sufficient context

MH: You can also associate errors with the originating/initiating event for tracing/debugging scenarios.

DD: these actions can happen concurrently, an example would be an HTTP server serving many requests, each would want a zone To associated relevant signals.

MH: When you have unit test you want to know when everything is done so you can clean up to prepare for the next test in a clean state.

MH: this would also prevent test polution

MH: How would this work? Zone.current

MM: are you proposing global state that yields different values over time

MF: would a meta property be ok

MM: I had not considered this, it raises other questions

YK: this is a hypothetical API

MM: I understand this

MH: Time changes over time as well, but you cannot mutatie it yourself. Zone.current is similar in this regard.


MH: in a promise example, the callback would be associated with the zone it was instantiated in. So when invoked, it would remember its zone.

JM: how do zones change

DD: it hasn't been presented yet

YK: it is possible to create this API self hosted

DD: only if all async was hooked, and a transpiler for async/await

YK: I meant, if a user wrote this manually it would work

MH: Correct.

MH: We could monkey patch the then method, but their are limitations. These limitations include user-land task-queues, and other foreign async.

YK: and its common

MH: if they don't properly capture the zone, the value diminishes.


YK: ember has a mechanism, but without a standard interopt is hard.

MH: yes

DH: TLS analogy is the strongest one, async in JS is cooperative userland threads. What i haven't seen is, how to create such zones.

BT: So you said current implentations have holes?

MH/YK: It's insufficient to monkey-patch everything because frameworks might have their own event loop.

MH: we need to provide the right primites so the platforms do the right thing.

MH: Now how to make new zones "slide: more realistic Example"

MH: Zones also offer local storage, and it is valuable

DD: The "node cloud team at google" wants TLS.

MH: ... describes other details, and suggests to look at the respositor...

MM: What prevents you from calling a zone transition sync

BT: that is embers use-case

MM: run calls the provided closure sync?

MH: correct, the only way to cahnge the zone is to call run or to call a wrapped function.

DD: run is to wrap, as call is to bind.

MM: the binding of rURL is it mutable? (referring to slide #12 "More Realistic Example")

MH: they are immutable

DD: one can put in a mutable structure

MM: the accessors are referenced via string, is that important?

MH: doesn't seem so.

MH: child zones inherit the parents zones

DT: can you arrange to merge multiple ancestors

DD: you can arrange manually yes

MH: we don't support that today.

(MM: Somewhere in here I made the point that asynchronous causality is a graph, but Zones needs to treat it as a tree. At the base, the triggering of a callback has two causal ancestors, the registration of the callback and the triggering of the condition that the callback should be notified about. In promises, these are respectively the .then and the settling of the promise. All is a higher level pattern in which an outcome has more than two causal inputs.

What I finally understood from the discussion is that Zone's always follows only the registration, not the triggering, and this does always pick a tree out of the causality graph. However, it is often not the tree that most intuitively corresponds to the programmer's understanding of causality in their programs. See www.hpl.hp.com/techreports/2009/HPL-2009-78.html)

MM: let me share when this would come in force, a Promise.all where the promise inputs were sourced from multiple zones.

SP: Only the callbacks will capture the zone, Promise.all itself wont' capture the zone, rather the callback passed to resulting promise one.

YK: i think we are making the graph vs tree mistake here

MH: the registration captures the zone

YK: I think MM is saying multiple consumer may want to be part of the causality

MM: Whoever invoked the then sets the zone

YK: that may not be correct

YK: let me try to say what the two use-cases are:

1. somethingly ike TLS, sounds good.
2. life-cycles hooks around stack pushing and popping, and that is

extremely importent for flushing and rendering.

DD: i don't want to get into the hooks discussion yet

MM: We need a standard API for the "wrap", the implementation isn't that important.

YK: The DOM has to do something, we will have to standardize.

DD: the host environment needs to register a callback, so a hook could be imagined.

MM: the fact that you are propagating from the registration, but that conflicts with the addEventListener example

SP: no this will work as expected as it will merely be another fork.

MM: If the first thing a zone does is execute a zone.wrap then the invoking zone gets throw away?

MH: The first thing I do in a click handler is to ask for a zone and do all the work in it.

MM: Okay.

YK: I agree that you could make these be trees, but I think it's bad that you can't handle multiple sources.

DD: Disagree as apps aren't trying to track this. We can take this offline to discuss more though.

YK: the concern that i have, is that causality and execution branching are intermixed. Frameworks will be the same place we are today, enumerating all the potential entry points.

MH: I'm having a hard time understanding

YK: do you enumerate all eventHandlers?

MH: no

MH: I want to make sure angular knows about everything, a second problem is to track user behavior flow. I would argue this requires hand tuning.

MH: Usually, zones trigger on router changes. App changes route and a new zone handles tracking from there.

WH: How do zones interact with iterators and generators? What happens if you start one from zone A and then call next from zone B?

DD: you suspect the execution context from the generator

MH: is this not the same as async

YK: presumably

YK: the data is stored on the execution context, pause resume should work.

MH: presents a strawman "slide: MVP API"

MH this is missing error handling, but that is handled by zone spec. Zone spec describes the details.

DD: having the fully customized wrap may not make it, as it makes some of us nervous.

MH: You get to wrap the callback into the wrap, but at the end of the day you don't get to override the Zone. Fundamentally, the result will be on the zone that was wrapped.

DD: Browser engineers are very unhappy about having to call code whenever setTimeout is called

YK: await having to do this is quite scary.

YK: if you don't monkey patch the world, the platform can be performant. This makes it somewhat scary.

WH: What's so special about 'then'? If a user implemented his own scheduling and callback mechanism analogous to 'then', would that capture and propagate zones from the creators of the callbacks or would it propagate them from the callers of the callbacks?

YK: i would hope async/await offers possibilities for optimization

SP: I believe async function would capture the zone

YK: await having different semantics seems like a refactoring hazard.

DD: if there is no callback, then there is no wrap.

SP: YK is the concern that the refactor from .then(...) -> await shouldn't

change the instrumentation calls?

YK: yes

YK: wrapping allows you to intercept the scheudling

MH: no, wrapping is only post scheduling

MM: what about realms? onFulfilled could be in a different realm. The execution stack can thread through many realms.

various members mime mushroom clouds

** collective brain splosion**

MH: passing a callback from iframe1 -> frame2,

DD: we could handle this like bind, and let it work.

SP: what about cross realm data leaks.

DD: i think this is solvable, but the cross realm point is a good catch. We will need to explore this.

...: Examples have a then block presented statically, if the function

MM: it is the registration of the callback not the instantiation of the promise nor the function.

DH: I have questions about intra-thread uses of the API. Two questions:

1. You have .get but not .set you can put immutable things in the .get

so I'm not sure what it buys you to make it immutable.

MH: One property I'd like to have is that for apps that expect zone behavior, when you fork a child zone, application should behave the same way as without the fork.

DH: Only true if users don't mutate things. Is it vital for the language to enforce this guarantee?

MH: You can certainly override a property and that COULD break behavior. If code running in a child zone could mutate the parent then you couldn't see it in the parent.

DH: I didn't understand

DD: I'll rephrase -- if you allow children to set new properties, then they don't share the idea across the boundary. This is more of a path we want to guide you down rather than a path that must be enforced.

DH: I have a question that may clarify around lack of .set. There's history for other languages with TLS with use cases for what has historically been achieved through dynamic scope. A concrete example program would be a recursive descent JS parser. You have certain context being passed around like the labeles currently in scope. Only used a few places in the parser. It's a total pain to keep track. Other option is to use an OO pattern to carry context in a class/object so it's still explicit, but it's shrunk to one place. Another mechanism is to use a TLS (thread local storage) like mechansim or dynamic scoping so this becomes implicit. Only operations that need to access the state go through this. One answer could be we disavow this and say the OO way is the right way to do this. Another answer is to say this (zone) is right for doing this. Creating new zones is a heavy-weight api. Is there a lightweight user-land abstraction? Is there no place for .set there?

YK: why not just provide set

MH: get will walk up the hirachy but set will not hence get/set are not symmetric.

YK: sounds like prototypes

WH: what you are after is dynamic scoping, and this is not dynamic scoping.

MM: two ways to implement dynamic scoping, shallow binding or deep binding. This is deep binding

DH: set is not a distraction here, the temp modify and revert is orthogonal, but in particulate in the dynamic set you actually want to use mutation.

MM: this sounds ok

DH: what does the UX look and feel like, when you are actually doing this. We may say, we don't care because its not a valid use-case. Could we build a library on top of this to improve the ergonomics

CM: if you make the zone mutable, you have taken away the immutability.

DH: yes

YK: I am not wrong that using a mutable object in the slot. The parent zone will see mutation in the values.

DE: a problem with dynamic scoping with set, is that you may have an outer scope that introduces a var, and an inner scope that defines a different variable. The hazard is accidentally overriding an unintentially is common, so disallowing set fixes this issue.

DH: we should do some exploration, using this API in those use-case and see if it falls over. We may decide that is not appropriate at all. OO may be a better way to solve this problem, although I myself am unsure what is the

DT: If A passes a zone to B and then to C, A could arrange so that B could change the state the C sees. A may want to arrange so that they are isolated very specifically. A needs to be sure, B cannot interfere with C etc. If we add set, A would need to add many defensive layers in-case of a malicious actor.

YK: a symmetrical problem is users may not realize the deep mutability.

SP: think prototype.value = {} vs prototype.value = 1;, the former shares state the later cannot.

MH: I feel zones are more like an observer like a logging service. They get to watch over how an app runs and notify you to do something about it. Whether it's there or not, the app should function the same way.

DH: maybe the answer if you are using thread local dynamic scoping, it should not be built on top of zones.

YK: Arriving at "you should not put mutable objects there" is good. (referring to values passed into the zone)

MM: The proposal as it stand, there are some good goals that we should seek a way to address. Kudos on the good goals. The mechanisms as proposed combine several nightmares -- mutable global state, dynamic scoping, and before/after hooks. Before/after hooks reminds me of the nightmare of aspect oriented programming. They introduce an attack vector of invoking someone else's code during a turn while invariants are supended. Classically a thread is a sequential program, TLS (thread local storage) is a global variable for that sequential program. In TC39, we have successfully avoided global state -- if you lock down all the primordials, everything still works so far. We must keep that property. LISP has dynamic scoping. Scheme has fluid scoping. In Fluid scoping, thing that changes depending on the context you're in is the value of a lexical variable. You cannot see the values or rebind that var if you're not in the lexical scope. The strings are worse than classical dynamic scoping because the program can calculate the strings. Making them something first class or record based -- we should look how to restrict how you name those things. Otherwise you have a truly global variable.

YK: if you are too restrictive, people will end up virtualizing again.

MM: If you have fluid variables, you don't need to reinvent dynamic variables. They're still bad, but less bad. I'm firmly on the lexical scoping side of the debate.

YK: i think everyone agrees with that. Lexical scoping is the 99.9% case, some things don't quite fit in that. You can use globals or OO, all of them have issues. If you end up restricting, users will end up approximating the same thing.

MM: for most of the motivating problems for dynamic scoping, if rethought, lexical scoping patterns typically address the issues nicely.

YK: Who is the one rethinking it? If it's an app developer, they won't end up doing it.

MM: I want to think through the concepts presented here without being anti-modular.

DD: to draw this to a close, why does this need to be in the language. Patching is hazardous, coordination between many collaborators is of value. We would like to move this to stage 0

MM: what does it mean to approve something to stage 0

DH: I think it's well motivated problem.

YK: well motivated problem

MM: if I endorse some of the goals but not the mechanisms, can I approve stage 0?

DD: Yes, and we encourage collaboration with the champions. Just want to move to stage zero if we can.

YK: Stage zero seems fine.


  • stage 0 approved


MM: Does ECMA have rules for NDA's signed at these meetings? Participants should not be required to sign an NDA, the company should protect its own secrets it should not be the burden of the participants.

We need to do some diligence, some work for the next meeting.

SP: Lots of these NDA's are totally incompatible with the nature of this TC

An email has been sent to Istvan, and Salesforce will be contacted.

Its completely not binding, if it was not obvious.

5.iii Shared memory and Atomics (proposal)

Presented by Lars Hansen

(request slides)

LH: motivation, why we need this. We will also go over some of the september concerns

(presenting slides)

Slides: lars-t-hansen/ecmascript_sharedmem/blob/master/tc39/presentation-jan-2016.odp

LH: Why not only for wasm? YK: wasm will want to be sync exposable from JS which transitively means these constructs need to shared.

LH: next slide willl cover that

LH: Why not only for wasm (2)

YK: we could say, wasm is only accesible async

LH: we can't really

YK: this is a platform feature

MM: workers that have access to shared memory, are only available async.

LH: what i am proposing is that we are proposing, is that JS define these semantics. This would give it some teeth, and enable healthier interopt.

DH: "if you're gonna drink, you're doing it under my roof"?

LH: Why not only for wasm? (3)

MM: given a shared memory buffer, each worker would be seeing it through a set of types. There is nothing that enforces which types, corect?

LH: correct

LH: why not something completely different?

YK: we also don't know what it is

DH: if we want, I could put a team on it for a couple of years

LH: what is Pjs?

** parallel JavaScript **

A: Why is racy required

LH: its hard to imagine C++ program that isn't racy

WH: Depends on what you mean by "racy". You can trivially eliminate all data race undefined behavior from a C++ program by turning all memory accesses into atomics. The execution would still be racy (i.e. unpredictable), but it would not be racy (i.e. have races causing undefined C++ behavior according to its memory model). The two meanings of "racy" are quite distinct.

A: one approach I could see, is the JS side only has synchronized acess to the array buffer.

LH: concerns about slow

MM: pony + rust provide strong rules, can we enforce this?

LH: that is off the table

DH: Don't know how to track ownership and infer types inside the asm.js typed array.

MM: the point that i am making, is that the type reasoning i am speaking of is only that of the typed array.

DH: but there is only 1 typed array for the program

DH: I can't make sense of this

YK: 1 heap, that is shared across threads, without races.

MM: no runtime cost im not claiming, there is a step (from dynamic ->

static) that may involve an additional test.

YK: do you believe this cost would be cheap?

MM: im assuming (hope) it will be cheap

LH: I would like to present this proposal not what MM is speaking about, but what MM is speaking of is interesting.

LH: Some sort of integrity

DH: I was thrown off, because it is much more general.


DH: imagine that we had 1 big typed array, but where you could checkout sections of the array with different permissions (rw r) the sharing would be controller based on the permissions one had. This would allow improved concurrency, and safety. It can be data-race free, but would require some clunkyness. Alll this could be done via the message passing system, this could be spec'd and implemented.

LH: the point is, this kind of sharing DH is talking about has some issues and likely requires a better type system than JS has. Multidimensional arrays make this more complicated, (what killed it, i missed it..)

LH: for ecmascript, we likely require a better system. But we have this system today.

LH: I have decided to provide a low level system, and build a better system on top.

DH: A bigger KO, is that this can't come anywhere near the performance of the pure shared array buffer. Message passing comes at a heavy cost, as the hardware support for racy shared access enables order of magnitudes better performance

... Would a more constrained compile target not just solve this.

LH: unity compiled some benchmarks, using shared buffer they benifited from 4x speed-up.

LH: this API is a good basis to build a system on

WH: what is the API


DH: We have done multiple years exploring this. With intel + Mozzilla, we looked at race free high level API's and we really couldn't come to something that would work. It's not to say we are the only people to solve this problem, but their is limit to how much we can explore.

BE: WH you were ill and were not present to attend when this was presented the last time.

LH: the shared buffer spec is small and stable

DE: In release behind a flag (in chrome)

LH: alpha/beta/release will be behind a flag (on FF)

LH: slide (API: Shared memory)

LH: slide (API: Atomic Operations)

LH: regular access to not guarentee tearing

WH: so everything is sequentially consistent, which is far slower than acquire/release on, say, x86

LH: atomic access are sequentially consistent

What is the safe guarentee?

LH: you cannot step outside the array, and the types remain safe.

WH: There is more to memory safety than that. Java got into trouble with this, and it caused grief for C++. Reading a value and using it twice, due to common optimizations, could result in seeing different values. Booleans that are neiter true or false, not because of strange bit patterns, but because of optimizations affecting the order of memory operations. If you try to nail this down so that it could never happen, we must restrict the optimizations to a level that hurts performance.

LH: slide (API: Agent sleep and wakeup)

LH: futexWait must no longer be used on the main thread of the browser.

LH: slide (Agent model)

DH: what does a forward progress guarentee mean

LH: more or less a fair scheduling guarentee

DD: are agents continents?

MM: worker goes through a sequence of jobs, there is a full ordering of jobs in any one worker. Each worker is a sequential program. Concurrency is between workers. I would be surprised if the division into jobs becomes relevant

LH: i likely misspoke, my agents are most likely similar to what you call a vat.

MM: ok, so each agent executes a fully order sequences of jobs, where each job is executed to completion before starting the next job.

JFB: C++ is exploring forward progress guarentees to support weaker models, such as SIMD lanes or fibers. Its more a technical point.

JFB: C++ has spent many hours discussion this, it is quite complex.

LH: slide (Agent Mapping)

LH: to wrap this up, how you create agents, what they are and how you share them is all mapping specific. Browser vs node would be totally different.

LH: in a browser it would be a worker, WW semantics need much work.

LH: again, no futuxWait on the main thread.

MM: you are assuming agents are only coupled via shared array buffer or asynchronously

LH: Slide (Memory model)

Totally ordered relative to a thread?

LH: totally ordered base don the atomics

Physics doesn't let you have that, so..

WH: no you can

LH: atomic operations from JS on all shared array buffers in your browser are totally ordered

JFB: the non atomic operations are all unordered, if you don't have atomics between them, everything can be re-ordered. The atomics provide ordering through happens-before with the non-atomic operations. The atomics provide inter-threads-happens-before between each other.

WH: I am not sure I believe you

JFB: there is a formal proof for the C++ model, there should also be a formal proof for this one before it is standardize.

WH: read behaves as sequentially consistent acquire, I don't know what happens if you try to load/release in c++ memory model

JFB: there is no load/release.. I believe this is beyond this content.

M: any atomic operation is sequentially consistent even if it is unrelated.

Browser that is spending many independent process, sharing memory is complicated. Im not sure what it means for them to be ordered

LH: total order not sequential order.

LH: slide (memory model 2)

LH: this is easy to reason about, but slower then alternatives

WH: what happens during a race?

MM: once you read a value, does it remain stable or can it change?

WH: Do you get classical garbage or quantum garbage? (Quantum garbage is what happens in C++: reading a racy value and storing it into a temporary can cause the temporary to later spontaneously change its value).

LH: i don't believe so

MM: so quantum garbage

LH: Yes, quantum garbage.

JFB: architecture differences can make this impossible.

LH: im wrestling with if that is reasonable, we have already defined races will create garbage, we are defining now how bad that garbage is. Even if you read garbage, the garbage is sensible for the type that you are reading.

LH: some interesting complications, since we are using typed arrays, we can alias arrays, we can have atomic and non-atomic operations operating on the same array at the same time. Interesting problem for weakly ordered scenarios. We would like to give races a little bit of meaning. We want them to have enough meaning, so we don't crash the system

MM: weakly ordered data describes this

LH: yes

MM: tearing is a out of thin-air value

LH: nono that happens in a non-racy scenarios

WH: That is a different concept, memory models do not always match the intuitive notion of causality. For example, the C++ memory model allows you to write programs that test whether an atomic value is 42, and set it to 42 if it was 42, and the optimizer can cause, via various memory model deduction rules, to cause the test to become self-fulfilling.

LH: relaxed atomics can cause this, we address this with strong atomics


LH: lets continue

LH: slide (Other memory model issues)

LH: the goal is to high performance, but we will get there

WH: i am concerned that this is the wrong starting point

can we get some numbers and see the difference

WH: Providing a low-level library that implements sequential consistency only instead of also supporting acquire-release-relaxed seems like defeating the purpose of the effort. Requiring sequential consistency on reads/writes is several times slower than just doing acquire-release semantics on reads/writes on x86. Sequential consistency only seems like the wrong starting point because it throws away so much performance compared to acquire/release, which almost always suffices. The point of this effort is to go for high performance.

LH: any questions:

MM: you mentioned we avoid blocking the main thread, can we also make it so high-speed access is ???.

LH: in principle yes, TypedArray constructers made illegal on the main thread would enable this. This may strike some people as strange, but in principle yes

YK: UI and IO threads blocking is a well known thing, I suspect not one will notice

LH: I believe MM was thinking disabled access to the shared memory from the same thread. But i would suggest that would be practical.

BN: WebGL is on the main thread, not having access to shared memory on the main thread would be unfortunate

LH: i believe MM proposes workers having access to such things

LH: slide (futexWait on the main thread)

LH: slide (futuxWaitCallback)

YK: isn't message channel more compisition then postMessage

LH: maybe we should hold off on this then

LH: slide (side-channel attack)

LH: slide (cache attack)

YK: i have a general question, other sandboxes allow this, how are we different? iOS sandbox etc. Prior art?

LH: Im sure they have thought about this, but not alot of evidence they care about it

WH: Those things were designed at a time when timing attacks just weren't on the radar. They're all vulnerable to cache timing attack mischief. A large mitigating factor is that evil apps can be reviewed and revoked with at least a modicum of success. Browsers on the other hand must deal with arbitrary evil content.

DH: We live in a world, were forcing users to essentially install by merely navigating is true. Maybe we can prevent this, bringing us in-line with the iOS or similar sandboxes.

DH: we have strong signals, we can detect if an API caused the navigation or a user. This may be sufficient.

LH: lets push this on the stack for two more slides

LH: Existing tech (Flash/Java/PNaCL/NaCL) already demonstrate them.

MM: I would like to point out on this slide (status quo?) flash, java, nacl/pnacl are dead or dying. The fact that those exists, does not mean we need to put up with this.

LH: I'm not saying that, only stating the current state.

(MM: A clearer statement I wish I said: "if we find the danger is bad enough, browser makers could turn off flash, java, and nacl/pnacl. iPad has already turned off flash. Many have turned off java. No one but chrome runs nacl or pnacl. OTOH, once this goes into javascript, it becomes impossible to turn off. So these prior systems do not commit us so strongly that we can deny that our actions today make things worse." Some of this was said in the unrecorded verbal discussion, but not as clearly.)

JFB: Tne google teams (chrome & security team) do not believe this attack vector matters. Timing isn't the attack, rather a mechanism of leak. Non-constant time crypto can be observed. Many ways to observe this state, the google security believes the problem is with non-constant time crypto itself, which should be fixed.

JFB: there is a large number of existing leaks, which need to be addressed, the timer is only the messanger not the route cause.

WH: Yes, non-constant time operations are vulnerable. But constant time operations are also vulnerable, as long as they access data-dependent memory locations within a cache shared by the attacker.

DH: performance.now was throttle for these reasons, was this to mitigate existing leaks, essentially buying more time?

JFB: I believe it was partly that, and partly because that precision was not required. It's a cost a running close to the metal, that you can observe the metal, preventing that defeats the feature

JFB: when the performance.now thing happened, it seems low cost to change (likely no-one depended on it) so given that something could be observed it was adjusted.

JFB: given this is going to happen, there will be high resolution timer. The course of action is to fix the route causes.

LH: the current resolution is already sufficient for these issues.

JFB: with row hammer you can flip bits without atomics, because of hardware issues.

LH: I haven't found any evidence of this making it worse.

YK: it doesn't seem like we are the first to encounter this

LH: we may be exposing something, so we should becareful

YK: it merely feels inappropriate to have panic mode

LH: i can agree witb this.

WH: I believe in defence in depth, it is extremely difficult to transition all code that handles secrets to run in constant time with data-invariant memory access patterns. It's likely impossible. This applies to all code running on the machine, not just the browser.

MM: Other secrets exist, that can't be protected by constant time algorithms. For example, say some code is handed a graph containing secrets, where that code must traverse the graph to process the secrets. Clearly the pattern of memory accesses or their timing is not going to be independent of the topology of the graph. This claim that one can practically write side-channel-free constant time algorithms applies only to very specialized algorithms such as crypto.

LH: moving along

LH: slide (Mitigations for side-channel)

YK: existing API/flows exist to prevent driveby

DH/YK: let me unpack it, when navigating to a web app with an install banner, the JS code can trigger the install banner, but only if the browser believes it is not a drive by

LH: slide (complexity)

LH: slide (compiler can't introduce races)

LH: slide (Shared Memory)

LH: slide (User affected "only" by races)

WH: these are easy to deal with, the quantum garbage is not

LH: yes, i believe my next slides will cover

LH: slide (Where do we stand?)

LH: do we want this?

MM: let me verify, can we negotiate re: deny shared memory buffer to the main thread?

LH: we can talk about it

LH: slide (Where do we stand? 2)

YK: can you do this with PNacL or flash?

Yes it is possible, but it is most likely quite slow

YK: stronger point, not only is it going to happen but it has already happened.

WH: Quantum garbage issue is new

LH: We need more direct input, need help fixing it, or finding bugs. Stage 2 has the notion of reviewrs.

For the review, memory model stuff is very hard. This one may be worth getting outside help

JFB: we have contacted several and have been getting feedback from industry standards.

DD: this TC can help best with integration with the language, deferring the memory model issues to the experts seems appropriate.

LH: for example WH doesn't want quantom garbage, this is good feedback. The current 2 month cycle isn't a tight enough loop.

WH: in the last few months, I haven't seen much improvement. Especially with the quantom garbage

LH: Until now, it was unclear we wanted to fix that issue.

WH: I haven't seen enough progresss

JFB: do you feel this would result in churn, or getting the entire proposal nixed.

WH: I don't want values that spontaneously change, as that will leak and break all existing invariants. This is a deal-breaker until we have a believable proposal on how to prevent quantum garbage.

MM: if their was a boundary between code directly interacting with the shared buffers, and the rest. It could prevent it the quantum garbage from leaking. If on that boundary crossing, we ensure an atomic operation. All values post the operation would be safe


LH: if two works are running with shared memory, if X reads a value and Y writes that value. X reads into local var. It is possible to.

x = mem[a];
if (x)
could print 0.

MM: ooupfh*

DH: this isn't a security concern, rather an correctness concern

MM: it is possible to fix it at the atomic operation level?

WH: No. This problem is independent of any atomic operations.

LH: no

  • lots of talking *

?: What do other languages do?

WH: C++ makes it undefined — lots of weird things can happen.

DH: the reaosn i mentioned Java, is because they have worked very hard, and it is still full of data races. They tried to avoid synthesing pointers to objects out of thin air, that is a seperate. Did they try harder? Did they try to solve this problem?

WH: Yes, they tried ;-). The first time they got it badly wrong. The second time, after a few years' work, they got it slightly wrong.

DH: given that they got it wrong several times, are they relatively confident in the current result?

JFB: Those researchers are worker with us.

MM: Java i think is a dismal failure in this regard.

DH: this is not the Java model, this isn't multi threaded objects out the wazoo.

MM: I agree it isn't the full java problem, I agree we should look to java for lessons. We should be cautious of thinking java is a positive example

MM: We should learn these lessons.

YK: I believe what is described is a deal breaker.

DE: in typed arrays they were initially spec'd outside of the TC, and now the TC and the vendors disagree. Recommendations landing sooner is healthy.

JFB: C++ hasn't tried to speciy what happens in the race, it merely says its undefined. I don't know if Java tries to specify it

WH: They tried it, but it was unimplementable, so no implementation was actually doing what the spec stated.

JFB: I think they worked to ensure the GC did the right thing

DH: that specific issue seems irrelevant, as we are only dealing with primitive values in an array buffer.

JFB: We should likely define how far the poisoning spreads.

DH: MM you argued that multiple nans (which is similar to this) was fine

MM: I merely argued that it was not fatal, due to nearly all the language features not being able to observe the issue. In general in JavaScript, if you read a value, and re-read it you can count on it being the same. This is true of all values including NaN for old code that does not include the new binary arrays.

MM: When you (Dave) figured out how to avoid the non-determinism without introducing the other problems my proposal was trying to avoid, I quickly accepted it as superior.

LH: no actually their is a distinction, compilers today can optimize this to be single lookup

LH: shared memory invalidates that, even in trivial ways

MM: can this be isolated?

YK: you can imagine a number leaks

JFB: we should define that if it leaves the shared buffer, the value no longer change

MM: could the compiler mark those object, preventing them from polluting.

LH: it could

MM: it seems like we want something the same as volatile

LH: I believe the compiler could detect these cases and prevent the issues.

JFB: yes, the memory model needs to be defined.

BE: does this help approaching stage 2?

LH: I believe we can address the quantum garbage issue as mentioned above, we should take a pool and see if their are other blockers.

WH: timing attack is still an issue

YK: it seems like its going to happen (has happened)

WH: The difference is that, when we get a timing attack security scare in the future, if the timing is done via something like web assembly, the advice to the general public will be to just turn web assembly off. If it's a timing attack enabled via ECMAScript, it will not be practical to tell folks to turn JavaScript off because it's relied on so widely.

MM: I was prepared say no, we shouldn't move to stage two. I have reluctantly good news for you. I believe that really, shared memory should be kept out of the world of the browser. I don't think TC39 has that power, as BE mentioned. Agreeing to this, I feel like I have blood on my hands, issues will likely happen. Just like proto it was better to define then to let it be implemented in an ad-hoc way. Given the large amount of high value pthread code in the world, competitive pressures will force all browsers will to do this whether it is safe or not. We should work to ensure it is as good as possible

M: we should be sure we work with webasm, and be sure this is something that works well for then.


MM: it was the potential ability, to stop the potential propagation of quantum garbage. If we can solve it, I am reluctantly OK.

WH: i would like to also see the quantum garbage issue sorted out before it moves from stage 2

MM: for me, the quantum garbage problem would be fatal, do I need to block on stage 2?

DD: you can stop the train at stage 4 still.

DD: not every stage 2 feature makes it in the spec.

YK: it is ok to say, I am willing to advance it but not beyond 3 or 4, until this issue has been addressed.

LH: Yes it has to be solved, it is rediculous for JS to have this. Even if it means we take a performance hit.

DH: Helps us hans booms, yous're our only hope.

... some process discussion...

LH: slide ("where do we stand? 3)

LH: market place pressure, showing our seriousness is healthy. We are now at the point, were additional reviewers are important, which stage 2 is for.

MM: let me rephrase, what we believe we are advancing is a proposal that includes removing the quantom garbage propagation


BT: It is important to advance proposals.

BE: it will go into it wasm regardless we may aswell own it.

WH: I go on the record as objecting to advancing to stage 2 on the basis of failure to satisfy the stage 2 prerequisites. The prerequisite "spec quality: all major semantics, syntax and API are covered" is not met at the moment with the race memory model and quantum garbage issues being both major and unaddressed in the current draft. However, I will not block the process.


  • advance to stage 2

Weak References

(Brendan Eich)

BE: quantum death drink, half of something and half of something that is incompatible

BE: I'm here to discuss weakreferences, some want this but no-one is championing it.

MM: i do not have the time to champion it, but I will help a champion

YK: i think the main hazard alan pointed out, was that many people expect it to solve more then it should

BE: weak references wont be prompt

YK: you will still need to right cleanup code

BE: we will decouple them from GC in general, we want to avoid people assuming they can use this for fine tuned GC

MM: it may never be GC'd

BE: do we think it is important


WH: No, and I mean this as a literal answer to Brendan's question: I don't think it's important, not that I want to actively prevent it.

BE: why, WH

WE: We already have WeakMaps (and yes, I know they are different!)

MM: WeakMaps and weak refs are totaly different. While "WeakMaps" is a better name than "Ephemeron Table", it has caused endless confusion.

YK: the fact that you can't self host addEventListener is the issue.

MM: WM and WR are totally different

WH: The main reason is that I don't want to make GC visible, which WeakRefs would do. I know you (MM) don't like it visible either. However, I have no antipathy to doing WeakRefs if the committee wants to.

A: one data point, v8 has finalization in its C++, people report false issues all the time wondering why some things are not destroyed

YK: removing all destructor logic will cause people grief, this will not replace that.

BE: the C++ layer has these things, JS is used more often to implement these features. I think this is far game, I think WH is ok with it as long as it doesn't telegraph the GC.

BE: I think we can do this

DT: I am interested, but what does that mean

MM: having worked with DT before, I am overjoyed.

DT: not currently on TC-39

MM: the individual who does the work, doesn't need to be on the TC, though it does help. I am happy to be the on-TC-advocate of the proposal if necessary.

LH: have you looked at guardians (paper: www.cs.indiana.edu/~dyb/pubs/guardians-pldi93.pdf )

MM: I am very much interested in looking at it, and preferring the small talk approach. In small talk 80, they added post mortem finalization.

DT: I preferred the small talk approach

... some talk describing the above paper ...

BE: I would love a champion, but this will require cooperation with GC implementers.

BE: the only practical issue is deans partnership/activity in the meeting.

5.viii Async Generators

DD: i believe JHD should present

5.xiv Object.values Object.entries

(Jordan Harband)


JHD: implemented in chakra, flagged in v8, my patch into JSC is not yet patched.

JHD: as part of core-js and es7-shim.

DE: i have no issues with the proposal, v8 implementation is flagged. We don't pass test 262 yet. I would like to wait until we implement this in atleast 2 browsers. So I would like to suggest we wait for the next meeting.

JHD: Browsers providing feedback, re: breakage or performance, should block it yes. I don't see that happening here thought

BT: this meeting is the last meeting for ES2016, if it doesn't make it here, it gets deferred to the next.

JHD: more then one feature on ES2016 would be good for PR.

SP: last time we discussed what is 2 implementations, did we decide what that meant

DD: no.

BT: how did the browser do on test 262

JHD: chakra passed, JSCS when it lands will be.

BT: i have zero doubt that this is implementable, but the question is from a web compat standpoint?

JHD: the class of problem is typically for prototype extensions not on Object.

SP: subclasses of Objects may be affected

JHD: it doesn't seem like their are many issues.

YK: should we just wait?

DD: yes

JHD: i'll bring it up next meeting again, hopefully it is shipping in one or two browsers and the web compat concern has been resolved.

BT: do you know what the chrome timeline is, will we have afew weeks of canary?

DE: ya, afew weeks.

AR: we should land it in M50

YK: People maybe confused with async/await, entries/values introduces potential web compatibility issues, which we haven't vetted yet. Async await, had technical implementation details.


  • Stay stage 3, wait for 2 shipping browsers to confirm web compat.

String#padStart/padEnd (JHD)


  • stay stage 3, no further concerns about unicode/graphemes/RTL, Intl will handle that.
  • will pursue stage 4 when enough browsers have shipped it to allay web compat concerns

Unicode fix: tc39/ecma262#300 (DE)

Discussion about support for old operating systems

WH: In practice the unicode version doesn't affect ES programs much. New unicode versions mainly add new characters, and those just flow through ES programs regardless of the unicode version. The places where unicode version matters are relatively obscure such as case conversions for non-BMP characters or whether you can use brand new characters in identifiers. The situation will change when we add character classes to RegExps, so we should update the required minimum unicode version of the spec then.

DE: should we stay at unicode 5.1?

DD: now, it seems like we should move to 8

WH: I am worried this will cause too much noise in the test262 tests. I think it is legitmate for implementations to lag if they rely on the OS's support for unicode and don't want to penalize them with test262 failures for being lightweight.

DD: I think its no less legitimate to implement all of ES2016

DE: i don't understand your concern WH, it seems like you want to save the implementers some time, but the implementers seem on board.

WH: [repeats above]

DE: I don't believe this would be alot of noise

BT: they way i see us implementing these tests, is to have a single file for this test, having a single test fail is fine, and implementors already have machinery to manage test failures.

MF: are we doing 8 or 8 or greater?

BT/DE: 8 or greater


Object.getOwnPropertyDescriptors proposal email (JHD)

JHD: this method instead of producing a single descriptor, this would return multiple. Ultimately being what would be passed to Object.create's second arguments

JHD: can we advance it to stage 2, and we will firm it all up

MM: i am happy with stage 2


  • advance to stage 2

Object.getOwnPropertyDescriptors object: null or Object.prototype as


DD: what is the prototype of the object it returns, null or object?

YK: does anything in the spec return null prototype?

SP: Does Object.create second arg us ownProperties

JHD: yes

MM: getOwnPropertyDescritpor returns an object with prototype of object.

DD: I am fine with the prototype being object.prototype


  • prototype stays as object, DD + SP will be reviewers.

5.xi Daniel, presenting SIMD changes since December

link: docs.google.com/presentation/d/1tREM-eLjadnXZogdKXlTWY8XzicXgylI_GlIxxsMNzc/edit

DE: (walks through slides)

DD: how do you feel about the test coverage

DE: test coverage feels pretty good, the tests for the value semantics will need some more work, but largely the test suite is good.

DE: we will need to do some work on the test harness, test262 would like to generate the tests precedurally

DE: test harness may want sameValue sameValue0

DE: do we want SIMD to be optional

M: I would prefer for it to be optional, i don't see value

BT: small IoT devices

BE: the devices in question, have the required hardware

BE: SIMD is analogous to C++ intrinsics available to mobile apps that web apps compete with and mix with via webviews,

M: exactly

BE: which type of device, we want to avoid the kiddie car model

YK: As a practioner, I would like to have it everywhere. But if these devices don't implement it anyways then...

BE: what is the pressing small device use-case, the compact profile is test

DD: we could create a IoT core

BE: We don't want to go back to the compact profile of 15 - 20 years ago.

BT: samsung spoke about such devices

M: a watch

DD: Whats wrong with a fruit-like watch not supporting the full spec?

BT: it is hard to not get SIMD

BE: if there is a device that really cant run this, I question if it will have other features. Those devices tend to be hard targets.

DH: This is the same issue, we want to maybe only provide specific instructions, feature detection may be needed anyways.

DH: If it turns out a significant amount of the market can't implement we can reinvestigate.

JFB: just to be clear on SIMD. it is the bare minimum, and happens to be on most devices, and devectorizing is also not hard. It becomes really hard on much wider SIMD, that will be much more effort.

DE: it seems like we have a settled position

DD: thanks for your update

SP: can we figure out a better strategy of dealing with these problems? We continue to cover the points, and no much process is being made.

DE: we should look for such devices

BE: why would we look for devices to cripple the spec

MM: has someone reached out to the samsung folks

DH: I believe they implemented something that may support it all: Samsung/jerryscript


  • successfully delivered the update to the committee
# Rick Waldron (8 years ago)

January 27th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), MarkS. Miller (MM), Paul Leathers (PL), Sebastian Markbage (SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)




AWB: slide (Ecma to ISO) AWB: ecma fast tracks it to become an ISO standard AWB: slide (ECMAScript 2015 and beyond) AWB: slide (the plan)

BT: Got a bunch of excellent editorial comments from JP22.

WH: The Japanese ISO delegation has been by far the most prolific in finding technical problems during our past ISO fast track reviews, but they were by no means the only ISO member to make productive comments.

BT: It's not clear if the other delegations are commenting or not. They feed comments via GitHub but we don't necessarily know if the GitHub input we're getting is coming from folks associated with ISO delegations. JP22 is conscientious in tagging their contributions, but I don't know if the other ones do.

BT: some of the issues have been editorial some are bugs or implementing concensus. Lots of pull requests for bug fixes.

WH: What are the natures of GitHub submissions from random entities to ES? For bug reports I'm not worried, but for more significant contributions there may be IPR issues.

BT: it is a heuristic, significant contributions is what matters. Some bug fixes could be considered contribution, if the contribution is significant they have to be a registered contributor.

AWB: it mostly comes into play for pull reuqests, but it is up to the editor

BT: not in theory, this is in practice, Largely contributions come from people in this room, but some substantial outside contributions have occured.

AWB: that is the general plan, addressing the ISO issue. So one final update that merely points to our documents.

AWB: slide (but still need something to fast-track as update to ISO/IEC 16262:2011)

AWB: slide, describing the content of the ecmascript suite.

BT: a downside I see, right now the fast-track process allows ISO members to provide feedback. If they do not see a document, would they provide feedback? I suspect this will result in less feedback from ISO. I don't believe that is fatal, but..

AWB: i believe that is true, but what alternative ?

DH: could we submit less frequently?

SP: seems very strange to get feedback on old versions, and not on the latest or new version

YK: does everyone agree that the standard is "official" is year old, would we want sony to feel required to implement an obsolete spec?

  • general consensus *

AWB: slide (ECMA to ISO)

AWB: should we provide a technical report for JTC1, that describes our process

WH: whats going to be in this document

AWB: the current draft is on the tc39 member area of the ecma site. (displays content on screen)

WH: is their more to this

AWB: no this is it

AWB: ISO people sent an email, that suggested we require a clause for a normative reference.

AWB: it is just a set of pointers

WH: This is just a bibliography without any paragraph that defines conformance. Once this gets an ISO standard number XYZ, what does it mean to conform to ISO standard XYZ? One can point to anything in a bibliography.

BT: do you mean, it should say must implement the entire spec

WH: Yes, the ISO pointer standard should have a short paragraph stating that conforming to the ISO standard is defined as conforming to the current ECMA standard that's referenced.

BT: we should say: If you conform to ecmascript262, then you conform to the ISO spec

YK: are they ok with this?

AWB: it is actually their idea

BT: likely concerns exist, but something we can work out

YK: presumably those are one-shot things.

SP: everyone seems "in spirit" to be on-board, we just need to deal with some of the details.

BT: for this body we don't have to care, because we just do our thing. No more IOS fast tracking.

John: how does this impact 2016 release

AWB: it is entirely decoupled, normative rules dictate if no specific version is specified, it implies the current version


  • next meeting we will vote for this.
  • if concerns exist, please let us know before the next meeting

ECMA-262/402 2016 End-Game

AWB: slide (Key dates)

BT: the way I want to do this, at the march meeting I want us to approve what is in master, or a snapshot. I don't want to make minor tech or editorial changes. I will make fixes if major issues exist, but otherwise I wish we can leave it as is. Leaving it as a tag

WH: What changes are you planning on making to the spec document between now and the April 1 deadline?

BT: Just small editorial changes and bug fixes.

WH: Which, if any, of the stage 3 or 4 proposals are you planning on adding into the document between now and then?

BT: None. As far as proposal-level features are concerned, the 2016 standard candidate spec will be what's in it today. Enjoy Array.prototype.includes (and the exponentiation operator).

AWB: have you discussed what will be in?

BT: changelogs have all the normative changes, I can go over those

AWB: we don't need to know, we should likely record exactly what are the new features.

BT: (lists features)

AWB: everything that applies here, applies to ecma 402 also. ecma 402 has to go through the process on the same dates, hopefully those editors are on top of that.

AWB: slide (draft stability)

BT: istvan wants a PDF, but will accept an HTML. Some may want a PDF, but it is merely a ctrl-p of the HTML. Those that want to use it, should be aware editorial changes may be more or less useless.

BT: I will give ecma a zip of a snapshot of the github repo.

YK: the PDF seems fine

BT: how are links

YK: people should use HTML

BT: the original PDF had links

YK: people should use HTML

WH: HTML has formatting issues.

WH: PDF needs links. It's much less useful without links.

  • general agreement *

AWB: some people may want to print this thing

BT: i believe those days are done

AWB: we should provide both

BT: companies could be hired to accomplish this

SP: is this a transition period, or will be do this forever

AWB: ecma would like to have the PDF

BT: ecma wants PDF, because of ISO requiring it, now that we no longer send the full spec to ISO, this may be fine.

AWB: ecma wants a zip file, that can run on a local machine and it has the full high fedility document.

BT: yup, they can host it.

AWB: they will want to insert some analytics

BT: I'll work with them to add that.

AWB: in the past, I have just copied their boiler plate

BT: do i take the snapshot on feb 26, lets pick a date.

AWB: Feb 29

BT: ok, thats a monday

BT: how about march 1

AWB: thats fine

BT: so if you have anything you want in the document, get it to me well before march 1

WH: How many files are in the HTML spec?

BT: 6. The HTML, CSS, diagrams, Javascript

WH: Why does the archival standard spec execute Javascript? Isn't that brittle?

BT: it isn't required, it merely improves the experience


  • 30 days before the next meeting, the final draft will be provided
  • next meeting we will vote to make it ES2016
  • start the out-patent review process, you may need to alert your organizations

Ecma archiving and web hosting issues: Github, wiki.ecmascript.org,


(Allen Wirfs-Brock)

AWB: slide (Ecma Archival Issues)

AWB: slide (github)

SP: We can likely include a snapshot of issues/pull/comments requests as part of the release

YK: ecma position seems correct

SP: AWB are you going to do this

AWB: yes

AWB: slide (ES6 archives)

AWB: We need a strategy, small to medium (1 -> 2 weeks) could likely be

covered by ecma.

AWB: tc39 reflector -> github private repo


  • BT will set up reflector
  • AWB will work on archival.
  • AWB wil own the wiki archival process

TC39 Invited Experts Fund - Proposal

AWB: Istvan Sebestyen floated this, this is actually Istvan's deck

AWB: root problem is as folllows, how to pay for AWB to come to the meeting.... I am an instance of the problem. We have in the past invited experts, we cannot assume it is reasonable for them to cover this. Is their a way for a group like TC39, which is made up of orgs. Is there a means for it to provide some level of support to unaffiliated individuals who would be important contributors and such.

YK: how does one decide who is important and who is not

AWB: yes, lots of practical points to discuss

AWB: slide (ecma: type of participants in an Ecma TC)

concern about hard limit on guests

MM: is there a hard limit?

DT: a hard limit of 2 observers

YK: the found would require a group, I am concerned that this group would be peers on TC39. As a person who would benefit from this, I would be concerned that I would have to use scarce political resources.

DH: this could create uncomfortable situation.

YK: the flip side, such indivudals seeking funds on their own would not have this problem.

AR: TC39 or ecma may be the wrong organization, an org may exist an external group that should cover this. An example would be the jQuery foundation (or similar)

AWB: slide (Proposal)

YK: I find this unsettling

BT: MS GA rep didn't like this

WH: Google GA rep didn't like this

AWB: Adobe's GA rep did

BT: been speaking with more people at MS

AWB: other orgs are also speaking about this, such as the W3c.

AR: I am doubt it will happen in the w3c, but i feel the best solution is something similar to the jQuery foundation sponsoring this.

YK: this poltically frought process

MM: yes, we should be careful to not erode the healthy work environment

TD: A minor variant that may work, ECMA may administer the found but allow individuals to self-found.

AWB: this sounds like a legitimate expense

... tax talk ...

Conclusion / Resolution


presenter: Yehuda Katz link to slides:

YK: the champion group has grown, in good ways.

YK: Still at stage 1, it will likely become more clear as i progress. I hope to progress it to stage 2 in munich.

YK: babel/ts want to explore some ideas before we move on.

YK: slide (quick recap)

YK: slide (on classes)

AWB: if decorators move forward, any future new class items would need to describe how to work with decorators.

YK: we should discuss, but yes we should consider this,

YK: slide (On Object literals)

YK: slide (originally out of scope)

YK: slide (prototyped in babel and TypeScript)

YK: slide (Users by angular 2 and Aurelia)

YK: class decorators are mandetory partof those frameworks

YK: slide (displays examples of angular 2 and aurelia)

YK: someone uses all the features in the proposal have some real usages, which help with features

YK: ember has also experiments, using decorators in concise object literals via an addon.

YK: react also uses this, aka @injectProps: (shows screenshot of an example) a large part of the react ecosystem seem to be excited about

YK: another example is core-decorators by jay phelps, an example of generic decorators everyone can use

MM: so what you are saying, is decorators are relieving pressure from the language to add more specific features, as they can be implemented nicely in user-land with decorators

YK: TL;DR decorators are popular

YK: slide (motivating use cases)

JM: can you state the difference of class vs constructor decorator

YK: the constructor is not a member, and my proposals do no cover it. As putting a decorator on the constructor is isomorphic to putting it on the class

YK: the main use-case for constructor replacement, is to deal with the fact that the spec says 3 sings exist. unfortunately specing this is complicated and will require additional machinery

YK: slide (changes going forward)

YK: given that there is usage now, let me describe what is important. I want to maintain rough syntactic compatilbity. Angular for example, should be able to provide compatible decorators, without consumers having to change.

YK: we should decide on @ vs #, this would likely be the only user-facing change. As it would be a simple transform.

YK: slide (maintain existing capabilities for library authors)

MM: should we say rough

YK: yes, i removed 1 capablity, but it appeared to not be used.

YK: slide (continuing requirements)

discussion about when decorator expressions are evaluated

WH: I noticed when reading your proposal that you allow decorators on methods defined inside object literals but not on plain properties inside object literals. Is that intentional?

YK: Not intentional. The proposal on github is old.

WH: In that case you'll get a syntax clash when you try to extend the object literal grammar to allow decorators on plain properties in addition to methods, regardless of whether you use @ or # to introduce decorators. The conflict will be between the tail of the decorator LHS expression and the property syntax that follows it.

... some discussion about jits ...

AR: We should collect evidence

YK: Some confusion, the world static confused the situation, stable would have been more work.

AR: I'm ready to believe that, but their are other things that could detect statically, that decorators impose

DH: an exampe would be, replacin an IF with a decorator, would reduce the ability to quickly analyse

YK: i accept that

AWB: is it any different then a normal predicate

DH: Abstractions cost

YK: I agree, I should not speculate

SP: In Ruby, metaprogramming can happen anywhere, at any time, and decorators are more stable

YK: you can express most metaprogramming in a visible way.

YK: slide (Continuing Requirements)

YK: We want decorators to be able to decorate everything that exists within a class, including a decorator which is generic across multiple of them

.. YK talks about how symmetry is hard, generic decorators working well has been a hard problem ...

MM: provide the decorator enough information to make these choices

MM: I don't recall the concrete API, is the decorator called with sufficient information to infer ??? ?

YK: This is the intent; we have to implement it

AWB: what is the hint then?

YK: it is a short-hand methed, vs property contains a function. We have removed this from the current indication, but we have removed it.

YK: a short-hand method is the same as object literal version

AWB: super

YK: i did not realize

YK: slide (Most common reported issues)

YK: one could have a reflect.defineField that doesn't work outside of class intanstiation time.

....lots of hard to track/write up conversation, we need a stenographer....

YK continues to present read slide (Most Common reported issues)

YK: extend and decorators need to collaborate, if you could know your superclass was being subclassed a collaborating decorator would not be required.

YK: slide (Changes Max-Min)

YK: havin to feature test the object to figure this out, is unfortunate.

YK: When adding an additional descriptor, you may need access to other properties. For example, _fullName may want fullName accessor. But with private this would not work, so I proposed an abstraction that allowed reflection of the private slot. Decorating a private slot, should give access to the private slot

MM: I don't know if I agree, but we have a session later this.

YK ...diagrams something..

AWB: wouldn't it be better to have a decorator, that decorates this specifically installing the appropriate slots

MM: the exploration in private state that unified the weakMap view on how to name the private state and the slot view, was to avoid reifing the name of the private slot. To postpone the issue

YK: i dont' think that is realted

MM: the get/set functions that we are passing to the private slot..

Yk: they don't know the name

MM: the get/set functions are in a sense the reification of the name as a WeakMap

YK: ...

YK: it takes a ths

YK: that is a tracking feature of what we postponed

YK: maybe that was urgent, but I decided it is way to speculative, we can retrofit it later.

YK: i bought it up last meeting with more examples, I think it is unlikely we wont need, as it will cause grief. But we can postpone.

YK: private slots and fields will feel very similar, things that make them not compat will be a problem

MM: i understand

YK: thats all stuff i removed, I worked with ron and angular folks on a mirror based API. Which is the result of last meetings discussion. As it turns out, it is a hard to design API. I would like to propose a seperate mirror proposal, maybe at the next meeting I attend. Rather then passing in a target/name you get a mirror, with APIs that allow your to perform the required operations. The idea is to encapsolate the whole problem in a specific API.

YK: I think their are many cases were the thunks are not require, some still do. Static fields do, property fields dont.

JM: that would be a change in properties, back to what they were before

YK: Static fields are more like fields then they are like properties. People really wanted to model them the same as properties.

E: Why doesn't it work

YK: Abunch of issues, TL;DR you want to be able to say, class C, saying static singleton is class C.

DE: is their any case other then the self reference case?

YK: classes have this problem

E: this is a TDZ

YK: people don't want it to be TDZ

JM: I think mkaing static fields fields instead of properties, feels ok. I haven't found any issues.

E: isnt it already a problem?

DE: which TDZ don't you want to add

E: no fields, but the self referential inner binding gets wierd up at the end, instead of the beginning.

YK: you are correct, in one interpretation their can be a TDZ, but I would like to avoid that

YK: the timing is complicated

AWB: this is a general problem with these initializers, i think the last time we talked about it we assumed their were issues.

YK: instance initializers don't have this exact problem

E: these things will be wired up before they run

YK: there may be issues, the TL;DR static fields are fields not property

AWB: all a static field is a definition of a property on a constructor

YK: the definitiation is an instruction to install but not right now

AWB: static field name may be a property name, we will need to define the order

JM: prior we were going to evaluate them as we install them

JM: now we treat them as a description for installation

AWB: i don't think thats right

YK: i feel we will want class decorators to modify the constructor, if we do that the static properties will have been installed on the original constructor. But the static fields will be install on the wrong constructor

AWB: We have to define the ordering

AWB: a field is something that is part of a class definition, but when the instance is created the field is installed.

JM: At class definition time we will need to define the ordering

YK: this is basically the discussion that caused me to think it is not important for use to.... The timing for initializers and instantiation is all very observable. We need to be careful, as to not tie our hands to much. At the point we discover a field that may not be time it is installed

YK: many different factors, suggest specifiying static field imparatively

AWB: i believe static fields, and object literals should share the same rule

YK: i believe

AWB: it would be disturbing, if I had an object literal with two decorated properties, and a class with two static properties, and observed a different initialization order.

DH: most class systems have several phases, reality is subtle

YK: decorators interleaving with the initializer expressions.

YK: all decorators run before initializers

DH: instance initialzer expression happen at instantiation time, the whole idea of top to bottom left to right doesn't work

AWB: it doesn't work for instance stuff

DH: there is only one syntactic block

DH: there has ot be some amount of interleaving of stages

MM: something factually wrong about what you said, top -> bototm, left ->

right, can be made without conflict if the instance fields and properties are set in the constructor

YK: one world view, static side is an instantion of a singleton side. You execute it as a single class, Another world view, is to embed the object literal. Both are valid and we need to decide which one

WH: the problem is, in C++ it is possible to have a static property whose initialized value is an instance of the same class. This is useful but has unexpected consequences in C++. Because they let you do that, now constexpr static value initializers cannot call static constexpr functions defined earlier in the class!

YK: What i said is true

AWB: if we don't the scoping rules get complicated

YK: it is orhogonal

YK: if it is a singleton class, that is instantiated immidately, we would run the decorators top -> bottom, followed by the initializers. Because

they are seperate.

AWB: umm

YK: this should be obvious, static fields either as something as embedding an object literal in a class, or an immediate invoked class

AWB: what does it mean to embed an object literal

YK: two semantics, object assign...

AWB: we know semantically, that static fields/properties become own properties of the constructor properties

YK: both world views are consistent here

AWB: we are defining properties, so the two questions are when is the own property created on the constructor object. And when is the value computed that is the value of the property.

YK: the way classes work, there is a seperation of declaration of the class and instances

MM: we aren't talking about the instances

YK: it is impossible to explain these seperately

MM: what happesn at class eval time

YK: their is a, i think many people here assume that you should not run the decorators and then the expression that is wrong. It is not my sense, and I'm trying to describe why.

YK: the only way it is observable without decorators is self reference.

AWB: this goes back to static fields

YK: I tried that, and WH said we should disallow self reference

WH: no i said, we need to clear up the ambiguity

JM provides some diagraming.

class Foo {

      static someFieldA = A; <--- 1. record this; <-- 4. intiatiate

      bar() { <-- 2. assign this
} <-- 3. end


MM: when does Foo get bound

YK: at the end

AWB: i don't believe the spec..

MM: from within the class, if you execute a reading of the variable Foo before you get to the end of the }, you are in a TDZ

MM: the things that are creating observable side-affects are the execution of A, but the instalation of bar is not observable

YK: this is today, but decorators/blocks/computed property names etc, make this observable

AWB: computed properties are the way to bump into the TDZ today.

YK: the partially initialized class is not observed

MM: if you are executing the get of the name Foo, you get a TDZ violation

YK: i would like to avoid this

MM: im trying for a factual understanding

YK: you are correct

WH: what scope are the initializers run in

YK: current lexical

MM: they would refer to lexical names, names of properties are not lexical

AWB: elThis is really a discussion...

YK: I believe we will need to make static fields, which is why i was initially over thunking.

YK: with mirrors you don't get the actual objects

AWB: is there a concrete API

BT: there is a must discuss topic about walking down the prototype chain

YK: i have no more slides

YK: We want to avoid viewing partially iniitialized state


MM: we should revisit this.

YK: i just reasoned from the use-cases

YK: slide (Property decorator, v.last)

AWB: mirrors on objects, and mirrors on function definitions are quite different

MM: function definitions are not reified objects

YK: for v0 it hasn't come up

AWB: it may be relevant to constructors, you may want to see a method definition.

WH: I have the same point, if the mirror mirrors a function it can call rather than a function creation descriptor, what is the point of the mirror, why not just use the function?

YK: the open question, is a mirror the snapeshop, or a singleton object that mirrors the entity.

WH: even a snapshot is dangerous, as it could give access to mutable state.

YK: why?

WH: Shallow snapshot or deep? A shallow snapshot can point to newly created internal mutable state that the class wasn't expecting to have gotten loose yet.

SP: i believe a shallow snapshot is being described

MM: a deep snapshot is off the table

DE: trying to interrupt to switch to a different agenda item can we move this to a break out?

BT: this is relevant, but lets avoid rambling

YK: a snapshot may be wrong, if someone wants a stable reference. Which enables talking about that entity.

AWB: something is bothering me, in ECMAscript, other then modules. Have two sorts of constructs, which have complex evaluation semantics, that result in the creation of one or more objects.

  1. object literals (sorta complex)
  2. class definitions (very complex)

It seems like fundamentally as we talk about decorators, we want to formalize those.

MM: I feel like I have learned something

AWB: i the piece I am missing, although you may have it in your head, but I would really like to 1 and 2 formalized.

YK: everything you said rings true to me, my current.. To go through the runtime semantics, I should submit this. It is reasonably clear where things go.

WH: i dont think so

YK: im not saying anyone can do this, but AWB analysis is correct

AWB: one could imagine a hook point, a processing pipeline that every class definition goes though. This could enable the extends clause aswell. This elevates the control

MM: it is a new way to think about it for me, I really like it. I have always thought about decorators as merely desugaring. But really, it is hooking the complex initialization process.

YK: yes, the motivation is to enable flexibility in the current declarative blob. I agree with the analysis. I believe it is correct to address this. We should discuss the snapshotting in a breakout. I believe having one mirror that lives the entire life.

MM: decorators thought of as multi stage programming model

YK: i think my last topic was quite long

MM: it is possible that the presentation was only understandable with this new world view.

MM: the hooking of instantiation if very distinct from multi-stage programming.

YK: yes, we should talk about this in a break out.

YK: ok, my question. I don't know how people feel about non-snapshots.

MM: Deep snapshots won't work, shallow are making a promise they can't deliver.

MM: the classic reflection APIs I am aware of are live.

MM: decorating reified things, vs multi-stage programming. Determining what the program is vs determining the value

YK: I agree, that seems fine. Im not sure what my next steps are

WH: it would be more productive if this was less vague, nothing we can carry on productively until that.

YK: that doesn't match what I need.

MM: as TC39 this isn't quite productive

WH: By more concrete, I mean a less vague proposal that we can discuss, not start implement something right away. We're not at the stage where we should be implementing yet.

DE: can you take an idea on those proposals and write it up

MM: any one of these perspectives needs to be fleshed out.

MM: fleshing out your persective is wonderful, fleshing out mutiple is also wonderful

YK: it was roughly fleshed out...

DE: I have not seen a sufficiently detailed proposal. Can you share a link

YK: i can send links, but their may be not something sufficiently speced out

MM: What is bothing me, is that as a designer you seem to be straddling multiple perspectives.

WH: the problem is, togglilng perspectives makes discussions compleciated

YK: tell me how

WH: For example, it all depends on the ordering of initialization — the different world views conflict on this.

E: isn't that the crux of the design of the whole thing the point of this

E: he is trying to figure out

YK: i am asking how to make this more conrete

MM: their are 3 distinct perspectives

  1. classic OO Design Patterns book: decoration replaces value with similar value, typically wrapper of original
  2. the hooking of the instantiation process
  3. mutli-stage perspective

These are very distinct, I would prefer to see one perspective fleshed out, this will help provide a more coherent model.

YK: I believe I am in the second camp, what leads you to believe I am not.


AWB + MM + YK will break out.

Object.Prototype Security issue with Proxy

presenters: Dan Ehrenberg / Jeff Walden

JW: slide (the attack: same-origin polciy workaround)

WH: we would have more of a problem if we expanded JS syntax?

JW/DE: slide (Why not, and not earlier?)

JW: getters are more constrained, but it is slightly harder.

YK: this seems also bad

YK: can you force SW to cache the opaque thing.

JW: the browser cache is sufficient, each new script element gets invoked.

YK: throttling that seems like one way to mitigate

… some discussion to clarify the attack vectors of CSRF …

JW: slide (The attack: Some-origin policy workdaround)

JW: Object.prototype/ Window.prototype. EventTarget.prototype

WH: Could the system say, this is not a a script?

MM: there is a header that can be used

DE: sights should use that, but that isn't sufficient.

JW: the browsers must support the flexilibty, due to far too much content depending on this.

JW: slide (...)

JHD: would [] cause the same issue wrt Array.prototype?

JW: no, not observable

JW: slide (Why not, and not earlier)

DE: i added some counters to chrome, and discovered far to many such occurances. Forcing mime-type/no-snift would break the web.

JW: slide (one solution: lock down proto)

AWB: ECMAScript requires that the global object had object.prototype in the chain.

JW: as of yesterday release FF ships with an immutable global object proto chain, with no compat issues so far.

JW: alpha 12 weeks, beta for 6 weeks. still no issues. (October)

YK: if you want to do this, we may explore the realm API.

JW: why?

DE: BT said they have an embedding object that uses this.

YK: you can imagine a realm API, that would allow a proxy wrapped global.

MM: wouldn't that cause the issue.

SP: no, the custom realm would not get script tags invoked with it in

YK: We should make sure that we also prevent the attacker from using realms for this, so being sure we can't get the scrpt tag behavior in it.

JW: slide (but how?)

A. make pbject.prototype exotic B. add a MOP operation

MM: i've wanted option B

BT: are you ok with A. now?

MM: yes, we should explore B later.

YK: is it possible to say, it can't be a proxy?

DE: The V8 team had an idea, to prevent the global trap to be a proxy

MM: it would allow the ability to discover whether an object is a proxy or not.

... discussions. some rabbit whole ...

MM: this is fairly strong, re: web compat

YK: it is not obvious to me, as we have seen IE ship for years, and only when chrome ships do we notice the web compat issue.

DE: we will have moderate evidence by march when this freezes

DE: IE has some anti phishing technique that no one is quite sure how it works.

MM: i am in-favour of accepted ??? now

DD: I second

MM: thank you Mozilla for doing this experiment.


  • lets do A (merge the PR now)
  • TC expresses interest in B, it requires a proposal (will be stage 0 once written)

quick interjection: method param decorators, function expression

decorators (YK, MH)

YK: stage 0 for function decorators?

AWB/MM: stage 0 is exploratory, make it part of the same proposal?

… discussion about splitting/decoupling proposals …

… MH putting up slides …

MH: first slide, method param decorators example: refresh(@lastRefreshTime timeStamp) { … } as example

YK: additional metadata about the param they're attached to

MM: can not change meaning?

YK/MH: can change meaning. decorator gets extra info to identify that it is a function param.

MM: happy with stage 0.

MH: function param decorators: schedule(@memoize (value) => ...)

WH: Syntax conflict with the method param decorator example @leg('right') rightLeg. When used with arrow functions above, the @memoize decorator would swallow the arrow parameter list (value), just like the @leg decorator swallows ('right').

MH: corrected function param decorators example: schedule(@memoize function (value) { … })

… discussion that clarifies that they could replace the value, like all decorators …

MM: keep as separate stage 0 proposals

MF: tl;dr about problem trying to be solved?

MH: 1) dependency injection, example shows on constructor parameters

MH: motivation: testing (@timeout), @flaky, @disabled, @slow/@expensive, @description, @async, etc


  • Method param decorators at stage 0
  • Function expression decorators at stage 0

Function#toString && Function#isPortable (MF)

MF: slides: current stage 1

MF: original goals:

  • remove forward-incompatible requirement
  • clarify "functionally equivalent"
  • standardize string representation
  • clarify "actual characteristics"

MF: revised goals: - define "portability" with Function#isPortable - make a guarantee about the behavior of portable functions after deserialization in an equivalent lexical context

MF: what does "portable" mean slide: - a function F defined in a lexical context L is portable is any function generated from the eval of Function#toString in L has a [[Call]] that's indistinguishable from F.[[Call]]

MM: closest to "no free variables" that you want is "no free vars besides standard globals". this might allow failing on the sending side instead of the receiving side.

JHD: use case of "list the free vars" might be, user deciding if they can send a function to a webworker for example and reconstitute it safely

MM: allows description of behavior to be moved

DH: perhaps isPortable shouldn't be something we encourage people to use and we should put it not on Function.prototype

WH: Why did you define the concept of portability?

AWB: when reading the agenda, i didn't know what "isPortable" meant, nor an intuitive sense

MF: that's why i've defined it on this slide

WH: commenting on slide with definition of portability in terms of function observational indistinguishability: What does it mean to be indistinguishable? If functions A and A' both return the current time, are they indistinguishable? If A returns 5 on big-endian machines and 7 on little-endian machines and its clone A' happens to run on a different endianness from A, are they indistinguishable?

MF: ?

MF: slide (goals);

YK: some function exist, which when calling toString may not produce an evalable function.

MM: MF is addressing that, but it doesn't answer, among functions that give you an evaluable string

MF: slide (what is the lexical context?)

MF: slide (what isn't portable)

YK: does the proposal introduce isPortable false, that is evalable?

YK: isPortable means, is evaluable then.

MF: slide (what isn't portable)

MM: isPortable is things that will evaluated without a syntax error.

MF shares spec text

ARB: indistinguishablity criterion is trying to use obsrvational equivalence, which is superhard even for much simpler languages. Moreover, this requirement is impossible.

WH: Any kind of definition of isPortable like this is not sufficient to meet the indistinguishability criterion. There are plenty of places where ECMAScript gives implementations latitude in how they implement features (sort, Unicode version, and floating point library accuracy are some examples; there are many others). A deserialized copy of a function serialized on a different engine will observationally differ from its original. Given this, I still question the use for defining the concept of a portable function or isPortable.

ARB: Much simpler counterexample to indistinguishability criterion:

let g = function f() { return f === g }

Eval'ing g.toString() cannot create an indistinguishable function.

MF: already in existing spec

ARB: then it's a bug

parse tree discussion exploring the idea of replacing function equivalence with parse tree equivalence

WH: What exactly is a parse tree? What about whitespace?

DH: White space and comments should be preserved.

YK: No, they shouldn't.

… discussion about parseability, errors, new Function to detect, toSource, etc …

MF: "possible solutions" slide


  • none yet, will continue tomorrow morning, first thing
# Rick Waldron (8 years ago)

January 28th 2016 Meeting Notes

Eric Farriauolo (EF), Caridy Patino (CP), Michael Ficarra (MF), Peter Jensen (PJ), Domenic Denicola (DD), Jordan Harband (JHD), Chip Morningstar (CM), Brian Terlson (BT), John Neumann (JN), Dave Herman (DH), Yehuda Katz (YK), Jeff Morrison (JM), Lee Byron (LB), Daniel Ehrenberg (DE), Lars Hansen (LH), Nagy Hostafa (NH), Michael Saboff (MS), John Buchanan (JB), Stefan Penner (SP), Sebastian McKenzie (SMK), Waldemar Horwat (WH), MarkS. Miller (MM), Sebastian Markbage (SM), Zibi Braniecki (ZB), Andreas Rossberg (ARB), Ian Halliday (IH), Keith Miller (KM), Tim Disney (TD), Misko Hevery (MH), Brad Green (BG), Kevin Smith (KS), Brad Nelson (BN), JF Bastien (JFB), Shu-yu Guo (SYG), Rick Waldron (RW), Staś Małolepszy (STM), Dean Tribble (DT)



Function#toString && Function#isPortable (MF)

Slides: docs.google.com/presentation/d/1o8jVhyVHljCFyXdxe-V4X1pUmCgx0FuFvEO0fFP4LJU/edit?usp=sharing Spec text: raw.githubusercontent.com/michaelficarra/Function-prototype-toString-revision/fc69a0a31dc6d625736bfbb712ac782eb241ff3d/proposal.html

MF: No longer interested in "portability"

YK: Do your changes cause a method with super to produce an evaluatable function with .toString()

MF: No.

MF: < Presents new spec text >

MF: Either you are a bound function exotic object or other callable or throw an error.

WH: What case does calling toString on Math.sin fall into?

MF: The last one: [native code].

AWB: What if I want Math.sin to be self-hosted in ECMAScript?

MF: Host can control the internal slot...

AWB: Not if it's an ecmascript function object. An ECMAScript function object is an object that is created syntactically from ECMAScript code.

MF: implementation cna pretend there's a slot.

AWB: Concern is for self hosted built-ins you want them to be opaque.

MF: We can add a case for built-in functions. Is that something that we want to do?

BT: We should mandate that built-in functions show [Native Code]

YK/MF: Agree.

AWB: Are implementations allowed to hide source code for ES functions?

YK: toString is a defacto reflection mechanism. Web depends on it.

AWB: Not all code runs on the web.

AWB: Seems like a value add.

MM: It would be a value add for an implementation not to support sloppy mode.... but it can't claim to be conformant.

(Discussion of how imortant toString returning source is...)

BT: Bound functions should show [Native Code]

MF: Currently an option.

(Agreement that it should be required)

MF: Ok.

discussion about what method name to use, and what if it isn't an identifier

MM: Don't use the current value of the name property.

WH: This won't solve the problem of it sometimes not being an identifier. You can have a computed property name for a method that doesn't evaluate to an identifier.

MM: Treat the [computedname] expression, instead of the string it evaluates to, as part of the source code of the function?

WH: That's not really part of the source code of the function. It's part of the context.

MM: It's the same situation as with class extends expressions.

YK: The fact that you can omit the extends clause is an issue.

?: Just use the original source's AST.

MM: Let them throw away comments.

?: What about calls to new Function?

WH: Don't want to require comments and whitespace to be preserved. And what about comments on the boundary of the function (before the first token or after the last one)? Are they part of the function or not?

back and forth about preserving whitespace or not

WH: Current engines are inconsistent about whitespace, even within one implementation. Firefox sometimes preserves whitespace, sometimes doesn't. Different implementations differ in many ways on this. Reiterate not mandating preservation of whitespace and comments.

MM: Agree.

later MM changed his mind again

No consensus on whitespace treatment.


Keep exactly the original source text starting from the position of the first token of the production and ending at the position of the last token. Within this text, keep comments and newlines. Still no conclusion about insignificant whitespace, i.e., whitespace other than newlines.

  • MF will adapt what was discussed into the spec text, advance stage 2 that is complete

  • Reviewers: MM, WH, YK


LH: slide (formal reviewers)

LH: looking for multiple reviewers

WH: I have memory model expertise and will review that aspect. Also suggest having Hans Boehm look at it.

BT: this specification requires continent etc.

LH: it doesn't have to be deep, but we require some framework to be in-place.

DE: any typed array designers inovled

AWB: me

DD: If he comes to us in afew months, and presents the API, we would prefer to not then have to dig in

DD: last time the TC made changes quite late, it would be great to catch those early


LH: some changes to the typed array spec, to accomodate SharedArrayBuffer, should be vetted

AWB: I would be happy to discuss


  • DD DE AWB will be reviewers

Rundown of reviewers (from LH's notes):

  • littledan will represent v8
  • brian for chakra (but he will look for a delegate)
  • unclear for jsc (LH will ask filip pizlo)
  • waldemar for the memory model
  • allen (informally possibly) for TypedArray changes
  • domenic for agents/vats/whatever

LH: Also desirable for everyone to read the spec and pitch in, the more eyeballs the better.

5.xix Proxy Enumerate - revisit decision to exhaust iterator

(Brian Terlson) tc39/ecma262#160

BT: issue with proxy enumerate trap and for-in, where iimplementations are prevented from pre-populating the list of keys in the object, because the iterator causes observable affects. Which means the iterate must be pulled for every iteration. Last meeting we thought it would be ok if the enumerate trap exhausts the iterator, we thought that would solve the problem. The issue was, now their is an observable difference between an object and proxy of that object, mainly due to delete.

AWB: thats wrong

AWB: if you doit as part of for-in it wont be a problem, as for-in can be specified to ignore deleted keys.

BT: right now, for-in does not do a has-check for every property. If a key is deleted, it wont be seen. That is how proxies in edge work today, deleted keys (during enumeratino) are not visited.

BT: We could say, for-in (or proxy enumerate trap) will exhaust the iterator and check on each iteration

ARB: that is what v8 does

BT: I dont want an observable difference for for-in

YK: the has check on a proxy is non-observable anyways, and often it can be skipped anyways.

AWB: the classic spec if i recall, you cannot get a duplicate key, if something is added during enumeration you may or may not see it, if it is deleted before you enumerate it you must not see it.

ARB: enumerability is also something we need to take into account, I think more issues exist, we should likely keep it vague.

YK: thats one approach, as we don't have this defined, maybe the proxy needs to reflect the implementation

AWB: proxies can do very interesting things

YK: the enumerability is already quite hazardous, this isn't really anything new.

MM: it seems like these rules could be specified, could we just do that?

MM: v8 on normal objects does snapshot + has check, but not post-snapshot enumerability check.

YK: So far, we have spec'd this as vague, to allow divergence

MM: we should specify this,

BT: i will need to do some exploration

MM: does anyone, based on their implementation know that they would object to specifying proxy + regular objects, the semantics of snapshot + has-check

BT: I would love that

MM: let's leave this to you to investigate, and a future meeting.

YK: we want this for es7

DE: can we get consensus on GH.

WH: Are we specifying a long delay before you get the first element if you begin iterating on an array with a billion elements, even if you just want the first few?

BT: yes we are, but we all do this already

ARB: one issue with snapshotting, is how does it relate to the prototype chain

BT: yes this is under specified

YK: we should try to

AWB: the reason it was under specified was

BT: jscript?

AWB: ya sorta, minor variations among implementations. At that point in time, consensus was dificult it seemed like we couldn't do this. If we can, we should

BT: unsure

YK: if we can, we should

AWB: the other issue is: it isn't clear to me why we have an enumerate trap

BT + ARB: me neither

AWB: for-in has enough meta operations to define what we want.

MM: we should ask tom, as he thought this stuff out in great detail

DH: isn't that question too late?

DE: it isn't a web compat issue yet.

DH: it isn't obviously a mut question, but we may not be able to.

DH: i do not know how often this is used, isn't enumerate a fundamental trap.

YK: i agree that is a thing

... discussion if enumerate is fundamental ...

YK: spidermonkey people have the strongest here

BT: We have internal users of proxies, we may have a constraint

YK: that isn't a constraint it can be deprecated,

BT: comes at as cost, but i doubt its actually used.

ARB: one reason for enumerate trap may be that the set of all properties is larger then the set of properties that are enumerable, so a performance difference is pssible.

YK: getOwnPropertyDescriptors + filter out enumerable, covers this

BT: what is the trap name for all property names .... getOwnPropertyNames

BT: should for-in just be implemented as that.

BT: we would get rid of enumerate trap

ARB: doesn't one return an iterator

AWB: i think the enumerate trap was the only MOP operation that returned the iterator

...: if we have serious performance implementations for internal, we will keep it, but wont expose it

BT: it might not be possible to... we will have to give an explicit ordering for prototype properties.

AWB: the only way to doit, is to set some requirements, vague or not


  • provisional consensus to kill enumerate trap, contingent on running it by tom
  • for-in does [[HasProperty]]

************** Response from Tom: **************

A few things come to mind:

  1. Faithful virtualization of the prototype chain. We decided that the Proxy should always be in control of operations involving prototype inheritance. This includes has, get, set and enumerate. For all of these operations, when executed on a normal object, they will walk the prototype chain until they hit a Proxy. After that point, full control is delegated to the Proxy. If a Proxy would only be able to override get() and set() but not enumerate(), this may lead to inconsistencies (without an enumerate() trap, the VM will have to externally walk the prototype chain of the Proxy via getPrototypeOf()).

  2. When we designed Proxies originally, we made the design decision to map many built-in operations directly to specific traps, even if these operations could be expressed in terms of more fundamental operations (get, set, has, enumerate are all examples here). The design argument here was always improved performance by reducing the number of temporary allocations.

Much later in the design, others started pushing back on the number of traps, leading us to reconsider some traps, e.g. I recall the "hasOwn" trap was dropped in favor of checking whether (getOwnProperty() !== undefined), even though it is strictly less efficient. I don't have a view on the actual cost of expressing enumerate() in terms of lower-level MOP operations, but it seems obvious that there will be more allocation costs involved. The question is then: if enumerate() gets dropped on these grounds, why not get(), set() and has()?

  1. As far as I recall, enumerate() is the only trap that actually returns an iterator over the property names, allowing efficient virtualization of objects with a large (or potentially, infinite) number of properties. The only other trap that returns a list of property keys, "ownKeys", returns a manifest array of property names.

  2. enumerate() had weaker invariants than ownKeys() [just like all the traps that deal with prototype inheritance, since a frozen object can still inherit from a non-frozen object, leading to weaker observable invariants in general]. If one would express for-in in terms of repeated calls to ownKeys(), the invariant check overhead may be substantial compared to just calling enumerate().

Unless there are really good reasons to get rid of enumerate(), I think it should remain in. For me, (1) and (3) are the killer arguments: consistency with has(),get(),set() and efficient enumeration via iteration.

Feel free to forward this mail to TC39. I'm happy to engage in follow-up discussions, just ping me when needed.

5.xviii Exponentiation Operator (RW)

RW: i implemented the changes, tried to get brendan to review it (no luck). BT reviewed, and chakra implements

RW: BT and I went over it line/line, followed up with new tests, and in the last 20 minutes per domenics suggestion I duplicated the applying ** operater tests, so both map.pow and ** tests. the SM folks will be happy that they all passed (except for one, but that's expected).

RW: chakra implements, applause for OSS chakra

RW: motion to include to stage 4, inclusion for 2016

BT: thanks rick

RW: any objections


  • stage 4!


Afternoon Agenda

  1. Date and place for the next meetings


Meet in Munich Monday May 23-Wednesday May 25

2. 402 needs reviewers (20min)

CP: HTML version of the second edition is now public ( www.ecma-international.org/ecma-402/2.0/), just like 262. We have done some re-orgs on the spec to make the new features easier to include. Many new features have been proposed, lots of new contributors, good momentum. At this point we need reviewers

DE: first we need to propose to stage 2.

CP: we want to move 3 things up, and get reviewers, and one small detail

AWB: before we get to stage 2 things, what is the status of 2016 402. COuld we have a summary of what is in 2016 402.

CP: it will be very small, some fixes related to locale parsing. One or two functions, that will expose existing abstract operations.

AWB: are those written up, you know the schedule, that means by the next meeting you have to be done

CP: yup

EF: we have one potential problem to discuss,

EF: slide edition 1 [[CALL] Behavior (Considered a Spec bug)

AWB: thats basically, at the time the spec was drafted that was how the current thinking of internal slots to happen. This allowed internal state to be dynamically added to instances, that was decided inappropriate, and ultiamtely abondoned.

EF: the problem was, a library intl, format cache. using memoizing used this pattern. This pattern was introduced in sept 2014. The issues rolled in nov 2015.

EF: I fixed this in a patch release of the library

EF: slide (tl;dr of intl-format-cache dep on Edition 1 Behavior)

EF: slide (intl-format-cache at 2.0.5)

EF: slide (Potential Impact? (Excluding Yahoo's Usage)

EF: slide (ative wart removal)

EF: impact is likely large.

AWB: in addition 1 of 402, it was possible for a single object to be multiply constructed, and get the private state of each constructor. Hopefully no-one has done that

EF: ya, not our problem.

AWB: it occurs me, leaving it as addition 2, their is likely a work-around. Specializing object.create for this pattern.

DE: no...

EF: slide (tl;dr of intl-format-cache dep on Editirion 1 behavior)

DE: if we can scope these changes to the intl functions, rather then O.create

AWB: you don't want this to be in the spec. So what is the smallest thing one can do to maintain the compat.

EF: we can also rollback the changes in 3, and see the impact.

EF: slide (active wart removal)

RW: the first addition was a mistake,

everyone agrees

RW: we fixed it because it was broken, the fact that library relied on the brokeness is unfortunate. The only way to fix this is to re-break it.

DE: What should implementations do

MM: i think we can fix this

RW: @MM, did you review the comment i posted?

MM: please send me the link to review.

EF: presents comments on GH issue 57

...MM explores the code...

MM: what you do, is the call behavior of Intl.Collator if its sees an object that inherits from Collator.prototype that is not a collator, it creates a new Collator and uses a unique Symbol to hang that newCollator off of that object. All the builtin Collator methods then checks whether their alleged Collator argument is a non-Collator with a property named by that Symbol. If so, it looks up the Collator state on the value of that property, i.e., it forwards all state lookup to the value of that property. A hack to deal with an emergency. No security issue here, so no problem that the Symbol can be read and used for other purposes. No accidental collisions, all the primitives must then detect the collator.

SP: this isolates the fallout

MM: it can be self hosted, after the emergency is over can be removed.

RW: (Agree)

YK: We may want to leave a note

AWB: Annex in 3rd Edition that explains the compatibility issue and how to address it.

YK: as long as its in the actual spec we are good

EF: DE could google try Mark's suggestion of restricting .call's extra behavior to just this case, on the output of Object.create for a given Intl instance type this out?

DE: yes, it seems reasonable


  • wont roll it back
  • try MM suggestion in chrome to support web compat
  • add note to 402 annex (third edition, references second and first)

5.xix (Revisit) Proxy Enumerate - revisit decision to exhaust iterator

BT: Proxy.enumerate is removed, should Reflect.enumerate be removed?

JDH: it would be unfortunate

YK: I think its worth having a bucket that is 1:1 with the MOP operations, reflect happens to do that. If we remove Proxy traps, MOP should also see a similar removal.

AWB: it seems alot harder for Reflect.enumerate then Proxy enumerate trap

BT: the usecases for Reflect.enumerate outside of proxy enumerate trap isn't very compelling. If we feel comfortable removing the proxy trap, we should feel comfortable removing Reflect.enumerate

MM: i think you are correct, but if some interleaving between enumeration + proxy traps

MM: cross browser web-pages, can't

JHD: polyfils have this

YK: they will continue to work

BT: any objection to remove Reflect.enumerate

MM: We need to check with Tom Van Cutsem first.


  • Remove Reflect.enumerate, contingent on further information from Tom

************** Response from Tom: **************

A few things come to mind:

  1. Faithful virtualization of the prototype chain. We decided that the Proxy should always be in control of operations involving prototype inheritance. This includes has, get, set and enumerate. For all of these operations, when executed on a normal object, they will walk the prototype chain until they hit a Proxy. After that point, full control is delegated to the Proxy. If a Proxy would only be able to override get() and set() but not enumerate(), this may lead to inconsistencies (without an enumerate() trap, the VM will have to externally walk the prototype chain of the Proxy via getPrototypeOf()).

  2. When we designed Proxies originally, we made the design decision to map many built-in operations directly to specific traps, even if these operations could be expressed in terms of more fundamental operations (get, set, has, enumerate are all examples here). The design argument here was always improved performance by reducing the number of temporary allocations.

Much later in the design, others started pushing back on the number of traps, leading us to reconsider some traps, e.g. I recall the "hasOwn" trap was dropped in favor of checking whether (getOwnProperty() !== undefined), even though it is strictly less efficient. I don't have a view on the actual cost of expressing enumerate() in terms of lower-level MOP operations, but it seems obvious that there will be more allocation costs involved. The question is then: if enumerate() gets dropped on these grounds, why not get(), set() and has()?

  1. As far as I recall, enumerate() is the only trap that actually returns an iterator over the property names, allowing efficient virtualization of objects with a large (or potentially, infinite) number of properties. The only other trap that returns a list of property keys, "ownKeys", returns a manifest array of property names.

  2. enumerate() had weaker invariants than ownKeys() [just like all the traps that deal with prototype inheritance, since a frozen object can still inherit from a non-frozen object, leading to weaker observable invariants in general]. If one would express for-in in terms of repeated calls to ownKeys(), the invariant check overhead may be substantial compared to just calling enumerate().

Unless there are really good reasons to get rid of enumerate(), I think it should remain in. For me, (1) and (3) are the killer arguments: consistency with has(),get(),set() and efficient enumeration via iteration.

Feel free to forward this mail to TC39. I'm happy to engage in follow-up discussions, just ping me when needed.

8 Ecma 402, Edition 3, Advance stage 2

(Zibi Braniecki)

402-related slides: drive.google.com/drive/u/1/folders/0B1rFz38aICo2YUpVd0VfTUdwRW8



ZB: slide (format to parts)

ZB: further customization, requires exposes of abstract operations such as format to parts.

ZB: slide (current status)

ZB: polyfil has it, gecko has it behind flag

ZB: we are looking for reviewers

AWB: how about formatParts

DE: its the output not the input, so formatToParts

DE: I will review

RW: I will review


  • stage 2
  • Reviewers:
    • Rick Waldron
    • Daniel Ehrenberg



ZB: slide (usage)

ZB: we are just following CLDR conventions here

ZB: we are at stage 1, we have spec text. Current status we worked on decimal parts, which was a previous concern

WH: How do you distinguish between 1 and 1.0? These two have different plural rules in some languages but 1 === 1.0.

DE: extra fields in the input to specify number of fractional digits

EF: to mirror what number format has

ZB: reviewers?

MF: Is there a reason why we are using strings instead of other output

ZB: yes, the users will use this in a switch catch, those categories are part of the CLDR

MF: some other identifer could be used on a stable object

YK: the web has moved away from this

YK: the web has stopped to create constant that point at a number

DD: yes, absolutely

AR: Yes, anyone presenting a sepc with a number constant will be asked to re-work it

DD: userland could implement if they want.

AWB: what value would we actually deliver, in both cases they need to know the name

YK: they are both constant

SP: userland can do this

AWB: Yes, I don't know how...

ZB: reviewers?

SP: me

DE: me


  • stage 2
  • Reviewers:
    • Daniel Ehrenberg
    • Stefan Penner


Abstract Locale Operations


ZB: we wont provide all formatters, but we will all users to build their own.

ZB: will allow users to build language negotiations

ZB: slide (Intl.getCanoncialLocales(locales)

ZB: Intl.getParentLocales(locales)

ZB: many exceptions here,

ZB: we have all these operations, somewhat inconsistently used internally. Now we will expose them, and also use them in-consistency

ZB: there are 100 exceptions to the rules

ZB: slide (Intl.resolveLocaleInfo(locale[ ,options])

WH: What's the point of passing in {direction:true, firstDay:true, hour12:true} when retrieving the options object? Why not just return the whole object?

CP: why filter, why not just return everything

ZB: optimization? We can drop it

ZB: slide (current status)

MM: can we agree that the second argument that contains the filter, that we are getting rid of that

ZB: yes

CP: yes

WH: yes

MM: does the api return a fresh one?

MM: It needs to either return a fresh one or a deeply frozen one. Otherwise you'd have a global communications channel.

ZB: unsure

DE: yes

CP: whats in the content of the object returned, is it spec'd

SP: needs further exploration


  • stage 2 reviewers
    • Stefan Penner
    • Daniel Ehrenberg

Intl Formatter preview

ZB: this is still exploration

ZB: slide (Intl.UnitFormat)

ZB: lots of un-answered questions

ZB: slide (Intl.DurationFormat): Video player or timer in a watch. Distinct from UnitFormat

ZB: slide (Intl.ListFormat): Localize "Mary, John and Nick", including change String.prototype.toLocaleString()

ZB: slide (Intl.RelativeTimeFormat): "two seconds ago", etc.

ZB: everything is in CLDR, and we want to expose this

DH: A lot of these are solved in userland, what is the scope? Is it for things that are already there, we want to surface those? If its not in CLDR do we leave it to userland

ZB: yes

CP: also prioritize it on the amount of data and complexity

ZB: these 4 handle the most common problems we have seen.

CP: considerable existing bikesheeding, but more are invited to join.

ZB: stage 0?


  • advanced to stage 0

Async generator functions

presenter: Kevin Smith link to presentation: docs.google.com/presentation/d/1OwDb4WH9pkdEFVhsY5kjaJ6MF1KrxBNQWpWc9SymweQ/edit#slide=id.p

KS: slide (overview)

KS: Async generator functions return AsyncGenerator objects, with a for-await loop

KS: Review iterator interface. Async iterators are analogous, but return a promise of the the IteratorResult, and use @@asyncIterator

DH: AsyncIterator extends AsyncIterable, right>?

KS: Yes.

KS: AsyncGenerator is what you expect, with next, throw and return. Why? Integration of existing concepts, rather than creating a new one. Pull-based, no extra backpressure protocol required, easily converted to push-based Observables. A nice feature of this, with streaming applications no backpressure is required. It can easily be converted to a push based source, by taking the async iterable and pushing it.

MM: by convert you mean adapter

KS: yes, exactly

KS: slide (The async iteration statement) – async variant of for of

KS: slide(Bikeshedding: Why for-await?)

DH: pretty strongly agree, the thing that is actually signalling, is that there are additional awaits

MM: additionally, these are interleaving points.

KS: ctrl-f for await, makes it easy to find interleaving points

YK: it is important that we are allowing two more control states to be reified through this mechanism

KS: that isn't a bikeshedding concern, rather a concern about modelling...

YK: No, I am fine with the modeling. I want to be sure break/continue control state to happen.

YK: async modifier takes a construct..

DD: it converts it into an async context, does it make it async itself.

DH: i dont think thats the intention

YK: Introducing more async functions would be good, but here we're talking about not introducing one so await makes sense

KS: we can explore other contexts, async do etc No baring on this.

KS: Slide (Details: Promise Unwrapping)

SP: so yield will unwrap any thenable (not promise)

DH: i am having a danger will robinson moment, composing two concepts, and now we merged them.

async function* agf() {
    yield Promise.resolve(1);

WH: Are you proposing that the above do the same thing as replacing the yield line above by 'yield 1`?

KS: Yes

WH: We've had the discussion before about whether promises stack or they are idempotent. We decided that one after a long debate to prevent promises stacking.

DH: yield and await merging.

YK: yield and await have different precedence is pretty bad

DE: doesn't it already do this, as we recursively unwrap.

KS: But we recursively unwrap the IteratorResult, not the data slot!

DE: Oh! So you want to await that?

KS: Yes, and we await as part of yield.

KS: these are still open question, what if i swap yield Promise.resolve with yield Promise.reject

DT: in midori we had iterator of promise, the producer can run ahead, launching the subsequent async computations.

DD: these are both handled: sync iterator for promise, async iterator for promises

DT: i think it is orthogonal

DD: there is no distinction, we can collapse them down to one level

DH: So because we don't have promise for promise, this structure wont absorb them.

DH: yield / await wanted to absorb

KS: originally i didn't have this flattening, the discussion was that well we have made choices were we dont want to have promises for promises, and that would seem to make it the same as a promise for a promise with an extra done bit

MM: I dont know what side of this I'm on yet, but let me put this into other terms. The things you can have a promise for are non-promises. Promises can only promise non-promises. The design question here, are async generators sources for a sequence of non-promises, or are they are source for a sequence of anything. Consistency cuts both ways, collapsing can be good. On the flip side, when you create a container, a container can contain any value not just non promises. A container can have more things over time. If you see a stream like this as simply a container. Then most containers can contain promises.

DD: you can swap the word "container" for promise, and the argument flips.

DD: complete abstract concepts should synergize

WH: i don't know what that means

DD: Async Iterator should have unique behavior that is the composition.

DD: I think that you are saying, that a type with a certain structure, that semantics are entirely containeed rather the surrounding semantics.

DD: there could be semantics on top of the compositional concepts.

DH: you guys agree 90%, there could be a new type Asynciterableresult, or you are saying promises could absorb this.

YK: or syntax could absorb it, but that is only half the battle

DH: absorption at all?

MM: Back when we were doing promises, one of the questions that came up regard the collapsing or not. Given collapsing, with the cooperation for both sides, can we still somehow express the functionality of a promise for promises? I have needed this. The work around is to wrap the promise in a cell, and the reciever needs to unwrap the cell. By a simple cooperative adaptation, can either functionality be layered on top of the other? I believe the answer is yes. Given that, the remaining design constraints should be "Simple things should be simple, complex things should be possible." (Famous Alan Kay quote).

DH: Are you saying async iterator can be implemented in terms of the other version?

MM: either of the two forms of async iterator we are discussing can be cooperatively represented via the other, so the main criteria should be simple should be simple, complex should be possible. The dominent use-case is delivering non promises.

MF: you are mistaken about several things, the goal isn't to deliver a promise of a promise. The goal is to deliver a promise of anything. We don't care about promise for promise, we care about a promise of anything. People see that as the simpler thing.

MM: you are correct, simple isn't the right word as simple can be used on both sides. A consumer that knows to only deal with non-promises, is the dominant kind of consumer.

MF: people write libraries that need to support this

MM: general polymorphic libraries that want to support any type of input

DE: we already have this precedent in promises, we should have this be an edge case.

DH: i think its really important to understand, some think interms of types and parametricity. The fact of the history of promises, JS types are split tino 2 universes. (promises and non-promises)

ARB: one is included in the other, which is the problem

YK: it is already the case ...

ARB: contents of promises is were the worlds "collide", otherwise unwrapping wouldn't be useful

KS: let me put a bookend on this part, clearly strong feelings on promise unwrapping.

KS: the difference would be, if you didn't do the unwrapping someone would need to do yield + await

MM: a worse issue, consumer side. Does it see iterations. Are we trying to define an abstraction to see an iteration of non-promises, or are we trying to define and abstraction to asynchronously deliver values.

WH: Collapsing is trying to remove the need to say await when calling a function in a yield. But how does this work in a regular async function?


``async function* f() { yield g(); yield h(); yield i(); }```



The latter one doesn't implicitly put awaits in front of the calls to g(),
h(), and i(). Consistency would imply that the former shouldn't either.

*more discussion*

KS: It unwraps it recursively

KS: for-await falls back to Symbol.iterator when Symbol.asyncIterator is

DT, MF: This may be a hazard, or maybe not if you insert the right

KS: slide (Queueing). What do you do when someone calls next repeatedly
without awaiting?

DH: Unbounded queue?

KS: You could return a rejected promise, or put it into a queue and pick
them up as appropriate. I've been going back and forth on the various
options. It's not essential to the design yet--at some point, I switched to
rejecting, but this caused some bugs in my program, but it ended up being

MM: in the queueing case, it still returns the exact same thing

MM: the queueing up seems much friendlier.

SP: yes

MM: one guy calling .next (can take an argument) because the consumer is
assumed to be paused on a yield, allowing it to go to the consumer without
an intermediate buffer. The whole reason for this, is 2 async coupled
entities, allowing one to run ahead sounds very fine.

TD: we started with "it fails" and worked around it, ultimately giving up.
As soon as anything got speculative, it got complicated. Pushing it into
the infrastructure, making it queue, up so that everyone had it.

MM: This can be very useful, not buggy

YK: the fact that is different that is is different from the flip side algo

KS: actually, examples exist.

KS: this is the same

YK: ...

DH:  mapping these to known analogies were i feel more confidence, falling
async is JS approach to threads. The analogy from a sync threading
language, I have a thread that is producing me abunch of values, I block
waiting for the next value, I as the consumer should not be sensitive to if
the other thread is blocked or not. It should be internal to the thread
implementation details, leaking this to the cosumer isn't correct

MM: both sides block, in JS that is a promise.

KS: slide (current status)

- partially implemented in regenerator
- its in there for several months, although for await isn't
- read for review

DH: please assume good faith, this is delicate. I think the space is
important, we need to figure out how these concepts work together, but
there is failure of our champion model, and that is over modularization...

DD: in the last meeting, we requested this specifically for big paper.

DH: No attack here.

DH: i don't see yet, how this fits in, with the other stuff that fits in
with Jafar. We have seen various variations, it is not clear to me... Maybe
the intention here is to drop all that stuff (possibly implied)

YK: is JH giving up on for on

JH:  for on, wasn't in the proposal

DH: we can't do all these things

DH: we need to figure out what our are async data types, and we need to
figure out the grand unified theory. KS has submitted great work, I still
don't see how this all works together.

DD: we said something stronger, we wanted both AsyncIterable and
Observables on stage, so we can properly view this.

DH: if we continue to advance these overlapping ideas, we need to be sure
we don't defer how to ensure the grand unified theory works.

YK: stronger concern, both proposals want to arrive at syntax. We can
likely only get one of the two syntaxes.

YK: we can get for on, or for await, not both.

DH: it seems far less for us to imagine the coexistance of both data-types
in the languages, but with the new syntactic constructs present much overlap

KS: My opinion is this is await for in is the only syntax, and observables
could use it. As I discussed above. In that direction, it should be
complete fluid. The other direction, the subject of the await for is more
complicated due to buffer differences. In my vision, observables would have
a method that would allow observables to choose buffering strats, that
returned an async iterable. Making it compatible with for await.

JH: KS and I are in alignment, for await is what i want. We can adapt an
observable to an iterator via a buffering strategy. Other types can achieve

YK: an alternative design would be async iterable result, and we should

DE: these things seem like refinement process tasks. They can be explored
at stage 2

AWB: this feels like stage 1

DD: does anyone have fundamental disagreement?

YK: someone needs to respond to my exploration request. I am pretty
uncomfortable combining the two types.

.... discussion ....

DH: let me add structure

DH: their are several work areas, that have been structured as independent.
JH has been a champ in 1 direction, and KS in another. Several areas of
    - work on observables + syntax
    - work on API for async sequences + syntax
    - it sounds like KS + JH are in aligment, observables aren't the base
for syntax. And it is orthogonal

- observables championed by JH
- we want some syntax (which obviously needs a protocol)
- API for async sequences, but without full consensus. But we need to
continue exploring.

YK: I totally agree, I am concerned that I must present an adequate
argument but do not feel able to at this time.

DE: we should explore this explicitly

DH: we should explore for await, and async sequences. We need to shake more

DH: its obvious to me that those could be stage 0

DD: my opinion is this proposal is ready for stage 2, if we can agree that
the changes can be resolved during stage 2.

YK: it depends how fundamental the type composition is to the proposal

KS: I think that we ought to use promises for something that will be
delivered async. As it works with the rest of the

YK: it can be skinned many ways, additional protocols can be created.

MM: await does a Promise.resolve, maps a value to a promise, and I don't
want to reopen this.

MM: if an AsyncIterationResult is something that is not a promise

YK: is it important that it is a nominal instance of the promise

MM: yes i believe so

YK: i am surprised

MM: if it is a thenable that it will be adapted by Promise.resolve. I am
not ok with reopening await being Promise.resolve(x).then(continuation); I
am not willing to change what that means

DE: can we decide stage 1 or stage 2, we have more to cover.

AWB: we cannot make it stage 2,

DE: we can say its stage 1 pending further review.

MM: (Somewhere in here I made the following unrecorded observation)

There is a third alternative. The async generator can be a generator of
anything. "yield" does not imply an implicit await, so no collapsing
happens on the generation side. The async iterator that is produced is an
iterator of anything. No implicit collapsing within the async iterator
itself. Its API remains fully parametric. Rather, the for-await construct
does the collapsing, in service of the simple-dominant-use-case consumer,
who wants to see an asynchronous sequence of non-promises. Each iteration
of the for-await loop does a double await -- one to get the
IterationResult, and one to get the promised value.

Any consumer who, instead, wishes to see an asynchronous sequence of
anything, can instead write their own loop rather than using the convenient
for-await sugar.

Big advantages of not collapsing at the generation side:
    * yielding an unresolved promise does not prevent the generator from
proceeding to generate. It is not surprising stalled at the yield point.
    * yielding a rejected promise does not cause a generation-side
exception. Rather it simply transmits the rejected promise. A simple
for-await consumer is stopped by the rejection throwing the reason.
    * (Pointed out by Dean): An implicit "await" at the "yield" violates
the rule that we can find all interleaving points by looking for "await".

### Conclusion/resolution

- Stage 1
- needs more exploration as per above discussion.

### Strong Mode Discussion

Presenter: Andreas Rossberg

ARB: slide (recap)

ARB: slide (progress)

ARB: slide (strong mode)

ARB: slide (what worked well)

ARB: Disallowed implicit conversions.

WH: Even toBoolean???

ARB: toBoolean is the only one that remains

ARB: string conversion is used alot, but it wasn't a problem. In es6 we
have template strings, which becomes explicit.

AWB: what about toSelector, number -> string for property

ARB: ya, it comes down to some things. This one is still allowed.

ARB: slide (what not worked well) Mutually recursive classes,

MM: what was the motivation for unbound variable ban

ARB: to make errors static and avoid runtime checks

ARB: interopt made locking down classes via seal

... discussion above strong vs non-string inheritance mixtures ...

ARB: slide (takeaway)

ARB: slide (soundscript)

### Teset262
presenter: Dan

DE: reptitive tests, lots of tests that repeat each other. Their exists a
proposal to generate tests precedurally, we require implementors feedback.
Ask me and I will provide more information

### Conclusion / resolution

- implementors need to provide feedback


#### Conclusion/resolution

# Test262 Updates
Presenter: DE

DE: We have some changes coming into test262, e.g.,
https://github.com/tc39/test262/issues/467. Users, please give feedback as
to whether these are appropriate for you! Please reach out to me if you
have any concerns.

#### Conclusion/resolution

# Progress review: Callable class constructors (Allen)
presenters: AWB / YK

AWB: slide (callable Class Constructors)

AWB: slide (refresher)

AWB: slide (refresher pt.2)

AWB: slide (refresher pt.3)

AWB: slide (refresher pt.4)

AWB: slide (interesting feedback via twitter and other channels after
publicizing proposal)

YK: some feel the new fork is non compositional

AWB: slide (more feedback)

AWB: inheriting is complicated

MM: it is possible, make the default call behavior on a derived class to do
a super *call* to its superclass constructor.

YK: ya

YK: another way to say, is that we install a constructor

MM: not suggesting it is a good idea

YK: not including it, caused confusing.

YK: baseclass providing default functionality was a big concern

AWB: we will remove the rocket

AWB: we do want to enable the calling constructor

YK: almost all people people want call to delegate to new

AWB: ya, 99.9% case. Two bodies is confusing, it clearly seperates it for
the 0.1% case, like date function.

YK: it is a middle ground

AWB: todays proposal (slide An alternative approach)

class RegExp {
   factory constructor(pattern, flags) {


MM: what about inheritance?

SP: it could now just be made to work, because its a unique function body

MM: does the factory bit inherit

AWB: i would say no, but it could.

MM: if the subclass does not say factory?

AWB: it reverts back to the default behavior to throw

WH: Almost the same as the original proposal. Can you use this to implement the Date use case as on the first slide?

AWB: yes, if you want to implement date (slide -> Use single body and

new.target for date-like case)

DD: something seems bad

YK: i would expect, it installs new

AWB: we don't quite support the date case, but the 99.9% has been sorted

AWB: I will think some more about this.

YK: ES5 can still be used for the edge-cases

..: it will be hard to implement

AWB: slide (an alternative approach)

class RegExp {
   factory constructor(pattern, flags) {


MM the only thing that gives me pause here, if long term we will only address this with a specified mechanism. Date case goign back to es5, then we are not gaining any value from having the default constructor throwing.

YK: incorrect.... i would make a looser term.

YK: lets go back to es5, a massive hazard to forget use. This made many people not want the newless behavior.

MM: I'm not buying this

YK: the world you want to live in, they can choose new or old style, If you happen to not like new, you call without. That world only works if all the classes are es6 classes, if you encounter an es5 class you will likely encounter a hazard.

MM: what I'm saying, we don't require new, the default call constructor is to new

YK: i almost proposaed this...

...: from an implemenators perspective, we only included the new.target in frames if we new we needed this. It is a huge pain in the neck to implement this default forwarding

BE: some wont use classes anyways, we shouldn't cater to them

MM: we should not help them

DD: their is an implementors concern.

AWB: the factory world is almost noise

... discussion ...

WH: This is unnecessary. It's creating a redundant way to create instance, for those who don't like new. Given the implementation concerns, we should not be doing this at all.

... (the implementors) it wlil be crappy

MM: could we make something shorter than "factory constructor"

AWB: maybe, but it is a factory call

MM what about

class RegExp {
   () {
      // ..

DT: seems like syntax and implementation default are two seperate issues

WH: Again, we shouldn't be doing this at all. Drop it instead of
bikeshedding syntax.

MM: I withdraw my proposal due to the implementation concerns

YK: i am on the side, that not using new is a minority opinioin. We should
still not lock it out

DD: we should likelynot provide constructs that will allow those to shoot
themselves in the foot, they can just use =>...

YK: decorators could enable this ergonomically

MM: we should drop this completely, and solve it with decorators.

#### Conclusion/resolution

Proposal dropped.

# Object.getOwnPropertyDescriptors to stage 3? (Jordan Harband, low
priority, but super quick!)
presenter JDH:

JDH: reviewers and editors +1'd, can we move to stage 3

all: yes

## Conclusion/resolution
- advance stage 3