shu: I just went through the transcript, I wasn't online anymore then, but putting aside the debate over due diligence and tradeoff judgements, I actually do not understand in which scenario a let declaration (without initialization) that occurs as the first statement of a scope can ever execute after any other code declared in that scope.

like, are you talking about the case where there are also no escaped, hoisted function declarations?

an interesting annex b change in jsc: https://bugs.webkit.org/show_bug.cgi?id=163209

I reached out to Brian to see if he knows what's going on with TCQ, he said he'll see if he can find out what's wrong.

TCQ comes back for one full second and we assume it's all roses?

If the concern is the inability to use native Base64 support in a memory constrained environment, I'm not 100% sure the solution is to spend more of that memory on a 3rd-party library or wrapper to do that for you.

I would assume the web would provide a web stream

littledan: I think it's vaguely possible we could get web streams in TC39 someday, but I don't think we should block the one-shot version of this proposal on that

Do we want to design a general-purpose sync streaming API in 262?

Brian said TCQ will be back up again soon, but folks will have to log in again since he needs to clear out the sessions as part of trying to resolve the issue.

this is an abuse of our process

It seems like the concern is that they could implement it but it wouldn't be usable in that environment due to the single-shot nature.

I am concerned that splitting the proposal is an opportunity for detractors to block the streaming portion indefinitely.

But does having the streaming api in tc39 make the single shot one more usable?

for example, that mindset would have blocked decorators until they worked on all functions. but that's not how we prefer to operate.

As opposed to having it in WHATWG? Having it in WHATWG doesn't help embedded at all.

let's give this at least another two months to try to resolve this rather than immediately do a venue switch

but it seems like a lose-lose for them

This is exactly what happened with cancellation

It's also a lose for web platform. I am relatively sure an in engine implementation will be significantly cheaper than a web platform implementation (because strings don't need to be exported from the engine and can instead be walked directly in engine)

eh that can be worked around. streams are implemented directly in SpiderMonkey. the fact that engine codebase lines follow standards org chart is mostly accidental, and can be worked around easily enough

let's give this at least another two months to try to resolve this rather than immediately do a venue switch

promise cancellation shipped in fetch during one of those 2 month gaps, without notice to tc39, and now we might never be able to have cancellation in the language as a result.

let's give this at least another two months to try to resolve this rather than immediately do a venue switch

eh that can be worked around. streams are implemented directly in SpiderMonkey. the fact that engine codebase lines follow standards org chart is mostly accidental, and can be worked around easily enough

Node Buffer has base64 functions. A WHATWG proposal would just be a modernized version of atob/btoa. Then base64 can be done in both browser and non-browser environments, just with different APIs. So that's the outcome we're heading toward.

I mean I could come back and force a vote, I guess. But I would prefer not to do that. The web streams version is independently useful anyway and it just seems more worth spending tie there.

Yes. With cancellation, Domenic withdrew it because he didn't like how I was advocating for it to be just library-based, without syntax extensions. In the end, it shipped in the web without those syntax extensions. So this is a good example of how doing a venue change also doesn't help get everything that you want.

yes, that wouldn't be the end of the world for this proposal, but I really want us to figure out how to get through these situations in general. That's why I'd want to bring this back in 2 months.

sorry, i meant, other people than peter disagree on what is already our process

I think a process change should center more around the nature of objections rather than just allowing a majority vote to push things through. That sounds like dangerous precedent.

Is TCQ down again? I logged out of GitHub and back in again, but I still get a blank page for TCQ

I think a process change should center more around the nature of objections rather than just allowing a majority vote to push things through. That sounds like dangerous precedent.

Some programmers I know are looking for a JSON parse streaming API

if we did a vote, IMO it should be a large supermajority and only be deployed in cases where we really don't feel like the objection makes sense

TC39 does NOT have a consensus process. It has a single blocker process. Many of us have been on both sides of the blocking process. In this case, one member asked for an accommodation, add a streaming API and I'll support. The committee, as a whole, wasn't willing to accept the addition. The member blocked.

Consensus is consensus, if you want to add some kind of "mechanism to overcome minorities" it is not consensus anymore. I do not think, that idea of consensus is wrong. People have to compromise, to make consensus work. The question is, if we have explored all compromise options. I have the feeling, from Kevin's side, we did and I have the same feeling, that we did not explore all compromises on peter's side.

Newline Terminated JSON? How would you stream the out the result of regular JSON streaming?

Consensus is consensus, if you want to add some kind of "mechanism to overcome minorities" it is not consensus anymore. I do not think, that idea of consensus is wrong. People have to compromise, to make consensus work. The question is, if we have explored all compromise options. I have the feeling, from Kevin's side, we did and I have the same feeling, that we did not explore all compromises on peter's side.

Consensus is consensus, if you want to add some kind of "mechanism to overcome minorities" it is not consensus anymore. I do not think, that idea of consensus is wrong. People have to compromise, to make consensus work. The question is, if we have explored all compromise options. I have the feeling, from Kevin's side, we did and I have the same feeling, that we did not explore all compromises on peter's side.

Newline Terminated JSON? How would you stream the out the result of regular JSON streaming?

The usefulness of streaming is that you can get partial responses out, I don't see how this can work with JSON objects becasue you have to wait for a closing }

Can you elaborate on what you think hasn't been explored?

But what are you getting out of the stream?

As many others, I do not get it, why "the single shot one" has to be "objected" to, if there is not a "streaming one". Advancing the singleShot one would not prevent another new take at the streaming one in the future. Why is this compromise not being explored, or at least given some thought to reconcile on this in some weeks...

As many others, I do not get it, why "the single shot one" has to be "objected" to, if there is not a "streaming one". Advancing the singleShot one would not prevent another new take at the streaming one in the future. Why is this compromise not being explored, or at least given some thought to reconcile on this in some weeks...

it can optimistically parse it. for { a: [1, 2] } it can be a stream of event: enter "a"; start array; enter 0, value 1; enter 1, value 2; end array; end "a";

Could you give an example of a hypothetical compromise? I think this is what bakkot has been working on for 2 years...

I have my own json streaming parser because some JSON files are too big to be stored in a string in V8

is it on github?

I have my own json streaming parser because some JSON files are too big to be stored in a string in V8

interesting that the object then does fit in memory

breaking news: https://github.com/tc39/proposal-arraybuffer-base64/issues/13#issuecomment-1738345569

I understand your position to be that the one-shot APIs are sufficient because they can be used to implement streaming with reasonable efficiency and without significant future compatibility concerns. If that is indeed the case, I will withdraw my objection.

Christian Ulbrich: I am having trouble understanding what you meant by "Why is this compromise not being explored, or at least given some thought to reconcile on this in some weeks..." -- do you see a potential compromise besides the two options (including or excluding a streaming API) that either side could take?

You need the magic Node.js flag to increase memory limit :P

I have a wrapper for node, that sets --max-old-space-size=16384 all the time, to consume my GB-JSON's! :)

you can set that in NODE_OPTIONS and not need a wrapper ftr

There are people who don't use kelvin for temperature?

https://gist.github.com/nicolo-ribaudo/c5b09c43a10a99fd92c90e81e60732ec

Of course I don't, I use the reasonable Degrees Temp system xanthir.com/b58m0

climate change means that 100F is no longer a reasonable upper limit for day-to-day temps tho :-/

does someone have a link to these slides?

i missed the rationale for why this is worth doing in TC39

would love to know how mu ended up being the key (evidently "measurement unit" but that doesn't suggest temperature at all...)

there's some hard limit on 8?

would love to know how mu ended up being the key (evidently "measurement unit" but that doesn't suggest temperature at all...)

yes: https://unicode.org/reports/tr35/#Unicode_locale_identifier

did the negated in/instanceof operators get stage 1

i might be blind but i don't see a link to that in the reflector issue

yeah everyone had to say "i support this" in the spreadsheet

i've been asked to prove the utility of Symbol.isRegisteredSymbol, for example :-p

okay i will fight some of you at lunch then

we had to do that for RegExp.escape too tho, and that research was a lot of extra work that kevin did

Except for the override mistake. Throwing there hasn't made it easier to change to a behavior that does not throw

like if we have stdlibFunction(v: bool), it should accept objects?

Possibly, yes.

in what context do they do that?

i'm not sure why true would be a reasonable stand-in for an object literal, unless it's an explicit part of the api

i'm not sure why true would be a reasonable stand-in for an object literal, unless it's an explicit part of the api

i'd expect config to be strictly validated ¯\_(ツ)_/¯

can't believe that's not how all people work

am I the only one who interpolates only strings?

am I the only one who interpolates only strings?

what about decimals? I wouldn't trust the generation of a digit string

huh? why not?

I would be interested in learning more about how sffc's libraries take advantage of the power of coercion.

sffc: https://googleprojectzero.blogspot.com/2015/08/attacking-ecmascript-engines-with.html

definitionally, all bugs due to conversion operators are engine bugs

sffc: why do you find the engine bugs to be unconvincing?

It's also the case that linting tools have become much, much more sophisticated in the last 10 years since the cited CVEs were filed. Both ASAN for C++ code and policies to use more Rust in new components.

because it still suggests you can use it

because it still suggests you can use it

I am still confused about how "pre-3" suggests you can use it

i am claiming that people will gloss over the "pre" and see "3" and think "stage 3". because people's reading comprehension is … inconsistent

we can just ask the core-JS guy to not ship stuff

2 + (1-epsilon)

2 + (1-epsilon)

so if concerns about whether that one specific person will ship a thing is the only blocker, I think that is the least of the concerns

I'm disturbed by the claims of the community being unteachable

it's not just that. that's just one example.

I'm disturbed by the claims of the community being unteachable

I'd agree with waiting a meeting at least. If I'd realized that tests were going to be a requirement for something like throw to remain at Stage 3 if it reached it this meeting, I would have written the tests prior to the meeting.

sffc: thoughts on my wording here?

Some APIs intentionally round non-integral inputs, for example as an attempt to provide a best-effort behavior, rather than because the API fundamentally only makes sense with integers. This guideline does not apply to those cases.

does anybody have a clear memory of why the names were removed from the process doc though?

Can you tag me on the issue and I'll take a closer look soon but not right now?

does anybody have a clear memory of why the names were removed from the process doc though?

i have no memory of us removing them

bakkot: Really? To me, do { throw x } feels pretty ergonomic.

In particular when considering cases where something more needs to be done that just throw x, do expressions feel like a pretty good potential solution.

would that have the right stack frames and call site?

no, it's because the import site needs to know where it's being imported from. you can do static analysis with globals just fine.

ljharb: Object.getOwnPropertyDescriptor(Error.prototype, 'throw').get.call(anything)

then you can't throw a non-error that way, it'd have to be static

I may have missed it. Did anyone suggest that throw should have approximately the same precedence as yield? You would just define the rule so that its production is
ThrowExpression ::= throw ShortCircuitExpression

throw with the precedence of yield would require parenthesis in pretty much all cases where it would be used.

then you can't throw a non-error that way, it'd have to be static

the same's true for throw expressions themselves, you can already (function () { throw e }()) :-p

I would place my preference for not requiring parens around throw expressions at at least the same level that @bakkot has placed his concern about reader confusion compared to ThrowStatement.

that just can't throw a

rbuckton: add me as reviewer for throw expressions, I have some ideas on the specifics for how we accomplish alternative 2

I'd appreciate it, though I believe alternative 2 is the (almost) worst case.

it would have moved to the tc39 team area

I guess I'll have to leave myself a reminder to check back on the incubator-agendas repo next week, once folks have had a chance to add issues representing their calls?

sounds like the best tractable case though