| 01:21 | <Mathieu Hofman> | Btw, re symbols, I'm still surprised no engine considers registered symbols separately from unique symbols, and simply implements them as a wrapped string. At that point there is no need to track instances of registered symbols and collect them, at least any more than roping the strings they wrap, and Symbol.for can simply recreate the value, Symbol.keyFor can unwrap the description, and comparing would match the subtype (registered symbol) + description value. |
| 17:52 | <Michael Ficarra> | if you want to talk more about the presentation from the KAIST research group yesterday, I've started a thread on the Reflector: https://github.com/tc39/Reflector/issues/417 |
| 18:02 | <Ashley Claymore> | Btw, re symbols, I'm still surprised no engine considers registered symbols separately from unique symbols, and simply implements them as a wrapped string. At that point there is no need to track instances of registered symbols and collect them, at least any more than roping the strings they wrap, and typeof to now handle 2 different representations for the same type). And if Symbol.for is only called a few times per application run, not a large optimization saving. |
| 18:03 | <HE Shi-Jun> | https://hackmd.io/yDDJCsS-Sv2AJwo8arAn3w?view |
| 18:05 | <ljharb> | the data flow call has begun; there's only 4 of us so far. jschoi, coming? |
| 18:10 | <ljharb> | oops, we're in the jitsi, not the meet on the calendar invite |
| 19:32 | <rkirsling> | TabAtkins: I meant uncurry-this |
| 19:32 | <rkirsling> | I assumed that was what was meant by call-this |
| 19:33 | <rkirsling> | because there is zero mention of call-this in either article |
| 19:34 | <rkirsling> | so if that's not what was meant then I have zero idea what was meant by that phrase |
| 19:35 | <TabAtkins> | https://github.com/tabatkins/proposal-call-this-operator |
| 19:35 | <TabAtkins> | literally just ".call(), but a calling operator" |
| 19:35 | <TabAtkins> | method@(reciever, arg) === method.call(receiver, arg) |
| 19:36 | <rkirsling> | I see |
| 19:36 | <TabAtkins> | Do people remember the reasons why named argument syntax was rejected in JS? A la foo(argname: 1, arg2name: 2)? |
| 19:36 | <rkirsling> | that too seems inoffensive (in that it adds onto existing syntax) |
| 20:16 | <rkirsling> | oh lol it's funny that my previous statement was in fact that :: is less confusing than ->https://github.com/tc39/proposal-bind-this/issues/10 |
| 20:19 | <rkirsling> | sorry about that, I do still think that's true |
| 20:22 | <rkirsling> | which means that my new point is really just that I'd have a preference for call-this |
| 20:23 | <jschoi> | rkirsling: Also, take a look at rbuckton’s new idea in the pipe room. f(this: thisArg). Or maybe f(thisArg:). |
| 20:31 | <Mathieu Hofman> | I could see conflicts with type systems which also use : |
| 22:14 | <ljharb> | TabAtkins: i think mainly because its value-add is negligible over "an options bag, destructured in the function" |