| 15:21 | <devsnek> | bterlson: forcing people to fill out attendance to get the meeting link? :P |
| 15:21 | <devsnek> | i like it |
| 15:22 | <brad4d> | I only noticed the request for RSVP on the reflector mtg 77 issue this morning |
| 15:23 | <brad4d> | I've "watched" the repo now to hopefully avoid that in future |
| 15:23 | <brad4d> | someone mentioned an "event calendar" on that same thread |
| 15:23 | <brad4d> | where is that? I don't see anything in the how-we-work repo |
| 15:24 | <devsnek> | brad4d: https://github.com/tc39/Reflector/issues/290 |
| 15:25 | <brad4d> | thx |
| 16:40 | <rkirsling> | the link appears to be to edit the form itself and not to fill it out |
| 16:44 | <devsnek> | bterlson: how do i change my name to say (OpenJS Foundation) instead of (Guest) |
| 16:53 | <Bakkot> | devsnek do you not get an option to set your name when joining the meeting? |
| 16:53 | <devsnek> | I put in "Gus Caplan" |
| 16:54 | <devsnek> | it added the (Guest) |
| 16:54 | <devsnek> | > Ross Kirsling (Playstation) (Guest) |
| 16:55 | <ljharb> | i see some people with two "(Guest)"s |
| 16:55 | <ljharb> | and a few with none, including me, but i signed in as a guest |
| 16:55 | <ljharb> | chicoxyzzy: ooh, good move putting your notes abbreviations in your name |
| 16:55 | <devsnek> | you think its live account related? |
| 16:55 | <ljharb> | maybe |
| 16:55 | <rickbutton> | i did not sign in and i have (Guest) next to my name |
| 16:58 | <rkirsling> | I have Guest too |
| 16:58 | <rkirsling> | weird |
| 16:58 | <ljharb> | i left to change my name and now i'm sitting in the queue - i assume it's just manual? |
| 16:59 | <ljharb> | bterlson: ^ |
| 17:03 | <ljharb> | am i the only one still waiting to get in? |
| 17:03 | <ljharb> | nvm, i'm in |
| 17:04 | <littledan> | For the meeting scheduling, could we move custom numeric literals to after records and tuples + symbol as weakmap keys? |
| 17:04 | <apaprocki> | How do you actually get into the video conf? (Assuming teams is up) |
| 17:04 | <littledan> | I'm worried the latter two topics could run over time, and I'm fine with that time being cannibalized from custom numeric literals |
| 17:04 | <littledan> | (btw if there's someplace else I should make this request, let me know) |
| 17:05 | <Bakkot> | apaprocki https://github.com/tc39/Reflector/issues/288 links a google form you fill out to get the link |
| 17:05 | <Bakkot> | and then you click the link |
| 17:05 | <apaprocki> | Hm yeah I did that but didn’t get a mail |
| 17:05 | <Bakkot> | it doesn't send you mail |
| 17:05 | <Bakkot> | it just has the link on the page that results from clicking submit |
| 17:06 | <apaprocki> | Ah ok must have sped through it |
| 17:06 | <Bakkot> | apaprocki dm'd |
| 17:11 | <shu> | that delegates info form has Thursday after Friday |
| 17:11 | <devsnek> | horrifying https://gc.gy/62970054.png |
| 17:11 | <shu> | jinx |
| 17:11 | <devsnek> | lol 3 seconds |
| 17:13 | <littledan> | BTW what do people think of replacing first name/last name on the forms with just "name" next time? Not all cultures have a first name/last name split |
| 17:13 | <littledan> | this is actually something I previously raised to Ecma as something we should also avoid in forms |
| 17:13 | <bradleymeck> | just name is easier to manage i think anyway |
| 17:16 | <brad4d> | +littledan I agree, let's just ask for "name" |
| 17:16 | <ljharb> | +1 |
| 17:17 | <ljharb> | google "falsehoods programmers believe about names"; it's a great reference for those who haven't seen it :-) |
| 17:18 | <devsnek> | shout out to my friend whose legal name is er3in |
| 17:20 | <littledan> | what is this notify command? |
| 17:21 | <devsnek> | notify command? |
| 17:21 | <ljharb> | like the irc `/notify`? |
| 17:23 | <bterlson> | devsnek: can you tell me more? I've been researching this topic and it seems like most places don't let you have anything novel in names? |
| 17:23 | <bterlson> | I want to change my legal name to have a null character in the middle or a zwsp or something |
| 17:23 | <rkirsling> | is it 3 as in 'ayn? |
| 17:24 | <devsnek> | bterlson: born in the us. apparently her birth certificate was submitted on new years eve and not checked properly |
| 17:24 | <rkirsling> | omg |
| 17:24 | <drousso> | FYI, Microsoft Teams apparently has an option for "Turn off incoming video" if Microsoft Teams is eating your CPU/RAM for breakfast :) |
| 17:25 | <michaelficarra> | drousso: does that help? |
| 17:25 | <devsnek> | rkirsling: it was supposed to be silent but she goes by "erthreein" |
| 17:25 | <devsnek> | well pronounces it like that, still spells it er3in |
| 17:25 | <drousso> | michaelficarra it seems to have helped for me! but not sure if that was just circumstantial 😅 |
| 17:27 | <devsnek> | it would be cool to get some stats on the github pages specs |
| 17:27 | <michaelficarra> | drousso: I am trying it now |
| 17:27 | <michaelficarra> | it would be nice to have "just show video for person speaking" |
| 17:31 | <drousso> | michaelficarra FWIW (and you probably see this too), you can still see their shared screen |
| 17:35 | <ystartsev> | do we have beginners in the room who would appreciate simplifications of topics that are discussed? |
| 17:40 | <mpcsh> | ystartsev: I'd be interested, what form are you thinking that would take? |
| 17:40 | <ystartsev> | I (and others who are willing) would translate what is being discussed in a beginner friendly way |
| 17:41 | <ystartsev> | clear up any definitions |
| 17:41 | <ystartsev> | etc. |
| 17:41 | <littledan> | I can't get the /notify command working in irccloud. Does it work for anyone else? |
| 17:41 | <ystartsev> | littledan: hm, not working for me either |
| 17:41 | <ljharb> | hm, maybe freenode disabled it |
| 17:43 | <littledan> | could the chairs recommend another way to contact them? |
| 17:44 | <mpcsh> | ystartsev: yeah speaking for me, that'd be really helpful |
| 17:44 | <ljharb> | (looking into it; it might be irccloud and not freenode; if so i'll take it up with them) |
| 17:44 | <ljharb> | turns out it's `/notice` not `/notify` (sorry if your IRC client makes this intrusive) |
| 17:44 | <mpcsh> | ^ |
| 17:45 | <ljharb> | littledan: in case you missed that - `/notice` |
| 17:45 | <mpcsh> | ljharb: could you post the slides from your status update in the notes? |
| 17:45 | <ljharb> | sure |
| 17:45 | <littledan> | ah, thanks! |
| 17:46 | <littledan> | yeah, that worked I think |
| 17:48 | <ryzokuken> | sffc: I made a slideshow for the rounding behaviour PR and added it to the agenda separately but if we get consensus about it right here, I suppose we could save some time? |
| 17:49 | <devsnek> | seems not weird to me |
| 17:49 | <Bakkot> | link for that issue: https://github.com/tc39/proposal-smart-unit-preferences/issues/10 |
| 17:52 | <ryzokuken> | It only affects the default value behaviour on an edge case. |
| 17:54 | <ryzokuken> | sffc: littledan: thanks! |
| 17:56 | <mpcsh> | rwaldron: could you post the slides for the test262 status update in the notes? |
| 18:13 | <ystartsev> | mpcsh: i invited you to #tc39-beginners, i will try to do a constant stream in there |
| 18:13 | <mpcsh> | sweet! thank you! |
| 18:14 | <ystartsev> | anyone who wants to help people on board or whatever please feel free to join, also if you are new-ish or have definitions questions |
| 18:20 | <devsnek> | shu: strong agree with your comment there |
| 18:22 | <bnb> | can't hear waldemar at all |
| 18:22 | <ljharb> | is it just me, or is waldemar's audio garbled? |
| 18:22 | <shu> | was robotic |
| 18:23 | <leobalter> | same here |
| 18:23 | <michaelficarra> | whew, I thought it was just me at first |
| 18:23 | <devsnek> | that's how you know opus isn't being used |
| 18:45 | <Bakkot> | +1 waldemar |
| 18:49 | <haxjs> | Either side will surprise parts of people, so only syntax error could protect people |
| 18:51 | <ljharb> | the syntax error would probably surprise a lot more people than one of the choices, tho |
| 18:53 | <haxjs> | At least it will tell them it may be not behave like u think |
| 18:54 | <rkirsling> | sorry for the "proposer with weak opinion" bit :p |
| 18:55 | <Bakkot> | direct eval is enough of a power-user feature that I think we can not worry about people who are specifically intending to get direct eval with new syntax being surprised by it not working |
| 18:55 | <haxjs> | And eval?.() actually have no solid use cases. so we'd better ban it |
| 18:57 | <shu> | is there a PR or issue for this item? where is it on the agenda? |
| 18:58 | <haxjs> | @shu https://github.com/tc39/ecma262/issues/2062 |
| 18:58 | <shu> | no, not that one |
| 18:58 | <shu> | the one leo is presenting right now |
| 18:58 | <michaelficarra> | shu: way at the bottom of the agenda |
| 18:58 | <michaelficarra> | https://github.com/tc39/ecma262/issues/2090 |
| 18:58 | <shu> | ah thanks |
| 18:58 | <michaelficarra> | https://github.com/tc39/proposal-numeric-separator/issues/49 |
| 19:01 | <michaelficarra> | what is the etiquette around muting someone who is making noise and doesn't seem to know they are unmuted? |
| 19:03 | <bterlson> | I mute aggressively, personally. |
| 19:04 | <bterlson> | anyone happier with teams this time around? There have been a few updates since last meeting... |
| 19:05 | <ljharb> | bterlson: the biggest problem for me is that (on iOS at least) it's impossible to change which 4 people i'm looking at. i can't hide "folks with no video" nor can i scoot it through the list |
| 19:06 | <haxjs> | Is there way to show the name of speaker in teams? |
| 19:33 | <leobalter> | bterlson: Teams are still going to town with the CPU usage if I use it as a native app on Mac OS |
| 19:33 | <leobalter> | I see myself forced to use the browser version, which is not problematic |
| 19:48 | <rkirsling> | let's see how Teams deals with me building JSC on the same machine |
| 19:49 | <rkirsling> | ystartsev: yeah you can say it continues from where the Berlin presentation left off, maybe? |
| 19:54 | <brad4d> | There some uncertainty in the last meeting regarding whether internal slots with non-primitive values pose a problem to avoid. |
| 19:54 | <brad4d> | Was some resolution reached around that? |
| 19:55 | <brad4d> | I believe someone said they would ask MM to present his views on this. |
| 19:55 | <brad4d> | but I didn't see that when I skimmed through the agenda. |
| 19:55 | <ystartsev> | brad4d: yes |
| 19:56 | <ystartsev> | there was, there are two items on the agenda related to this |
| 19:56 | <ystartsev> | "documenting intrinsics" and "specific intrinsics |
| 19:56 | <ystartsev> | i don't know if we will get to them |
| 19:56 | <ystartsev> | but the short story is that ses group dropped it's objection afaik |
| 19:57 | <brad4d> | do you mean "documenting invariants"? |
| 19:57 | <jridgewell> | There's a small write up on the Intl docs |
| 19:57 | <ystartsev> | gah |
| 19:57 | <ystartsev> | sorry |
| 19:57 | <ystartsev> | _invariants_ in both cases |
| 19:57 | <jridgewell> | https://github.com/tc39/proposal-intl-segmenter/issues/96#issuecomment-661008571 |
| 19:57 | <brad4d> | shiny, thx for clarifying |
| 19:58 | <robpalme> | starting in 3 mins |
| 20:07 | <brad4d> | Does "NonOctal" specifically mean "starts with a 0, but isn't an octal?" rather than just "not an octal"? |
| 20:07 | <rkirsling> | brad4d: yeah |
| 20:08 | <devsnek> | its a very scary part of js |
| 20:08 | <rkirsling> | it's specifically when 8 or 9 pulls a switcheroo in an otherwise octal context |
| 20:08 | <rickbutton> | bterlson: mic might be accidentally unmuted |
| 20:08 | <rkirsling> | abbreviated "noctal" |
| 20:08 | <devsnek> | i'm excited that the rewrite of engine262 doesn't include legacy octals at all |
| 20:08 | <rkirsling> | (because it's catchy, I assume) |
| 20:09 | <rkirsling> | devsnek: doesn't that translate to "I'm excited that engine262 doesn't implement the whole spec" though |
| 20:09 | <devsnek> | annex b? |
| 20:09 | <Bakkot> | we have consensus to pull the non-regex/html comments part of annex B into the main spec |
| 20:09 | <Bakkot> | editors are just busy with other stuff |
| 20:09 | <devsnek> | if someone moves it out of annex b i will be very excited to implement it |
| 20:09 | <Bakkot> | there is so much editorial work to be done |
| 20:10 | <Bakkot> | ooh, I am excited for this presentation |
| 20:10 | <rkirsling> | devsnek: ahh okay |
| 20:10 | <rickbutton> | Bakkot: same! |
| 20:10 | <devsnek> | also excited for this pres |
| 20:10 | <rkirsling> | yay let's get cognitive |
| 20:10 | <rkirsling> | 🧠 |
| 20:10 | <shu> | i'm not used to using my brain on the job |
| 20:10 | <devsnek> | lol |
| 20:12 | <michaelficarra> | we've actually made a lot of progress reducing this "secret language" over the years lol, it used to be sooooo esoteric |
| 20:12 | <devsnek> | this is where we learn tc39 is a programming language design noob |
| 20:13 | <rkirsling> | michaelficarra: yeah I feel like those particular examples are at least "it means what you think it means" |
| 20:13 | <rkirsling> | :) |
| 20:14 | <michaelficarra> | to be clear, I'm not trying to say we don't have plenty of examples of "secret language" today, just that they used to be worse and more common |
| 20:14 | <Bakkot> | yeah |
| 20:14 | <Bakkot> | also we started writing them down: https://github.com/tc39/how-we-work/blob/HEAD/terminology.md |
| 20:15 | <shu> | "worth its own weight" is a general english idiom IME, right? |
| 20:15 | <rickbutton> | ^ yes, but what "weight" means in this context is complicated |
| 20:15 | <michaelficarra> | I love this use of "viscosity" |
| 20:15 | <rickbutton> | (is my take) |
| 20:16 | <rkirsling> | michaelficarra: +1 |
| 20:16 | <shu> | it is interesting that it's called viscosity instead of liquidity |
| 20:16 | <rkirsling> | heh, guess that's a question of vantage point |
| 20:16 | <devsnek> | shu: i guess its whether you're thinking of "worth the pros" vs "worth the cons" |
| 20:17 | <shu> | devsnek: right: https://en.wikipedia.org/wiki/Markedness |
| 20:17 | <rkirsling> | I guess JS tends to have a viscosity level resembling molasses |
| 20:17 | <ljharb> | lol i've found the opposite |
| 20:18 | <haxjs> | “ viscosity” is really a secret language itself |
| 20:19 | <devsnek> | js has the viscosity of helium |
| 20:19 | <Bakkot> | i would say I find it easier to make changes in small JS programs than in e.g. Java, but usually harder to make large changes |
| 20:19 | <shu> | oooh no CDN is a terrible acronym |
| 20:19 | <rkirsling> | oh noo it's an overload for CDN |
| 20:19 | <rickbutton> | Cognitive Delivery Network |
| 20:19 | <michaelficarra> | rkirsling: I can see it both ways, typed FP languages are really rigid, but they also guide your hand when refactoring |
| 20:19 | <Bakkot> | yeah that's basically my experience |
| 20:19 | <Bakkot> | not just FP |
| 20:20 | <rkirsling> | I wonder if I misunderstood the term then |
| 20:20 | <rkirsling> | vs. malleability / rigidity |
| 20:20 | <rickbutton> | yeah it depends on whether you define viscosity as "ease of making local changes" or "ease of making changes that satisfy some constraint, correctness, or type soundness, etc" |
| 20:22 | <michaelficarra> | omg I love the idea to enumerate our language design guidelines |
| 20:22 | <rkirsling> | michaelficarra: we've had the rationale repo for a long time, it's just been really hard to get off the ground |
| 20:23 | <shu> | michaelficarra: i'm skeptical of utility, because i don't think we can really whittle them down |
| 20:24 | <michaelficarra> | shu: it doesn't need to be 100%, just a "checklist" as Felienne puts it, of things we should consider |
| 20:24 | <rkirsling> | yeah, like "these are the battles one often needs to fight" |
| 20:25 | <rkirsling> | er like "the perspectives one would want to have arguments toward" |
| 20:25 | <rkirsling> | ohh wow I thought it was viscosity of *design* |
| 20:26 | <rkirsling> | not of *use* |
| 20:26 | <rkirsling> | my bad |
| 20:27 | <devsnek> | i love that this is called a "maneuver" |
| 20:28 | <ljharb> | ystartsev: "a double equals b" |
| 20:28 | <ljharb> | or "a triple equals b" |
| 20:29 | <michaelficarra> | "abstract equality" and "strict equality" |
| 20:29 | <ljharb> | "abstractly equal" and "strictly equal" don't roll off the tongue nearly as well to me :-p |
| 20:30 | <devsnek> | "equal" and "eichwal" |
| 20:30 | <michaelficarra> | I don't think the spec-internal names are any worse than "double/triple equals" lol |
| 20:30 | <haxjs> | triple equal actually not strict enough (+0, -0, NaN) :-) |
| 20:30 | <ljharb> | double/triple is how it's already colloquially spoken aloud |
| 20:30 | <ljharb> | devsnek: eichwal, wow |
| 20:30 | <michaelficarra> | haxjs: SameValue |
| 20:30 | <devsnek> | ljharb: i know i'm very proud |
| 20:32 | <rkirsling> | that's amazing |
| 20:32 | <haxjs> | I really hope we can have a Truely Strict equal ... maybe `a is b` which use `Object.is` semantic |
| 20:32 | <rkirsling> | eichwal would be == though, yeah? |
| 20:33 | <rickbutton> | "equal" and "typo: you forgot a =" operators |
| 20:33 | <rkirsling> | devsnek: also can you tweet that so that I can RT it without taking credit from you |
| 20:34 | <devsnek> | lol |
| 20:36 | <devsnek> | rkirsling: one sec, putting into drake meme format |
| 20:36 | <jridgewell> | Can we mute Caio? |
| 20:37 | <mpcsh> | is anyone else finding WH's language on this topic uncomfortably aggressive? |
| 20:37 | <bradleymeck> | can delegates not talk in #tc39-editor-group ? |
| 20:38 | <mpcsh> | I was not aware of that channel |
| 20:38 | <michaelficarra> | bradleymeck: I think you should be able to |
| 20:38 | <littledan> | mpcsh: Yes, I agree |
| 20:38 | <ystartsev> | I also agree |
| 20:38 | <mpcsh> | bradleymeck: oh sorry, I thought you were responding to me and saying that discussion was happening in that channel |
| 20:39 | <michaelficarra> | rickbutton: if I wanted to stop using `x == null`, would I start using `!!(x ?? !0)`? |
| 20:39 | <mpcsh> | "you've actually made it worse" was particularly unacceptable to me |
| 20:40 | <mpcsh> | ditto "[the definitions] are unusably fuzzy" |
| 20:40 | <rickbutton> | michaelficarra: `/null|undefined/.test(x)` is the only valid way going forward |
| 20:41 | <michaelficarra> | rickbutton: doesn't that fail for "null"? |
| 20:41 | <rickbutton> | yes :P i was joking |
| 20:41 | <bradleymeck> | michaelficarra: i don't appear to be able to mmm |
| 20:42 | <michaelficarra> | bradleymeck: I see you in there |
| 20:42 | <bradleymeck> | michaelficarra: can't send messages |
| 20:42 | <michaelficarra> | ooohh |
| 20:42 | <rickbutton> | our linter rules disable == in all cases, and our style guide suggests checking for null and undefined explicitly, but really the callee should only return one or the other, not both, and should be documented |
| 20:43 | <ljharb> | most common linter configs disable `==` except when it's `== null`, fwiw |
| 20:43 | <michaelficarra> | the only thing I use `==` for is `== null` |
| 20:43 | <rickbutton> | I don't really have a strong opinion either way, if I read `== null` i will know what it means |
| 20:43 | <ljharb> | put another way, i don't know any common linter configs that allow `==` for anything non-null |
| 20:46 | <haxjs> | really hope we fixed == as JS 1.2 :-P |
| 20:50 | <michaelficarra> | ljharb: how about "equal-equal" and "equal-equal-equal" for names? |
| 20:50 | <ljharb> | we shorten "2 and 2 and 2" to "2 cubed" so why not shorten those to double and triple :-p |
| 20:51 | <haxjs> | so we will face the typo problem for eq-eq and eq-eq-eq just like == vs === :-P |
| 20:52 | <rkirsling> | trying to pronounce eq-eq-eq reminds me of the Knights of Ni |
| 20:52 | <michaelficarra> | ljharb: "2 and 2 and 2" is 6 |
| 20:52 | <ljharb> | oh lol sorry, wasn't paying full attention |
| 20:53 | <michaelficarra> | 🙃 |
| 20:56 | <ljharb> | robpalme: update the queue? |
| 20:58 | <Bakkot> | bradleymeck you had that proposal for `private` decls outside of class bodies, yeah? |
| 20:59 | <Bakkot> | is that still live? |
| 20:59 | <bradleymeck> | Bakkot: jridgewell I believe is still handling it |
| 20:59 | <Bakkot> | cool, same question to jridgewell |
| 20:59 | <bradleymeck> | i just wanted to find someone to do it |
| 21:06 | <shu> | whoa, new VariableEnvironment, hm |
| 21:06 | <Bakkot> | feel weird about that a bit |
| 21:06 | <shu> | very weird |
| 21:06 | <Bakkot> | would prefer disallowing `var` maybe |
| 21:07 | <devsnek> | just don't do anything with var |
| 21:07 | <shu> | any concerns with letting them hoist? |
| 21:07 | <jridgewell> | Yes, it's still alive |
| 21:07 | <devsnek> | ya just let it hoist |
| 21:07 | <Bakkot> | ehh... class is kind of a function boundary is the reason I assume |
| 21:07 | <jridgewell> | But waiting for Class Fields to land before I bring it back. |
| 21:07 | <shu> | the constructor is a function boundary |
| 21:07 | <shu> | the "static part" is also? |
| 21:07 | <shu> | i don't have that intuition in any sense |
| 21:07 | <devsnek> | same |
| 21:08 | <devsnek> | someone should get on the queue |
| 21:08 | <Bakkot> | I think that doesn't need to be solved at this stage |
| 21:08 | <Bakkot> | but worth bringing up if you care a bunch I guess |
| 21:08 | <Bakkot> | shu well it changes the scoping of `this` |
| 21:08 | <Bakkot> | which is a lot like being a function boundary |
| 21:09 | <devsnek> | this being different is also weird |
| 21:09 | <shu> | Bakkot: interesting, would need to stew on that |
| 21:09 | <shu> | Bakkot: that seems better solved to me as requiring to use class name itself, unbind this, so i can think of the static block as a run-once, well, block |
| 21:09 | <shu> | but maybe i'm missing something |
| 21:10 | <shu> | i suppose consistency with field initializers, but those are the odd ones out in my mind |
| 21:10 | <devsnek> | i don't get why those need `this` either |
| 21:12 | <Bakkot> | instances fields definitely do |
| 21:12 | <devsnek> | static field initializers |
| 21:13 | <ljharb> | it's nice to not have to repeat the class name |
| 21:13 | <devsnek> | within the context of static it is weird to bring `this` into it |
| 21:13 | <devsnek> | imo |
| 21:13 | <ljharb> | i'd prefer "class access expressions" over using `this` tho |
| 21:13 | <devsnek> | is that the uh |
| 21:13 | <devsnek> | `class.x` thing |
| 21:13 | <ljharb> | yeah |
| 21:14 | <devsnek> | +1 on that |
| 21:14 | <devsnek> | since that proposal exists i don't see a point in binding `this` |
| 21:15 | <ljharb> | it doesn't exist yet tho |
| 21:15 | <devsnek> | what doesn't exist yet |
| 21:15 | <Bakkot> | that proposal has not advanced |
| 21:15 | <Bakkot> | to stage 4 |
| 21:15 | <devsnek> | yeah |
| 21:15 | <ljharb> | right. it's still stage 1 iirc |
| 21:16 | <ljharb> | if it was stage 4, then i'd have wanted static class fields to not have `this` available either |
| 21:16 | <devsnek> | i'm saying we should recognize the value of that here instead of hacking it in with `this` |
| 21:16 | <ljharb> | but since static class fields already bind the `this` i think it'd be very weird for static blocks not to |
| 21:16 | <bradleymeck> | class.this.* is > than class.* |
| 21:16 | <ljharb> | lol |
| 21:16 | <bradleymeck> | not even joking |
| 21:16 | <ljharb> | i don't understand |
| 21:16 | <devsnek> | isn't that just `class.*` |
| 21:16 | <haxjs> | what is class.this? |
| 21:17 | <ljharb> | `class.` is supposed to be a way to reference the current class constructor |
| 21:17 | <ljharb> | so like, `class C { static x() { return class.x === C.x; } } C.x() // true` |
| 21:17 | <ljharb> | you're suggesting `class.this.x`? |
| 21:17 | <haxjs> | I mean what is `class.this` , it should be `this` property on the class? |
| 21:17 | <bradleymeck> | devsnek: except it leaves space for any other meta-properties we may want |
| 21:18 | <ljharb> | `class.this` definitely should be the "this" property on the class |
| 21:18 | <ljharb> | bradleymeck: what else would we want tho? the class is the constructor, conceptually |
| 21:18 | <ljharb> | `class.#x` would work too, i assume |
| 21:19 | <bradleymeck> | decorator stuff, exposing other things that aren't obvious (heritage?) |
| 21:19 | <devsnek> | heritage is Object.getPrototypeOf(class) |
| 21:19 | <bradleymeck> | not if you don't use extends |
| 21:20 | <devsnek> | then its not real heritage |
| 21:20 | <devsnek> | and not our problem |
| 21:20 | <bradleymeck> | it still inherits XD |
| 21:20 | <bradleymeck> | we can argue about various possible futures, but if i got some time i could probably ramble on with ideas of things i might want to store |
| 21:20 | <devsnek> | if we want it to be static constructor why not just `static constructor` |
| 21:21 | <ljharb> | bradleymeck: `class.@decoratorStuff` |
| 21:21 | <devsnek> | oh i guess that overrides the constructor property |
| 21:21 | <devsnek> | sigh |
| 21:21 | <devsnek> | anyway if that's the goal it should be a lot clearer |
| 21:22 | <haxjs> | Could we use `static.x` syntax instead of `class.x` ? |
| 21:23 | <ljharb> | we could, but i don't see why that'd be clearer |
| 21:23 | <ljharb> | haxjs: what's the advantage to using `static.`? |
| 21:23 | <haxjs> | mapping to static declaration I think. |
| 21:24 | <shu> | rbuckton: maybe my concern can be addressed by simply changing the name of the feature to "static constructor" |
| 21:24 | <ljharb> | haxjs: worth filing on https://github.com/tc39/proposal-class-access-expressions |
| 21:24 | <shu> | and communicating it both inside and outside of committee using that, while keeping the block syntax |
| 21:25 | <devsnek> | using a function syntax would be interesting |
| 21:26 | <rbuckton> | shu: I named it based on its syntax, I was worried calling it `static constructor` would be possibly confusing because `static constructor () {}` is legal: https://usercontent.irccloud-cdn.com/file/tEbveTEq/image.png |
| 21:27 | <Bakkot> | this is one of the most arcane parts of the web platform |
| 21:27 | <Bakkot> | hope y'all are paying attention |
| 21:27 | <devsnek> | this is all i think about |
| 21:28 | <devsnek> | rbuckton: `static #constructor`? |
| 21:28 | <devsnek> | maybe too much magic |
| 21:29 | <haxjs> | @ljharb filed https://github.com/tc39/proposal-class-access-expressions/issues/3 |
| 21:29 | <rbuckton> | Not a big fan of `static #constructor`, a lot to write, hard to remember, and too easy to do the wrong thing and forget the `#` |
| 21:30 | <ljharb> | haxjs: ty |
| 21:30 | <devsnek> | rbuckton: yeah idk, i would be on board with the static constructor idea if it was clearer that it was like a function |
| 21:30 | <Bakkot> | also static blocks have precedent in languages like e.g. Java |
| 21:30 | <Bakkot> | I prefer using the same syntax for things where it makes sense to do so |
| 21:31 | <devsnek> | like even if we did getter style syntax `static ( ) Block` sort of thing |
| 21:31 | <haxjs> | What will happen if have multiple static block? |
| 21:31 | <devsnek> | if its not a function i don't think it should do function things |
| 21:31 | <devsnek> | haxjs: i assumeearly error like multiple constructors |
| 21:32 | <Bakkot> | the presentation said early error |
| 21:33 | <haxjs> | Java seems allow multiple static block |
| 21:33 | <rbuckton> | The problem with `static.x` is that `static` isn't a reserved word, so we could break existing code. |
| 21:33 | <ljharb> | ah right |
| 21:33 | <haxjs> | rbuckton static is reserved word in strict mode, and class code is strict |
| 21:34 | <rbuckton> | ``` |
| 21:34 | <rbuckton> | let static = 1; |
| 21:34 | <rbuckton> | class C { |
| 21:34 | <rbuckton> | static { |
| 21:34 | <rbuckton> | static; // 1 or `this`? |
| 21:34 | <rbuckton> | } |
| 21:34 | <rbuckton> | } |
| 21:34 | <rbuckton> | ``` |
| 21:34 | <ljharb> | `static` by itself would be 1 |
| 21:34 | <devsnek> | static in a class body is a reserved word |
| 21:34 | <ljharb> | but if `let static = { x: 1 };` then `static.x` would be the question |
| 21:34 | <Bakkot> | fwiw I like `this` a lot better than this new syntax |
| 21:34 | <ljharb> | devsnek: so `x = static.y;` is invalid? |
| 21:35 | <haxjs> | not valid in class |
| 21:35 | <devsnek> | ljharb: yes |
| 21:35 | <ljharb> | hm |
| 21:35 | <devsnek> | static is a reserved word in strict mode |
| 21:35 | <rbuckton> | I guess `static` is reserved in strict, but still it feels weird to reuse it. |
| 21:35 | <devsnek> | and class bodies are strict |
| 21:35 | <mpcsh> | how can we ensure that people use the queue? it's highly disruptive and burdensome on the notetakers when people interrupt a presentation for what should be entered as a clarifying question on the queue. WH has done this twice today, despite my earlier reminder to use the queue after the first instance. |
| 21:35 | <devsnek> | that being said |
| 21:35 | <devsnek> | i don't like using `static` for this |
| 21:35 | <devsnek> | +1 for `class` |
| 21:35 | <rbuckton> | Neither do I. I proposed `class.x` because there would be no ambiguity |
| 21:36 | <ljharb> | +1 |
| 21:37 | <rbuckton> | Well, that's it for me this TC39, I won't be available for the rest of it. Thanks all |
| 21:37 | <bterlson> | rbuckton: thank you sir :) |
| 21:38 | <devsnek> | bradleymeck: could you bind the function constructor or eval with the first argument being the string |
| 21:39 | <wsdferdksl> | mpcsh: Please stop the personal attacks |
| 21:41 | <mpcsh> | wsdferdksl: (assuming this is Waldemar) I didn't realize you were on IRC, will send a DM |
| 21:44 | <devsnek> | shu: mark is saying if the base is null, delegate to the surrounding realm |
| 21:46 | <devsnek> | s/base/referencingScriptOrModule/ |
| 21:47 | <shu> | devsnek: i understood mark as saying delegate to the [[Realm]] that the eval came from |
| 21:47 | <ryzokuken> | a second please |
| 21:47 | <bradleymeck> | devsnek: thats unclear as the behavior seems to call the hook with the execution context that is enqueueing the job |
| 21:47 | <devsnek> | an indirect eval should have the correct realm |
| 21:48 | <devsnek> | shu: that would be the active realm afaik |
| 21:49 | <shu> | devsnek: question is what if it itself doesn't have an active script? |
| 21:49 | <devsnek> | at that point it is html's problem right? you have a realm that came from some page |
| 21:50 | <devsnek> | the specificity is "the entire page" |
| 21:52 | <shu> | it's not html's problem |
| 21:52 | <shu> | i mean it is, but it needs JS to tell it when to do the capture |
| 21:52 | <shu> | which is what this is |
| 21:52 | <shu> | bradleymeck: i am pretty sure incumbents are not polyfillable |
| 21:52 | <devsnek> | given the active realm doesn't that give you the correct incumbent |
| 21:52 | <ljharb> | i wouldn't expect any host hook things to be polyfillable atm |
| 21:52 | <ljharb> | you can't polyfill the unhandled rejection hook either |
| 21:53 | <shu> | bradleymeck: the backup incumbent stack, that is, nor the active script check for dynamic import() base url |
| 21:53 | <shu> | bradleymeck: the question to you is why is that a goal? |
| 21:53 | <bradleymeck> | ljharb: the problem is that if you polyfill Promise.prototype.finally it won't match a native impl ever |
| 21:53 | <ljharb> | bradleymeck: that's already true, because of `await` |
| 21:54 | <ljharb> | well, i guess since it calls into a native `.then`, it'd work fine |
| 21:54 | <shu> | bradleymeck: that's a different problem, which is HTML's implementation of the hook isn't polyfillable, and therefore you can't polyfill a perfect replica of one integrated with HTML |
| 21:54 | <bradleymeck> | ljharb: it would be relative to the polyfill not the document from my understanding |
| 21:54 | <ljharb> | bradleymeck: but in a host where there's no unhandled rejection behavior, it's not possible to provide that behavior |
| 21:54 | <ljharb> | bradleymeck: oh sorry i'm talking about unhandled rejections; not this one |
| 21:55 | <ljharb> | bradleymeck: i'm trying to claim that it's not a reasonable expectation to be able to polyfill any host hook |
| 21:55 | <bradleymeck> | shu: sure, but i'm just coming from node's perspective not purely HTML |
| 21:55 | <bradleymeck> | and the behavior isn't necessarily problematic, but very unexpected |
| 21:55 | <bradleymeck> | and that makes me not want to move forward on my level of review for this meeting |
| 21:56 | <bradleymeck> | if it just errored instead of resolving against the user code that is acting like native code, that seems fine |
| 21:56 | <shu> | what errors? i am confused |
| 21:56 | <devsnek> | alright we have four minutes to push monads through |
| 21:56 | <shu> | like the proposal is to add a host hook that by default is a nop, not to add any specific behavior |
| 21:57 | <bradleymeck> | shu: correct, and I am unclear on why we would ever want to have the expected usage of the hook behavior |
| 21:57 | <bradleymeck> | the expected behavior seems to misalign with my expectations |
| 21:57 | <devsnek> | shu: i don't get why %eval%.[[Realm]] isn't the correct realm |
| 21:57 | <bradleymeck> | i do want to fix the code example, but the solution seems off |
| 21:58 | <shu> | bradleymeck: because the web already works this way for all web APIs, and firefox already works this way for Promises, and i want to reflect that reality in the spec instead of stringing together willful violations |
| 21:58 | <shu> | bradleymeck: i'm fairly confident there isn't a significantly cleaner way to layer this |
| 21:58 | <ryzokuken> | sorry for the technical issues, everyone. My computer seems to be really acting up today but I'm avoiding a restart because kernel updates 😅 |
| 21:58 | <bradleymeck> | shu: I'd agree but I don't really want hosts to diverge here and thats what the hook is encouraging |
| 21:58 | <devsnek> | ryzokuken: was fine tbh |
| 21:58 | <ryzokuken> | devsnek: thanks |
| 21:59 | <ryzokuken> | also, i hate pulseaudio |
| 21:59 | <ryzokuken> | but yes |
| 21:59 | <bradleymeck> | shu: in part because, it is soo edge casey already, does it even need to be fixed? |
| 22:00 | <bradleymeck> | do newer web APIs even have this behavior or are we trying to align with what is considered bad practice these days |
| 22:00 | <shu> | bradleymeck: yes, if you use WebIDL you basically have this behavior |
| 22:00 | <shu> | bradleymeck: it needs to be fixed largely because HTML folks feel strongly that finalizers and promises should align with WebIDL here |
| 22:00 | <shu> | and i'd rather give them a clean point than willful violations |
| 22:01 | <shu> | firefox especially feels that finalizers and promises should track incumbents |
| 22:01 | <bradleymeck> | shu: i'm not really sure how user code or node could align with that |
| 22:01 | <shu> | bradleymeck: they don't, that's why it's a host hook |
| 22:01 | <shu> | full virtualizability is not a goal |
| 22:01 | <shu> | i understand you might desire that, but that's not true today |
| 22:01 | <bradleymeck> | shu: node doesn't need virtualizability |
| 22:01 | <shu> | sorry i was responding to the "how user code could align with that" |
| 22:01 | <bradleymeck> | shu: just the host itself seems to be against this pattern |
| 22:02 | <shu> | node COULD align with it by providing some privileged API that's like "capture incumbent" |
| 22:02 | <bradleymeck> | we have no such existing APIs, and that seems very odd to me |
| 22:02 | <shu> | do you have a rejection handler API, right? |
| 22:02 | <shu> | err, s/right// |
| 22:02 | <bradleymeck> | yes |
| 22:03 | <shu> | this would be along those lines if it was important to capture the backup incumbent stack behavior |
| 22:03 | <bradleymeck> | i don't understand that last sentence |
| 22:04 | <shu> | if it was important for node to capture the backup incumbent settings object stack behavior that HTML exhibits, then node could expose an API like "capture incumbent" and "restore incumbent" along the same lines of the already-provided rejection handler API |
| 22:05 | <bradleymeck> | i am unclear on what we need to capture, we already get the hook via the realm. I don't think stating everything related to "backup" + "incumbent" + (the settings object) is helping |
| 22:06 | <bradleymeck> | i'm familiar with settings and have some understanding of incumbent |
| 22:06 | <shu> | i tried to abstract all of that away with a notion of "some ambient state at the point of passing a callback to an API that eventually schedules the job" but that's even harder to talk about, i guess |
| 22:06 | <bradleymeck> | but none of this seems to align with my understanding of how this hook is supposed to enable a use case except for a very specific things for HTML and cause other hosts to have potentially drastic differences in how import() works |
| 22:07 | <shu> | ah, is that the actual concern, for import() divergence? |
| 22:07 | <bradleymeck> | shu: i think as long as we can align on what wouldn't cause node libs to require themselves to use privileged APIS and manage their own contexts it would be fine |
| 22:07 | <bradleymeck> | shu: yes |
| 22:07 | <bradleymeck> | i think mark's is around grabbing the data from the execution context itself |
| 22:07 | <bradleymeck> | which seems... bad to me |
| 22:08 | <bradleymeck> | but not fatal |
| 22:08 | <shu> | bradleymeck: do you have time to try to work through that right now? |
| 22:08 | <bradleymeck> | nope, gotta feed a kid |
| 22:08 | <shu> | k, let me schedule something for later then |
| 22:08 | <bradleymeck> | k |
| 22:16 | <shu> | devsnek: as for why eval's [[Realm]] wouldn't work, please read through the convoluted examples in https://html.spec.whatwg.org/#incumbent |
| 22:17 | <devsnek> | shu: I was looking through them, I don't get why it wouldn't |
| 22:18 | <shu> | the last one, with iframes |
| 22:18 | <shu> | you could schedule a Promise.resolve('import("whatever")').then(otherFrame.eval) |
| 22:18 | <shu> | the incumbent should still be yourself |
| 22:20 | <devsnek> | shu: I think the point was in that case it should be the other frame |
| 22:21 | <shu> | what do you mean "it should"? |
| 22:21 | <devsnek> | idk, a value judgement |
| 22:21 | <shu> | that behavior is not up for debate, it is what it is today |
| 22:22 | <devsnek> | only in firefox though right? |
| 22:22 | <shu> | no, for all web APIs (setTimeout) in all browsers, and for Promises only in Firefox |
| 22:23 | <shu> | so the question is, if we refuse to add these hooks to ecma262, there'll always be this corner case that makes Job-queuing APIs in ecma262 different from those that use WebIDL |
| 22:24 | <shu> | that's one outcome |
| 22:24 | <shu> | but there's no outcome where we, as tc39, can legislate the behavior away |
| 22:24 | <devsnek> | as long as promises observably stay the same, html can say they do additional things right? |
| 22:25 | <shu> | i don't understand what you mean by "observably stay the same" |
| 22:26 | <devsnek> | like can't it just say "insert this logic" |
| 22:26 | <devsnek> | that's not violating ecma262 |
| 22:26 | <shu> | insert this logic in the middle of two algorithmic steps in a builtin? |
| 22:26 | <devsnek> | I guess something like that, yeah |
| 22:27 | <shu> | technically it can do whatever it wants, but myself, as a 262 editor, and the html editors, want a well understood, structured way to interface the specs |
| 22:27 | <shu> | thus host hooks |
| 22:27 | <shu> | this is not a question of expressivity. willful violations are also possible |
| 22:27 | <devsnek> | yeah it just seems like a very undesirable behaviour we wouldn't want to encourage |
| 22:28 | <devsnek> | I'm not expressly against the hooks |
| 22:28 | <shu> | i lament that we will intentionally create a harder to read document because of a lack of real argument |
| 22:28 | <shu> | i don't get this encouraging point |
| 22:28 | <shu> | you can almost do whatever you want with the module specifier right now |
| 22:28 | <shu> | but you weren't primed with that whatever's done right now is "weird and arcane" |
| 22:29 | <devsnek> | like within the design of the language you'd want the "context" to be determined by the eval, not where the string was written |
| 22:29 | <devsnek> | maybe that's what mark meant by dynamic scope |
| 22:29 | <shu> | that is what he's meant, but it's also not up to him or tc39 to decide, because that weirdness is already here with setTimeout |
| 22:29 | <shu> | or at least i also believe that's what he meant |
| 22:29 | <shu> | also it's not where the string is written, it's where the eval was passed |
| 22:32 | <devsnek> | theoretically what happens if js stuff determines the incumbent differently |
| 22:32 | <shu> | what does that mean, it provides a different default implementation than no-op? |
| 22:33 | <devsnek> | differently from setTimeout |
| 22:33 | <shu> | theoretically nothing happens because theoretically there is no default implementation of job scheduling and running |
| 22:34 | <devsnek> | I mean what if it works like not firefox |
| 22:35 | <shu> | then patterns like passing `postMessage.bind(whatever)` into Promise#then will behave differently from passing it into setTimeout |
| 22:35 | <shu> | a rare gotcha |
| 22:35 | <shu> | it is also possible that HTML and browsers decide, well, we'll just do the behavior anyways without host hooks |
| 22:36 | <shu> | in which case both will work the same but the specs will unfortunately obscure this fact |
| 22:36 | <devsnek> | you could say all new APIs do the active realm trick and timers are the exception |
| 22:37 | <shu> | but it's not just all setTimeout, it's *all* WebIDL that takes callbacks |
| 22:37 | <shu> | and you could say that, but does that serve the web dev better than aligning? |
| 22:37 | <shu> | i haven't heard a good argument that it does |
| 22:37 | <devsnek> | I guess I'm having trouble imagining when any of these options provide any use to a web dev anyway |
| 22:39 | <shu> | fair, but having complete interop semantics is the general strength of the web platform, and i'd like to keep that |
| 22:42 | <devsnek> | I assume the web breaks if you change webidl to use the builtin function's realm |
| 22:42 | <devsnek> | for everything |
| 22:45 | <shu> | that's the assumption |
