TC39 General on 2026-06-11

09:07	<snek>	i wish the blog post had come alive by any other means
09:07	<snek>	because i think js does really need this
09:09	<snek>	i don't think anything disallows it as such but i would imagine that if you aren't careful with the implementation there are ways to hit spec assertions
16:29	<bakkot>	it's always been a little unclear whether spec assertions constrain implementations or not
16:30	<bakkot>	technically they're supposed to describe invariants which hold anyway, so if an implementation is otherwise allowed to do something but it would violate an assertion, that's an inconsistency in our spec and we should spell out an actual restriction on implementations which forbids them doing whatever it is
19:48	<Richard Gibson>	I'm curious as to how we would do that. For example, consider the assertions in AddValueToKeyedGroup and Symbol.for—they could be violated if two threads race with the same argument(s), fail to find an existing element, and each end up appending a List element with the same keying data. Where would we specify a restriction enforcing the validity of those assertions that obviously connects to them? Maybe in Agents?
20:45	<bakkot>	Probably there, yes; I'm thinking something along the lines of "Values created within one agent cannot be accessed by another agent, with the exception of the values which belong to an entire agent cluster as specified in [the agent clusters section]."
22:00	<Mathieu Hofman>	That seems stronger than what I suggested. But also an implementation can always actually share values if the fact they're shared is not observable to the program? Still to be closer, I'd prefer a wording closer to what I believe should be the constraint: no observable synchronous cross thread value changes outside of explicit shared values.
22:02	<Mathieu Hofman>	because i think js does really need this I can understand that some programs have a use case for shared memory concurrency beyond SAB, but unrestricted shared memory concurrency on existing object values is not the answer. The shared struct proposal exists to come up with a solution that still lets program authors understand where shared access may happen.
22:04	<Mathieu Hofman>	And apparently in the approach here scope binding too 🤯
22:06	<Mathieu Hofman>	And apparently the approach in that PR also allows scope bindings to also change 🤯
22:56	<bakkot>	An implementation can do whatever it wants under the hood; the spec only constraints observables. But yes, we could find some other wording. I would tweak your suggestion to something like "with the exception of shared data blocks, no observable value changes while the execution context stack is not empty except as a result of a specific algorithm step being executed by the current executing thread"; no need to introduce the notion of a "cross thread value" into it.