| 17:44 | <michaelficarra> | is anyone in the meeting yet? |
| 17:55 | <ljharb> | michaelficarra: to change your name, you have to leave and rejoin i believe. |
| 17:59 | <ryzokuken> | do we need to fill in the table on the docs? |
| 17:59 | <ryzokuken> | since we already have an attendance form? |
| 18:02 | <Bakkot> | ryzokuken the table in the docs is useful for the note-takers, I think |
| 18:02 | <ryzokuken> | oh right |
| 18:02 | <ryzokuken> | thanks |
| 18:02 | <ljharb> | akirose: force quit and reopened the ipad app, and i briefly saw the BA again, then the slides popped in, so i'm good |
| 18:03 | <rkirsling> | everyone does indeed look like themself, ha |
| 18:08 | <gibson042> | Teams doesn't seem to be working for me; is anyone else stuck on something like "You're not on Teams yet, but you can set it up for your organization"? |
| 18:08 | <ljharb> | gibson042: you have to sign in as a guest |
| 18:09 | <gibson042> | I don't even see a way to do that |
| 18:09 | <gibson042> | anyway, joining via browser seems to work |
| 18:09 | <rbuckton> | transcription bot: `s/Baht/bot` |
| 18:10 | <ljharb> | gibson042: it's possible if you're logged into your microsoft passport account it skips that screen |
| 18:14 | <ystartsev> | editors ready after this? |
| 18:14 | <gibson042> | hmm, now Teams is showing a "Sign in" screen but there is no guest option |
| 18:15 | <akirose> | what the heck |
| 18:15 | <gibson042> | whatever, the web app is working so I'll stick with that |
| 18:16 | <sffc> | It might work if you join as a guest using the web client |
| 18:16 | <sffc> | yep |
| 18:24 | <ryzokuken> | I have had some informal comms with CalConnect folks, they are actively working on it, just as an FYI. |
| 18:24 | <leobalter> | sffc: wrt ECMA-402 updates, we should communicate we're doing the cut of ECMA-402 for the 2021 candidate. I believe the only next additions before the cut would be DTF formatRange and perhaps the current listed PRs if they get consensus in this meeting. |
| 18:24 | <leobalter> | gibson042: ^^ |
| 18:27 | <sffc> | leobalter gibson042: I added a slide. Do you want to discuss it? |
| 18:28 | <sffc> | (also, this is #tc39-delegates; we have #tc39-ecma402 for i18n discussions) |
| 18:29 | <leobalter> | moving the discussion there |
| 18:30 | <Bakkot> | also for anyone considering taking notes, you should know that it usually does a better job than it was doing iwth Istvan |
| 18:31 | <Bakkot> | e.g. it got dan almost perfectly |
| 18:42 | <akirose> | "SDO" is also the acronym for standards orgs |
| 18:43 | <akirose> | standards develop(ing|ment) organization |
| 18:45 | <ystartsev> | I am so happy about this channge |
| 18:46 | <ljharb> | super great |
| 18:47 | <littledan> | omg I'm so excited about this |
| 18:47 | <littledan> | this is awesome |
| 18:53 | <ystartsev> | Editor group has done amazing stuff |
| 18:53 | <JaseW> | That |
| 18:55 | <JaseW> | That's great news Bakkot |
| 18:56 | <michaelficarra> | btw a lot of these changes will apply to ECMA-402 as well, since they use ecmarkup |
| 18:58 | <michaelficarra> | littledan ystartsev we are, too! |
| 19:00 | <michaelficarra> | as editors, we spend a decent amount of time navigating the spec and we were constantly feeling the pains addressed by the SDO re-org |
| 19:04 | <rpamely> | I just noticed the reflector issue link in the room title is old. Current meeting is issue 340. |
| 19:07 | <ljharb> | rpamely: thanks, fixed |
| 19:17 | <ryzokuken> | 👏 |
| 19:20 | <akirose> | the department of meta |
| 19:34 | <ljharb> | ok so `(console.log(0), null)[console.log(1)] = console.log(2);` logs 0,1,2 in my browser - what order does the current spec dictate? (Bakkot, ystartsev) |
| 19:34 | <Bakkot> | ljharb it dictates 0, 1, throw, I believe |
| 19:34 | <ljharb> | i'd kind of expect 0, throw |
| 19:34 | <ljharb> | ah k |
| 19:34 | <Bakkot> | not totally sure; might be 0, throw |
| 19:35 | <Bakkot> | ah, I was right the first time |
| 19:35 | <Bakkot> | that's part of why it's so painful |
| 19:35 | <Bakkot> | because you look at the object, then the key, then the object again |
| 19:36 | <ljharb> | which is what you already have to do for `o[k]` in case o is a proxy or has a setter on o[k], no? |
| 19:37 | <ljharb> | i guess in those two cases you'd have to have the RHS first |
| 19:37 | <Bakkot> | sorry, so, current spec dictates: |
| 19:37 | <Bakkot> | object, key, object, rhs, object+key+rhs |
| 19:38 | <Bakkot> | you do have to check for proxies or setters or whatever, but those happen as part of performing the assingment |
| 19:38 | <Bakkot> | which happens after evaluating the HRS |
| 19:38 | <Bakkot> | *RHS |
| 19:39 | <ljharb> | right |
| 19:39 | <ljharb> | so this would just become "object, key, rhs, all" |
| 19:40 | <Bakkot> | yeah |
| 19:41 | <ljharb> | k, thanks |
| 19:41 | <ystartsev> | sorry for the mixup earlier |
| 19:42 | <ystartsev> | the chairing transition was a bit rough |
| 19:43 | <JaseW> | I think the note taker has stopped |
| 19:43 | <JaseW> | and it's back |
| 19:43 | <Bakkot> | JaseW refresh |
| 19:43 | <Bakkot> | yeah |
| 19:43 | <Bakkot> | ljharb in fact it was even worse than that, now that I've looked |
| 19:43 | <Bakkot> | it was, evaluate obj, evaluate prop, coerce obj to object, coerce prop to string, evaluate RHS, perform assignment |
| 19:43 | <ljharb> | and now? |
| 19:44 | <Bakkot> | now it's just evaluate object, evaluate prop, coerce prop to string, evaluate RHS, perform assignment |
| 19:44 | <Bakkot> | so the "evaluate prop" and "coerce prop to string" become adjacent |
| 19:45 | <ystartsev> | ^ yeah that is the main change |
| 19:45 | <ljharb> | and "coerce obj to object" happens as part of "perform assignment" |
| 19:45 | <ljharb> | gotcha |
| 19:45 | <shu> | 46! |
| 19:45 | <ystartsev> | yeah, ToObject basically does the same |
| 19:46 | <ystartsev> | there is a more in depth write up in my test repo for it |
| 19:56 | <ystartsev> | sffc: I got the thumbs up on #500 |
| 19:56 | <ystartsev> | sorry for the delay and thanks for the patience |
| 20:01 | <sffc> | ystartzev: thanks! |
| 20:03 | <shu> | rbuckton: yay, thanks for presenting |
| 20:04 | <rbuckton> | 👍 |
| 21:09 | <msaboff> | rbuckton Someone on the JSC team ask a question about materializing "indices" and I didn't know the answer. |
| 21:11 | <msaboff> | rbuckton With the latest, just approved, version of the spec, is there a reason we don't set 'indices' to 'undefined' when the 'd' flag isn't present? |
| 21:12 | <msaboff> | I haven't run any perf tests on that variant and I don't remember it being discuss as part of the new option discussion. |
| 21:12 | <msaboff> | The team member noted that 'indices' has a different creation semantic than the 'groups' property. |
| 21:25 | <rbuckton> | msaboff: No particular reason, other than not to have it if its not requested. If we unconditionally create the property (like we do for groups), and leave it as `undefined`, I would have no issue. |
| 21:26 | <msaboff> | rbuckton Okay. I can run perf tests to see if there is any issue. I'll try to get to that by the end of the meeting. |
| 21:32 | <littledan> | +100 to ljharb 's point on the queue |
| 21:46 | <caridy> | I get the same impression than Waldemar, same issue with Trusted Types! |
| 21:47 | <caridy> | you must own/control the whole app, the whole code running for the app to make this any useful |
| 21:49 | <littledan> | I don't think Mark's proposed constraint makes sense. I think it would be a very unreasonable constraint on the development of the JS standard library |
| 21:49 | <littledan> | I agree that checking whether a template tag is literal is a rather low-level property |
| 21:51 | <jridgewell> | From Google’s experience, controling the whole app is expected |
| 21:52 | <caridy> | right! but majority of apps are not like that! anything using anything from NPM is automatically in the other category! |
| 21:52 | <jridgewell> | I’m not sure I agree |
| 21:53 | <jridgewell> | The point isn’t to guard against a truly malicious 3p script running on the page |
| 21:53 | <jridgewell> | It’s to guard against accidental usage |
| 21:54 | <ljharb> | i don't think there's agreement that that's not the point |
| 21:55 | <jridgewell> | Having `makeSafeUrl(codeIThoughtWasStaticButIsActuallyDynamic)` is a wholey different attack than `makeSafeUrl'https://im.actually.static'` |
| 21:55 | <jridgewell> | Potecting against a page that’s exposed `eval`, you’re entire app is insecure, their’s no fixing that. |
| 21:55 | <littledan> | there's sort of an interesting parallel between the shape of Mark's argument and previous arguments against SES-motivated features: both allege that the scenario where the feature is useful is impractical |
| 21:56 | <ljharb> | jridgewell: there's tons of ways to protect against eval |
| 21:56 | <littledan> | I wonder if we could dig into this practicality and think about how to assess it more broadly |
| 21:56 | <ljharb> | jridgewell: eval doesn't break closures. |
| 21:56 | <littledan> | ljharb: +1 |
| 21:56 | <Bakkot> | jridgewell I still pretty much agree with waldemar |
| 21:56 | <Bakkot> | if you are not concerned about malicious code, checking for "it's frozen and has a raw property" is good enough |
| 21:56 | <Bakkot> | if you are concerned about malicious code, this doesn't help |
| 21:58 | <littledan> | this is a sort of integrity feature. It gets exactly what you want in terms of "did this really come from syntax". A bunch of people asked me if this feature is related to my topic later, about tests like Map.isMap, and my initial reaction was "no" but now I've sort of come around to, they are kind of logically similar, in letting you check whether something really is something |
| 22:07 | <littledan> | jridgewell: Module blocks are like module specifiers, not namespace objects |
| 22:13 | <rbuckton> | If it was a _real_ ModuleSpecifier, you could do this... (though I'm unsure as to whether this is a good idea or not) |
| 22:13 | <rbuckton> | ``` |
| 22:13 | <rbuckton> | import { x } from module { |
| 22:13 | <rbuckton> | export const x = 1; |
| 22:13 | <rbuckton> | }; |
| 22:13 | <rbuckton> | ``` |
| 22:13 | <jridgewell> | I didn't realize you needed to import them. |
| 22:17 | <michaelficarra> | rbuckton: makes sense to me |
| 22:31 | <ljharb> | kind of seems like if we had `class.foo = bar` syntax we wouldn't have to use `this` |
| 22:33 | <shu> | i think ClassName suffices, still, kind of like kevin |
| 22:33 | <shu> | that was the conclusion from the subclassing hazard discussion |
| 22:34 | <shu> | it doesn't follow from that that we should *ban* `this`; i'm just saying ron's implication in the other direction that `this` is the natural way to assign static properties |
| 22:35 | <shu> | isn't that compelling |
| 22:36 | <ljharb> | i agree that repeating the class name is the status quo, and is "fine" |
| 22:36 | <ljharb> | but i also think repeating it sucks, and that's why i liked the `class.` proposal |
| 22:36 | <ljharb> | but we could go with "repeat the class name" here and still do `class.` later |
| 22:37 | <shu> | ah |
| 22:37 | <shu> | there are weird inconsistencies that cut both ways |
| 22:37 | <shu> | like Ron i feel _really_ strongly that vars shouldn't hoist out |
| 22:37 | <shu> | pls no |
| 22:38 | <Bakkot> | this is 50% idealogical and 50% a very practical concern that this straight-up doesn't work for half the code I wrote, which has `await` |
| 22:39 | <littledan> | I really think that this makes sense to treat like static field initializers |
| 22:39 | <littledan> | both in terms of scoping and ordering |
| 22:39 | <ljharb> | Bakkot: you write a lot of code that sets static properties on a class and uses `await`? |
| 22:39 | <Bakkot> | well, the proposal does not match filed initializers |
| 22:39 | <Bakkot> | ljharb of the code I wrote that sets static properties on a class, 50% uses initializers |
| 22:39 | <ljharb> | interesting, k |
| 22:39 | <Bakkot> | er |
| 22:39 | <Bakkot> | 50% uses await |
| 22:39 | <ljharb> | right |
| 22:39 | <littledan> | Bakkot: Well, it's fairly close; I'd prefer that it match entirely but I can buy the motivation for the changes |
| 22:39 | <Bakkot> | sorry, too many words going on |
| 22:40 | <ljharb> | what about this proposal doesn't match field initializers? |
| 22:40 | <Bakkot> | littledan this proposal is that static {} runs last, regardless of where it is relative to initializers |
| 22:40 | <littledan> | right, I'd be up for changing that |
| 22:40 | <Bakkot> | littledan fwiw the major upshot of this conversation is that I feel like static initializers should inherit the ability to `await` |
| 22:41 | <littledan> | well... I'm happy that we designed them to behave like little methods instead |
| 22:41 | <littledan> | that was a deliberate design |
| 22:41 | <Bakkot> | mostly to match regular fields |
| 22:41 | <Bakkot> | where it makes a lot of sense |
| 22:41 | <Bakkot> | makes much less sense for static methods |
| 22:41 | <Bakkot> | er, static initalizers |
| 22:43 | <ljharb> | Bakkot: notes, `a weight` should be `await` most often in the bot :-p |
| 22:45 | <rkirsling> | in a phrase like "allow a weight to carry over" you can hardly blame it lol |
| 22:45 | <ljharb> | lol true |
| 22:45 | <Bakkot> | ljharb I made that change a minute ago, just doesn't work if it ends up doing the post when it only has the `a` ready |
| 22:46 | <ljharb> | ah true |
| 22:46 | <littledan> | it was not underspecified. It has been specified as undefined the whole time |
| 22:46 | <littledan> | but the good thing is, the class features specs are all rebased and in great shape thanks to Ms2ger so this is more clear |
| 22:47 | <littledan> | you can see the spec at https://arai-a.github.io/ecma262-compare/?pr=1668 |
| 22:47 | <shu> | oh good |
| 22:47 | <shu> | allowing multiple interleaving blocks in order seems the most JS-y thing |
| 22:47 | <littledan> | (it = new.target in static field initializers) |
| 22:47 | <shu> | i see no good reason to limit to 1 |
| 22:47 | <littledan> | shu: +1 |
| 22:47 | <Bakkot> | would they interleave with static initalizers? |
| 22:47 | <Bakkot> | (presumably yes?) |
| 22:47 | <shu> | yes |
| 22:48 | <shu> | i think that's the point yes |
| 22:48 | <ljharb> | top-down order seems pretty important |
| 22:50 | <Bakkot> | oh god we've lost note taking |
| 22:54 | <Bakkot> | would `var`s be shared? |
| 22:54 | <Bakkot> | would they be visible to computed property names? |
| 22:54 | <ljharb> | i'd hope no |
| 22:58 | <shu> | Bakkot: yeah, i also hope each block would have its own var scope as the single initialized block does now |
| 23:04 | <littledan> | woohoo! |
| 23:06 | <rkirsling> | sorry, I'll help with notes tomorrow >_< |
| 23:29 | <Bakkot> | the bot's unedited output definitely has some of the character of gpt2 |
| 23:30 | <Bakkot> | where it's _almost_ coherent and _almost_ topical but it's also complete gibberish |
| 23:41 | <rkirsling> | hubs is way shinier than before |
| 23:41 | <rkirsling> | might just be a UI refresh but I like it |