| 01:04 | <ljharb> | i'm confused, i don't hear any audio coming out of jitsi (but i do hear jitsi sound effects) but i see the notes transcribing things |
| 01:04 | <littledan> | maybe try refreshing? I hear audio |
| 01:04 | <ljharb> | rejoining didn't seem to help, i'll try force quitting the app and reopening it |
| 01:05 | <ljharb> | still nothing |
| 01:05 | <bakkot> | did you mute the tab? |
| 01:05 | <ljharb> | it's not a tab, it's the native iPad app i've used every other time |
| 01:05 | <bakkot> | ah, hm |
| 01:05 | <littledan> | note that this isn't 8x8, it's Igalia's server |
| 01:06 | <ljharb> | ah, i thought igalia's server didn't work for us multiple times. either way i'm connected to it and it's not sending me audio :-( |
| 01:06 | <Michael Ficarra> | ljharb: I've had that issue and reconnecting to the meeting fixed it |
| 01:07 | <littledan> | Igalia updated its Jitsi instance; I think it worked well after that (just not from Google's room). Maybe try joining via the browser if your app doesn't work? |
| 01:07 | <ljharb> | i've already tried that twice; i'll try one more time |
| 01:08 | <ljharb> | i do hear it through the web (a third try on the app didn't work) |
| 01:08 | <ljharb> | why aren't we using 8x8? |
| 01:09 | <Michael Ficarra> | what's the difference between them? jitsi version? |
| 01:09 | <ryzokuken> | Igalia updated its Jitsi instance; I think it worked well after that (just not from Google's room). Maybe try joining via the browser if your app doesn't work? |
| 01:09 | <ljharb> | right, but we used the 8x8 for jitsi the last year or two, no? |
| 01:10 | <ryzokuken> | we had issues with it a few meetings ago |
| 01:11 | <littledan> | there's a general jtsii app, it's just a different app from the 8x8 app |
| 01:14 | <ljharb> | the one i use is called "Jitsi Meet", which is from 8x8 - i'm not aware of another ipad-compatible jitsi app (altho maybe the search results are drowned out by keyword spam) |
| 01:14 | <ljharb> | it's worked fine since we started using jitsi, until now :-/ |
| 01:14 | <littledan> | OK, yes, Jitsi Meet worked for me in the past with Igalia's servers |
| 01:14 | <ljharb> | yeah same, so i'm confused why it wouldn't be working now |
| 01:15 | <ryzokuken> | Jitsi Meet should ideally work with our servers, but I have to admit that I just use the browser, even when connecting on my phone |
| 01:16 | <littledan> | what's the difference between them? jitsi version? |
| 01:16 | <Bradford Smith> | Did I miss an announcement explaining why we don´t have a professional stenographer this time? I thought that was the plan. |
| 01:17 | <littledan> | Bradford Smith: I've submitted a request, and will be raising it at the ExeCom meeting in three weeks |
| 01:17 | <Bradford Smith> | ah, thx |
| 01:34 | <littledan> | Huh? What is this hardcoded logic, and why can't those people sign the form? |
| 01:36 | <bakkot> | littledan: ask ljharb for details |
| 01:36 | <bakkot> | it's for existing commits in the repo, though |
| 01:36 | <bakkot> | not for new PRs |
| 01:36 | <msaboff> | Please add your name, abbreviation and organization to the top of today's notes. |
| 01:37 | <littledan> | yeah, when I started the IPR form I went back and solicited signatures for past contributors who I couldn't find IPR documentation of; sounds like it's time to do that exercise again |
| 01:37 | <bakkot> | I believe it's people who contributed long ago and aren't visibly marked as delegates on Github? something like that |
| 01:37 | <littledan> | (everyone agreed to sign this form except Domenic; we still lack a paper trail for the Promise spec IPR) |
| 01:39 | <ljharb> | littledan: yes, i've started to do that, but they're hard to track down |
| 01:39 | <littledan> | ah great, I appreciate that! |
| 01:39 | <ljharb> | feel free to reach out as well; it's an array or Set or something called "exceptions" in the script |
| 01:40 | <littledan> | yeah could you link to that in the source, so I could help? |
| 01:41 | <ljharb> | https://github.com/tc39/ecma262/blob/main/scripts/check-form.js#L162-L202 |
| 01:42 | <Michael Ficarra> | this is so much better! |
| 01:43 | <Michael Ficarra> | dodged a bullet accepting "all truthy strings" |
| 01:48 | <bakkot> | ^ this is the sort of thing TG1 can help with I think |
| 01:50 | <shu> | yes, 100% |
| 01:50 | <shu> | i think chip's and my comments are directed at the actual domain-specific i18n stuff |
| 01:50 | <littledan> | TG1? |
| 01:50 | <shu> | plenary |
| 01:56 | <bakkot> | could one of the DurationFormat people update the conclusion with a precise list of the things we just gave consensus for? |
| 01:56 | <ryzokuken> | will do |
| 01:56 | <bakkot> | I don't like having just "consensus for presented changes" but don't have time to fix it up |
| 01:57 | <bakkot> | thanks! |
| 01:57 | <littledan> | I'm wondering, is DurationFormat "shippable"? Do we anticipate further changes? |
| 01:58 | <ryzokuken> | littledan: I believe so, but I can do a quick triage and let you know precisely. |
| 01:59 | <littledan> | Great news! If so, maybe announce this specifically to the committee in a follow-on topic if there's time, since that wasn't quite clear so far? This is a nice conclusion to a string of fix-up presentations. |
| 02:01 | <littledan> | Great news on the RFC side for Temporal. If we have consensus among the relevant parties for moving forward on this, I'm not sure we need to wait for formal publication before shipping this in browsers. (Isn't the IETF all about running code?) |
| 02:06 | <bakkot> | oh no, why is a string of eight digits a valid calendar name |
| 02:07 | <shu> | have you read the temporal 8601 grammar |
| 02:08 | <bakkot> | if I have I presumably wiped that from my memory after reading |
| 02:08 | <shu> | it makes me throw up a little in my mouth every time |
| 02:08 | <shu> | we did not invent formal grammar for this |
| 02:10 | <snek> | hello everyone |
| 02:16 | <littledan> | Is there an issue for this frozen calendar topic? |
| 02:16 | <Michael Ficarra> | I just noticed we adopted the agenda with this PR open: https://github.com/tc39/agendas/pull/1252 |
| 02:17 | <Michael Ficarra> | is that presenter in here? should we amend the agenda? |
| 02:17 | <littledan> | (FWIW I'm skeptical of using frozen intrinsic objects here; I was pushing against custom calendars exactly because this sort of thing is likely infeasible) |
| 02:18 | <littledan> | I don't understand the motivation for what Jordan is talking about; maybe this could be filed as an issue? |
| 02:19 | <littledan> | +1 to Philip's point about the critical flag |
| 02:20 | <ryzokuken> | fwiw, this interpretation of the flag is also shared by the folks at IETF |
| 02:21 | <littledan> | also note that there are other sorts of normalization around the spec, e.g., in Intl locales |
| 02:22 | <littledan> | this seems analogous |
| 02:23 | <littledan> | Yay Justin's back!!! |
| 02:23 | <shu> | ljharb: AFAIU the crux of the argument is that Temporal objects are not meant for interchange, and that they are already lossy wrt some input |
| 02:23 | <bakkot> | can presenter or someone capture what we did and did not get consensus for on the notes? |
| 02:24 | <ptomato> | I can |
| 02:24 | <ljharb> | https://github.com/tc39/proposal-temporal/issues/2403 is the issue |
| 02:24 | <shu> | i also understand there to be that there's no implication of the form "critical annotation implies serialized for further interchange" |
| 02:24 | <ljharb> | that doesn't sound like a compelling argument to add more lossiness |
| 02:24 | <shu> | but this isn't more lossiness |
| 02:24 | <shu> | this is just existing lossiness (lossiness via toString) |
| 02:25 | <ljharb> | the toString part is i think a separate item; i'm saying that i would expect/hope that Temporal could parse a string and give me sufficient info about what was in that string |
| 02:25 | <shu> | and my understanding is that that was never the case and won't be the case |
| 02:26 | <shu> | because of what frank was saying about "ignorable brackets" |
| 02:26 | <ljharb> | i understand the ignorable annotation stuff would be lost |
| 02:26 | <ryzokuken> | I think you might be misunderstanding the purpose of the critical flag here. It's just not relevant for Temporal |
| 02:26 | <shu> | yeah i'd like to understand your use case jordan |
| 02:26 | <ljharb> | i don't have a use case in mind - i just learned about this flag 20 minutes ago |
| 02:27 | <ljharb> | but it seems shortsighted to throw out data gathered during a difficult parse |
| 02:27 | <shu> | but you have a position -- that this be preserved for toString, what's the motivation for that position |
| 02:27 | <ljharb> | i only mildly care about preserving it in toString - i think it's important to have a way to get it from the object |
| 02:27 | <shu> | that doesn't follow for me, i don't see why that's shortsighted when other stuff is already thrown out? |
| 02:27 | <ljharb> | like parsed.isCritical or something |
| 02:28 | <shu> | yeah but why |
| 02:28 | <ljharb> | "some stuff is thrown out so it's fine to throw anything else out" is a slippery slope argument. |
| 02:28 | <ljharb> | because it was in the string, and per the slide, "some consumers may care about it" |
| 02:28 | <ljharb> | if somebody cares about it then it seems important to preserve. if nobody cares about it then why support it at all |
| 02:28 | <shu> | yes, but not via an instantiated Temporal object! |
| 02:28 | <shu> | the consumer IS the temporal object, the code instantiating the temporal object |
| 02:29 | <ptomato> | I think the intention of the RFC is that the flag is thrown out when parsed; it just says "do not ignore this annotation when you parse it"; and Temporal doesn't ignore it |
| 02:29 | <shu> | not the users of the instantiated object |
| 02:29 | <ryzokuken> | I think the intention of the RFC is that the flag is thrown out when parsed; it just says "do not ignore this annotation when you parse it"; and Temporal doesn't ignore it |
| 02:29 | <shu> | like does this come down to how it's called "Critical" |
| 02:29 | <shu> | what if it wasn't that, and was "Temporal parser don't ignore" |
| 02:29 | <shu> | err |
| 02:30 | <ljharb> | lol but it's in an IETF standard. |
| 02:30 | <ptomato> | I would also be fine getting rid of the option to output it, for now 😄 |
| 02:30 | <shu> | let me rephrase |
| 02:30 | <littledan> | lol but it's in an IETF standard. |
| 02:30 | <shu> | what if "critical" had a very particular meaning in the IETF standard, and that meaning was "Temporal parser don't ignore" |
| 02:30 | <littledan> | (e.g., locales, which we support) |
| 02:31 | <ryzokuken> | but temporal parser never ignores |
| 02:31 | <ljharb> | i understand that temporal doesn't do anything different based on the presence of the flag. and if nobody ever ends up with a use case where they need to know if the ! was present, then obviously it'd be fine. |
| 02:31 | <ljharb> | but that's only 1 of the 4 possible outcomes |
| 02:31 | <shu> | what i'm sensing is mainly there's more read into the "criticality" than what is actually meant |
| 02:31 | <shu> | by both IETF and the temporal champions |
| 02:32 | <ljharb> | either we have it, and it's needed; we have it, it's not needed; we don't have it, it's not needed; or we don't have it and it's needed. in 2 of those, everything's fine, in 1 of those, we have an extra unneeded bit on temporal instances, and in 1, somebody's use case is impossible |
| 02:32 | <Michael Ficarra> | is there a temporal channel or something we could take this to? I'd rather discuss the current topic here |
| 02:32 | <shu> | sigh |
| 02:32 | <ljharb> | why wouldn't we want to avoid the "it's impossible" outcome? |
| 02:33 | <Michael Ficarra> | anyway, for something that's supposed to be a function of only how the source text is formatted, only looking at raw sounds like the right idea |
| 02:34 | <HE Shi-Jun> | what happened if called as function? |
| 02:35 | <littledan> | IMO reusing ParseText seems better to avoid (unlikely) future mismatch |
| 02:36 | <littledan> | what happened if called as function? |
| 02:36 | <HE Shi-Jun> | I assume it will try to read raw prop ? what will happen if no raw prop? |
| 02:36 | <bakkot> | it will throw |
| 02:37 | <snek> | big lunch |
| 02:37 | <Anthony Bullard> | Sorry, I missed the time to reconvene? |
| 02:37 | <snek> | one hour and 23 minutes from now |
| 02:37 | <HE Shi-Jun> | it will throw |
| 02:37 | <ljharb> | don't all/most template tags behave like that? |
| 02:38 | <bakkot> | a lot of template tags only care about the cooked code |
| 02:38 | <ljharb> | ah k |
| 02:38 | <bakkot> | so no, it's somewhat unusual |
| 02:38 | <bakkot> | but only somewhat |
| 02:38 | <bakkot> | mostly they're not built to be used as functions directly |
| 02:38 | <bakkot> | but I'm going to do that until we have a way to dedent a non-source-text string |
| 02:39 | <bakkot> | which will be slightly awkward now because I have to escape \s to prevent them getting cooked before passing them |
| 02:39 | <bakkot> | but whatever |
| 02:39 | <HE Shi-Jun> | I asked that because JSCIG discussed this proposal and someone asked that. Not sure everyone happy with throwing. |
| 02:39 | <bakkot> | see https://github.com/tc39/proposal-string-dedent/issues/45 for the "dedenting strings which are not source text" use case |
| 02:39 | <Anthony Bullard> | Justin Ridgewell: One thing I was going to ask if not for my terrible connection, is it seems odd that we respect the cooked value of some escaped characters(\n), but not others in this new proposal . Am I misunderstanding? |
| 02:40 | <bakkot> | HE Shi-Jun: do you know why they aren't happy with it? or can you ask? |
| 02:40 | <Justin Ridgewell> | I think you're misunderstanding |
| 02:40 | <Justin Ridgewell> | All escape sequences will be cooked, they're just cooked after dedenting |
| 02:41 | <Anthony Bullard> | But \n has the following characters treated as if it were a newline, no? |
| 02:41 | <Anthony Bullard> | Is that true in all cooked strings? |
| 02:42 | <Justin Ridgewell> | In the current implementation, it cooks first then dedents. |
| 02:42 | <HE Shi-Jun> | HE Shi-Jun: do you know why they aren't happy with it? or can you ask? |
| 02:42 | <Justin Ridgewell> | So the \n turns into a newline, then dedenting finds the content after that as part of the common indentation calculation. |
| 02:43 | <Justin Ridgewell> | In the PR, it calculates common indentation, dedents, then cooks the \n |
| 02:43 | <Justin Ridgewell> | A \x20 sequence would behave the same. |
| 02:43 | <Justin Ridgewell> | Currently, cook first, then dedent (it only matters if it appears before any content chars) |
| 02:43 | <Anthony Bullard> | I looked at the slides again, and I see what I expect |
| 02:43 | <Justin Ridgewell> | Proposed, dedent first, then cook |
| 02:44 | <Anthony Bullard> | My apologies |
| 02:44 | <Anthony Bullard> | My only concern was that we were special casing newlines |
| 02:44 | <Anthony Bullard> | Thanks for following up Justin |
| 02:45 | <shu> | i zoned out for a bit, are we coming back at 2100 PT? |
| 02:45 | <Anthony Bullard> | shu: yes |
| 02:45 | <shu> | thanks |
| 02:52 | <Anthony Bullard> | Since this is my first meeting, I wanted to understand the protocol. The meetings can take up to the four days, but only if the agenda takes us that long? |
| 02:52 | <shu> | the amount of stuff on the agenda waxes and wanes over the years |
| 02:52 | <shu> | the trend recently has been more undersubscription than oversubscription |
| 02:52 | <shu> | for most of TC39 i've attended in years past, we've often been quite stretched for time |
| 02:52 | <shu> | this agenda is especially short |
| 02:53 | <shu> | so yes, we have 4 days allotted, but may end early (i hope so!) |
| 02:53 | <Anthony Bullard> | Awesome, this is a tough schedule from CST |
| 02:53 | <ryzokuken> | it heavily depends on a lot of complicated factors... like timezones |
| 02:55 | <ryzokuken> | also some might've deferred their presentations in favor of giving it at the next meeting in person (and same with pulling forward for the last one). |
| 02:56 | <bakkot> | Justin Ridgewell: what happens if you do ``String.dedent`\invalid```? |
| 02:57 | <bakkot> | ugh, markup. String.dedent but you use an invalid escape in the template. |
| 02:58 | <Justin Ridgewell> | Currently, it would have [undefined] and ['\\invalid'] |
| 02:58 | <Justin Ridgewell> | It should be the same after the PR |
| 02:58 | <Justin Ridgewell> | (I hope) |
| 02:59 | <bakkot> | I mean when used as a tag directly, not when used as a wrapper for another tag |
| 02:59 | <bakkot> | that's reasonable behavior for passing to the wrapped tag, in the tag-wrapping case, but when used as a tag directly it gives you a string; what string does it give you? |
| 02:59 | <Justin Ridgewell> | It throws as part of the String.cooked implementation |
| 03:00 | <bakkot> | ah great |
| 03:00 | <bakkot> | I could not find that in the spec text |
| 03:00 | <Justin Ridgewell> | CookTemplateStringsArray |
| 03:00 | <bakkot> | oh, indeed, I see that |
| 03:00 | <Justin Ridgewell> | 7.C |
| 03:00 | <bakkot> | seems like it should be a SyntaxError but otherwise yes good |
| 03:57 | <bakkot> | Justin Ridgewell: https://github.com/tc39/proposal-string-dedent/pull/67 |
| 03:57 | <Rob Palmer> | We are resuming plenary in 2 mins! |
| 04:03 | <ryzokuken> | you can turn down the connection quality |
| 04:21 | <HE Shi-Jun> | so we only have message, no error name? |
| 04:22 | <caridy> | https://github.com/tc39/proposal-shadowrealm/pull/372/files#r966197227 |
| 04:22 | <caridy> | that's the specific normative note that @littledan is referencing to. |
| 04:23 | <littledan> | note, this isn't just Mathieu and me, Caridy proposed something sort of in between (not as concrete as I'd do it but I don't want to be too picky) |
| 04:23 | <littledan> | IMO the name doesn't give you very much, but also it's not a big deal to make an observable Get |
| 04:25 | <littledan> | Note, whether there's an observable Get, and whether the contents of the message are totally implementation-defined, are two separate questions |
| 04:26 | <littledan> | My position is that it's simply overkill to avoid the Get; I think it'd be fine to use the approach Mathieu suggests, of first checking [[ErrorData]] and then doing GetOwnProperty and then using it only if it's a value |
| 04:29 | <Michael Ficarra> | It throws as part of the |
| 04:30 | <bakkot> | it's only for non-tagged |
| 04:31 | <bakkot> | when you use String.dedent to wrap a tagged template it doesn't throw |
| 04:31 | <bakkot> | but if you use it directly as a tag it should throw, because the original code would have thrown without String.dedent |
| 04:34 | <Michael Ficarra> | but if you use it directly as a tag it should throw, because the original code would have thrown without |
| 04:34 | <Justin Ridgewell> | String.cooked`\invalid` throws |
| 04:35 | <Justin Ridgewell> | When you're concatting the values, it sees an undefined, and throws |
| 04:35 | <bakkot> | Michael Ficarra: what... would you want it to do |
| 04:35 | <bakkot> | would you want it to interpolate the string "undefined"? |
| 04:35 | <bakkot> | there is no issue for this because there is no other imaginable semantics, but you can make one to propose some other unimaginable semantics if you want |
| 04:35 | <Michael Ficarra> | cooked should still be undefined but raw should be dedented |
| 04:36 | <bakkot> | that's what it is |
| 04:36 | <bakkot> | but again, if you use it as a tag directly, there is no "cooked" vs "raw" distinction |
| 04:36 | <bakkot> | you get a string out, not an array |
| 04:36 | <bakkot> | and the string has to be a string |
| 04:36 | <Justin Ridgewell> | So, String.dedent`foo` performs String.cooked internally, because it's the default tag implementation. |
| 04:36 | <Anthony Bullard> | Etherpad link? |
| 04:37 | <Justin Ridgewell> | String.dedent(String.raw)`\invalid` wouldn't throw an error, String.dedent(String.cooked)`\invalid` would |
| 04:37 | <littledan> | The notes link is in the Reflector |
| 04:37 | <Michael Ficarra> | the reflector link is in the channel topic |
| 04:37 | <Rob Palmer> |
|
| 04:40 | <snek> | we should put that in the MOTD |
| 04:41 | <Michael Ficarra> | we should put it at the top of the reflector post in big red letters |
| 04:41 | <snek> | we should do the twitch chat thing, every 60 seconds or so a bot posts a reminder here |
| 04:42 | <Michael Ficarra> | Twitch chat would just automod the link away before it propagates |
| 04:43 | <HE Shi-Jun> | One thing I want to confirm, does Reflect.get(#{x:1}, "x" work or throw? I suppose it should throw? |
| 04:43 | <bakkot> | it works; why would it throw? |
| 04:43 | <bakkot> | (I assume anyway) |
| 04:43 | <ljharb> | if #{x:1}.x works then that should certainly work |
| 04:44 | <ljharb> | since they're the same operation |
| 04:44 | <HE Shi-Jun> | If Reflect works, so new Proxy(#{x: 1}, {}) also works?? |
| 04:45 | <Michael Ficarra> | { __proto__: #{} } doesn't work though |
| 04:45 | <ljharb> | hm, hax makes a good point |
| 04:45 | <bakkot> | ljharb: eh, "str"[0] works |
| 04:46 | <bakkot> | but Reflect.get("str", 0) does not |
| 04:46 | <ljharb> | yeah true |
| 04:46 | <littledan> | If Reflect works, so new Proxy(#{x: 1}, {}) also works?? |
| 04:46 | <HE Shi-Jun> | Currently Reflect API throws for all primitives. |
| 04:47 | <ljharb> | it makes sense that Reflect shouldn't work for anything that can't be a Proxy target, since reflect's only supposed to be for proxy traps |
| 04:47 | <littledan> | there was a somewhat detailed look into whether R&T could be Proxy targets, and Caridy noted that, given the Proxy invariants, this would not be remotely useful |
| 04:47 | <bakkot> | I think there is an open issue about which existing APIs should work |
| 04:47 | <ljharb> | it would be useful for observation, just not really changing the results |
| 04:47 | <bakkot> | which might have discussion of Reflect |
| 04:48 | <bakkot> | ljharb: IIRC the currently discussed issue was raised by you? |
| 04:48 | <bakkot> | the brand checking thing |
| 04:48 | <ljharb> | yes |
| 04:48 | <bakkot> | did you ever come up with a concrete use case? |
| 04:48 | <ljharb> | i haven't written anything up, no. |
| 04:48 | <ljharb> | one of them tho is for debugging, to be able to tell users what kind of value it is |
| 04:49 | <ljharb> | test frameworks, node, https://npmjs.com/object-inspect, etc all do similar things with existing boxed primitives |
| 04:50 | <HE Shi-Jun> | I think there is a conflict, on one side, we might want record/tuple could be used as replace of object/array in most cases, on the other side, we need to keep consistency with current API design, and many APIs treat primitives/objects very different. |
| 04:51 | <ljharb> | i agree. R&T occupy a very weird space where they're conceptually both objects and primitives, so it's hard to know what the best tradeoffs are between DX and consistency and existing axioms |
| 04:52 | <snek> | i don't like this idea but i'm not entirely sure why |
| 04:52 | <HE Shi-Jun> | Another interesting case was raised in our JSCIG meeting, someone ask whether class { constructor() { return #{} } } works... |
| 04:53 | <msaboff> | shu: What Web API's for ShadowRealms do you have questions about Safari 16 supporting? |
| 04:53 | <Robin Ricard> | HE Shi-Jun: might be worth raising on the queue |
| 04:54 | <shu> | msaboff: my question is 1) what part of ShadowRealms did Safari 16 ship, since web API integration isn't yet finished, 2) was it a mistake, as saam suggested on twitter |
| 04:54 | <littledan> | ljharb: Did you end up developing a use case for the other issue we discussed, of the Record prototype? The current state of the proposal is still that Records have a null [[Prototype]] |
| 04:54 | <ljharb> | no, i haven't written anything up yet |
| 04:54 | <bakkot> | +1 to not calling .join |
| 04:54 | <bakkot> | that was always crazy |
| 04:54 | <HE Shi-Jun> | HE Shi-Jun: might be worth raising on the queue |
| 04:55 | <Michael Ficarra> | one of very few places we defer to a method lookup by string |
| 04:55 | <Robin Ricard> | ljharb: also feel free to bring up the debug use case in tcq |
| 04:55 | <littledan> | msaboff: my question is 1) what part of ShadowRealms did Safari 16 ship, since web API integration isn't yet finished, 2) was it a mistake, as saam suggested on twitter |
| 04:57 | <Michael Ficarra> | also looks like undefined values are printed as "undefined", not empty |
| 04:58 | <msaboff> | I don't think the ShadowRealms we have support the Web APIs. |
| 05:00 | <littledan> | Oh, that's a relief. So if the list of web APIs ends up matching (and I can't imagine what kind of semantic mismatch might exist), the only mismatch would be the error message semantics, which is unlikely to be much of a compatibility issue |
| 05:00 | <bakkot> | have we considered just not boxing these things even in sloppy mode |
| 05:01 | <Jack Works> | how can you observe the stringification result of Symbol? |
| 05:01 | <bakkot> | that would be a weird divergence in sloppy mode |
| 05:01 | <shu> | littledan: is the list of web APIs finalized? |
| 05:01 | <shu> | like, the list Exposed=* stuff |
| 05:01 | <bakkot> | but you should not be in sloppy mode so I don't care if there are weird divergences |
| 05:01 | <Jack Works> | I tried Object.prototype.toString, "" + ... and with Object wrapper for Symbol, they don't work |
| 05:01 | <littledan> | shu: Yeah this has been stable for more than a month and is generally landed upstream |
| 05:01 | <shu> | okay, great |
| 05:01 | <bakkot> | Jack Works: String(Symbol()) |
| 05:01 | <Michael Ficarra> | shu: #[0] and #[0n] have the same toString |
| 05:02 | <nicolo-ribaudo> | have we considered just not boxing these things even in sloppy mode |
| 05:02 | <bakkot> | throw |
| 05:02 | <shu> | Michael Ficarra: right, thanks |
| 05:02 | <bakkot> | I guess |
| 05:02 | <bakkot> | or just make a copy instead of a wrapper |
| 05:03 | <littledan> | IMO we should decide on whether to introduce a brand check based on use cases today, rather than promises in the ES6 era |
| 05:04 | <ljharb> | the use cases remain the same. |
| 05:05 | <shu> | then those aren't invariants, those are just properties |
| 05:06 | <leobalter> | Rob Palmer: do we have other topics for today? |
| 05:06 | <Rob Palmer> | Michael Ficarra will be next |
| 05:06 | <ljharb> | note that "a primitive has a wrapper" is another "invariant-esque property" |
| 05:06 | <bakkot> | is it one you care about |
| 05:06 | <Jack Works> | what invariant? |
| 05:06 | <bakkot> | it is not one I care about |
| 05:06 | <ljharb> | bakkot: yes; tons of old on the web will likely break if that property is broken |
| 05:07 | <nicolo-ribaudo> | The old code on the web doesn't use R&T |
| 05:08 | <ljharb> | no, but the old code includes shims like es5-shim, and people will pass R&Ts to those shimmed methods. and some of them shim even in modern engines. |
| 05:08 | <msaboff> | I don't think the ShadowRealms we have support the Web APIs. |
| 05:08 | <snek> | the shims are not written in sloppy mode are they? |
| 05:08 | <bakkot> | no, but the old code includes shims like es5-shim, and people will pass R&Ts to those shimmed methods. and some of them shim even in modern engines. |
| 05:09 | <ljharb> | i am not |
| 05:10 | <bakkot> | we definitely should not be trying to maintain the property that old code works when you pass it new values |
| 05:10 | <shu> | the backwards compat promise is that unmaintained sites continue to work |
| 05:10 | <shu> | it is not sites continue to work regardless of what modifications they make |
| 05:10 | <ljharb> | i'm not sure how simple that is given that people update third-party dependencies they don't control. |
| 05:10 | <ljharb> | but fair enough |
| 05:10 | <rbuckton> | there exists a fair amount of code in the wild that preferred Object(value) === value to test for objects instead of typeof value === "object" && value !== null || typeof value === "function". Not boxing would cause code that expects to be safe to evaluate to become unsafe. |
| 05:11 | <snek> | Object(#{}) === #{} would be false, since it is not an object |
| 05:11 | <littledan> | I don't think the ShadowRealms we have support the Web APIs. |
| 05:12 | <rbuckton> | Object(#{}) === #{} would be false, since it is not an object |
| 05:12 | <shu> | Oh wow I somehow missed the word "don't" here. So, now this makes a compatibility matrix for ShadowRealms that I was hoping we could avoid. |
| 05:12 | <shu> | msaboff: given that i'm asking something radical: i'd consider this a mistake and a respin would be nice, if possible |
| 05:12 | <msaboff> | Oh wow I somehow missed the word "don't" here. So, now this makes a compatibility matrix for ShadowRealms that I was hoping we could avoid. |
| 05:12 | <shu> | but of course, safari rel-eng makes the decision |
| 05:13 | <rbuckton> | Throwing would be unexpected and has the potential to break code paths that are expected to not throw for anything. |
| 05:13 | <Richard Gibson> | I would not have guessed Records & Tuples to break a language that already has string primitives with both numeric index properties and a named property |
| 05:13 | <shu> | msaboff: is ShadowRealm unflagged or on-by-default? |
| 05:13 | <Anthony Bullard> | Thanks whoever is helping on notes |
| 05:14 | <msaboff> | msaboff: is ShadowRealm unflagged or on-by-default? |
| 05:14 | <rbuckton> | What would be the point of creating a Proxy for a record/tuple? |
| 05:15 | <shu> | msaboff: hmm, i see. at the risk of forward interop, i think a respin would be good if at all possible |
| 05:15 | <rbuckton> | You can't create a proxy for a number or string |
| 05:15 | <ljharb> | What would be the point of creating a Proxy for a record/tuple? |
| 05:15 | <shu> | leobalter: no that's not a good thing! |
| 05:15 | <snek> | problem solved? https://gc.gy/130751150.png |
| 05:16 | <msaboff> | @shu littledan I am checking on the true status of Web APIs and ShadowRealms in Safari 16. I'm looking at the current ToT WebKit. |
| 05:16 | <bakkot> | I would not have guessed Records & Tuples to break a language that already has string primitives with both numeric index properties and a named property |
| 05:16 | <shu> | msaboff: thank you |
| 05:17 | <leobalter> | shu: I believe the Web API on by default could lead to unwanted usage if we eventually drop anything from what is currently offered |
| 05:17 | <shu> | leobalter: but SRs being shipped unflagged is not good for forward compat |
| 05:18 | <shu> | if that is the case, maybe it isn't |
| 05:18 | <Richard Gibson> | I can't tell what this means |
| 05:19 | <leobalter> | shu: I understand that, and I've been talking to WebKit people all day at TPAC. My 🙌 reaction was to the least blast of impact |
| 05:20 | <snek> | is anyone talking right now |
| 05:20 | <bakkot> | Richard Gibson: what specific deviation are you referring to? |
| 05:21 | <ryzokuken> | yes |
| 05:21 | <snek> | oh nvm |
| 05:21 | <HE Shi-Jun> | I am not sure I understand the brand-checking issue. What Object.p.toString.call(Object(#{})) returns as current draft?? |
| 05:22 | <Richard Gibson> | @bakkot: Object(#{…}) returning anything other than a wrapper object |
| 05:22 | <Ashley Claymore> | "[Object record]" |
| 05:22 | <bakkot> | Richard Gibson: the benefit is not introducing a new kind of wrapper object |
| 05:22 | <bakkot> | I would like to only introduce new kinds of things if we want them |
| 05:22 | <HE Shi-Jun> | So we already have brand check via Object.p.toString ? |
| 05:23 | <Ashley Claymore> | Object.p.toString can be faked with Symbol.toStringTag |
| 05:23 | <Ashley Claymore> | so would need to check if the value has the symbol, but that can be faked with a proxy |
| 05:23 | <leobalter> | shu: from my end, this release is forcing me to prioritize the shadowrealms work internally, I keep committed to make sure we mitigate the risk of impact. I'm trying this through resolution for the last parts needed to unlock regular implementation. That's why I summarize them, I wanted to make sure I'm not missing anything. |
| 05:23 | <Mathieu Hofman> | Promise does not have a brand check that has no side effects |
| 05:24 | <shu> | leobalter: understood |
| 05:24 | <snek> | you can brand check a promise? |
| 05:24 | <Richard Gibson> | I would like to only introduce new kinds of things if we want them |
| 05:24 | <Mathieu Hofman> | You can but it may execute user code. I don't know if that's a requirement for other brand checks |
| 05:24 | <rbuckton> | Bradford Smith: { __proto__: null, toString() { return "#{" } } would satisfy your example and not be a record wrapper. |
| 05:25 | <ljharb> | Mathieu Hofman: that's true. but Promise.resolve(p) === p ends up being "fine" in practice. i'd certainly prefer a robust approach, ofc. |
| 05:25 | <snek> | oh with Promise.resolve right |
| 05:26 | <Robin Ricard> | agree: fine to go ahead without brand check |
| 05:26 | <Robin Ricard> | unconvinced: something is needed to address brand check |
| 05:26 | <bakkot> | Richard Gibson: it is not clear to me why this intuition is valuable? |
| 05:26 | <snek> | ljharb this feels kind of like "your scientists were so preoccupied with whether they could they didn't stop to think if they should" |
| 05:26 | <bakkot> | like, who cares whether it is an actual wrapper or a copy? who is that important to? |
| 05:27 | <leobalter> | shu: also, our membrane framework at Salesforce deletes all the Web APIs from a ShadowRealm and we don't rely on the errors (we have userland mechanisms to capture details cross realms). We won't ship the membrane framework using ShadowRealms for at least 6 months, guaranteed. |
| 05:27 | <ljharb> | to users who want to realize they accidentally wrapped a primitive. it happens, albeit rarely. |
| 05:27 | <rbuckton> | Any reason not to have Records have a prototype that is frozen and has a valueOf method? |
| 05:27 | <ljharb> | then you couldn't have a record with a valueOf key |
| 05:27 | <shu> | leobalter: i am not concerned about SF, it is clear enough that y'all can push updates out if needed |
| 05:27 | <Richard Gibson> | like, who cares whether it is an actual wrapper or a copy? who is that important to? Object(…) as an "is not primitive" predicate |
| 05:27 | <rbuckton> | ljharb: it could have an own valueOf key, just like an object. |
| 05:28 | <bakkot> | Richard Gibson: that would not be broken by my proposal |
| 05:28 | <leobalter> | shu: once again, I'm trying to mitigate the impact by usage of the feature. It's what I can do at this point. |
| 05:28 | <Jack Works> | what is temp checking RN? |
| 05:28 | <ljharb> | rbuckton: so then you wouldn't be able to safely .valueOf on a record. there was a strong desire to avoid that kind of problem. |
| 05:28 | <rbuckton> | bakkot: that could be significantly more expensive than Object(0) |
| 05:28 | <nicolo-ribaudo> | what is temp checking RN? |
| 05:28 | <waldemar> | We opened such a Pandora's box by letting folks customize Object.prototype.toString tags. |
| 05:29 | <ljharb> | yep, and we shouldn't have |
| 05:29 | <ljharb> | we could have pulled toStringTag from ES6 and left time to come up with a better solution, but we didn't do that (and i was too green to realize i could have insisted) |
| 05:29 | <rbuckton> | Having Object(#{ arbitrarilyLargeRecord }) convert the record to an object seems expensive for such a test. |
| 05:29 | <littledan> | yeah, like half of the symbols were a mistake |
| 05:30 | <snek> | most of javascript was a mistake tbh |
| 05:30 | <snek> | bigints are good though |
| 05:30 | <Michael Ficarra> | and throwing them all on a big string-based namespace under Symbol is both ironic and stupid |
| 05:30 | <shu> | and making Symbol.for symbols different from strings lol |
| 05:30 | <bakkot> | that's fair, but I don't think it would be expensive in practice - how expensive is Object.entries? (It wouldn't be a deep conversion, to be clear) |
| 05:30 | <Mathieu Hofman> | I still wish all Symbol.toStringTag were actually getters that brand checked like for the TypedArray prototype. Then we'd solve all brand check problems |
| 05:31 | <ljharb> | I still wish all |
| 05:31 | <ljharb> | altho i'm pretty sure it would still be web-compatible to change them all into those now, it's just that the committee at large likely doesn't care enough to want to spend time on that. |
| 05:32 | <rbuckton> | If we don't have a prototype, could we have a Record.unwrap(wrappedRecord) (or other name) that throws on non-record, and non-wrapped-records? It could act as a brand check and give you a valueOf workaround. |
| 05:33 | <ljharb> | that's what the champions think is ill-fitting. |
| 05:33 | <ljharb> | record primitives could also have an own Symbol.toPrimitive method. there's lots of ways to solve it, but it seems unpalatable to some. |
| 05:37 | <danielrosenwasser> | can someone advance the queue? |
| 05:38 | <shu> | is this really an FYI for committee? |
| 05:38 | <shu> | is there feedback R&T champions are specifically looking for from TC39 and not just from TS? |
| 05:39 | <danielrosenwasser> | well it's implementer feedback from tooling - e.g., "if we do XYZ, a linter or type-checker cannot catch ...." |
| 05:40 | <bakkot> | danielrosenwasser: is it though? |
| 05:40 | <bakkot> | what's the XYZ here? |
| 05:40 | <danielrosenwasser> | It is? |
| 05:40 | <littledan> | there are also lots of TS users in committee, and this all ties together, so it's good to get more developer feedback here |
| 05:40 | <bakkot> | like I'm missing what the feedback for the proposal actually is |
| 05:40 | <shu> | that's all fine, but i'm looking for the actual ask |
| 05:40 | <bakkot> | I am in general in favor of such feedback |
| 05:40 | <HE Shi-Jun> | Agree TS is very important to consider in any proposals. |
| 05:40 | <shu> | it is not a general thing that proposals lay out what TS integration looks like |
| 05:41 | <littledan> | A big takeaway: TS raised a reasonable compatibility risk, Bloomberg investigated this and found that the breakage was much less than some other TS upgrades have been |
| 05:41 | <shu> | but... did the proposal itself need changing? |
| 05:41 | <littledan> | the compatibility risk is based on our choice of typeof (in the language!) |
| 05:41 | <shu> | okay |
| 05:41 | <Ashley Claymore> | FWIW we also looked at how flow models its core types. And the story is different there as they are generally stricter about modelling things like primitive vs object and readonly |
| 05:41 | <littledan> | but... did the proposal itself need changing? |
| 05:42 | <shu> | i see |
| 05:42 | <littledan> | IMO this is pretty relevant to JS developers |
| 05:42 | <bakkot> | I am glad to hear that TS is exploring how to make this work and the champions think it will probably work with minimal breaking changes, if that is the intended takeaway? |
| 05:43 | <littledan> | I am glad to hear that TS is exploring how to make this work and the champions think it will probably work with minimal breaking changes, if that is the intended takeaway? |
| 05:44 | <Anthony Bullard> | I have to drop, thanks all |
| 05:48 | <danielrosenwasser> | like I'm missing what the feedback for the proposal actually is My 2 cents here - the state of this proposal poses a set of possible design directions for type-checkers. In the case of TypeScript, for example, we must decide whether our current object-like hierarchy can also model records and tuples, or if it must create a completely separate type hierarchy (or perhaps something in between if we think very hard). Bloomberg investigated how disruptive choosing one path would be, and wanted to provide their feedback on the experience. So it's relevant to discuss here because maybe there are ideas/thoughts from the committee, or maybe there are possible suggestions for the champions on how the proposal can make adjustments. |
| 05:49 | <Anthony Bullard> | Someone please take my place helping with notes - to the extent I was a help at all |
| 05:49 | <nicolo-ribaudo> | Someone please take my place helping with notes - to the extent I was a help at all |
| 05:49 | <Anthony Bullard> | Thank you nicolo-ribaudo ! |
| 05:51 | <shu> | danielrosenwasser: thank you, that's a very helpful summary |
| 05:52 | <snek> | does \p{Surrogate} only match unpaired surrogates? |
| 05:52 | <littledan> | yeah probably my takeaway was too strong, but it's just my personal opinion, how I understand it. You notice both the champions and Daniel are refraining from drawing such a strong reading... |
| 05:53 | <Justin Ridgewell> | I imagine it does in u mode |
| 05:55 | <waldemar> | The spec text of this proposal is delightfully short! |
| 05:55 | <littledan> | +1 to this proposal advancing |
| 05:55 | <bakkot> | danielrosenwasser: I guess I think TC39 probably isn't going to be all that helpful for suggestions for how TS should represent or typecheck stuff, as a rule, 'cause we don't really have the tradeoffs internalized for what breakages are acceptable and etc |
| 05:57 | <Justin Ridgewell> | 👍️ Unicode says to use the Replacement Character |
| 05:58 | <littledan> | danielrosenwasser: I guess I think TC39 probably isn't going to be all that helpful for suggestions for how TS should represent or typecheck stuff, as a rule, 'cause we don't really have the tradeoffs internalized for what breakages are acceptable and etc |
| 06:02 | <bakkot> | I'm definitely such a person. I just don't think I have feedback in my capacity as a TC39 member, vs as a person who writes TS, if that makes sense? |
| 06:02 | <HE Shi-Jun> | waldemar: Current slice() may break a well formed string into non well formed pieces. I am considering possible extensions of slice notation proposal (not current, because current draft do not include string) might solve that. |
| 06:03 | <littledan> | I'm definitely such a person. I just don't think I have feedback in my capacity as a TC39 member, vs as a person who writes TS, if that makes sense? |
| 06:03 | <littledan> | (so, no, it doesn't make sense to me) |
| 06:04 | <bakkot> | well, it's more a question of what the committee is? the committee is a good venue for discussing JS, the language, and so is a good place for discussions like "what changes can we make to the proposal to make it easier for TS to typecheck, if they're having difficulties" |
| 06:04 | <bakkot> | but I don't think it is a good venue for discussing "what are the tradeoffs TS should make when typechecking this feature we've proposed", even if that's a subject I do have opinions on |
| 06:05 | <shu> | i was approaching it from a pure time efficiency standpoint. it seemed to me at the time there was risk of delegates getting nerdsniped with no material effect on the proposal, which didn't seem like a good use of time |
| 06:05 | <bakkot> | it is maybe a good place for questions like "how do we expect this proposal to be used?", as data for the TS team to use to make decisions about those tradeoffs, but I didn't really hear a question of that form in this discussion |
| 06:08 | <Ashley Claymore> | This is good feedback. We had a mix of items, some were about sharing the outcomes of our research, others were items we explicitly wanted feedback on. We did not make it clear which were which. |
