04:34
<ljharb>
yeah that was a bummer :-(
14:40
<Hemanth H.M>
Do we still have a chance to resurface it with array-equality?
14:41
<littledan>
I think there are lots of chances to resurface the spaceship operator, array comparison, etc. For me, the symbol-based protocol which was disconnected from how < etc work was what I didn't like so much, not the spaceship operator itself.
14:42
<littledan>
anyway yes we agreed on Stage 1 for a proposal for array equality tests
17:25
<bakkot>
oh hey, someone actually using Atomics! https://jlongster.com/future-sql-web
17:56
<shu>
🥲
17:56
<shu>
"The real magic is the Atomics.wait API. It’s a beautiful thing." i don't know if i'd call futexes beautiful personally
18:55
<bakkot>
keep in mind this is the opinion of someone who has just implemented sqlite on top of indexdb
20:23
<bradleymeck>
I'm back! Also I still hate @@species
20:26
<bradleymeck>
did a brute force replace of globals to see what node is leaking and can't think of a clean way to not have @@species leak out a mutable vector when calling some builtins
20:27
<bradleymeck>
so, if anyone knows how to safely act like Array.prototype.concat but not call @@species without subclassing Array or mutating the receiver that would be nice
20:52
<bakkot>
proxy the receiver instead of mutating it :P
21:40
<Richard Gibson>
bradleymeck: can you clarify the question? Array.prototype.concat requires getting @@species only when the receiver was initialized by ArrayCreate and getting its constructor returns an Object that is not a cross-realm %Array% intrinsic, but it requires getting @@species in those cases so "act like Array.prototype.concat" would be violated by skipping it.