btw if anybody else didn't get added to the Tokyo 2024 channel, please do speak up!

Oh! Could you add me too? Thanks!

shu: maybe DE can elaborate, but my understanding is that they are going to fully move to Ecma, rather than have the split of the CG vs WG

specifically i'm wondering are you doing the thing where you're sending all the contributors IP transfer documents or whatever

is that thign pending legal review from the original folks who raised the IP concerns

Someone wanna drop that screenshot of TCQ questions for me so I can answer them here?

i'd assume the largest review is needed for 1 → 2 or 2 → 2.7, and the smallest for a stage 0 → 1 or 2.7 → 3 or 3 → 4

I don't have strong feelings on this but I do not want a complex rules engine for which deadlines apply to which stages

fwiw I also did not notice that the agenda item contained "TG4: Source Map Specification, 2024 edition approval (30m, Jonathan Kuperman)"

those extra 4 days have been very helpful in the past to get ducks in a row for an upcoming plenary

maybe we should make that should a must

maybe we should make that should a must

I'm not following the chat, but if it's for source map: it would be a 6 months delay and not 2 months, due to the GA meeting twice per year

littledan Btw, the reason we were thinking about the license for the spec itself, is that both ECMA-262 and ECMA-402 are published under Ecma's BSD version

I could generate one but it's best if the speakers do it

Either way, auto-wrapping is a footgun. it also doesn't align with our recent decision to cut back on coercing things

If you consider Iterator.concat to essentially be (...args) => args.values().flatMap(x => x), then we should also throw for non-iterators

if it's an object it should work

private fields, if/when supported, will also have a fixed layout.

can you class extends Struct {}? if so you can surely put a private filed in that class?

did I blink and miss an explanation of function coloring

Function coloring is a function being aware of whether it is invoked inside of an unsafe block.

https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/

rbuckton: Yeah, I mean it seems we should use syntax like sealed class { } to make it clear (though sealed is not a correct keyword) that it's a better but restricted class. And let shared struct just use struct {} ...

so i'd be able to write an "am i in an unsafe block" predicate?

so i'd be able to write an "am i in an unsafe block" predicate?

oh no

so i'd be able to write an "am i in an unsafe block" predicate?

Shu and the v8 team have other reasons to want struct, including the unique construction semantics. struct and shared struct construction differs significantly from class.

I understand from the engine viewpoint (or spec viewpoint) it's true, but I guess from developer concept model, it's too different.

so i'd be able to write an "am i in an unsafe block" predicate?

I understand from the engine viewpoint (or spec viewpoint) it's true, but I guess from developer concept model, it's too different.

You can try/catch around reading from a shared struct that you have, right?

shared struct Test { x }

{
  try { new Test().x } catch { console.log("not unsafe block") }
}

unsafe {
  try { new Test().x; console.log("unsafe block") } catch { }
}

ok, but can i run that try/catch inside a function that someone else invokes in, or not in, an unsafe block?

ah I've misunderstood - so is the following disallowed?

function foo() {
    unsafe {
        bar();
    }
}

function bar(sharedInstance) {
    sharedInstance.property = 123;
}

sorry I spoke too quickly, there is currently no spec behavior that allows a host to prevent object keys to be added to WeakMap, but there is to allow them to refuse any private field stamping

that would be a much bigger problem for existing programs, a new type that has object like bahviors

"use unsafe";

and if you call an unsafe function and do not have unsafe {} in your call stack then it throws

and if you call an unsafe function and do not have unsafe {} in your call stack then it throws

yeah other names have been proposed, like volatile, i think?

That level of indirection would be a major performance bottleneck for a performance-critical feature.

This was in response to Reflect.getUnsafe()

i gotta say, given that we can already do sharedArrayBuffer[0] = 42 wherever we want, I really do not understand the hard constraint of unsafe blocks from mark

thank you but why am i so unhappy

thank you but why am i so unhappy

How is it a level of indirection, this can be optimized the same as foo.bar

I am OK with making these deniable in the environment, if that's the concern? have like a SharedStruct which every shared struct needs to extend and which can be deleted

Even if it can, I don't really want to write Reflect.getUnsafe(Reflect.getUnsafe(x, "y"), "z") on a regular basis, that's terrible DX.

I don’t really wanna write unsafe {} everywhere either

Neither do I, but its far more convenient than Reflect.getUnsafe().

can we do unsafe functionName () {} and just make it like async/await? (not a serious suggestion)

i mean, async/await doesn't directly do that either

I did propose this, but not like async/await, more as a way to avoid doubly nested blocks. Alternatively, function foo() unsafe {}

I don't understand what "contamination" means here

unsafe will contaminate generic abstractions and algorithms, which will be pressured to wrap themselves inside unsafe blocks just so that folks can pass shared structs into them. Most don't really care about consistency and we already have the same problem with accessors, callbacs, and proxies. Wrapping one of these in unsafe will just become boilerplate practice.

unsafe will contaminate generic abstractions and algorithms, which will be pressured to wrap themselves inside unsafe blocks just so that folks can pass shared structs into them. Most don't really care about consistency and we already have the same problem with accessors, callbacs, and proxies. Wrapping one of these in unsafe will just become boilerplate practice.

I would encourage anyone who has interest or concerns in the shared structs proposal to join our regularly scheduled stakeholders calls, we've been making a lot of positive progress in all areas.

How do you tell an abstraction that can apply to both shared and unshared structs that this usage is safe and that usage is unsafe?

But generic abstractions and algorithms shouldn't be unsafely dealing with shared structs, that's the point. They are likely not able to operate generically on the object.

that would give you immutable structs right out of the gate, no?

"immutable" if you squint hard.

In practice there is very little delta between the mischief shared objects can get into and what ordinary callbacks, accessors, proxies, etc. can do.

i agree, but i also don't know how to address mark's requirement that the app-wide opt-in/out switch like COOP/COEP is insufficient

yet somehow shared memory programs have a lot more race type bugs than async or callback code

wtf is wrong with matrix

though i don't think we've fully engaged with bakkot's idea that there be a programmatic way to deny shared structs, even if they're syntax?

waldemar: is it a fair characterization to say your skepticism of unsafe {} boils down to SABs already must be grandfathered in, so it's a false guardrail?

In JS, we have "name your function fooUnsafe()"

I want to know what portion of these CVEs would have been impossible had they been implemented in a memory safe language

I want to know what portion of these CVEs would have been impossible had they been implemented in a memory safe language

Maybe we could just write engines in JS and compile them to native with Porffor

I didn't speak of browsers, but implementers. Moddable is a cosigner

Okay, I meant vendors, not specifically browser vendors. Igalia is an implementer who works on engines built by other vendors. Although we're probably in a unique position

also part of the context here is the unshippability of the things that we spec, see my upcoming presentation on species

Do you think that's something we still risk today with our current stage process?

okay then maybe JITs are the real evil

So you'd have to have a proof-carrying compiler, which is, AFAIK, still mostly in academia only

something something wasm kind of somewhat does this?

(it was a HUGE attack surface on PS4)

(we have JIT totally disabled on PS for security reasons)

This happened to me earlier but after a minute I could see it again

I'm unhappy about the framing of this as a tension between users, developers, and implementors. In most cases we can reduce complexity for all three; existing complexity is a result of past decisions that benefited none of these three.

I'm unhappy about the framing of this as a tension between users, developers, and implementors. In most cases we can reduce complexity for all three; existing complexity is a result of past decisions that benefited none of these three.

thats certainly the case for something like species, but bigint is an independent proposal that had a similar effect

A lot of folks are making points about low BigInt usage, but we'd be hurting if something like that weren't in the language — it comes up rarely in APIs, but, when it does come up, hacking around the lack of BigInt would have made a bigger mess.

A lot of folks are making points about low BigInt usage, but we'd be hurting if something like that weren't in the language — it comes up rarely in APIs, but, when it does come up, hacking around the lack of BigInt would have made a bigger mess.

this is because syntax in particular is not forward compatible. you can't shim it, you have to transpile it.

I don't think any financial application could work without BigInt

How is this relevant? Those websites would have broken even if there was a missing runtime API. The developer would have still chosen to ship the polyfill for that browser version, similarly to how they could have shipped with the transpiled code

shims are lightweight to ship, you can't ship a shim for syntax. it requires tooling, shims don't

thats certainly the case for something like species, but bigint is an independent proposal that had a similar effect

I don't have data to support this, but I really think the presentation overestimates the use of build/compilation tooling, and disregards the abundance of... not using those things, or in the same way

Tooling can't address eval, new Function, other evaluators, or new RegExp() which would need the tooling to be run in browser to support these transformations.

please don't do these things

I don't have data to support this, but I really think the presentation overestimates the use of build/compilation tooling, and disregards the abundance of... not using those things, or in the same way

... and eval(...) differing completely in support feels 🥴

Node.js shipping a TS compiler is the proof that people hate using tooling

Node.js shipping a TS compiler is the proof that people hate using tooling

So if you didn't have the history: we tried to standardize source maps before. That is what became the wasm debugging group

the problem there is that Babel would become a singular blessed tool

Does Mozilla not have someone attending TG2 meetings?

maybe it's not seen in the instrumentation of browsers, but there are a lot of backend use cases for BigInt

Tooling can't address eval, new Function, other evaluators, or new RegExp() which would need the tooling to be run in browser to support these transformations.

I don't really care either way about regexp. Don't use eval or Function.

eval is not evil. there are ways to safely evaluate untrusted code.

shu: yulia I captured the queue for JSSugar. do you want a continuation if we have time later?

In a sandbox, out of process, on another machine...

no in the same process, either different realm (ShadowRealm) or even same realm (Compartment in hardened Realm). Salesforce uses realms, we use Compartments in production, and Moddable uses compartments too in their devices. Let's not claim there is no way to securely run 3rd party JS in the same process

https://github.com/tc39/Reflector/issues/539

Ah yes, I thought you asked for all 3 ;)

Separate: Please could someone unmute @marjakh:matrix.org: