| 13:26 | <ryzokuken> | Sora Morimoto, others: we kickstarted a space for TC39 stuff, join it at https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org. |
| 15:44 | <Sora Morimoto> | ryzokuken: Cool! |
| 15:44 | <ryzokuken> | Sora Morimoto: I sent you an invite already |
| 15:48 | <Sora Morimoto> | Great thanks |
| 15:50 | <Sora Morimoto> | I'm already joined! 🙃 |
| 15:55 | <Sora Morimoto> | It seems that the bridge channel between freenode can also be added to the space, so I don't think it's a bad idea to add it to the space's room list. |
| 15:56 | <Sora Morimoto> | But it also makes sense to list only Matrix stuff. |
| 15:56 | <littledan> | I don't think we should encourage the use of bridges unless we're sure that they can work well technically. I would also prefer to avoid bridging to Freenode in particular right now, since we all just need to abandon Freenode. |
| 15:56 | <devsnek> | freenode bridge is glitchy at the best of times |
| 15:58 | <Sora Morimoto> | I don't think we should encourage the use of bridges unless we're sure that they can work well technically. I would also prefer to avoid bridging to Freenode in particular right now, since we all just need to abandon Freenode. |
| 15:58 | <Sora Morimoto> | freenode bridge is glitchy at the best of times |
| 16:00 | <jasew> | I will be speaking about Matrix/IRC today |
| 16:20 | <Sora Morimoto> | 👀 |
| 16:25 | <Rob Palmer> | could I get a volunteer to try entering the call today please. link is in the reflector. |
| 16:27 | <jasew> | I can do that, if you give me a couple of minutes |
| 16:27 | <Rob Palmer> | all done - Richard Gibson confirmed the call is active |
| 16:27 | <jasew> | ah ok |
| 16:40 | <jasew> | Rob Palmer: Can you hear me in the room? |
| 16:40 | <Aki> | i think rob stepped out for a sec |
| 16:43 | <jasew> | ok |
| 16:43 | <jasew> | no probs |
| 16:52 | <devsnek> | can we put https://github.com/tc39/Reflector/issues/367 in the topic |
| 16:53 | <ryzokuken> | I don't have admin access, rricard could you try that? |
| 16:53 | <rricard> | I can try, do I have admin access? |
| 16:54 | <rricard> | looks like I do |
| 16:56 | <littledan> | oh, looks like I have admin access. Should the set of people with admin access be expanded (or restricted?) |
| 16:56 | <ryzokuken> | I feel that on this channel, only the chairs/dowagers/moderators should have admin access |
| 16:57 | <rricard> | I do not need admin access tbh |
| 17:01 | <waldemarh> | Am I able to post now? |
| 17:01 | <devsnek> | yes |
| 17:01 | <jasew> | Yes |
| 17:02 | <ryzokuken> | 🎉 |
| 17:18 | <jridgewell> | 😃 |
| 17:18 | <ljharb> | ty |
| 17:19 | <rkirsling> | I only see four rooms though? |
| 17:20 | <ljharb> | i see at least 7 rooms with "tc39" in the name, plus TDZ |
| 17:20 | <ljharb> | i clicked the "+", went to "explore public rooms", and typed "tc39" (i'm in the web client) |
| 17:21 | <rkirsling> | i clicked the "+", went to "explore public rooms", and typed "tc39" (i'm in the web client) |
| 17:21 | <devsnek> | i think this should help https://matrix.to/#/!hmsRHUEXriRovkvcin:matrix.org?via=matrix.org&via=igalia.com&via=mozilla.org |
| 17:22 | <devsnek> | it should prompt you to enable "spaces" |
| 17:22 | <devsnek> | and then you'll see all our associated channels |
| 17:22 | <rkirsling> | oh that worked |
| 17:22 | <ptomato> | that didn't prompt me to enable spaces |
| 17:23 | <Ben Newman> | thanks Rob Palmer! |
| 17:23 | <littledan> | 10 |
| 17:23 | <ljharb> | @ptomato not directly; but there's another button that takes you to settings to enable it (in the web client, i guess) |
| 17:23 | <ryzokuken> | ptomato: that's because you're on igalia's older version 😅 |
| 17:23 | <rkirsling> | that didn't prompt me to enable spaces |
| 17:23 | <ryzokuken> | igalia's server does not support spaces yet |
| 17:23 | <ptomato> | oh i see |
| 17:24 | <rkirsling> | oh dear |
| 17:24 | <devsnek> | all these js devs and no one could whip up a tcq clone website in an hour? |
| 17:25 | <devsnek> | (/s) |
| 17:26 | <ryzokuken> | how many js devs does it take to change a tcq? 😛 |
| 17:29 | <Tierney Cyren> | hope the first in-person meeting we have again is in Tokyo |
| 17:33 | <shu> | so what are we using for this meeting, this or irc? |
| 17:34 | <Tierney Cyren> | my understanding is this |
| 17:34 | <littledan> | Is SoftwareChris a delegate? |
| 17:34 | <Rob Palmer> | littledan: yes |
| 17:34 | <littledan> | and Granville Schmidt ? |
| 17:34 | <Rob Palmer> | littledan: yes |
| 17:34 | <shu> | Tierney Cyren: hm, i don't think we have the critical mass yet here to use this |
| 17:35 | <Tierney Cyren> | @shu |
| 17:35 | <Tierney Cyren> | ack |
| 17:35 | <Tierney Cyren> | the autocomplete will kill me |
| 17:35 | <Tierney Cyren> | apologies in advance for the many mistakes I'll make |
| 17:35 | <Tierney Cyren> | shu: |
| 17:35 | <Tierney Cyren> | AAAAA |
| 17:36 | <yulia> | you get used to it, eventually |
| 17:36 | <shu> | i seem to get highlighted either way shrug |
| 17:36 | <littledan> | Is tkopp a registered invited expert? |
| 17:36 | <Tierney Cyren> | shu: there's 50 people in the meeting and 40 in this room |
| 17:36 | <shu> | wait really? when i expanded the list i saw like 10 |
| 17:36 | <shu> | am i pressing the wrong button |
| 17:36 | <littledan> | yeah I think this is as much critical mass as IRC had |
| 17:36 | <littledan> | not everyone joined IRC either |
| 17:37 | <ryzokuken> | I think more people would join this, though. |
| 17:37 | <shu> | when i click on "40 People", why do i only see a list of 13 people? |
| 17:37 | <ryzokuken> | I mean, that was the whole point though, wasn't it? |
| 17:38 | <devsnek> | shu: option at the bottom is like "and 10 others" |
| 17:38 | <devsnek> | and you can click on that |
| 17:38 | <shu> | i do not have such a button |
| 17:38 | <littledan> | shu: Maybe if you can post a screenshot of where you got the 10 from we could help you interpret it? |
| 17:38 | <littledan> | or we can just ignore this |
| 17:39 | <devsnek> | https://gc.gy/89669355.png |
| 17:39 | <shu> | that's scrolled all the way to the bottom in the list |
| 17:39 | <ryzokuken> | https://gc.gy/89669355.png |
| 17:40 | <Tierney Cyren> | shu: there's a different set of people on my list |
| 17:40 | <Tierney Cyren> | luv 2 decentralize |
| 17:40 | <ryzokuken> | but but you're all on the same homeserver 😭 |
| 17:40 | <devsnek> | isn't element like 50000 homeservers |
| 17:40 | <devsnek> | glued together |
| 17:41 | <ryzokuken> | well fair |
| 17:41 | <ryzokuken> | scaling synapse is... hard |
| 17:42 | <ljharb> | ryan phillipe figured it out easily enough |
| 17:42 | <shu> | perfect compression |
| 17:45 | <justingrant> | FYI: I tried using the Jitsi Electron app on MacOS, and the audio didn't work well. Was choppy and every 10 seconds I'd lose 5-ish seconds of audio. The browser Jitsi seems to be working OK. |
| 17:47 | <leobalter> | Aki: I believe rwaldron and jugglinmike are both working on Test262 but they are not present on the meeting. I've been catching just a PR here and there on Test262 and there isn't much to say about it from my very end. |
| 17:50 | <littledan> | See the link to alternaqueue in https://github.com/tc39/Reflector/issues/367 |
| 17:53 | <littledan> | shu: lgtm, thanks for the fix |
| 17:53 | <rbuckton> | Rob Palmer: trying to open your message but either matrix or element is not cooperating |
| 17:54 | <Rob Palmer> | rbuckton: i received your reponse - so all fixed now |
| 18:01 | <rkirsling> | congrats! :tada: |
| 18:01 | <ryzokuken> | 🎉 |
| 18:01 | <Tierney Cyren> | Congrats rbuckton |
| 18:01 | <shu> | pls no excessive animations |
| 18:01 | <shu> | this laptop cannot handle |
| 18:01 | <ryzokuken> | shu: you can disable the confetti/snow/etc animations. |
| 18:01 | <shu> | oh good, let me do that |
| 18:01 | <ryzokuken> | in the settings |
| 18:01 | <rbuckton> | Such excite |
| 18:02 | <ryzokuken> | I see the slides |
| 18:02 | <littledan> | congrats rbuckton ! Well-earned. |
| 18:03 | <rkirsling> | I dunno, you'll have to .then it to find out rimshot |
| 18:06 | <shu> | who can add new rooms to the space? |
| 18:06 | <rbuckton> | Have been busy with TypeScript, but hope to get static {} ready for Stage 4 this year too. |
| 18:07 | <shu> | rbuckton: test262's what's been blocking chrome from shipping for a month or two now |
| 18:07 | <ryzokuken> | which one do you want to be added? |
| 18:07 | <ryzokuken> | who can add new rooms to the space? |
| 18:07 | <shu> | and that is currently blocked on the "await as identifier" issue |
| 18:07 | <shu> | ryzokuken: an editors' channel |
| 18:07 | <rbuckton> | shu: I plan to look at it this week. |
| 18:07 | <shu> | rbuckton: thanks |
| 18:08 | <ryzokuken> | can you make the room? If I make it, it will be created on the igalia.com server and not matrix.org. I could add that room to the space, then. |
| 18:13 | <shu> | well that's what i'm asking |
| 18:13 | <shu> | i don't know how to make the room, or if i can :) |
| 18:13 | <Aki> | i |
| 18:13 | <Aki> | i'm on it |
| 18:13 | <ryzokuken> | awesome, thanks! |
| 18:15 | <Aki> | shu: will this be a publicly listed room? |
| 18:15 | <ljharb> | justingrant: the deadline only applies to stage advancement. |
| 18:19 | <shu> | Aki: hm, i think public listed and readonly is fine, but we'd like only editors to be able to send messages |
| 18:19 | <shu> | bakkot: opinions on the editor's room? |
| 18:20 | <bakkot> | shu: depends on if we can get michael to join |
| 18:20 | <shu> | heh |
| 18:20 | <bakkot> | if not, I'd prefer to do it on libera |
| 18:20 | <shu> | okay |
| 18:21 | <shu> | Aki: sounds like let's hold off making the room then |
| 18:22 | <Aki> | Michael Ficarra: poke |
| 18:23 | <Michael Ficarra> | Aki: yes? |
| 18:24 | <bakkot> | Michael Ficarra: if we had a room here for tc39 editors would you participate |
| 18:25 | <Michael Ficarra> | at least as much as I participated in the IRC room |
| 18:25 | <Michael Ficarra> | this is definitely easier for me |
| 18:25 | <shu> | oh good |
| 18:25 | <Aki> | https://snaps.akibraun.com/eori1.gif |
| 18:26 | <Michael Ficarra> | good movie! |
| 18:28 | <Michael Ficarra> | lol @ "you can't rely on hasOwnProperty being there so let's add another writable property to a built-in 4Head" |
| 18:29 | <devsnek> | yes |
| 18:29 | <devsnek> | v.constructor.hasOwn(v, p) |
| 18:30 | <littledan> | I guess s-urabeis not a delegate or IE, and I accidentally gave them power level 10, and need to reduce it. However, Matrix gives me an error message when I try to do this. Does anyone have ideas? |
| 18:53 | <littledan> | Should we continue going down the queue? |
| 18:54 | <mpcsh> | I guess s-urabeis not a delegate or IE, and I accidentally gave them power level 10, and need to reduce it. However, Matrix gives me an error message when I try to do this. Does anyone have ideas? |
| 18:54 | <ljharb> | Aki: it might be nice to move through the queue; there's a number of responses to waldemar's points |
| 18:54 | <littledan> | you can't change the power level of anyone who has the same power level as you; someone with a higher power level has to do it, which it looks like Aki did |
| 18:55 | <mpcsh> | oh! weird. |
| 18:55 | <Aki> | littledan: whenever that happens to me (a couple times now) i quit and relaunch |
| 19:02 | <shu> | i think TCQ in the future should always have a Sheets backend |
| 19:02 | <bakkot> | all applications should |
| 19:02 | <bakkot> | sheets is the ideal database |
| 19:02 | <shu> | yeah |
| 19:03 | <shu> | time to launch a new cloud computing company that scales excel better |
| 19:03 | <shu> | "cloud is someone else's spreadsheet" |
| 19:03 | <littledan> | it's NoSQL! |
| 19:03 | <shu> | damn, time is a flat circle |
| 19:03 | <shu> | i would've just named the space vlookup |
| 19:04 | <ryzokuken> | isn't SQLite technically a SQL-compatible spreadsheet? |
| 19:06 | <ljharb> | how can i disable the behavior where i have to grant people permission to message me? |
| 19:10 | <ryzokuken> | Hm, I'm not sure you can do that, since that would mean that you'd automatically join every room you're invited to... |
| 19:11 | <ryzokuken> | Each DM is just a 1:1 room 😅 |
| 19:14 | <littledan> | They can send the first message immediately and you'll receive it once you accept |
| 19:26 | <Tierney Cyren> | time to launch a new cloud computing company that scales excel better |
| 19:27 | <Tierney Cyren> | also Notion to some extent? I've not used it enough to actually know. |
| 19:43 | <shu> | oh cool, i've never used either |
| 19:44 | <shu> | for some reason i thought airtable was an email thing |
| 20:09 | <yulia> | shu: do you have any schedule constraints around Resizable Array Buffer? |
| 20:12 | <shu> | no |
| 20:13 | <yulia> | shu: would you be willing to step in at the end of today if we end up with 45 min? |
| 20:14 | <shu> | sure |
| 20:14 | <yulia> | cool |
| 20:28 | <ljharb> | it'd be nice if the sheeTCQ listed the current agenda item name |
| 20:29 | <Robin Ricard> | bold should represent the ongoing item |
| 20:31 | <Rob Palmer> | agreed |
| 20:37 | <ljharb> | that's the queue item. i mean the agenda item |
| 20:37 | <Robin Ricard> | oh, I look at hackmd |
| 20:37 | <ljharb> | that's what i did. but regular TCQ has that info up top also, so it'd be nice as a reference |
| 20:37 | <Robin Ricard> | but yea agreed |
| 20:38 | <Robin Ricard> | well it is a collaborative document, I think it can be added |
| 20:38 | <Aki> | do ittttt |
| 20:39 | <Robin Ricard> | it has been added |
| 20:40 | <ljharb> | how is :gavel: not an emoji |
| 20:40 | <ptomato> | 🔨 |
| 20:51 | <littledan> | I'm not going to be able to make it to the ResizableArrayBuffer presentation, but I'm +1 on Stage 3 for the proposal |
| 20:51 | <littledan> | great work finding a compromise way forward here |
| 20:55 | <bakkot> | has anyone proposed using a Set here |
| 20:55 | <bakkot> | that seems like the thing you actually want |
| 20:56 | <bakkot> | also I would like to hear from implementors about cost of arrays vs iterators, if possible |
| 20:59 | <shu> | not a fan of iterators |
| 20:59 | <shu> | purely from implementation perspective |
| 21:00 | <shu> | too many intermediate values, don't like thinking about edge cases with iterator close |
| 21:00 | <yulia> | ljharb: just to be clear -- its not just tied to this proposal |
| 21:00 | <ljharb> | right, i get that it would impact everything |
| 21:00 | <yulia> | we will require it for all proposals that implement similar behavior going forward |
| 21:00 | <ljharb> | but i mean, i don't think this or any proposal should be held back until that separate proposal advances |
| 21:01 | <yulia> | hm, to word it differently: We would like to introduce this invariant |
| 21:01 | <ljharb> | ie, even if there's impls right now that ship partial datasets, i can already observe that without this proposal, so i don't think this proposal should be affected |
| 21:01 | <ryzokuken> | my understanding is that this proposal doesn't incur any addition in the CLDR data included |
| 21:01 | <ljharb> | right - i think that's a great invariant to introduce! but it doesn't seem reasonable to me to hold back a stage 2 proposal from stage 3 due to an invariant that doesn't exist yet |
| 21:01 | <yulia> | right, from my reading of the spec that doesn't change |
| 21:02 | <ljharb> | (especially considering this proposal doesn't seem to in any way worsen the thing the invariant is designed to prevent) |
| 21:02 | <yulia> | do we have anything like this already in the language? specifically about listing apis available in the browser in this specific way? |
| 21:02 | <bakkot> | If implementors don't want iterators, and the point of iterators was to make things easier for implementors, it sounds like we should not do iterators |
| 21:03 | <shu> | wait, it's not at all my understanding iterators was to make things easier for implementers |
| 21:03 | <yulia> | because from my understanding -- the privacy review found that while we are not concerned with this specific proposal, we are concerned with the tendency |
| 21:03 | <ljharb> | yulia: not that i know of; it'd be tricky i think to word it since 402 doesn't precisely mandate what's shipped |
| 21:03 | <yulia> | yeah, that was my understanding as well |
| 21:03 | <ljharb> | but something like a consistency invariant seems like it has precedent |
| 21:03 | <ljharb> | ie, "if a locale is accepted anywhere, it must appear everywhere locales do" etc |
| 21:04 | <yulia> | right |
| 21:04 | <yulia> | I don't think we are disagreeing here, but it is a hard requirement for us going forward |
| 21:08 | <ljharb> | if by "going forward" you mean "all other proposals besides this one" then we agree :-D |
| 21:08 | <bakkot> | shu: it certainly sounded like it the point of iterators was to conserve memory or something |
| 21:08 | <bakkot> | not because of any design question |
| 21:08 | <shu> | waaat |
| 21:09 | <bakkot> | for this specific topic, I mean |
| 21:09 | <shu> | a protocol that produces a new object every iteration |
| 21:09 | <shu> | ooooh |
| 21:09 | <shu> | i thought you were talking about why we introduced iterators to begin with |
| 21:09 | <bakkot> | oh, no, sorry |
| 21:09 | <bakkot> | for this specific proposal |
| 21:09 | <shu> | right, but that's not about ease, that's at the expense of ease |
| 21:09 | <ryzokuken> | yeah, in this case the idea was that we might not have the entire list on memory... |
| 21:09 | <bakkot> | the idea of using iterators instead of arrays, for this question, would be to save memory in implementations |
| 21:09 | <yulia> | ljharb: this proposal isn't yet at stage 3, and this is a pre-implementation concern |
| 21:10 | <yulia> | to be faiiir though i think this is not so complicated |
| 21:10 | <yulia> | and i believe this was already agreed |
| 21:10 | <shu> | bakkot: i don't really have anything against that; iterators are a known quantity of complexity, and could arguably reduce peak memory use |
| 21:12 | <ljharb> | yulia: totally agree; but i think it would be unfortunate to block it based on an invariant we don't even have consensus on yet, when the "problem" the invariant is solving already exists |
| 21:13 | <yulia> | The invariant is for future proposals |
| 21:13 | <yulia> | this is a requirement for this one |
| 21:13 | <ljharb> | yulia: ok so that's the part we disagree on. i think it's unreasonable to make it a requirement for this one since this one doesn't worsen the fingerprintability of existing implementations. |
| 21:14 | <yulia> | if i understood mozilla's review on fingerprinting, it depends on this -- that all users get the same dataset |
| 21:15 | <ljharb> | i'm pretty sure i could build a 100% compliant polyfill for the current proposal, it'd just be large and annoying to write, which means it's not providing any new capabilities (i'd be happy to do that as an exercise if it changes anything) |
| 21:15 | <yulia> | im not sure what the goal there would be? |
| 21:16 | <ljharb> | to demonstrate that the proposal doesn't make "the problems the invariant is preventing" any worse, and thus, the invariant needn't block the proposal |
| 21:17 | <yulia> | ok, let me order things a bit |
| 21:17 | <yulia> |
|
| 21:18 | <yulia> |
|
| 21:18 | <yulia> | this is non-negotiable, so i am not sure why we are having this discussion |
| 21:18 | <ljharb> | the first obv makes anything else moot; but i don't understand how the second is logically consistent |
| 21:19 | <yulia> | if 1 is not satisfied, we do not have such an api in the language where this was a risk |
| 21:19 | <ljharb> | i'm not understanding how it being "an enumeration API" makes anything less safe/ideal than the current needed approach of "hardcoding a list and brute-forcing" |
| 21:19 | <ljharb> | we have that api already - i can make a hardcoded list of every possible Intl value, and brute-force a list of all the supported things. the only difference is that i have to keep up with new possible values over time; with an enumeration API i wouldn't. |
| 21:19 | <yulia> | hard coding a list is shipping the full data set, or am i missing something? |
| 21:20 | <ryzokuken> | I don't think I understand "partial data sets" here. |
| 21:20 | <ljharb> | me, the user would ship it |
| 21:20 | <ljharb> | the concern as i understand it is about fingerprinting |
| 21:20 | <ljharb> | i can ship the full dataset in my JS, in order to fingerprint the partial data set some browser/engine is already shipping |
| 21:21 | <ljharb> | the enumeration api allows legit use cases (pickers, validation, etc) to be much easier and cheaper, without making fingerprinting use cases any more possible (just, also easier) |
| 21:21 | <yulia> | does the enumeration api ship the same data set to all users? |
| 21:22 | <ljharb> | the enumeration API doesn't ship a data set - it exposes the data set that's already shipped, that all the other Intl APIs already use (and thus, already expose in a one-off fashion) |
| 21:22 | <yulia> | ok, does it expose the same data set? |
| 21:22 | <ljharb> | yes |
| 21:22 | <yulia> | ok. then what are we arguing about? |
| 21:23 | <ljharb> | hm |
| 21:23 | <yulia> | aside from terminology |
| 21:23 | <ljharb> | ok so by "not a partial dataset" you mean, it has to correspond to the same data set all the other Intl apis use? |
| 21:23 | <yulia> | yes |
| 21:23 | <Michael Ficarra> | @ljha |
| 21:23 | <ljharb> | oh lol ok then sorry for the confusion, seems like we violently agree |
| 21:23 | <yulia> | very good! |
| 21:24 | <yulia> | better than disagreeing |
| 21:24 | <Michael Ficarra> | ljharb: I believe anti-fingerprinting techniques are easier to implement against a single test style API than an enumeration style API |
| 21:24 | <ljharb> | if the spec allows some locale data to be supported somewhere, but not show up in the enumeration - or vice versa - that sounds like a spec bug to me (and i'd be shocked if an implementation knowingly shipped that) |
| 21:40 | <Robin Ricard> | does anyone has the saved queue? |
| 21:44 | <bakkot> | I am confused, I thought well-known symbols were pre-populated into the symbol.for registry |
| 21:45 | <bakkot> | maybe I am wrong |
| 21:45 | <waldemarh> | I think the last bullet point is just poorly worded. Shouldn't dwell on it. |
| 21:47 | <ljharb> | Robin Ricard: it's a tab on the spreadsheet |
| 21:47 | <Robin Ricard> | yep it was ported |
| 21:47 | <ljharb> | well-known symbols are not in the registry, but are the same across all realms |
| 21:47 | <bakkot> | apparently I am wrong, well-known symbols are not put into the global symbol registry |
| 21:47 | <Robin Ricard> | thanks |
| 21:48 | <Michael Ficarra> | I don't understand, couldn't you register a symbol after putting it in the weak map/set? |
| 21:48 | <ljharb> | I don't understand, couldn't you register a symbol after putting it in the weak map/set? |
| 21:48 | <shu> | i thought not, that'd be real bad |
| 21:49 | <ljharb> | you can't register a symbol, you get a symbol out of the registry by a string |
| 21:49 | <ljharb> | p sure a non-registry symbol can't ever === a registry symbol |
| 21:49 | <waldemarh> | ljharb: agree |
| 21:49 | <waldemarh> | that's an important distinction |
| 21:49 | <Michael Ficarra> | bakkot: uhh aren't they? Symbol.for('iterator') |
| 21:50 | <ljharb> | Symbol.iterator !== Symbol.for('iterator') |
| 21:50 | <Michael Ficarra> | oh wow I did not know that |
| 21:50 | <ljharb> | it's also not Symbol.for(Symbol.iterator.description) or Symbol.for(Symbol.iterator.toString()) |
| 21:53 | <Michael Ficarra> | for some reason, I also thought that well-known symbols were already in the global symbol registry |
| 21:54 | <ljharb> | shu: const wm = new WeakMap(); var o = {}; wm.add(o, () => o); o = null makes o uncollectible also, until wm is, no? |
| 21:55 | <Richard Gibson> | the last time this was raised, Mark presented what was to me a novel mental model in which registered symbols are functionally a distinct type from other symbols, and leaned on that model in support of excluding them as WeakMap keys |
| 21:55 | <ljharb> | that sounds interesting but i don't think that's how any users think about symbols |
| 21:55 | <Richard Gibson> | I agree |
| 21:56 | <Richard Gibson> | and I share your original objection, but I think my position has since weakened more than yours |
| 21:56 | <Richard Gibson> | but it still makes me uncomfortable to allow some symbols but not others |
| 21:57 | <ljharb> | Justin Ridgewell: also "is it a well-known symbol" which is much more complex logic |
| 21:58 | <ljharb> | * <i want to delete this dupe>< |
| 21:58 | <ljharb> | * <i want to delete this dupe> |
| 21:58 | <Richard Gibson> | I'd just be willing to make that compromise, because well-known and registered symbols aren't the ones I really care about |
| 21:58 | <Justin Ridgewell> | For reference, my code sample was if (Symbol.keyFor(s)) { useMap(s) } else { useWeakMap(s) } |
| 21:59 | <ljharb> | i absolutely care about keying on well-known symbols, but ofc i write polyfills |
| 21:59 | <Justin Ridgewell> | Meaning that the fallback case will have the same uncollectable behavior, because I have to insert it into a Map |
| 22:01 | <Richard Gibson> | I don't even know if there is a robust way to identify a value as a well-known symbol |
| 22:02 | <ljharb> | if you assume caching of all relevant methods/objects, the equivalent of function isWKS(s) { return typeof s === 'symbol' && !Symbol.keyFor(s) && Reflect.ownKeys(Symbol).filter(x => typeof x === 'symbol').some(x => x === s); }, which is onerous and gross |
| 22:04 | <shu> | ljharb: no, it shouldn't |
| 22:04 | <shu> | ljharb: weakmaps are ephemerons, so the closure that captures o would only be marked as live if its key, o is also marked as live. it's an implication |
| 22:04 | <ljharb> | ah ok, gotcha |
| 22:04 | <bakkot> | we could add a isWellKnown getter to symbols |
| 22:04 | <ljharb> | .canGoInWeakStuff |
| 22:05 | <bakkot> | !Symbol.keyFor(s) isn't right because Symbol.keyFor(Symbol.for('')) === '' |
| 22:05 | <bakkot> | have to check == null |
| 22:05 | <ljharb> | oh right, typeof Symbol.keyFor(s) !== 'string' or something |
| 22:06 | <Richard Gibson> | I was concerned about Symbol properties corresponding to well-known symbols being configurable or writable, but that is thankfully not the case |
| 22:07 | <Richard Gibson> | so at least first-run code can reliably detect, the process just sucks |
| 22:07 | <Michael Ficarra> | ljharb: old IE used to have trouble cleaning up objects with mutual references like var a = {}; var b = { a: a }; a.b = b; |
| 22:07 | <shu> | did they not have a garbage collector o_O |
| 22:08 | <Michael Ficarra> | beats me, this was like IE6/7 days |
| 22:09 | <leobalter> | yulia: Rob Palmer We had a constraint for Daniel and Caio in the agenda, but I cleared it out with them already, they are now able to attend it at 1PM |
| 22:09 | <Rob Palmer> | perfect - thank you |
| 22:09 | <yulia> | Ok, that was part of the confusion, thanks for clarifying! |
| 22:16 | <bakkot> | Richard Gibson: you can always just check if (new WeakSet).add(k) throws. pretend we're python. |
| 22:38 | <Richard Gibson> | that's actually what was on my mind, if this goes through then it becomes the best way of detecting cross-realm symbols |
| 22:43 | <ljharb> | and i suspect it will become idiomatic for APIs to only accept a subset of the three kinds of symbols |
| 23:12 | <bakkot> | I'm not certain I've ever seen Symbol.for in the wild |
| 23:12 | <bakkot> | so that is probably not a huge loss |
| 23:12 | <bakkot> | though also I think I Have never seen an API which takes as an argument an arbitrary symbol, so |
| 23:25 | <Richard Gibson> | likewise for me, and that's why I think I can live with the compromise even though I don't like the added spec and practitioner complexity of differentiating symbols that can be WM keys vs. those that can't |
| 23:31 | <Richard Gibson> | but I do recognize that well-known symbols and registered symbols are special in practice because they can enter an object graph even after becoming unreachable (having been revived by creation of a new realm) |
