| 05:00 | <Rob Palmer> | As mentioned in yesterday's meeting, July's meeting is confirmed as our first hybrid meeting in over two years. Meaning you can attend in-person if you wish. The Reflector now has the July plenary invite, which includes a registration form that anyone who plans to attend in-person must complete. |
| 05:37 | <bakkot> |
|
| 05:51 | <Rob Palmer> | I have asked Patrick to create an Ecma-approved doodle. He normally does that part. |
| 08:44 | <Rob Palmer> | The Doodle is live. |
| 09:40 | <ryzokuken> | Could someone with edit access to the calendar remove the event today? |
| 12:06 | <yulia> | Done |
| 18:30 | <keith_miller> | yulia: shu Out of curiosity do either FF or Chrome need the function part (at least I'm not sure about normal var variables) of https://tc39.es/ecma262/#sec-web-compat-globaldeclarationinstantiation for web compatibility? JSC at least doesn't do it per our failing of: |
| 18:34 | <shu> | i've not tried to remove the logic and see what happens on chrome |
| 18:34 | <shu> | when i implemented this for SM i feel like there were breakages without it? |
| 18:35 | <shu> | are you interested in seeing if it's web compatible to remove the weird function var synthesis + hoisting? |
| 18:36 | <keith_miller> | Yeah, at least for functions |
| 18:36 | <keith_miller> | Although maybe that's just more confusing than doing it for all var-like things |
| 18:39 | <shu> | i'd be all for it if it didn't require constant vigilance for unexplainable "site stopped working" bugs |
| 18:40 | <littledan> | I mean, I tried implementing it without all that and it definitely broke the web in 2015 |
| 18:40 | <littledan> | maybe the web got better? I wouldn't chance it though |
| 18:40 | <keith_miller> | I see, it's weird that it would break sites since Safari never did it |
| 18:40 | <keith_miller> | Or maybe those sites were always broken safari lol |
| 18:41 | <littledan> | well, no one did the "full lexical scoping" thing for inner functions before ES6 |
| 18:41 | <littledan> | everyone had their own hacks to somehow or other permit functions in blocks in sloppy mode |
| 18:41 | <littledan> | nobody scoped them exactly just to the block |
| 18:41 | <keith_miller> | Oh, I just mean that the binding inside the function should be the same as the outer block |
| 18:42 | <shu> | wait what does that mean |
| 18:42 | <littledan> | well, kinda, except there's if statements and stuff |
| 18:42 | <littledan> | in ES6 times, the committee liked to apply "intersection semantics" logic, reasoning that if it's not permitted in all browsers, then it won't affect web compatibility. Such a philosophy didn't turn out to result in something that Chrome could ship in all cases. |
| 18:42 | <keith_miller> | Like AFIACT, f() { f = 123 }; f() print(f); doesn't print 123 |
| 18:42 | <littledan> | "union semantics" would be unnecessarily strict; web compat reality is messy |
| 18:43 | <shu> | it doesn't print 123 by my understanding too but what does that example have to do with the annex b lexical function hoisting thing? |
| 18:44 | <keith_miller> | It has to do with the fact that annex b creates a new binding inside f |
| 18:44 | <keith_miller> | Maybe I linked to the wrong section? |
| 18:44 | <shu> | wait, really? |
| 18:44 | <shu> | the thing you linked by my understanding only deals with stuff like { function f() {} } or if (exp) { function f() {} } etc |
| 18:44 | <keith_miller> | I mean that's why you don't print 123 |
| 18:44 | <shu> | but your example has no lexically scoped function decl |
| 18:45 | <keith_miller> | AFAICT |
| 18:45 | <keith_miller> | Sorry |
| 18:45 | <keith_miller> | There should be { } around the declaration of f |
| 18:47 | <keith_miller> | So, { function f() { f = 123 } } f(); console.log(f); |
| 18:48 | <keith_miller> | That will print 123 in Safari but ƒ f() { f = 123 } in Chrome |
| 18:52 | <shu> | uhh let me page this cursed knowledge back in |
| 18:53 | <keith_miller> | Also, the fact that let b = function() { b = 123 }; b(); console.log(b); and let b = function b() { b = 123 }; b(); console.log(b); have different outputs is 😭 |
| 18:53 | <littledan> | there are definitely other things that we could've done while being web-compatible, but I don't see the point in changing things now |
| 18:53 | <littledan> | I mean yeah it's a complete mess and horrible |
| 18:54 | <keith_miller> | I have NO idea why those are different... |
| 18:54 | <littledan> | oh, that is more straightforward, that example |
| 18:54 | <littledan> | in the second case, there is an inner b binding, which is non-writeable, but writing to it is a silent error in sloppy mode |
| 18:54 | <littledan> | whereas the first case overwrites the outer b binding |
| 18:55 | <littledan> | this is because JS permits anonymous functions to be recursive by just having an inner name! |
| 18:55 | <keith_miller> | Oh, ok, what a beautiful language lol |
| 18:55 | <shu> | that scope is the worst |
| 18:55 | <littledan> | the inner name pattern is mirrored by named class expressions even!!! |
| 18:55 | <shu> | the anonymous lambda scope |
| 18:55 | <littledan> | but the errors are a little stricter |
| 18:55 | <shu> | it's like, almost a const |
| 18:55 | <shu> | but it's not a const |
| 18:55 | <shu> | because it predates consts |
| 18:55 | <shu> | it is the ur-const |
| 18:55 | <littledan> | right, for classes it's just a const |
| 18:56 | <littledan> | as of a few years ago, V8 scope tracking had a special bit for this particular case |
| 18:57 | <littledan> | That will print |
| 18:57 | littledan | heads out for an exorcism |
| 18:58 | <keith_miller> | Right, I see what's happening here even though I hate it |
| 18:58 | <keith_miller> | I wonder why it differs between the other example and that |
| 18:58 | <keith_miller> | Right, I see what's happening here even though I hate it |
| 19:01 | <shu> | okay i think i have this paged in |
| 19:01 | <littledan> | IIRC back in 2015 when I came across this mess, i first proposed that we just make sloppy-mode block-scoped functions basically vars that were just assigned to where their declaration appeared |
| 19:01 | <littledan> | Waldemar wasn't a fan |
| 19:02 | <shu> | yes, i had the same proposal maybe? it was the first thing i presented to tc39 |
| 19:02 | <shu> | and also rejected, allen didn't like it either i think |
| 19:02 | <littledan> | oops, yeah probably that was you and I remembered wrong? or we worked together on it? |
| 19:02 | <shu> | maybe |
| 19:02 | <littledan> | but yes I remember Allen also not liking it |
| 19:02 | <shu> | it was a disheartening start |
| 19:02 | <shu> | i was like "these are a bunch of wackjobs" |
| 19:02 | <littledan> | yeah same |
| 19:03 | <littledan> | I think folks were defensive since ES6 had just gone out |
| 19:03 | <shu> | keith_miller: so wait what are the two examples you were wondering the difference between? |
| 19:03 | <shu> | the function declaration one and the function expression one that dan already explained? |
| 19:04 | <shu> | i mean yes it is kind of weird that named function expressions get a const inner binding and named function declarations do not |
| 19:04 | <shu> | but that's also nothing to do with annex b |
| 19:05 | <littledan> | yeah that predates ES6 |
| 19:05 | <littledan> | maybe it was an ES5 thing? |
| 19:06 | <littledan> | or earlier? |
| 19:07 | <shu> | the positive spin is that that annex b semantics section is the forge in which true bonds of brotherhood of JS implementers are forged! |
| 19:07 | <bakkot> | for anyone trying to follow along, https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go has an explanation of the spec semantics here |
| 19:07 | <bakkot> | incidentally there are still one or two known outstanding bugs here (places web reality requires a different thing than the spec says) which are going to live forever unless one of us feels like fixing them |
| 19:08 | <littledan> | bakkot: Are these tracked by issues? |
| 19:08 | <bakkot> | https://github.com/tc39/ecma262/issues?q=is%3Aissue+is%3Aopen+b.3.3 |
| 19:09 | <littledan> | omg https://github.com/tc39/ecma262/issues/2019 |
| 19:09 | <littledan> | yeah I used to be really excited about fixing the web reality... |
| 19:11 | <shu> | i am in this picture and i don't like it |
| 19:27 | <keith_miller> | keith_miller: so wait what are the two examples you were wondering the difference between? |
| 19:28 | <keith_miller> | shu: Also, is resizable TypedArray's ready to ship? Or is it stage 3 but not plz don't ship? |
| 19:29 | <keith_miller> | We really need a stage 3.5 that's this is ready to ship publicly or w/e |
| 19:34 | <littledan> | I think what held up Stage 3.5 was both standing disagreements about what the stages mean (now resolved) as well as concerns that requiring consensus on Stage 3.5 would slow our velocity |
| 19:34 | <littledan> | What if Stage 3.5 is just something unilaterally declared by champions based on their understanding of the state of everything? |
| 19:35 | <littledan> | We could just call it "shippable" and not a stage (so that it wouldn't call into question the meaning of Stage 3 or 4) |
| 19:35 | <littledan> | it could be documented in the proposal's readme, and just used as a term in meetings, e.g., "Status update: XYZ proposal is shippable, thanks everyone, good work" |
| 19:36 | <littledan> | but declarations of shippability wouldn't rely on committee consensus--the committee had already done that handoff at Stage 3 |
| 19:36 | <littledan> | wdyt? |
| 19:39 | <littledan> | engines would not be expected to definitely hold off until a champion group declares something shippable, but if an engine wants to be conservative, it can look for that bit, and in the normal case the champions would set the bit in time that things usually match up |
| 19:41 | <keith_miller> | That seems reasonable to me? I'd like an easily searchable list of proposals in that stage though. It could even just be a column in the proposals GH page. |
| 19:42 | <littledan> | yeah that page already has lots of non-consensus-seeking information |
| 20:30 | <shu> | keith_miller: on chrome side? it's almost ready to ship |
| 20:31 | <shu> | we're doing the last bits now to make sure it's fast in the optimizing JIT and double-checking that the Array.prototype builtins work |
| 22:00 | <littledan> | shu: The question is, is the proposal definition stable enough to ship, or should engines hold back for possible changes/discussion |
| 22:22 | <shu> | oh, yes, i consider it stable enough to ship modulo editorial improvements |
| 22:23 | <littledan> | (this is what a "shippable" declaration by a champion would mean) |
| 22:23 | <shu> | well i feel like if i felt that way, or felt it was full of bugs, i wouldn't have asked for stage 3? |
| 22:23 | <littledan> | sometimes we keep discussing things after Stage 3 and we ask people to hold them back |
| 22:23 | <shu> | a few times we have had conditional stage 3 based on upstream changes like HTML integration that blocks shipping |
| 22:23 | <shu> | but for a self-contained proposal i'd hope not |
| 22:24 | <littledan> | e.g., we debated class features for a while, though arguably that was regrettable |
| 22:24 | <littledan> | anyway that is not very comparable |
| 22:24 | <littledan> | but this has come up in TC39 before |
| 22:24 | <littledan> | I think it'd be fine to say, "this is shippable" at the exact same time as we say "this is Stage 3" but it wouldn't be the first time we had this as a question |
| 22:29 | <shu> | agreed, i'd be fine with the state that we should strive very hard for "shippable" and "stage 3" to coincide |
| 22:29 | <shu> | but we know they don't always coincide, so when they don't we should be explicit |
| 22:30 | <littledan> | I think we try to do that, but would it be OK to have an explicit signal with the reverse polarity? |
| 22:30 | <littledan> | where the normal practice would be to set that bit immediately |
| 22:30 | <littledan> | the problem is something like, we don't have a great way to keep track of that explicit signal in the opposite direction; it may be buried in the notes |
| 22:31 | <shu> | what's the opposite direction? |
| 22:31 | <shu> | i thought the only direction is "shippable" can lag behind "stage 3" |
| 22:31 | <littledan> | sorry by "opposite direction" I mean going out and marking shippable, rather than only noting "unshippable" as the exception to keep track of |
| 22:32 | <shu> | i think i'd prefer we identify the proposals that need to track the shippable signal separately at stage 3 time |
| 22:32 | <shu> | do you think that's possible? |
| 22:32 | <shu> | for some it obviously is, like ShadowRealms due to the upstream integration |
| 22:34 | <littledan> | yeah, I could see this working either way, as long as we have a column in the proposals page which indicates a yay/nay |
| 22:35 | <littledan> | I agree that the default should be that Stage 3 things are already considered shippable and need no further confirmation |