Bradley Farias

@domenic from a lot of what I have heard/talked to people Loader would be instrumented as part of the es6 loading mechanism; which is where these concerns come from, having...

as per the conditional loader, it is more limited since the resolution is part of the loader, you cannot have easy user logic like `if (!Promise) require("bluebird")` to my knowledge

@matthewp for places that support await , which is not available at top level or module level of the https://github.com/tc39/ecmascript-asyncawait proposal

@matthewp https://tc39.github.io/ecmascript-asyncawait/#modified-productions as per the lack of it at a module level We would love to have it work with existing code! Which is why we are here, to discuss...

@matthewp Still would not fix circular dependencies or the timing concern of task queue vs immediate side effects as I read it. Maybe you can elaborate?

@matthewp currently there are multiple stages of promises during the evaluation phase that would have to be placed on the task queue if we use a fulfillment handler : -...

Other thread that you have been replying to contains the comments and relevant links: - https://github.com/WebAssembly/design/issues/256#issuecomment-120481934 - https://github.com/WebAssembly/design/issues/256#issuecomment-120558466 On Fri, Jul 10, 2015 at 6:45 PM, Caridy Patiño [email protected] wrote:...

There is miscommunication going on about all of this; I will be on a Google Hangout on Air today from 1PM CDT 14 Jul 2015 to discuss with anyone who...

Is there any reason we cannot use a prefixing solution rather than IIFE for this? For node this would be something like replacing Module.wrap to generate this instead: ``` es6...

@caridy are those public somewhere? I don't see it referenced in the repo