also an earlier slide implied that PDF quality impacts downloads, and that 402's PDF is better, but 402's PDF downloads is a tiny fraction of 262's PDF.

i'm confused, why were we talking about normative changes in this section

we don't do that in 262 updates, and i definitely want more explanation than "go look at the PR"

that way we can be sure we actually agree on it

we can do that, but it could get somewhat time consuming

last meeting I wrote many of the summaries. I want to get out of that pattern.

yeah that was good. There was nothing to write in the summary; we just had a conclusion.

summary: proposal meets all stage 4 criteria

rbuckton: now that it's stage 2, it's the perfect time to suggest alternative names

The property names more and extra are a bit opaque, but I imagine anyone using the streaming API is going to likely need to refer to documentation anyways

TextDecoder has stream which must be false for the last call, which confuses people a great deal, and I was trying to pick a name which avoids that problem (hence more)

[ugh matrix does not have strikethrough]

a similar API would be sufficient, but much heavier - I'd really prefer to avoid adding an entirely new class to the language for this

the buffers aren't growable so you can't copy from one into the other

asking to copy into a new array seems like a big ask

by "a big ask" I mean "that does not seem like it is a more ergonomic API than the current proposal"

If implementations object on the grounds of creating new objects I'd hear them out, but I'd want to hear that from them - generally speaking we create new objects all of the place and don't worry too much about it

and if your concern with the design in the proposal is memory, having something which requires manual management and copying with an additional working buffer seems like it is worse for memory concerns

Perhaps this might be a question for implementers, since this seems exactly like how the current spec text might be implemented at runtime.

I have a question about "attach context" and "link", these two phase seems do not need to be in specific order? I mean currently is is designed to first attach context then link, but could first link then attach context also work?

This design is halfway between efficient and ergonomic. One that works on offsets would be far more efficient, but far less ergonomic. One that utilized a class to encapsulate scope could be both extremely efficient and far more ergonomic, so I'm not very convinced of the argument that the UX benefit of the proposed design is worth the efficiency loss.

Can you show an example API? I weakly preferred a stateful class instead of the objects myself in #13

wait what is "attach context" again?

So can i also structureclone module declaration?

It seems like it would have to be a host hook requirement that there's no module source for JS imports, right?

It seems like it would have to be a host hook requirement that there's no module source for JS imports, right?

Concretely the throwing behavior is inherited from Cyclic Module Records

(maybe it would make sense to move it to Source Text Module Record, since Wasm modules also are cyclic module records in the Wasm-ESM integration)

i am not understanding the alternative ron is proposing

My reasoning is that phase is conceptually similar to an evaluator, meaning it changes the source text of the thing it imports (and this is how it's going to be implemented in bundlers)

The intersection semantics with importHook would be quite bad in that case. The importHook is responsible for returning a Module irrespective of the phase, and the importHook will need to see the whole options bag, and the importHook is memoized according to the specifier + all attributes. You will get duplicate instances if you import with multiple phases.

I have a weak preference against import <keyword> for the static syntax.
I have a stronger preference for import.<phase>() for the dynamic syntax as the import(url, { phase }) syntax either introduces unnecessary asynchrony for asset references, or it introduces a non-promise return value from import (for asset references). The import(url, { phase }) syntax also introduces complexity for future proposals that may need to somehow navigate phase and with attributes on the object.

The only way this could work is to "hide" the phase attribute and not pass it to the importHook even if it's specified

if everything was S-expressions, I guess it would be less brittle, but also it would look like (()()()))()()()()(())())()()())))()()((()((())

I can understand this argument, but also it seems really specific to asset references, which we really haven't worked out yet.

Its somewhat odd that we can import asset ... to resolve a url, and import source ... to fetch AND compile, but no way to just fetch via syntax.

The importHook's memo can handle that case pretty easily?

module from {}
import source from from
"url"

it sounds like you're arguing against import attributes then?

is this case cause syntax ambiguity ?

No, import attributes are a bit more esoteric. This is far more obviously an operation

oh, I see, we're back on import.stage() and not talking about the put-it-all-in-attributes side (which would be fine with phase:)

Yes this is probably what WH was worried about. It can be specced as unambiguous (and in parser it's a two tokens lookahead, or just "eat three identifiers and then decide if they are bindings or syntax").
It would still "read" as ambiguous, but how often would you import a source binding from a module declaration named from? (how many files do currently exist have called from.js that export a source variable?)

Yes. I also brought up the cache-key concern internally, though the same argument was made that "such attributes don't need to be made part of the cache key"

people don't mean literally import.phase, right? you mean import.source()?

why do SES folks have the time to burden every proposal with this requirement but they don't have the time to work on the getIntrinsics proposal or whatever it is?

I'm sorry, I missed part of the conversation because my power cut out, but I do not want to do conditional advancement

I also don't support "conditional" stage N, where N is ≥ 2. We have time during this meeting for the champions to come back with the dynamic import.phase() change discussed.

i've been thinking of conditional stage 3 as like, look, here're a few small things that a small set of stakeholders care about for small N, settle that async, i'll reload the issue in a month when i or someone on the team implement the feature

I do wish we made more use of "consensus for this thing not being open for further discussion" outside of specific stage questions

guybedford, Luca Casonato: apologies this concern didn't come up earlier in stage 2. My preference for import.<phase>() is stronger than the "no preference" described by the champions, but not a deal breaker. If no one else strongly prefers that syntax, I certainly won't block advancement.

no worries - i think your strong preference outweighs the "no to very light preference" from others here, so we can make the change for next meeting

If allow, i guess parser need to read many token in the case like:
module source {}
import source
x
from
"url"

HE Shi-Jun I'm curious, do you get these cases by experience working on a JS parser? I would love to borrow some tests for Babel 👀

or actually even easier, just ban import <phase>;

If allow, i guess parser need to read many token in the case like:
module source {}
import source
x
from
"url"