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. |