... we have delegates.txt for that msaboff

ah, perhaps it just needed to be made clear that we no longer need it

msaboff should be good to go now

Would really appreciate having Locale Extensions get onto the agenda in order to surface stakeholders and get a temperature check on the current direction. ( Rob Palmer ryzokuken Chris de Almeida )

Is this on the agenda? If not, please PR it.

someday I hope 262 achieves that level of stability

JS is much more like a shark than JSON

Safari took ~5 seconds for me and this is a 2019 Intel MBP.

true, maybe just a link to the list for easy tab-opening would be better then

that's an engine specific thing right? just like v8 bug is v8 only

syg: msaboff To be clear, I'm not saying everything needs to be discussed in TC39 plenary, just that Spectre represented an interesting case to review, as it was a vulnerability at the design level rather than in a particular implementation.

It just seems a little weird to me that an open standards body would discuss vulnerabilities. The CVE and other similar processes provide a means for those with issues to address them before bad actors are generally aware of the vulnerability.

i am very uncomfortable if the mismatch is in fact with unsaid properties that could be depended upon but we have not otherwise explicitly committed to keeping

... isn't it normative already?

everything inside notes is non-normative; everything outside notes is normative

'axc'.replace(/x/, '$01') === 'a$01c'

in that case we could move the text out of the notes

if we have time which we cannot otherwise use, I am happy to take any >10m slot to get through as much of "stop coercing things" as possible

if we have time which we cannot otherwise use, I am happy to take any >10m slot to get through as much of "stop coercing things" as possible

Does anyone know how long implementations had this replace behavior?

This is the relevant v8 code I believe https://github.com/v8/v8/blob/main/src/runtime/runtime-regexp.cc#L208-L251

The second digit thing in there appears to be from when replace was first implemented in C++ in 2009: https://github.com/v8/v8/commit/e2af4529c3a5a31eaf21240ffc6fce42f0af2d3b#diff-df9cd537d3ef3350ae6d69fd7067704522b83ff80efdcfd53d2e30870ab977d2R1457-R1465

though IIRC someone wanted to be there for that, which makes it harder to do impromptu

for TG2 proposals, we do this kind of tracking centrally (in a wiki in this case). Would it be useful to do this as part of tc39/proposals or something like that?

Yeah SES does also freezing...

hmm, they didn't make a working tamper-resistant mode?

they freeze in the correct way. ses grabs the Iterator from [].values() not global name

I assume upgrading regenerator-runtime also "fixes" it?

Good to know, there is a correct way. I did not mean it as criticism, but as a response to nicolo-ribaudo asking, whether some other members are using this strategy...

[[Shadowable]]: true or something to that effect

then the question becomes how you add it. if you change how O.freeze works, you're basically fix the whole override mistake

Yes, it would be something you would have to opt-in to, and something like Iterator.prototype.constructor would opt-in by default.

lets take precedence from import and require parens

in other words, how could I write a function, that throws if multiple arguments are not given by using throw as a default value? Thx. ljharb ...

ljharb: But, would function(a, (b = throw c), (c = throw d)) also work?

Okay, that would be fine with me, I would not want to explain to devs, that the syntax depends on the position of something...

it's possible in destructing to mean required. let [x, y = throw new Error(), z] = ...

no, just the necessity of the syntax. i'm sure there'd be a linter that either forbids or requires the parens in the terminal case

I agree it's not a big deal, just ask whether we can loose the restriction...

yeah true, that's not the comma operator so maybe that one would be fine?

yeah thats what I ask

Could it work to follow the pattern of import for throw. Treat it like a function call - require parentheses like throw(thingTothrow) - does that help anything?

oof, import() is like a function call, and throwing isn't, that doesn't seem like an ideal workaround to me

what happened to nicolo's queue item?

sigh, comma operator's so gross

which direction is "high" precedence will never not be confusing

UnaryExpression :
  throw Expression

Can somebody remind me why this is not doable?

I believe it's doable, just introduce some inconsistence and refactor harzard when switch from throw exp/statement

I am not sure that function f(x = throw a, y){} throwing y is actually a good outcome either

i'n happy as long as we aren't making things weirder to make comma op more readable

If I cannot use an Early Error (per waldemar), and we cannot use UnaryExpression without banning trailing infix punctuators (per bakkot), I do not see another solution aside from always requiring parens. I'm open to other suggestions, though.

I don't think a grammar-only solution is feasible, as it would also trigger ASI.

UnaryExpression :
  throw Expression

Can somebody remind me why this is not doable?

Or just static semantics rules to each of the infix operators, like:

LogicalANDExpression :
  LogicalANDExpression `&&` BitwiseOrExpressions

• It is a Syntax Error if LogicalANDExpression is ThrowExpression
  or something to that effect.

frankly I do not understand the concern about having a bunch of early errors

(like you can't do a ?? yield b)

that was my suggestion in the thread but waldemar doesn't like having a bunch of early errors

If throw is at Expression precedence, then we don't need ThrowStatement anymore, since it would be completely covered by ExpressionStatement.

I too had no idea about ?? yield x though. does that also apply to ?? await x?

I too had no idea about ?? yield x though. does that also apply to ?? await x?

If throw is at Expression precedence, then we don't need ThrowStatement anymore, since it would be completely covered by ExpressionStatement.

I think that might change its completion value though

errors are best encountered early

where is this gist?

the third arm of the trilemma seems obviously better than the first two, to me

I am concerned about usability.

https://gist.github.com/bakkot/5a22c8c13ce269f6da46c7f7e56d3c3f

Either a throw expression can be used in a logical expression or not. Having it sometimes be usable in a logical expression and sometimes not is too confusing.

ryzokuken: can we get the queue cleared out?

Either a throw expression can be used in a logical expression or not. Having it sometimes be usable in a logical expression and sometimes not is too confusing.

Parenthesizing throw expr as throw(expr) is intuitive. Parenthesizing it as (throw expr) is not.

Also, personally, I would prefer having throw only usable in parentheses. (throw new Error()) looks a lot more natural, to me, than throw (new Error()).

TCQ feedback: we have two positive options but just one negative

"Possible API to do the clamping logic" doesn't seem settled to me.

the thing where some specific person needs to say "I withhold consensus" seems like it makes proposals to easy to advance

i've seen real code hit this problem

thenables are like a top-three mistake in JS, after "accepting things of the wrong type" and "existence of object.prototype"

I really hope we can have Symbol.thenable or any solution to solve the weird behaivor of module with then export.

thenables are like a top-three mistake in JS, after "accepting things of the wrong type" and "existence of object.prototype"

with enters the room

Symbol.thenable wouldn't fix that, since you can't export a symbol name

Symbol.thenable wouldn't fix that, since you can't export a symbol name

just let module have it automaticlly

Symbol.thenable wouldn't fix that, since you can't export a symbol name

just let module have it automaticlly

It breaks modules that currently export then

unfortunately I think we are not willing to break the web, so we can't fix it

did it break things?

msaboff: ljharb: yes, endianness is about the bytes, not the bits. but clamping clamps something between 0 to 255, i think in a DataView method that is like, all about reinterpreting byte buffers, isn't there a possibility for confusion on whether you're clamping the leftmost byte or the rightmost byte of the Number value?

that said i'd be much comfortable going to stage 2 with a clear direction

chairs: shu and I are happy to reduce our TDZ/coercing items (respectively) to 45 minutes if it means getting to discuss both items