await.all [a, b, c] just doesn't seem that different from await Promise.all([a, b, c]) to me

yulia: i totally agree this doesn't fix the education problem. to me it's fixing an ergonomics problem.

ljharb I definitely see people do await a; await b; await c over await Promise.all but I have generally assumed it was because of thinking serially rather than because of wanting to avoid Promise?

ljharb I definitely see people do await a; await b; await c over await Promise.all but I have generally assumed it was because of thinking serially rather than because of wanting to avoid Promise?

if the main problem is await all, should we only add await.all without await.race and others? Or even just introduce a special syntax (eg. await* promises)?

speaking of research -- anyone wanna take over running that call?

Sad to see you cannot attend

they're just not at a place to reason about things in parallel

"do nothing" is always an option.

should we only add a subset of + - * /, because some of them get more usage than the others?

OOT: imo some operators (| & %) do not deserve a single character operator because they're not used so often (than || &&)

OOT: imo some operators (| & %) do not deserve a single character operator because they're not used so often (than || &&)

wanna take over?

Jack Works: have you tried to use editor abbreviations?

i know how to confirm my priors and ignore counter evidence

One of the main pain point is when I'm using for...of loop and I want to use await in the loop body

Proxy does not have a prototype to store @@disposable

yeah, cross realm seems a requirement of this proposal?

And I meant that its not the proxy that is disposable, but the { proxy, revoke } object

Vue is proxying objects to implement immutability?

const disposable = new DisposableStack()
function createProxy() {
    const {proxy, revoke} = Proxy.revocable(...)
    disposable.defer(revoke)
    return proxy
    // at this point, revoke only hold by the DisposableStack.
    // engine can GC `revoke` and knowing the Proxy is being revoked after the DisposableStack disposes
}

Jack Works: according to the definition of liveness, clearing out the proxy target is not necessary, as the target's identity would be unobservable to the program through the proxy already

so do we have a non-theoretical go-to use case of revocation then?

the [[ProxyHandler]] might get access to [[ProxyTarget]] when the internal slot is called right

I missed a key point in my presentation: when we revoke a proxy, the underlying slots are nullified, but the proxy itself remains part of the object graph it lives in. You can't do anything with the proxy, but it's still there because (probably) something else refers to it. The revocation of an object graph, and of proxies pointing to it, means the original objects in that object graph can be gc'd. The proxies themselves are still reachable

also I really like https://github.com/whatwg/html/issues/8557#issuecomment-1331448189

wait i don't understand why "async" isn't a clear indication of an interleaving point?

people are smart and adaptable

right and I'm disagreeing with erights

I don't understand that position either. await in a conditional doesn't "release zalgo", so such a constraint seems confusing.

well my response to that is, sorry you don't get to ship an implicit linter in the language

Mathieu Hofman I think that most people have not found await in conditional statements to actually be a problem. so I think if you are reasoning about your code in a way where it is a problem, the appropriate way for you to enforce that is by writing your own linting rules, which forbid both await in conditional statements and using async in blocks, and let the rest of us have both of those things

Mathieu Hofman: I accept that you have, but stand by my statement, and my position that the appropriate resolution for you is to have lint rules which enforce the stronger invariants that you apparently need; most people, in my experience, do not need them, so we should not bake them into the language.

?? would like to disagree with you. I was not in favor of requiring parens to disambiguate with || and && given clear precedence rules, but here we are.

Motivations aside, there is so much shared between them its difficult to talk about them independently.

I think it is reasonable to talk about expressions without declarations, but not the other way around.

Are nested modules scoped to within the parent module?

Are modules independently cachable in browsers? If Site A serves lodash, can Site B use that?

besides, practically speaking, due to the widespread use of bundlers it's not very likely

so bundled modules could be cached

if we allowed over the wire or on disk serialization of module expressions we'd need a formal binary AST

Right, but with module declarations you can now cache module based on some other identifier than URL

Why is it any different than caching the react source from a CDN, if you cache the react source from a bundled site?

aren't module declarations top level only?

And what about:

const x = module { }
const y = module { import x; }

There is so much inconsistency with the "two worlds" approach that breaks the decl/expr equivalence of function and class

I think it may be a reasonable to investigate using a seperate identifier namespace to clarify the difference between "regular values" and "module values". For example module $foo {}; import $foo;

Curious about static importability and portability of import module foo from ... and module bar { import foo; }. Is that valid?

we can think of, some values are just available eariler, before the execute

// foo.js
export module A { }

// bar.js
export function maybeDoAThing() {
  const A = await import("./foo.js").A;
  const B = module { import A };
  new Worker(B).postMessage(...);
}

it's difficult to explain why this is the case:

const a = module {};
module b {};
import a; // link error
import b; // fine

so maybe we can also accept const ident = module {}. no more complex

I think if we have two things called module where there is a declaration and an expression version, then what they contain and how they handle scoping should be consistent.

// foo.js
export module A { }

// bar.js
export function maybeDoAThing() {
  const A = await import("./foo.js").A;
  const B = module { import A };
  new Worker(B).postMessage(...);
}

Well, your examples are about scoping of module declarations and const declarations

Some thought:

Link of module B in your example can be deferred to when maybeDoAThing is called. When the expression is evaluated, it checks if A is a Module and if it is a constant binding, if not, it failed to evaluate.

a and b aren't capturable in that example though, right?

Accessing a serializable or replaceable binding in a module would be fine, but other bindings would not. There's a circularity issue there though:

const a = module { export function f() { return import(b); } };
const b = module { export function g() { return import(a); } };

This seems like a perfectly reasonable case, but you can't eagerly serialize b because it's not defined. You'd have to defer such serialization until it is needed, so you would again have to capture all bindings.

oh, because they would be valid if it was written as

module a { export function f() { return import(b); } };
module b { export function g() { return import(a); } };

If it isn't then we don't have the same kind of decl/expr parity that function and class have.

Functions already don't have parity - they have different scoping rules. Only classes can be transparently replaced with let className = class { ...

If you have this code:

module a { let b = getAModule(); await import(b); };
module b { await import(a); };

the dynamic import(b) imports the result of getAModule and not the outer declaration. That looks expected.

In this case:

module a { globalThis.b = getAModule(); await import(b); };
module b { await import(a); };

I see that it would be confusing, since globalThis.b = might be lexically somewhere else and not discoverable.

How would you feel if bindings of module declarations where not captured, but only statically importable?

module a {}
module b { import a; } // ok

module a {}
module b { console.log(a); } // ReferenceError: as every other type of bindings, you cannot capture bindings from the outer scope. You can only use them in import specifiers, which is not a generic "binding usage" position

Note: the current spec text throws the ReferenceError in this case, but just because it was easier to specify. We didn't have a reason to do one thing or the other, but this possible confusion seems to indicate what we should keep the error.

I mean it's non-standard, there could be non-standard "amIRunningInAShadowReam" function

we could just advance the error stacks proposal...

Could a chair help me by finishing the transfer of https://github.com/tc39-transfer/proposal-async-explicit-resource-management to the tc39 org to help with the async resource management split?

I think if we had module declarations, I would prefer the "do not implicitly capture" behavior, but it feels like that defeats a lot of what would make them "special". I'm not sure if that's the right answer, but I found the current behavior confusing because my mental model was "modules capture nothing"

i would think dev expectations of module fragments/blocks is that they either capture everything, like a function, or nothing at all (in which case the way to "pass in" something would be like in php's using declaration on closures)