2023-10-19 [19:50:13.0241] i haven't done much work on the proposal since TC39. does anyone have topics they want to talk about tomorrow? happy to cancel otherwise [20:41:52.0692] I had a chat with Sulekha the other day about a few tangential things to this proposal that might be helpful in tandem with shared structs. One of the things I needed to put together for TS was a concurrent map, and a missing building block I had to work around was the lack of an identity-hash API in the standard library. It's something I've thought about proposing in the past as well [20:43:53.0003] It might be worth some time discussing what other things are missing that might need a follow-on proposal [20:54:46.0629] Either the building blocks for, or complete implementations of, concurrent multi-producer/multi-consumer maps, sets, and bags, thread-safe deques, shared mutexes (multi-reader/single-writer), RAII locking primitives, efficient spin waiting for lock-free algorithms to reduce contention. Userland implementations can't build a true identity hash efficiently, nor fast string hashing w/o resorting to WASM or native code, nor can they implement spin-waiting efficiently. [21:02:58.0324] It might also be good to come up with a different namespace for concurrency primitives if we do pursue those as follow-ons, rather than abuse the `Atomics` namespace like we are for Mutex/Condition. [21:03:57.0375] (and, in fact, move Mutex/Condition off `Atomics` since they don't quite belong there). [21:08:47.0257] And speaking of RAII locking, I'd like to discuss the feasibility of including a `Uniquelock`-like primitive in the origin trial, even if it's too early to expect `Symbol.dispose` to ship. For the purpose of the trial, it could simply have a public `dispose()` method on its prototype and I could patch in a `[Symbol.dispose]()` method onto it's prototype to work with the TS down-leveling of `using` [07:59:19.0862] okay, does sound like we have items to discuss then