| 16:03 | <ystartsev> | incubator call? ping ljharb shu |
| 16:04 | <ystartsev> | leobalter: also |
| 16:04 | <shu> | ystartsev: i am in the call |
| 16:05 | <shu> | ystartsev: are you in a different call? |
| 16:05 | <ystartsev> | yes |
| 16:05 | <ystartsev> | it looks like we have 2 |
| 16:05 | <shu> | ystartsev: i am in https://meet.google.com/sao-fyma-sxe |
| 16:05 | <leobalter> | ystartsev shu I've been waiting forsomeome to allow me in the call |
| 16:05 | <leobalter> | this is a different link that what we have |
| 16:05 | <ystartsev> | we are on our way |
| 16:05 | <leobalter> | I'll ping caridy |
| 16:18 | <ljharb> | oops, i didn’t have it in my calendar |
| 16:18 | <ljharb> | is it now? |
| 16:36 | <ljharb> | apparently google meet's web app doesn't show presented screen contents; i had to switch to the ios app to see it :-/ |
| 21:55 | <davepoole> | ljharb: I'm going through our next agenda, and I'm curious about something in Ergo checks for private fields. What's the benefit to this instead of instanceof? |
| 21:58 | <ljharb> | davepoole: instanceof is brittle, and can be faked with `Symbol.hasInstance` |
| 21:59 | <ljharb> | davepoole: also it doesn't work cross-realm for builtins (not that that applies to private fields) so i reflexively am repulsed by it in code review :-) |
| 21:59 | <ljharb> | davepoole: iow any use case for the "private" in private fields also needs it to be robust, which means anything forgeable is out |
| 22:00 | <davepoole> | gotcha, thanks! |
| 22:52 | <Bakkot> | devsnek: https://github.com/tc39/proposal-record-tuple/issues/65#issuecomment-634321864 is pretty rude. |
| 22:53 | <devsnek> | hm? it seemed like a reasonable compromise to me |
| 22:54 | <Bakkot> | you're asserting that the semantics littledan and erights and and I have been arguing for are broken. |
| 22:54 | <Bakkot> | they are different from the semantics you want |
| 22:54 | <devsnek> | I mean, they are |
| 22:55 | <Bakkot> | :| |
| 22:55 | <Bakkot> | no |
| 22:55 | <Bakkot> | they are different from the semantics you want |
| 22:55 | <devsnek> | and also don't compare numbers correctly |
| 22:55 | <devsnek> | according to === |
| 22:56 | <devsnek> | so we could just add a new thing |
| 22:56 | <Bakkot> | we are discussing how to compare structures. IEEE does not mandate a particular semantics for comparing data structures containing numbers. |
| 22:56 | <Bakkot> | there is no objective notion of "correctness" to appeal to here. |
| 22:57 | <Bakkot> | there are different possible semantics, with different justifications. |
| 22:57 | <devsnek> | not the structure, the numbers in the structure |
| 22:57 | <Bakkot> | asserting that your preferred semantics are the only correct semantics, and all other semantics are broken, is rude. |
| 22:58 | <devsnek> | "if it doesn't work on numbers" |
| 22:58 | <devsnek> | I'm not entirely sure how to phrase it |
| 22:58 | <littledan> | I disagree with this kind of categorical phrasing like "it doesn't work on numbers" |
| 22:59 | <devsnek> | if === does your behaviour |
| 22:59 | <devsnek> | we still need the one that compares them how numbers are supposed to be compared |
| 22:59 | <littledan> | yes I think I know what you're getting at and I disagree |
| 22:59 | <devsnek> | we shouldn't provide it at all? |
| 22:59 | <Bakkot> | (gotta run to a meeting) |
| 23:01 | <devsnek> | littledan: you don't think that js should include a comparison that compares the numbers according to their spec |
| 23:01 | <devsnek> | and should leave that to userland |
| 23:02 | <littledan> | well, I don't have a very strong reason why it'd be fatal; we could put it on Record. |
| 23:02 | <devsnek> | well it should be more general |
| 23:02 | <devsnek> | I'd want to use it in place of === |
| 23:03 | <littledan> | yeah, it'd work on Tuples as well |
| 23:03 | <littledan> | and all values I guess |
| 23:03 | <devsnek> | cool |
| 23:03 | <littledan> | but, I don't really understand where you'd want to use it, beyond simple point/complex number examples. I don't understand why you'd want to use it in place of === in general. |
| 23:04 | <devsnek> | id want to use it everywhere for everything |
| 23:04 | <littledan> | why? |
| 23:04 | <devsnek> | because the semantics you're proposing don't work |
| 23:04 | <devsnek> | unless you're memoizing things I guess |
| 23:04 | <devsnek> | but I can't imagine that's the common case here |
| 23:06 | <devsnek> | in any case I reached the point where I want to stop arguing about this more than I want js to be a good language so I'll just make an eslint rule for whatever method we add |
| 23:38 | <littledan> | yeah sorry I guess I'm fine with stopping arguing too... what do you mean by an eslint rule? |
| 23:39 | <devsnek> | littledan: to say that occurances of === should be replaced with Object.strictEquals or whatever it is called |