Remote attendees:
| Name | Abbreviation | Organization |
|---|---|---|
| Bradford C. Smith | BSH | |
| Robin Ricard | RRD | Bloomberg |
| Rob Palmer | RPR | Bloomberg |
| Luca Casonato | LCA | Deno |
| Ujjwal Sharma | USA | Igalia |
| Chris de Almeida | CDA | IBM |
| Ben Newman | BN | Apollo |
| Frank Yung-Fong Tang | FYT | |
| Leo Balter | LEO | Salesforce |
| Waldemar Horwat | WH | |
| Jordan Harband | JHD | Coinbase |
| Philip Chimento | PFC | Igalia |
| Pieter Ouwerkerk | POK | RunKit |
| Istvan Sebestyen | IS | Ecma |
- Approval of last Meeting’s minutes: Approved
- Adoption of current agenda: Adopted
Presenter: Yulia Startsev (YSV)
[NO NOTES]
Elected:
- Brian Terlson (Microsoft)
- Rob Palmer (Bloomberg)
- Ujjwal Sharma (Igalia)
Presenter: Brian Terlson (BT)
BT: JHD is nominated as TC39 administrator. A TC39 administrator is selected by the chairs and they manage TC39 space, helping out with the day-to-day chores that come with maintaining a good Github or with, you know, dozens of people in that activity. So, in detail. we're looking at things like onboarding delegates, which is very frequent task that also includes an off-boarding delegates. Also grooming all of our Repos, and handling some of the tasks delegated by the code of conduct committee. Like if you need to take a moderation action, there's quite a bit of I work that goes into affecting those so. and then, you know, Matrix and discourse about things too. So that's just a reminder, but the gist of this is welcome JHD. And thank you for helping us out.
Presenter: István Sebestyén (IS)
IS: Okay, the presentation it will be very easy because the last meeting that we have had it was just a month ago. And since then we had Christmas and New Year Etc. So actually not not too much has happened. So as you can see, well, I will just show you the usual list of the relevant TC39 and Ecma GA documents, that have been created since the last meeting.. And then what is the status of TC39 meeting participation? And then for 2021 the final results of the standards download and access statistics and finally the next Execom and GA meetings. It is very similar what I had last year in December.
So here the list of the TC39 documents that we have created. This is basically the duplication of the slide contributions to the Github of the December meeting. The next one is the minutes of the last meeting that we have approved a couple of minutes ago, and then venue for the new meeting agenda for new meeting. So this is the list of the newly created TC39 documents.
There is always a question and I will come to that immediately after the presentation of this, why are we doing it? And this is a repetition I usually tell you once a year or so, but let me go very quickly to the list of the Ecma GA documents that have been published lately. So here the interesting thing that we are now in the process of preparing the special execom meeting on the 31st of January 2022 and this execom will be just in order to discuss the new optional draft Ecma text copyright policy. This permissive text copyright policy that has been proposed by some TC39 members. So there is an agenda for it. So this is now in progress and it will happen on the 31 of January. Then of course the GA also gets TC39 meeting minutes. So that's also of Interest, not only to TC39 members, but also generally to other ECMA members, so that's the reason why it is published there. There is obviously the same reason also with the published agenda for this meeting Etc.
IS: Now this document 004: This is what we are creating once a year. So this summary of the web statistics, in terms access from which country that access to the Ecma website and download of the standard access to the standards, etc. Etc. And I have taken out of this a couple of slides, also, in this presentation to show you the final figures, but I will be very short on that because it is not that much different from the figures that I have shown you a month ago.
And this is the document of the Ecma general assembly for December 2021, GA/2021/170. This is interesting, and which I would recommend to anybody who is interested in the outcome of the last of the last General Assembly. By the way, we have presented the main results verbally at the last meeting, But here, if you want to know, for instance, what is the exact state of Ecma projects in careful writing, you can go there and find out etc. Etc. So this is an interesting document in the series of the General Assembly documents.
IS: Okay. So why are we doing this “double storage” of documents, especially with regard to TC39? On one hand we have the usual TC39 tools that we use at the moment, this is basically the GitHub Etc. The problem with that on the Ecma level, that TC39 Github documents are not automatically available to every Ecma members interested in the work of TC39, i.e. also for those people who are not TC39 members, but just general Ecma members Etc. So somehow we have to make information available also to them. So that's the reason why we are taking out certain information from the GitHub and put them into the form of “classical” Ecma documents. Not all TC39 information, For instance not the discussions on Github between two TC39 meetings. We don't have a good tool for that to turn that into a TC39 document. But basically all the contributions to TC39 meetings, such as the agenda of the meeting, the results of the meeting, etc.. So these are the typical documents which are also turned into classical Ecma documents. The additional value added information which you don't see in the TC39 meeting documents on Github is really very minimal. But there is some, like the list of participants of the meeting, then which company has participated in the TC39 meeting. But it is very much a duplication of the information that is available also on GitHub. We have to do it because this is the official Ecma documentation for TC39, but it has also the advantage that of course, for long-term archival and long-term archiving it is much better. I mean, I don't know, long-term is 10, 20, 25 years already in the history of TC39, you know, so this is certainly what it is. The TC39 tools like GitHub etcetera they are changing after a few years in practice. Tools of 5-10 years, you know people are comfortable in using those. But long-term archival in standards documentation is very important. Like for solving relevant IPR issues, which I hope we will not have in Tc39, then to look into old documents, especially patent-related documents. It is very important in some of the, some of the other Ecma TCs, so that's the reason why we are doing this. Okay.
Now, the next slide is the TC39 participation. This is just a continuation of the record. So here you can see, we had sixty nine people at the last December remote meeting, which is a good number and 24 entities or companies have participated. So this is also a usual figure.
IS: Now coming to the next one, this is difficult to read but because I have copied it from the 004 document from the GA. But here you can see it is not very much different in terms the download statistics that I have shown in the December meeting. Here, it's difficult to read. But here the TC39 standards that are here in, in written a letter red letters. As you can see, one is ECMA-262. So, this is the absolute leader, almost 50% of all downloaded documents, and then the JSON standard. It has also climbed up in the meantime. It is now 13 thousand downloads per year. So it is, it is interesting. So this is this is going up and up. And there is the ECMA-402, ECMA-414 etcetera. So as you can see, in total, the share of the TC39 standards in the share of the total downloads is significant. It is going up. I would guess it must be 60% of all.
And then the next one is the access statistics. It is really dominating. So I got ECMA-262 all together in 2021. 470,000 html access, etc. And then here the respective downloads.
Next for the technical reports. The first one Is the jpeg interchange format So this is basically an old document, which we needed more than 10 years ago in TC46.
Now I am mentioning TR/104 which is basically the “read me” file for the Test262 modules. we are going to discuss the topic in this meeting, you know, how we are going to do with that in the future, Etc. This is the place to update it e.g. the description of the test262 process. So this according to my feeling, this will be up to a revision after the discussion that we are going to have. That's my feeling.
Next, ecma mementos, not very much. 217 were downloaded last year.
And that's the 2022 schedule of ecma TC39 meetings. Unchanged. So I just show it to you to have already seen this. The same is also for the GA venues and dates. You have also seen how change there will be - it was already pointed out at the December meeting. I guess so, yeah, on the 23rd of March 2022 we will approve the optional new text copyright policy. We will see if it will be a new Option or it will be “experimental”. I do not know, but my feeling is that something will be approved on the 23rd of March. I do not see the reason why not.
So you know this information already, the same also true for the execom meeting in April and in October 2022, the same as it was presented in December. And then this the January, 31st meeting on the text copyright policy, and that's all.
IS: So, first of all, if you have any questions, then please ask me now.
I would like to thank for your attention and I hope that I was more too long, and that's Casey.
SFC: Yeah, hi, if you can go back to, I think it was slide 11. I think this is something that I've seen in your presentation several times. For Ecma-402, at least the HTML version, the first edition has an order of magnitude more downloads than the 8th Edition, and that's also reflected on ECMA262 to a lesser degree. So I was just wondering if we have data on why the first edition still has all those hits, because that's very much an old edition and we changed and evolved since then.
IS: We have seen this problem already for years and we discussed it also in Tc39. Unfortunately we still do not have the right explanation. May be it is accessed by bots or whatever. So we don't know. it's completely illogical but we have it like that.
SFC: Do you think that you could possibly acquire additional information about the request, like the referrer or the user agent of these requests, to maybe get a little more clarity than just a number?
IS: okay, if you try to do it, yeah, so there is, there is one thing you know that observe which I have not shown, that in the access figures of? So I have noticed from the different countries that for instance countries, which should not be terribly interested in downloading standard, but still the downloads are rather High. I don't know from Belarus or from Ukraine, Russia Etc. So I have to a feeling that we are also getting actually WH pointed out this possibility a couple of years ago, that are also getting access from different places, you know, which has nothing to do with ECMA. So it is also possible that it is coming from all different bots but not from serious people who are really interested in downloading Ecma standards. But I will talk to the Ecma people who are doing this like Isabel in order to have see if we can find something more about that. But it is not a new thing. (After the meeting: I have asked the Ecma Secretariat to look into the matter again….)
SFC: Yep. Thank you.
IS: there one small thing, you know, that, which I would like to talk with you about it, maybe to announce it now that what we try to do it at least once per year, to archive the entire TC39 Github content into the a large Zip file in the TC39 Ecma File server, in order to try to make a total transposition of the TC39 GitHub. Unfortunately GitHub was never terribly friendly to support archival, but how is the situation now? And would it be possible to do it again? also to, to capture at least once a year? Also, the discussions that we are having over because at the moment that is not really covered in TC39 in the equity system and documents. And it would be nice to have at least once per year that, that mirroring the of the github.
RPR: Okay. All right. So you're highlighting that there is interest in archiving all the discussions on the various GitHub. It sounds like that. Something like that. Yeah, I think chat with JHD and maybe some others after this will be good.
PFC: I'd just like to say that I don't think we should necessarily be surprised if we see downloads of the standards coming from any country. Especially Ecma-402, because the functionality we standardized in that standard opens up participation in the web from countries that don't use the Latin alphabet, for example. So I'd honestly rather not talk about countries where there "shouldn't be" interest in downloading the Ecma standards.
IS: If they are getting access with people, you know, then we are very happy. If it is something else and we are not so happy.
Presenter: Kevin Gibbons (KG)
KG: So it's relatively short because the last month was not a time of doing things. Couple of things. The first one is not small, the can-call-user-code annotation, but I will talk about that in detail later. Other than that, we've committed a few more PRs that standardize some of the phrasing and notation we use within the spec, which is something that we're always trying to do more of just so that there's fewer different ways of writing the same thing. Also, we have landed one normative change. This one was discussed at the last meeting. This was the update to the script extensions values in the regex properties, as well as adding a note describing the process by which that table has historically been updated and will be updated in the future. In particular: we are not going to ask for consensus from the committee to make future normative changes that follow that process. We'll just do it whenever there's a new unicode version.
KG: Upcoming work #1796 for completion record reform. I've mentioned this repeatedly, Michael has been making excellent progress on it. I also want to mention that as part of this. I will be updating ecmarkup in a way that will have a small breaking change for consumers. So for anyone using ecmarkup in a proposal there will be a slightly different Syntax for invoking it from the command line to get the 262 biblio, that is, the ability to link against the specification. That ability has not been updated since 2015 or 2016. So it doesn't have the right list of abstract operations and so on. As part of #1796 or I guess, coincidental with it, I will be updating ecmarkup so that the automatic linking against 262 is fixed. That's going to entail a breaking change for proposals. So just don't update your proposal a new major version of ecmarkup, if you don't don't know what you're doing.
KG: Other than that, it's the same list of work we've had the last long while. I'm not going to talk about all of these in detail. One thing I wanted to mention before we get to the demo is that if you want something to get into the 2022 edition of the specification, and it has consensus or expects to have consensus soon, please let the editors know because that's coming up. Currently, we have a label on GitHub for tracking those and the only things in it are the match indices proposal, which has had stage 4 for while, I believe, and a normative pull request that changes how NaN's are handled in date prototype methods, which is also had consensus for more than a year. Those we are hoping to land shortly. Anything else we're not aware of, so if you want something to get in, let us know.
SFC: Regarding your mention of the script extensions updates. This has been a question that I've been hoping to resolve for a long time in ecma-402, where we also have similar types of updates that come from Unicode. I would like a little more information on how you arrived at this proposal to make it not require consensus update and if this is documented anywhere, such that we could point to it in ecma402 for the updates that we have that are of the same type.
KG: Sure. So the way we ended up in the place that we did is that MB who was I believe the champion of the original proposal that added the property escapes in the first place was under the impression that we would always be making the normative change without consensus. Editors could not find anywhere that that was recorded. So at the last meeting, we asked for a consensus for a specific process, which was, we documented the process by which decisions were made about the precise spelling of values that would go into the table and got consensus that we would just follow that process for any future changes without requiring a normative consensus, i.e. without coming to plenary with it. And that is written down in the specification, but it's only like a short paragraph above the two tables for which it's relevant. So, it's probably not something you could just reference easily from 402, but you could certainly copy it. The pull request #2515 introduces the paragraph that describes the process and also has a little more elaboration on what the process is.
SFC: Okay, and then one other follow-up question. Have any delegates raised concerns about the specification moving faster than implementations? Because I know that in Ecma-402, we had one PR to add number new numbering systems, and there was pushback from implementers to say that they didn't want the specification to outpace the implementations because things involving Unicode properties are not implementable until ICU, for example, is updated and widespread. So there was some concern about Ecma-402 specifications outpacing the implementations. Is that all ever brought up here? Was that a concern for anyone?
KG: No one raised that concern during the discussion that I can recall. I can't speak for implementers if they have this concern and just failed to raise it.
MF: Are there any implementers that can speak to that concern that SFC referencing on the number formatting?
YSV: I can't speak to that concern specifically, but we've recently had some staff changes. So we are catching up on the Ecma, 402 again. Let me ask internally and I can verify whether or not those concerned on our side.
SFC: I'll point you to some of those from the notes of the TC39-TG2 meetings, where this concern was raised. I think by JSC. I can point you to that section of the notes.
YSV: That would be great. Please do so.
MF: Yeah, I agree. It does seem highly related, but it seems that if implementers are the first movers then they're still going to be -- because the spec does not allow you to use any values that are not within the spec -- they're still going to be out of compliance either way, so it doesn't seem like there's any benefit for the cause of that being the implementer moving faster over the cause of that being the spec moving faster.
YSV: This on how this relates to the Ecma 262 spec. I don't know if I have any open concerns, but I'm curious to see how this is working in 402. I don't see this as a blocking issue and I don't recall it being raised in our discussions in the past.
KG: OK, back to the presentation.
KG: So, we have two new features in the specification. The first one is just that if you press ? you get a little dialogue that tells you what shortcuts spec has. 2 of them already existed: toggling multipage by pressing M, and jump to search box by pressing /. The other two are new. The first one is pressing ?, as I just mentioned, and the other one is this fancy new "toggle user code annotations". This is a feature SYG worked on and it's fantastic. It is primarily aimed at implementers, but there are lots of other people who will also find it useful I'm sure.
KG: So what this is is, if you are looking at an algorithm and you want to know which parts of this might potentially invoke user code, which is particularly relevant for implementations because those are the parts that they need to be careful with regarding ordering and like side effects, if you press u, you get this this little you see annotation that notes when things can call user code. And it's propagated automatically. [demo] I think it's great. Some notes on the maintenance of this. It mostly doesn't require manual annotations. It's just propagated through stuff with a couple of heuristics about when to propagate and when to not propagate. But the heuristics are sometimes wrong. So you occasionally need to explicitly note if you're doing something weird, particularly anything involving generators, that sort of thing. You may explicitly need to note when something calls user code or when something that looks like it might call user code in fact cannot in this particular case. A good example is ToString. A call ToString usually calls user code when you pass it an arbitrary argument because it can of course invoke the toString method on an object. But in many cases, it's not actually going to those cases. Usually those also can't throw. If you pass it a primitive or a non-string primitive, for example, it can't throw. So usually you will be invoking that in a way that's marked as not throwing in the heuristic will figure out that implies that it's not like a whole user code. Again if you're doing something weird, you may need to override the heuristic. Editors, who will be happy to work with people on this. We don't expect it to involve very much effort because the heuristics really are quite accurate. That said there are a couple of known false positives currently, which we intend to fix relatively soon as part of the completion record reform because it's just going to fix those issues anyway. If you find other false positives and false negatives, please open issues on the spec. We obviously can't have checked every single thing exhaustively. So it is entirely possible there are unknown false positives or false negatives still in here somewhere.
KG: And of course you can toggle it back off with u again. Questions, comments, concerns? And again, thank you to SYG for doing all of this work.
WH: What are some false negatives?
KG: There are no known false negatives, but what a false negative would tend to look like is if you are invoking code in an unusual way, so like resuming a generator. Resuming a generator involves kind of a weird control flow within specification itself. You "resume the suspended evaluation of gencontext". And this had to be manually annotated because this is not like invoking an abstract operation where we know that the abstract operation is going to involve user code. This is like we're going to move control in the specification and it happens that what we are moving to, again in the general case, can involve executing user code. But we believe every place that we are aware of where this needed to happen has been manually annotated. And it was only like a five or something, not a huge list.
PFC: Thanks for the demo. I think it's going to be a really useful feature for Temporal and also for writing test262 coverage for Temporal. I'm wondering if it's possible to annotate under what circumstances an abstract operation might call user code. There are a few places in Temporal where if you pass such-and-such into an abstract operation, or you use a built-in calendar, then the user code won't be called, but if you pass something different then user code might be called. Is that something that you just have to put in the description of the abstract operation or does the annotation handle this somehow?
KG: The answer to the question is that is not something that it currently does. This really is just an abstract operation that either can or cannot invoke user code. And then at specific call sites. If at that call site you know that it's not going to invoke user code, sometimes the heuristic will be able to figure it out. But if the heuristic fails, then you need to manually suppress the effect in that case. And if at a particular call, sometimes it does and sometimes it doesn't, that's not something the annotation will be able to handle. So you just have to write it down in prose.
SYG: If I can jump in here, I think it sounds like maybe you're asking two things. One is, is smart enough to do any kind of flow sensitivity, and the answer is definitely, no. And I don't think we're going to ever get there. Like it seems like a lot of work to teach ecmarkup and ecmarkdown control flow. Basically, that would basically be kind of like making an actual DSL out of this.
PFC: Oh, no, that's not what I was asking for. I meant like you could maybe annotate an operation to say "calls user code if you pass an object as argument" and then that information propagates up to the next level of the callers of that operation.
SYG: So that when you toggle this annotation the notes would toggle, like it's "can call user code under these circumstances" and it would take care of that kind of note propagation, is that what you're asking?
PFC: Yeah, that's what I was asking.
SYG: I see, maybe useful. Feel free to file an issue. There's a couple improvements that could be made here in terms of just usability, like, we want to make the annotations linkable when you toggle them on, we want to persist them across visits to the spec and so on, if you have ideas feel free to create an issue.
PFC: Okay, thanks.
KG: Also regarding specifically the use in Temporal, I want to say this is currently only usable within 262 to itself because the linkage, that I was talking about earlier, between the 262 specification and proposals is currently extremely stale and doesn't capture this information about which AOs can throw, that sort of thing. I'm hoping that relatively soon, that information will be exported and then will automatically be available in proposals with no additional work once you update ecmarkup, but that's not currently done. So it will not currently work anywhere outside of the spec and pull requests to the spec.
MM: Useful for reasoning about re-entrancy attack, bravo!
Presenter: Ujjwal Sharma (USA)
USA: Well, hello. And welcome to the Ecma 402. status update, the first one for the Gregorian and Julian year 2022. So we have two normative PRs that we could hear your thoughts about. First up this is the normative PR that SFC mentioned. This is the one that we have which is quite similar to the Unicode, Unicode,#614 that was discussed by 262. So we have added a new numbering system. It was authored by ABL and it has the new Tnsa script. It adds a new numbering system, NSA from the tanks of script that a new addition. In Unicode 14, It was released in ICU 70.1, which is why we had issues getting this in before because it was blocking implementations. And yeah, so that's that's the first one.
USA: And then next up. We have a normative PR that does pretty much exactly what it says. It does allows the use of underscore from the calendar names when referring to UTS 35. So no more underscores in calendar names, and that's that's it. So, Do people have any thoughts on these?
FYT: Just want to correct the numbering. assistance, all lowercase instead of uppercase.
USA: This right title is all lowercase. Yes, I am afraid. This is because of the styling of the header element has. Yeah, so let's clarify that, the actual name is lower case, is not uppercase. Like here
USA: So I think we have no objections. Next up. I just wanted to tell you briefly about the three stage 4 proposals. recently had so these would be going to the 2022 edition. First up. We have Intl.segmenter, which we spend quite a lot of time on working with. And it is finally at stage 4 and was merged to the Ecma 402 repository. We also Have extend TimeZoneName option, which extends the time zone names Intl display names. We talking off, there would be an Intl segment to that. You'll listen to later on, in this meeting. Yeah, that's it from for to thank you.
Presenter: Chip Morningstar (CM)
CM: It’s 2022 and all is well. Or at least all is well with respect to JSON. Can't speak to the rest of the world.
Presenter: Rick Waldron (RW)
RW: Test is has actually some interesting Updates this time around. Usually, it's just like, yeah, that's tested being written. Things are good. Stage 3 stuff is progressing. That is all true. However, I am excited to tell you all about two very specific elements. First is sort of the onboarding of a whole Squad. It's called of the squad of galleons who I made committers to test262, they all have write access to test262 now because it makes sense, they are now the Handling test262 to testify. think for PA Gribble stuff that had previously been working on. So that is very exciting. So just a call-out. I just assumed that this fellow that I'll say this correctly because I actually don't know the person's name. Every time I doubt anyone does. MS2ger who has And writing a lot of Intl tests and now Temporal tests, tests, exciting SHO, who fun story. We met like a million years ago at a JavaScript meet up. She will also be now committed to test262 to work on the same stuff, stuff, and with Igalia Which is, I think right now in total and Temporal stuff, obviously, they'll be expecting out RCA as well. And gentlemen, you just heard from a few moments ago. There's USA. So those folks are now committers ontest262 and the that's exciting. So the bigger that team gets all the focus of more people working on tests262, the larget my heart grows like in a Actually healthy weight, like in a kind of righteous. In addition to that, there has been a proposal to create a test 262 maintainers group, and we're going to have our inaugural meeting next week. They're excited. So yeah, that's big moves there and I'm just excited because it just makes more and frequent work going into the test262 system. Oh, and one other minor thing after the last TC39 needed, had a like a private session with YSV and some for students. And I'm hoping that they will also start contributing to test262 as well. I thought that are our sort of like Q&A session went. Really, really well, and I hope that they feel inspired to continue or just pulled start, and in some cases continue playing tests. So yeah, test 262 is really healthy right now, which is Awesome, very pleasing to be able to say. That's that. Does anybody from my squad You want to add to this report because want to again?
RPR: Looks like we've also got another test 262 agenda item coming up.
RW: Probably, I think that probably if I had to choose, I don't have to do with the maintainers group that has its inaugural meeting. SYG is that accurate.
SYG: Yeah, that is accurate. I will be talking about the maintainer group. Sorry to interrupt SHO.
SHO: Oh, you're just interrupting me talking for you. Yes, if yeah, that's all there's going to be a maintainers meeting next week. I am really excited to work with everyone. I think it's gonna be really cool.
RW: yep, so that that is I think all the update that I need to get. Like I said, if anybody from g… like to give update status of temporal testing or interesting you have time to have time to do that. This is your moment. If not, we can just give the time back.
SHO: I think we can give it back to the committee.
RW: All right, there it is. Time is see the rest of our time to the committee. Thank you very much
YSV: I have one response on the queue, which is regarding the students. So I'll poke them and I'll see if they can find some time. But because they have other classes now, they have limited time to work on this. However, we will probably run that class again in the near future, so we may get new students and some of them may stay, see if we can get a retention pipeline going with Leiden University.
RW: Fantastic. That's great. Okay, great.
RPR: Thank you, Rick and really good news about test262.
Presenter: Brian Terlson (BT)
BT: Hello friends. So this last little bit has been pretty quiet. We do have we are working with one individual. And I think for those that are involved in that I think aware of what's happening. But other than that, I really wanted to ask that anyone who has an interest and helping the code of conduct committee out. Please reach out the code of conduct committees. Email address is in our code of conduct. I can post it in Matrix as well. are often finding ourselves short-staffed when there is, you know an issue that we need to discuss. So if helping everyone be happy and helping productive Members of our committee is something that you think you might be passionate about, please reach out. We'd love to have help. if any other members of the committee would like to speak feel free. Otherwise that is it for me.
RPR: So we have a request for volunteers for the COC committee.
Presenter: Jordan Harband (JHD)
JHD: There's been some contention on the PR from a particular community member and myself. But the reason that this came about is because it was brought to my attention that the process document, which has an “implementation types expected” column, says polyfills are expected in the stage one row. The challenge here is that what we want in stage one,are some experimental kind of playground implementations to get a feel for how a solution might look. What we explicitly do not want here are things that are published and encouraged to be used in production environments because that would create a web compatibility risk - which we do not want at all, but especially at such an early stage. Stage 1 is where we're still figuring out the problem, and stage 2 is when we've kind of started to form a solution, and stage 3 is where we're sure about that solution’s shape, so I am concerned about the word “polyfill” being present in that column because that has a connotation of a thing you publish to npm, that people use on their website. The exact change to the process document is less important to me. I believe my current PR changes the word “polyfills” to “demos and experimental reference implementations” and then in parens, it says “implementations that modify global built-in objects should not be published as libraries or used in production or deployed code. Implementations that do not modify global built-in objects may be published”. This was iterated on with some feedback to get to this point. The intention is to say if you want to publish a function that does what a proposal does, go nuts - that's awesome. Get feedback, experiment, that's great - but we do not want to be, as a committee, encouraging modifying the global.
JHD: So the thing I'm asking the committee for is essentially consensus to make a change to the document to discourage mutating the global environment. The exact content of the change we can bikeshed in the pull request, and we shouldn't take up plenary time for it, but I believe based on everything I've heard in my years on the committee, that what I'm trying to capture here matches the consensus of the committee, even if the exact words I choose or have chosen may not. So that's where I'm at.
JHD: Scanning the queue in advance, obviously this is not a document that has enforcement power. We cannot block people from publishing things. It's more that we want to explicitly discourage. We want to first remove encouragement of publishing things that modify the global, and perhaps even stronger, we want to discourage doing so with the knowledge that nobody can be stopped.
YSV:Are you responding to my comment?
JHD: Yeah
YSV: maybe I'd like to have a well, I posted that because I had more to say about it. Also when we get to the conversation and then we can discuss it further.
JHD: Of course. Well, then in that case, I think we can go to the queue.
MM: Well, yeah, so I said I agree but since then you said something that confuses me so I need clarification so it seemed like the problem that I first understood that you're trying to correct, Is that the existing text implies that The thing that you're encouraged to create is something that other people might use in production and you want to head that off and make it clear that this is experimental for the purpose of exploring. The feature that I completely agree with.
MM: the other thing that you said, that confuses me is discouraging modifying the global. If thing you're proposing would modify the global and especially if the code that you're putting out there is understood not to be used in production in order to be representative more representative of what you're actually proposing. It seems to me that it will often be appropriate for it to modify the global to reflect the proposal better.
JHD: This was brought up in the long discussion thread of his PR. There are very few proposals that actually need to be installed on a global in order to function and test out - for those that do, that’s sort of a gray area where they will have to figure it out. And again, this is not intending to be an enforcement mechanism or a constraint. It's meant to send the right message, which doesn't have to apply to every case.
MM: Well, I so There's enough proposals that where the proposal is proposing to modify the global that I think an experimental piece of code for the purpose of learning about what is proposed, shouldn't modify the global. If the, if it is reflecting a proposal, that proposes modifying the global.
JHD: Well, so at a time when the proposal is finalized, then is, it great to have a spec compliant polyfill that installed like, for example, …
MM: I understand that we're talking about an earlier phase, but I'm making this comment specifically about that earlier phase where it's just for experimenting and learning about right,
JHD: There's very little to be gained from… let's say you're talking about Array.prototype.flat, using it as a standalone function, that takes an array and the arguments, versus installing on Array.prototype and doing .flat. The difference between those two is ergonomic, but you don't need to actually try it out in your code.
MM: If so, this is a great example. Yeah, if the proposal is to put it on Array.prototype. The experimental code is explicitly being provided for exploration with regard to what is proposed. I would think we want to encourage the experimental exploration code to put the method on Array.prototype.
JHD: So what I guess I hear what you're saying and what I’m responding to is I think that the vast majority of such a proposal has nothing to do with what object it’s on. If it has to do with the semantics of it operating on an array with some arguments, that can be tested out without installing it on Array.prototype with complete fidelity. The only thing that you get by having it on Array.prototype is the ergonomics of using it in a method chain, and that's the sort of thing that we already understand is good. There's no value to testing that out at this point as long as you can, you know, you can get those semantics of operating on the receiver and arguments with a standalone function, which you can for every single prototype method in the spec, at least that I have a polyfill for my, you know, all of those packages do not install it on the prototype by default and they work perfectly fine and all the tests work. The only difference is if you opt into installing it is that you can chain it off of arrays. It's not that there's zero value from having it installed, it's that the value is negligible and well understood, and the danger of trying that and risking that going into production code is high.
MM: Okay, so that so that I think that answers next, part of my question, which is: I understand why the value might be low, but I still didn't hear a rationale for why to discourage it.
JHD: Web compatibility. So for example, String.prototype.at is a proposal we recently advanced and but it was also an older proposal in 2017 or something. core-js has published an .at method that installed itself on String.prototype which had different semantics and there was a concern that that might have blocked the proposal. It didn't actually block it, but that could have happened with any polyfill provider who is installing things onto a prototype too early.
MM: Okay. So the, so the, so the overall answer is that despite the first part of what you're saying that this should not be considered production and should be considered only an experiment for learning. The reason for the second part of the recommendation, avoid modifying Global state is in case the thing goes to production despite the first part of it. Was that right?
JHD: correct. And also it's that this is intended to be a strong recommendation, but it's not a law, right? You can still violate it, but if it's worded properly and you violate it, you know what you're doing, and you're going to be careful about it. So I'm trying to be safe for the common case, which is a user who may not understand the consequences, the possible consequences and dangers of this action.
MM: Okay. This makes sense to me. I agree. I support it with both parts.
JHD: thank you very much.
PFC: I'm not sure that "we already understand that having methods on the prototype is good ergonomics" is going to be a compelling argument for, say, community members who are interested in trying out the feature in a playground environment. But I can say, what we did with Temporal before it reached stage 3 was we had a polyfill that did not install a global Temporal object, and then in the playground environment we loaded the polyfill and then— just only in that playground environment— we installed it on to the global. People who want to try out the full experience of having, say, an .at method on String.prototype, would be able to load a polyfill that gives them that function, and then just with a one-liner install it, like String.prototype.at = whatever. I agree with JHD that we want to avoid polyfills being published that do that installation already, right?
JHD: The playground approach I'm completely content with, because we can never stop anybody from doing whatever they want - so if they want to install it they can. The issue is requiring it to be an explicit step and not encouraging it to be done silently for people.
JSC: So I wanted to add on to I guess JHD already covered this though that most proposals that you know, are about a new function or whatever. Most of the value is in this and testing it in isolation. There are on the thread. If you want to read through it, like back and forth. About which proposals it's super important to add on the global cross-cutting cross-cutting like certain well known symbols or certain things involving method to keep the Prototype chains, but really, as far as I can tell the, the large majority of proposals involving new functions or syntax even do not involve modifying the global environment. Now having said that I have a future thing on the Queue about making it more specific, but this item is done.
JHX: Okay, Okay, and then. Yeah, just so I'm to a provided example, for example, if we want to upgrade its iterator protocol like double ended iterator proposal need to modify global Symbol object or submit may need to modify that or it's or it's hard to get the behavior. That's it.
JHD: That's a fair point. And for that type of scenario as long as the symbol wasn't actually installed on Symbol itself, then making an arbitrary symbol and installing that symbol as a property on the various built-ins wouldn't actually create a web compat risk because that wouldn't collide with anything that TC39 would produce. The risk, though, is that if you put it as a string property on Symbol and then we want to use that string property name, then there might be a collision. But yeah, there's there's definitely a lot of gray area here, here, but the my experience is that the folks who can do this safely, don't need this guidance to do it correctly and the guidance is meant to be for those who have not done it or, or don't know how to do it safely.
JHX: Okay. Yeah. I agree.
YSV: Right. There's been a lot of really interesting discussion so far, So I support the goal that this is aiming at which is to warn people away from potentially shooting themselves the foot and also making our work as spec authors more difficult. Of course, there is an issue with saying that these cannot be published. I wish there was a way for us to communicate more broadly, that Modifying built-ins is really dangerous. We just had another web compatibility issue, this time with groupBy, which is implementing a totally different API surface than what is specified. So this is a problem that goes beyond just the people trying to polyfill proposals. It extends into people anticipating what we will do in The future implementing some version of it and then us specifying something different causing breakages the web. I don't know how we can do that. more broadly, but I do think that we need to change this language that it cannot be published and I'll propose something in the pull request. The other thing that I'm wondering is this polyfill text. Maybe it's a holdover from a previous time, or maybe it didn't fully understand what Polyfill is because, like, stage 1 proposal. My understanding of a polyfill is implementing specs, behavior that isn't there yet for a browser, but it's being used here in this context as something. That is a spike. Something that is experimental. So I think the original intent of the word polyfill has simply changed and we need to specify that original intent as an experimenter demo. I don't even know if we need to have a lengthy text about what that is. I know that there is a contributor who has really strong feelings about it, and it feels like part of the text is geared towards arguing with him, but in the general case, I think that polyfill even at the time that this was written was intended as an experiment.
JHD: I agree with you.
YSV: So I think I think like this is just a clarification and also PFC. I want I want him to get to his topic. Because the WHATWG finding on polyfills is, I think a useful thing for us to reference. And I think that we can also Define what the word polyfill means. Because I do think that there's an underlying misunderstanding of what that word was meant to be and it evolved over time.
JHD: Yeah, I think that's very true. I think the definition of polyfill does not actually have a single cohesive definition even now - defining it may be tricky, but I think defining what we want in stage one, I think is important. I agree with you that the understood meaning of polyfill has shifted since this document was written in 2013 or 2014 or whenever.
YSV: I would say we Define it for the scope of this document. This is just a local definition for this document.
JHD: Yeah, my general philosophy here has been that there's a lot of places in the spec and in these sort of documents where folks outside of TC39 use it as a justification for something, and because we are in some ways community stewards, it's important that we be aware of unintended consequences of our wording, and that we update our wording when we know of unintended consequences, to attempt to avoid them.
JSC: So, I guess I have two items in a row, the first one quick reply to YS. One. Is that the current wording, We can go back and forth. So like obviously on the PR wording, I've made some like I made some suggestions that got command. I made some more suggestions, but the current wording, which I think can from me both avoid the word ‘must’ we use the word ‘should not be’, whatever the phrase. And the other thing is that the current wording actually for when I cited, doesn't use the word polyfill anymore. We could talk about whether it's valuable to conclude it again, but the way I saw it was that since polyfill is a confusing word like we could reference the what would finding we could? could point to articles, articles, or whatever. But like, you know, polyfill is something. Lots of things to lots of people. It might be best to just avoid it right now. The phrasing is demos and experimental reference implementations, which are a little more wordier than polyfill. But which I think might be good for me right now. So right now we should think about whether it's even valuable to include the word polyfill at all of this document, as far as, like, the finding on polyfills, Etc. That's my reply.
JSC: The other thing is, my next topic is I think there's an important distinction to be made between should not modify globals versus should not modify globals with feature detection. And by feature detection, mean, you know, like checking for the existence of some, some member on some built-in global object and then monkey patching or whatever if it doesn't exist. this, I think that that's the by far, the most dangerous web compatibility risk because like people modify even built in globals all the time without web compatibility risk because they're not feature detecting, they're doing it unconditionally. So with the browser environment changes, its Behavior is not going to change because they might be monkey patching but they're doing it unconditionally. So the browser environment doesn't matter anymore. So that's why talked about this in mind. Since the founding of the long where that I also added some more suggestions. I think it's important to call ??? and in particular as something to avoid. That's I think that's a super important distinction because I think that is the crux of the web compatibility risk as far as I can tell.
JHD: So my reply on the queue is that the problem is that presence detection is not actually feature detection, and presence detection is the problem. If you actually are detecting it works that the way your code expects it to work, then theoretically it should be fine because either the newly provided built-in will do that and you won't polyfill it, or it won't do that and you will - and then either way your code keeps working. But to correctly, do feature detection is difficult and almost nobody does, so feature detection in general is probably best to discourage.
JSC: Okay, so it's okay. Yeah, I think that's a good point. It. Yeah, yeah, that's a good point.
SYG: So, I have a few comments here, One is, I think you answered this already, JHD, but it's the only in recent memory is the only actual occurrence of this threat. The .at thing that you mentioned, from CoreJS, has.
JHD: the only one that will that I'm aware of that, at least recently, that would have that risk to disrupting our proposals, core-js has in the past speculatively polyfilled things that weren't very far in the stage process and that has caused other breakage - but not breakage to proposals.
SYG:Okay, my my main concern here is that, while, I kind of agree that I agree with general thing of being clear, about experimental versus production and I very much want to get ahead of web compat hazards by well-meaning, but ultimately mistaken polyfill authors. So far this the actual problem here is seems to be one an education problem with the ecosystem and to maybe a specific problem with CoreJS, and I am not really interested in inviting more process, document exegesis by wordsmithing something specific and this is, I think in agreement with what you Lea was saying, I don't know if we do something pretty specific and targeted if the issue is ultimately rests with CorejsCoreJs. Now, I am sympathetic and I also have a very difficult time working with or communicating. With the coreJS author, but I'm not sure the process document is the right place to solve that problem.
JHD: You may be right. I think that when the process document is cited as a justification, I feel like that is the moment when it becomes important for the process document to adjust its message. Maybe this is overly specific. We can simplify it, sure, but I think that we cannot stop people from doing things we don't like, and if there is one particular actor that is doing something we don't like then, okay, then, that's an issue we should take up with that actor, but I still think it is important that our documents don't give the wrong impression. We have been very careful in many cases in the spec to word the editorial parts so that they do not give the wrong impression for similar reasons because there are those in the community that read it and take it as gospel. I would prefer that the process document not give the wrong impression as in this case it objectively has, but beyond that you're right - there may be specific issues with specific actors that need to be dealt with outside these documents and that's fine.
SYG: Then I'll close with that. I'm not sure. Okay, so the end when you re asked for consensus, I would like a more concise question of what you're asking for, if it's a broad thing, like we should have get consensus on distinguish, an experimental versus production implementations. That's decidedly less controversial than we should have some attempt at an exhaustive, best practices guide in Our the process document.
JHD: At the end of the queue/timebox, I will re-ask for consensus in the way you’ve discussed, because I'm definitely looking for a broad consensus.
[presenting document: https://www.w3.org/2001/tag/doc/polyfills/]
PFC: I wanted to mention the W3C TAG Finding on Polyfills. Is that something that we as a committee can say that we agree with, and we can use that as an explanation in our process document? I remember that reading that document was really instrumental for me to understand the sort of fine distinctions here about what polyfills should and shouldn't do for web compat reasons. Can we just say that we underwrite that document as well?
YSV: Yeah, I support that. I think that that's a good idea because this issue in particular effects the web platform because it's an uncontrolled space and we need to maintain backwards compatibility with the entire ecosystem that may run on the web platform. So citing the w3c here and their definition of polyfills feels appropriate.
JHD: That sounds great.
LEO: Yeah, hi, so I tried to get myself involved in the thread and trying to understand all the problems. I kind of agree with a lot of things that JHD say here. Also, JSC saying that this might be a thing. not only for API. But like, ref implementations because think there's a like we probably can get more examples for this from proposals that work through the sync text like ???, such as decorators, private Fields. I think we get more examples from that, and I think it's important to understand a message what we have today. And if I try to understand the scenario here, is that like we have corejs. Somehow using the process document to validate one thing in. Like, if we change the process document that will like feels like invalidates, their work for 8 years. I totally understand and respect their work, but at the same time, I don't want our process document validating like being used as a document to validate someone's work, like the process document should not generate anything that is compliant or not. The process just says, like how we want to advance things. The choice of words from what Jordans proposing In here, I kind of appreciate that and the same should also don't want someone to do some wordsmithing here and I totally understand the reasons and support that but think also saying like TC39 doesn't recommend anyone to do that is different from how it affects them. Like we are not making anything compliant or not. I think this is the message like the process document should be like this process documents should not be used to make to tell anything is compliant or not. I kind of support that for these reasons. I try my best to understand everything like how this got coreJS involved, but at the end, I still support these change. Like for these very reasons.
JHX: I agree that modifying Global is a problem, but essentially it's essential problem is how to Mark a PR as experimental. Currently. We do not have official way to do such things. I mean, currently mean, the pollyfills or the other reference implementation. There are just normal modules and you import them. So it have risk, but if we have some official way to mark and use the experimental API, it may be the solution. I don't know. How we could have that in it, but I really think this may be the real solution to this problem.
JHD: I'm not sure it would be a solution because marking it is experimental would just be a way to tell people don't rely on it. But if they do and their website breaks, then it's still a web compat issue just the same.
JHX: Sorry. Yeah, so I think we need some strong mechanism. For example, the reference implementation need to readjust it to experimental design and and maybe we can't have a API for experimental. So you are the people use that and it could have some mechanism, for example, if it may have the expiration time. So people use where you see, it's more careful that way. Yeah, something like that.
PHD: I'll be brief. I think I support the discussion about encouraging people, not to modify globals, I think it might not be obvious for people what options they have to not do that. And so, and I found the discussion for example, example, briefly about what Temporal did to be really interesting and helpful. And so I just like to suggest that maybe in addition to saying, what people shouldn't do, we could provide some options or recomendations about what what they should do based on the experience of the committee.
JHD: I would like to ask for just clarifying in the notes that we table is something we have consensus doing that is not sufficient to land the pr that is just I want I think it is important to have that on record and I think it will avoid distractions on the PR. Further. If we get consensus for that, then anyone who's interested, I would love to workshop with that in the pool request and then we can come back at a future Plenary to see consensus for the final text. So if there any objection to that / explicit support for it?
SYG: I'm sorry. I still missed what you're asking.
JHD: I would like consensus that we will change the “implementation types expected” cell in the stage table to clarify, the meanings we have discussed. Precise text will come back to plenary for future consensus.
SYG: Okay. Thank you.
MM: I approve.
JHD: Thank you. I will come back in the future plenary after we've workshopped something and to SYG’s comments. I will try and make it somewhat broader and bigger and I will also include a link to the TAG polyfill findings.
- No objection to modifying the Stage 1 cell for this purpose
- Exact wording to be approved at an upcoming meeting
Presenter: Philip Chimento (PFC)
PFC: I don't have slides. This is just about a process change, pull request and I hope we can be done in much fewer than the 20 minutes that I reserved for it, but we'll see. So, I linked the pull request in the agenda item. This is actually a pull request from Mike Pennisi from Bocoup about the status of normative changes to stage 3 proposals, and I have an interest in this because, as I'm sure everybody's aware, we've been presenting a number of these in the past few meetings for the Temporal proposal. Such changes have been presented for other proposals as well, like I believe the static blocks proposal.
PFC: The intent of this PR is to clarify whether it's required for normative changes in proposals that are in stage 3, to receive consensus from the committee. My understanding is that this has been an unofficial requirement and it should be fine to make it an official requirement, but I'd like to check and see if anybody has any problems with that. And the second pull request is about putting normative changes for post-stage-3 proposals on the agenda before the agenda deadline, and linking to supporting materials and such. I don't think this has been a requirement, even an unofficial one, but it's one that we've been treating as a requirement at least for the Temporal proposal's normative changes, out of courtesy towards implementers. I think personally, it would be a good idea to require this as well, that if you want to make normative changes to a proposal in stage 3, you should put it on the agenda before the agenda deadline and link to the supporting materials. So that's the second question, does anybody have a problem with making that a requirement? That's all I had to say. I'd like to open it up for discussion.
YSV: Thank you. The queue is currently empty. So I will leave it up for a moment. Please add yourself to the queue if you have any comments.
CM: I've been looking through the agenda and I'm trying to understand - what is the thing that is being proposed here? It says it's a requirement change, but what is the change?
PFC: Currently It's not documented whether proposals in stage 3 can make normative changes to the proposal without the approval of the committee. And so, what I'm proposing here or actually what Mike is proposing is that committee consensus is required to make normative changes to proposals in stage 3.
CM: Okay. That's very clear. Thank you.
PFC: And then the second change, is that those normative changes must be submitted to the agenda before the agenda deadline.
YSV: Great. Thank you for clarifying that Philip. Do we have any other clarifying questions or topics for discussion on this item? While people are gathering their thoughts I personally support the change.
JHD: I do support the change, but I think that the deadline may be an issue in the sense that if a day before plenary, we discover that a normative change needs to be made in a proposal for some sort of urgent implementation reason. It seems unfortunate if somebody could delay that by, you know, up to two months solely on the basis of the deadline. And risk further web incompatibility. So it seems to me like it's a courtesy - like whenever possible we should be putting it before the deadline, but that it feels like. That shouldn't be a constraint because normative proposals, normal changes to things in stage 3 seem like urgent matters to me.
PFC: I don't disagree with you, that it would be unfortunate if we had to delay it, but I think that phrasing it this way with the deadline puts the burden on the person proposing the change, rather than putting the burden on a delegate who might be uncomfortable giving their okay to something that they didn't feel that they had enough time to review. In practice — for example in the October meeting, FYT found a bug in the Temporal proposal just the day before our presentation. We fixed that and we asked if anybody had a problem with presenting that for consensus the same day and nobody had a problem with it. I think in practice, we do have this flexibility. Though I get what you're saying, on the other hand, I feel it would be equally unfortunate if I were able to propose some sort of major normative change just the day before the meeting and put the burden on other delegates to object to it on the basis of it not being on the agenda. That's my feeling about this, I don't know if other people see it differently.
SYG: I want to ask for a clarification from JHD about the urgency of such bugs. So suppose one were to be discovered. Where stage 3 normative changes would be urgent are things like something is, you know, I guess insecure or something has a major problem that we didn't foresee. I'm not sure in that case the plenary should be the first line of defense for that, like, if that such a, if such urgent concerns were surfaced regardless of whether it advances or if browsers, for example, or other implementations have shipped. I imagine we will try to undo that and that's a separate process than awaiting consensus. Like, if something is so urgent. It's like an insecure thing. We must not let it continue to be on the web. I don't think browser's are going to be Waiting for a consensus to do something about it. So what is it?
JHD: I wasn't speaking of the like when SharedArrayBuffers were removed. I'm not talking about that kind of concern. I'm saying if one browser implements something and discovers that there needs to be - or that maybe we want a normative change. That in the mean time until the next plenary when it can be put on in for it in advance of the deadline, a second browser may implement it or a third and it may get to the point where we no longer are able to change it due to web compatibility concerns. In other words, the window to make normative changes for things that are shipped is small in general. And so I mean, hopefully we would all be able to make these decisions ad hoc, right? their case by case rather and like and then somebody wouldn't lock solely on the basis of the deadline for something like that and you know, so on and so forth, but it's kind of that's what I'm thinking of is losing the opportunity to make a normative change due to web compatibility concerns caused by the delay, does that I see clarify
SYG: I think so, but that doesn't really change my hunch here, which is, I reckon that urgent issues of that nature are going to be resolved, adhoc by us like they have in past. I mean, we operate fairly High trust especially the browser vendors if something comes up. And You know, we do try to warn each other. I suppose if for whatever reason - like I just don't see TC39 plenary being the thing that might hold that up if something needed to be unshipped or something needed to be drastically course corrected. That is to say, I think that the deadline change is fine.
YSV: yeah, I'll just chime in and say that I feel like this can be addressed in multiple different ways and if there is a high severity thing, I think we have several avenues for that. The main thing that this may impact is how quickly the proposal gets to stage 4 in which case a proposal may or may not be included in that years’ specification, but it will be included in browsers. So I don't think that's necessarily a blocking situation for a proposal that Work will get finished. My position is I do support the deadline, deadline, but also I think maybe we can soften the language around how likely people are to block compared to the proposals because reviewing a full proposal is a much more significant change then reviewing most normative changes.
LEO: Okay. Just want to give a plus one if it's so noisy here. here. Just show me off too. there's I think this only reproduces what we already do in TC39 and I appreciate having this requirement for like, things need to be in the agenda as the same way as like stage advancement things does. Or for anything urgent, like Shu says I don't think the TC 39 plenary is the venue for anything urgent and this communication has happened in the past. I think everything's going to be fine. I appreciate the clarity doing these changes. I think we are fine. It's my take on this.
MM: I'm going to ask a clarifying question first, because if not sure that I understand, but if I did understand correctly, I think I strongly object to where we're going. Is the language that we're proposing here preclude someone at a plenary asking the plenary to make an exception. If the plenary has consensus to make an exception, then the process can go forward, under that, decision to make an exception. Does this language preclude that?
PFC: No, this doesn't preclude that at all. In fact, I think I mentioned that we did exactly that at the October plenary for one of the Temporal changes for a bug FYT discovered at the last minute.
MM: Okay. And this language would continue to allow that?
PFC: As far as I'm aware, yes.
MM: okay. In that case I do not object. I think that being able to ask the committee - all of our rules are promises to ourselves and we're right there able to make judgments. And I think if we have consensus on an exception, we should be able to proceed with an exception. So it sounds like we're fine, so I support this.
YSV: Thank you, Mark. The queue is currently empty and we have five minutes left. Do we have any last comments that people want to get in before we close this topic?
LEO: I understand MM’s question. And like I am in favor of this. I think it's nice to be clear to Mark here. I think there is one catch. We are still creating documentation telling delegates, They're not required to wait on consensus for something that is added after the deadline. We can ask for the exception, yes, but there's still the chance of one delegate might come in and say, I didn't have time to reveal this work so I cannot wade in because of that. you can ask for the exception, but they also need to rely on like other people accepting this.
MM: I'm not understanding if your are you disagreeing with the stance that I took because I didn't hear disagreement?
LEO: I don't disagree with you. I'm trying to give clarity. You can still ask for the exception but you need consensus.
MM: Yeah, I think that a normative change. Can't go in, until it has somehow reached consensus . yes, okay
LEO: but it still opens for someone to come in a delegate to to bring in like the the answer being solely based on, I didn't have time to review this because this was added to agenda after the deadline is exactly the kind of exception I have in mind.
MM: so that I have to it sounds like we're In complete agreement. I was also want to explain why I'm very uncomfortable with the argument that SYG made in particular. Although when we say that, it's a completely addressed by the fact that we agreed that we can do exceptions. The thing is, when there's an emergency and something needs to be changed, even if all the browser vendors or all of the engine vendors, all agree that it needs to be changed, it might be complicated and subtle to figure out what the changes and we seen multiple times that people who thought they were in agreement without an extended discussion actually interpreted the agreement in different incompatible ways. Therefore the, the process, that TC39 brings of having a discussion to reduce the ambiguity of what we think we're agreeing to is often very valuable even in an emergency.
SYG: I'm not sure what part of my argument you disagreed with. I don't think we should bypass that process. I was saying. That the urgent.. that TC39 is not on the critical path. For urgent things that need immediate like product level, mitigation, like turning something off. That's a product decision and it remains a product decision, exactly. So that could hatch out normative things. Okay? Normally changes that need to be made in community.
MM: Yeah, so I agree with that completely, especially the scenario of turning things off, like SharedArrayBuffer because it's very easy. To not misunderstand, not have ambiguity that causes people to do different things. If it's just turning things off, if the thing needed to repair is more subtle then it still might not be able to wait for a plenary in which case doing something else is certainly called for. But the kind of process that we go through in reaching consensus can still be very valuable. If there is a danger of ambiguity in what you all are agreeing to do.
SYG: Sounds like we are in agreement.
MM: Great.
YSV: So I would like to jump in here and pause our discussion because we do have one minute left on this topic. PFC, would you like to request consensus?
PFC: I would like to request consensus on the change for documenting this requirement and for the deadline. I've heard a lot of concern about the deadline, although it seems like people are generally in favor of it. Maybe I can address those concerns by adding language explicitly to the change that says something like, 'it's encouraged to ask for an exception if need be.'
MM: Yeah, I would appreciate that. And, and even without the the language it sounds like it's clear enough that it doesn't preclude that that I'm I'm in support but I do I would prefer that that issue be made explicit. Thank you.
PFC: Can we have consensus on this then?
YSV: We have silence at the moment. It sounds like we have consensus.
PFC: Okay. Thanks everyone.
YSV: Just to be clear for the notes. We have consensus on the 2 PRs modulo, a change to soften the language and encourage exceptions.
- consensus to document that normative changes in stage 3 require consensus
- consensus that these should be added to the agenda with the same deadline as stage advancement items, but with softer language (i.e. exceptions to this requirement are expected)
Presenter: Joshua S. Choi (JSC)
JSC: Okay, slide 1. This Array from async for stage 3. I presented this at the previous plenary last month. When it achieved stage2 and two reviewers have signed off Jordan and Niccolo? Thank you both for reviewing of course, of course the editors need to take a look at it, too. But other than that, I'd like to present for consensus for stage 3
JSC: This is going to be a rapid review. Array.from the sync is basically the same as Array.from except it works on async things. The analogy is between for vs for await. This is useful for dumping async iterators and to async a single synchronous data structure. People do this for testing, for debugging. Like when you quickly want to see what an async generator or stream actually contains. This happens in command line interfaces. The explainer has some real world examples from Adobe, from ipfs, there's a npm package that gets a bunch of downloads, but this is so easy to re-implement that it's probably underestimating. But this is a real hole in the standard Library, given that we have async async' iterators and array.from
JSC: The spec is available for anyone to read, it's short, it fits on one page and this image links directly to the spec
JSC: Continuing the Brief Review of the semantics. This is a generic Factory method. It has three arguments, the first one is required. It's pretty much like array.from except it always returns a promise and the items can be an async iterable. So the return value is a promise that resolves to the new array. if it's everything goes right. It basically creates an array, it drains the input into that array.
JSC: Like for await, it works on sync iterables too, so it's basically the same, except that if the sync iterable yields promises, those get awaited. This is the same thing as for await.
JSC: One more thing is that array dot from supports non iterable array like objects as inputs. These are objects that have a length property as well as numeric properties, and these are treated like as if they were arrays and they are iterated over. Array dot from already does this. We think that this would be quite surprising if array.fromAsync did not also support this there. It's basically the same as if they were sync iterables one representative in particular thinks that these objects are very much, not obsolete. Even though we have iterables now, and this was pre fleece???. We discussed that, in November, plenary without objections
JSC: This is a generic Factory method. Symbol.species isn't involved at all. Instead it, this receiver is treated as a Constructor, if it's not callable, if it's if it's not callable, then it's treated as the array built in by default, but it will be called with no arguments and then stuff will be added to it. So, this is the same as array dot from. Items are numerically assigned to the constructive data structure. Which again, is an array by default.
JSC: So, optional parameters. There are two optional parameters, same as array dot from. The first is a mapping callback and the second is a this value that's supplied to the mapping callback the this receiver by default. It's the first optional. The mapping. Callback is basically an identity function. Same as array.from the second optional parameter is undefined by default. These match the behavior of array dot from and their exclusion would be surprising to any developer who's already used to array.from.
JSC: So the summary of this error slide is that array.from async will never synchronously throw an error, any will be a promise Rejection. It will always return a promise to prevents Zalgo. So that we this goes comprehensively through the different types of errors that can happen and these all result in promise, rejections, one thing that's not on this slide is that async iterator cleanup happens in the same way as for await.
JSC: One more thing that came up since the last plenary, this regarding when the identity callback is omitted. We're trying to treat it as an identity function. So it's equivalent to supplying like v return v. The if you don't include an identity call back, so because of that and because the result of the mapping callback is awaited so that we can use async functions as the mapping callback. That means that the result of each value. If you don't Supply a mapping and callback is awaited, that might be a little that might be slightly surprising to someone used to using For awaits and not awaiting the each value because for-await does not await values of async iterables. It does await, each value of sync iterables, but we think of, but we think that this is important enough to match the behavior of supplying an identity function explicitly. This is the only thing that might I can think of them might be a little contentious, but I think that this behavior is find and good enough for stage 3, for me.
JSC: These next slides are the same as the previous plenary. This goes over cross-cutting concerns with other proposals. For instance, iterator helpers has a toArray method on iterators. That overlaps. We think this is okay. And that they can coexist. If we had to choose, I would rather have a array from async on the array Constructor because array dot from already exists and we should exhibit the match that precedent, but we think it's okay to have both anyway.
JSC: Right now we're focusing on array only, we're not focusing on sets or map or object entries or whatever or typed arrays.
JSC: It's called fromAsync not asyncFrom to match precedent with Atom.waitAsync and also some web GPU APIs.
JSC: There's an editorial changes that we can make to the array from async spec. It currently uses array.prototype.slice.call see it in step 3, 3D to when using sync, iterator is getting defined. So, if non-async sync input is given, then it basically uses array dot prototype dot values, which is pretty much the same thing. We could make it so that the array dot from method, the synchronous existing method, relies on array.prototype that values to the algorithm currently does not. And I'm pretty sure it's completely equivalent. And then, we can also try creating abstract operations to maximally share steps, same with iterator helpers toArray. That's about it. Let me take a look at the queue clarifying.
WH: Can the map callback be either sync or async?
JSC: Yes. the map callback can be either sync or async. Either way its result is awaited. That why that is why Yulia if you could go back to slide 11, that is why omitting the map callback results in each value getting awaited because it's the same as supplying, an identity function and each result of the identity function would be awaited. So yes, the Callback can be sync or a sync and each result is awaited.
Does that satisfy your question?
WH: Yes.
KG: I am generally strongly in favor of the sort of reasoning that you use to end up with this double await, where you really want omitting the argument to behave like passing the identity, that's generally good reasoning. That said, I think that the overwhelming majority of usage of array.from and probably also array.fromAsync will not pass the second argument. And I think if you are not thinking about this analogy with the identity function, the behavior that you are proposing in this case is very surprising, not behaving the way that for await would have behaved. So I think it makes more sense to optimize for the common case rather than trying to match the case where you pass the identity.
JSC: I think this is reasonable. The two other Alternatives that I can think of one making omitting the mapping call back different than than using an identity call back. I do not like this at all
KG: Seems fine to me.
JSC: So the other alternative which I like a little better if that's palpable to you is to make the mapping callback synchronous only so that So that each result from the mapping callback is not awaited.
KG: seems bad.
JSC: Okay, Okay, so you so I’m understanding you correctly, you would rather have omitting, the callback behave differently than including an identity function callback.
KG: I would prefer to have it behave differently than including an asynchronous identity callback. Yes.
SYG: You have the double await problem because you're assuming the omitted identity is the synchronous identity.
JSC: Yeah, that is a third alternative. Yeah, we could do that. I think that's reasonable. We could do that, I would like to get a temperature check about that result. And then perhaps, if I commit to that, would I be to get just get stage 3 now or what? I have to come back next plenary with the updated spec text.
SYG: It's a tangent from from that point, but for stage 3, when the editors were triaging proposals going for stage 3, when we looked at it on the agenda. I don't think it was marked as going for stage 3. So we have not reviewed it editorial yet.
JSC: In that case. I can in that case, we can make this an update. And then I can have, we can properly mark it next time and if I'm getting a, if I'm getting the sense that everyone is fine with making the identity callback async, the v returns await v; is that if everyone's fine with that, then I will change that.
JHD: The identity function is like x => x, right? If you just stick an async in front of that. Is that the same thing then? Because an async function automatically awaits.
JSC: It should be yes. So to that, that should be the same.
JHD: OK, I was originally in favor of the double await because I want the consistency there. It does seem completely compelling to me to say the identity function for Array.from is x => x, and for Array.fromAsync is async x => x. That seems very straightforward and intuitive to me. So I'm on board with that change.
JSC: so WH, just to clarify for you, what we're talking about is the behavior of the function, when no mapping callback is supplied. What should it be? What kind of call back? Should it be equivalent to no callback. if it should be a good one to call back. right now, Right now. If you don't supply in mapping callback, it's equivalent to supplying async, sync function, sync, identity function x to the X return X, but we are, but That necessitates us a winning every waiting, Everything twice. When we don't support. When we Supply, that synchronous identity function. And when we omit the mapping function.
WH: Where are the two awaits?
JSC: Going to the spec... So if mapping is true… Oh wait. Yes about Yes, that's right. Actually right now the spec only awaits once when mapping is false, but then that would be equivalent that's an error in the spec right now. It should be. It should be awaited twice. Basically, what we're saying is that they would be a way to await twice because it would be equivalent to supplying a synchronous identity call back. So I think, I think that, I think it's okay to just make it await to make it await once. So in fact, the spec right now matches. That's what yeah, the spec right now actually matches return supplying async x => x. So, in fact Waldemar, yes, the spec actually matches the proposed new semantics. My slides are incorrect.
WH: Okay, so there's no change when mapping is false. Still a bit unsure about whether we were talking about awaiting the result of the mapper or doing await of its argument, before it does the mapping.
JSC: Okay, yeah. right now, like let's say you have an async' async' generator that yields a bunch of promises. So basically the question is when you don't supply a callback, will the yielded promises get awaited or not? Right now in the in the specification or me go through this again It mapping is false. Else let it gets awaited once. So basically I. yeah, okay. Let me come. Let me come back to that. But come back to the spec later and check this one more time, but either way now. I'm getting a sense from plenary that if when a callback the mapping callback is not supplied. Do we want each value to be unwrapped value to awaited should or not? Oh, wait. No, the double await thing. Actually, wait, I'm sorry. Sorry, who was the one? Who was talking about the double await thing. KG?
KG: Yes
JSC: Were you talking about when synchronous iterables are given as an input and they get double awaited? Or are you talking about? Can you can you give a specific example of when something would be double awaited?
KG: No. This is hard to talk about without code. My understanding of the double await thing was that there would be an additional await that we are only putting there because of an analogy to what happens when you pass the second argument. And my position is that we should not worry too much about what happens when you pass the second argument. When trying to figure out what happens when you don't pass the second argument, we should figure out what the best behavior is when you don't pass the second argument, independently of the second argument.
JSC: Okay, I think that in that case, let's talk about this more in the issue. The issue will be issue number 19. We can talk about it more than but but basically, we've got a bunch of different kinds of different options here. For instance, when we don't supply amapping call back and we have an AC and DC link input. We can, we can not await anything. Which we can't because we want some sort of identity callback equivalency. We can await each value once or we can await each value twice. So I think that we all want to await each value only once and that and to have it equivalent to supplying async identity function as a call back.
KG: That would not be equivalent to passing the async function as a callback because that would do two awaits.
JSC: Oh, right. Okay, we can we can return, we can return to that. But the goal would be to only await once is that and you and you would strongly object to anything involving to awaits is, is
KG: I'm not going to say I would strongly object to it, necessarily. My position is we should figure out what behavior is reasonable when there is only one argument without thinking about the second argument. If there is a strong reason to have two awaits even if there isn't a second argument that I am fine with that, but if the only reason to introduce an additional await is because of reasoning about the second argument that I am opposed to that. We should figure out what the best behavior is in the absence of the second argument. Like, without thinking about the second argument at all.
JSC: Okay, in that case, I think, yeah, I only realized a couple of these issues today. So I think that we can come back here next plenary, and we can discuss this more in issue number 19.
WH: Can you bring up the spec on slide 4?
[displayed]
WH: I see one await in step viii, where is the other one when mapping is true? I don't know what IfAbruptCloseAsyncIterator is. Is there an await in there?
JSC: No, there is not. So right now, in the spec, there's only one await when mapping is false on each result.
WH: So then where's the other await when mapping is true?
JSC: the status quo to spec itself — there is only one await in each case. It's not equivalent to including an identity call back. So yeah, we'll come back to this. So I'm not going to try for stage 3 properly this time. We'll come back to this after resolving this omitting mapping function semantics.
JSC: Let's see what's on the queue.
KG: I think it would be helpful to have slides that give examples of the different behaviors We're talking about because I was having trouble keeping track of that track of that in my head.
JSC: Yeah, okay. And by that, you mean like different potential behaviors for like -
KG: Like, here are some code snippets. This is what this code snippet does under the behavior we are proposing, this is what it does under this alternative that we considered and rejected, so that we can understand the decision we're making.
JSC: Okay. Got it. All right, we can do that. All right. Is anything else before we close this part of it?
JSC: All right. Thanks everyone for listening. We'll come back next month with with a clear semantics for when the mapping call back is emitted.
- Not advancing, discussion of double-await to continue in tc39/proposal-array-from-async#19
Presenter: Shu (SYG)
SYG: Okay, I have also have no slides for this. This is mainly to come back to when we brought it up the first time and MM had raised concerns that he would like more detailed review of the algorithm since which I believe he has done on a GitHub thread. thread. There are so, I was trying to get something actionable out of that thread and please correct me if I'm wrong MM my understanding of your current position is that still are in favor of some group within TC39 taking over the structure clone algorithm, but you are not in favor of the being with ecma262 to the document. Is that correct?
MM: That is exactly correct. Thank you. Structured clone is incompatible with the semantics of JavaScript. It does not belong in the language, but the maintenance, the maintenance issue of keeping structure clone itself the language, which it needs to do is much better done us. So yes, you got my position, exactly.
SYG: Okay, then I would like to move on to Kevin's question because I'm not quite sure what you mean by incompatible. Like it exists and people use it. So it's at some prima facie level it is compatible.
MM: Do you happen to have the issue number handy or actually best would be could you paste a link to the issue into the echat?
MM: Yeah, because I went through in detail. The algorithm I noted, noted many things. I noted many things but the answer to the question, the only one I remember off the top of my head is proxy. So I need to review in order to remember what my other objections were. So I'm doing that now you can get, you can go on. however, you want to handle this, but it's going to take me a while to review this thread. and, and remember what my other objections were
KG: MM I'd like to talk to you about proxy, but please go through the thread first, okay.
SYG: In the meantime I guess I would like to clarify our position here. So structured clone as it exists today as specified by the HTML specification works a certain way, and it's not open to being changed because the web platform depends on it. That is the existing behavior. However, specifically in the case of proxies, all proxies cause this algorithm to throw currently. And the usual game we play with web compatible changes, is that we are able to change things from throwing to not throwing. So it is out of scope for this particular proposal, which is just taking over maintenance of the thing verbatim. Um, Chrome in V8 are certainly not against extending this proposal to have it work with proxies given that they do not work with proxies at all. So I want to clarify that we are not against any proposed changes, but we are not proposing changes and we want to not propose changes in the scope. Taking over maintain ownership. Then just do it later. Okay?
MM: Given that I'm going to, I think I can reply in a sufficiently general way. As to cover the things from that thread. not remembering. Also, I'll stipulate there. All of my objections are in the thread. I review the algorithm carefully at the time and any And so I'm content to to stipulate that that only the objections that I raised In the thread are ones that I'm expecting to come back to. Your position, the position you just stated on proxies. Let me see if I can State a general form of that if there are adjustments to the structured clone algorithm that the browser vendors agree is sufficiently web compatible - it doesn't have to be web compatible in theory, we've often broken things that are web compatible broken, Web compatibility in theory, but not in practice. If they agree that it's web compatible enough that they're willing to consider those changes. Then a structured clone that that is modified to deal with the show-stopping algorithms might at some point, be on the table, and certainly if it meets the objections that I consider show-stopping, whatever those are then I would be very happy to see it enter 262.
SYG: Okay, I'll clarify with a quick response. All I'm saying is that agree that Chrome is open to extension here and at the same time also saying that Chrome and specifically myself will not be taking the initiative to do the extension, we won't be objecting to the extension. if it's web compatible as you say,
MM: okay, so as far as the initiative goes, let me let me just make sure that we're saying the same thing. Just as I took the initiative to go through algorithm and accumulate objections in order to make this particular form of progress, you would expect me to go through my objections and think about what changes I might be able to propose to structured clone that you would find acceptable and that the result of the changes to structure clone to be acceptable to me and, and obviously, until I go through them and for me, formulate, those proposals, I don't know that there's anything that hits that sweet spot, but it would be up me, to take the initiative to finding that sweet spot. And if I do find it and you guys are agreed. And then obviously we need committee consensus in whatever the state is. Then such a mutually agreed structure clone could go in 262. Am I getting it?
SYG: I think so. I don't want to put this all on you, MM. I think of other other interested parties who want this to work with proxies. They're certainly also welcome to do so, there might be an intermediate state here where we still want to take over maintenance before this normative proposal takes more concrete shape. and maybe we do that in a separate as you hinted at but but maybe in a separate document giving your objection direct the question into 262.
MM: Yeah, I think I thought I was explicit about the separate document. But yes, I think especially given that we don't know what the timeframe might look like for resolving, whatever these open issues are. But there's immediate maintenance reasons to move it under TC39. I think seeing that separate document as hopefully a stage that we grow out of, But starting there is a good way to move forward.
SYG: Then I think we're on the same page and let's move on to the queue.
MM: Great.
JHD: Without having anything concrete in mind, I had a hypothetical question. SYG. You were very careful I think to use the word "extensions". What if there are changes that are web compatible, are not extensions, that drop functionality or alter existing functionality that already works. Is that something that potentially Chrome is open to, or is that something that you think wouldn't be able to ship?
SYG: the year re? Yes, but it definitely has a higher bar because that runs the risk of convincing a browser vendor Chrome or Firefox or whoever wants to take the initiative to ship and see, right. It's it be we can do corpa analysis as we have in the past. Need to try to do static analysis on web archive or something like that. But at the end of the day, non extensions, changing things that don't throw into other behavior that also don't throw, or throwing I guess, it's just harder to figure out if they're truly compatible.
JHD: So no philosophical objection, just the standard technical barriers to making potentially incompatible changes.
SYG: Right, but I mean, depends on how you mean by for philosophical is the is the right distinction. Here is probably should just like how far were you get in convincing people? and you might not get very far very fast.
JHD: Thank you, that clarifies.
KG: MM. So in the thread you expressed surprise at some things and I wasn't entirely sure which of those were objections and you also expressed places where you thought wording needed to be improved, which I largely agree with. So, I am not entirely sure which of the things are like you have issues with the normative behavior, versus just how it's written. One place it was very clear you had an issue with the normative behavior was that currently, it throws for proxies. And I wanted to ask you if treating proxies like a plain object or I guess in the case that they wrap a plain array or in the case that they wrap a callable behaving like those, if that behavior would be acceptable you. That is, in the case that let's say it wraps something which is not IsArray and which is not callable. Then you just call enumerable own properties or whatever the trap is called and serialize all of the properties. And on the other side, what you get is an object with those properties. Is that a reasonable behavior? Because that's the only one I can imagine working here.
MM: Let me, let me test your question against the following hypothesis, which I'm hopefully the answer is yes. Let's right now. The algorithm is phrased in terms of directly reaching into various objects accessing internal slots. For many of those things for non exotic objects, the behavior of accessing the internal slots is equivalent to accessing one of the traps, one of the internal methods where if the object is a proxy, the internal method is reflected into a handler trap. And if the, if the object is a non exotic object then, Phrasing it in terms of the internal method rather than direct access should mean at least close enough to the same thing, but that makes everything work with proxies not by completely enumerating what the proxy behavior is as a separate case that you hope maintains the equivalents but maintains equivalence. Because all of the semantics is phrased in terms of interacting with the objects internal Behavior, rather than directly accessing it’s internal slots.
KG: So, 50%. There are as you say a lot of places it reaches into internal slots, and I think that's not likely to Change.
MM: Even if you're watching this and you say, you not not likely to change, even if the other way of phrasing. It is, in fact, behavioral equivalent for non proxies.
KG: Well, the problem is that - you're reaching into the internals of like a platform object or a Map. There isn't any other way of phrasing "reach into the internals slot of a map", Like that's just - there's no trap that gives you the entries of a map. You just have to reach into those slots. That said, I said it was only 50%, because for specifically, the case of objects and arrays, those specific cases could easily be phrased in terms the regular MOP (meta object protocol) methods and proxy could fall into those cases and then work the same in, specifically, those cases by virtue of, like, in the case that you don't do anything special. You just fall back to the normal, hit the internal methods case. And then, yes, Proxy would work the same way.
MM: Okay. So, first of all, that I'm very glad to - so let me make sure we're arriving at the same conclusion scoped to normal non exotic objects.
KG: Not just non-exotic. Map is not an exotic object. It just has additional internal slots. So this is scoped to things that don't have additional internal slots.
MM: Okay, so for things that don't have additional internal slots and are not exotic. So, let me specify both of those for those things if specifying the interaction behaviourally. So that the interaction with proxy simply follows rather than being enumerated as a special case, you are open to that rephrasing of those parts of the spectrum.
KG: Well, I can't speak for anyone else. But like that was what I had in mind for proposing a change. Yes.
MM: That's the clarification I wanted. That's fine.
KG: to be clear, Proxy would still be a special case because proxy is an exotic object. So this case would be: anything that doesn't have additional internal slots and is not exotic, or is a proxy.
MM: Right, right, right. Okay, but there's not a delicate, these two ways of saying the same, semantics must be held to be equivalent even though they're stated in a completely different way, but that's the maintenance that I want to avoid.
KG: Yes. It would have the same semantics, just the test for whether to use the semantics would mention proxy explicitly.
MM: Now with regard to, let's take Map specifically. We do have an extension point that we reach for one occasion. On occasions like this, which is the committee can create new well-known symbols and define behaviors in terms of the well known symbols that have no observable difference for any code that doesn't use those. Those new well known symbols, so, so for example, a symbol that says, I want to be treated as map like and then if that symbol exists and structured clone tests for it, then it proceeds to interact with the alleged map behaviourally rather than reaching into internal slots and then a proxy that' membrane aware, that it needs to decorate. the the proxy with the symbol in order to be transparent through, membranes could go to go ahead and do that. I'm not proposing that specifically want to raise that as an example of how we might extend the sweet spot without having enumerate, lots of special paste, proxy behaviors, but still have more objects be practically transparent across membranes.
KG: I think that would be a much larger change than the one I was discussing to just treat proxies like plain objects, and I think much more contentious, but you are welcome to pursue it.
MM: Okay. I don't think we need more agreement on that issue than this.
YSV: Mozilla is open to extending structured clone.
SYG: I think Mark that there is agreement that that you do, find the maintenance argument compelling. So I would like to go do the actual work of bringing it into a TC39 thing. But, as a separate document. So I want to reaffirm that consensus. Before I move on to the rest of the conclusion.
MM: I am in favor.
SYG: Okay, hearing no other concerns. I'll take that as consensus. And as part of that work, I am partial to the proxy solution that KG outlined. I would be pretty skeptical - and right now would be against kind of adding new possible user code calls in structure clone. It sounded like with the well-known symbol idea it's possible that it results in a bunch of arbitrary, user code, being called when you try to structured clone stuff. That doesn't seem great to me, but we can certainly discuss.
MM: Yeah, the proxy solution also causes user code to happen during structure clone
SYG: But for proxies, not for non proxies.
MM: Well, for the non proxies, that would be only those decorated with the symbol and the symbol thing is just the first thing that popped into my head. The main thing that I that I wanted to resolve now is you are open to exploring further extensions beyond plain objects, in order to rescue practical membrane transparency.
SYG: In theory yes. I think that depends on are finding agreement on ‘practical’. Like, I think having ordinary objects being able to masquerade as other ordinary objects, is not something I'm really open to. But like having proxies masquerade as other things is something I'm open to. Like, I don't really agree with the program of, I'm going to give a plain object a symbol and then I'm going to have it be able to be serialized as a Map. Like, I don't really agree with that.
MM: I see. The part of that you're uncomfortable with is also not the part that's important to me. So, just to pursue this to make sure we're still can actually compatible in terms of what I want you to be open to exploring. Let's say the rule was, if the proxy - oh I can make it more straight forward. If the proxy's target object is a map, then the structured clone algorithm does some kind of behavioral interaction with the proxy that mirrors the - in order to extract what it considers to be the contents of the map, but it's now up to the proxy and Handler how to emulate the map.
SYG: That sounds like extending the meta-object protocol which is a larger discussion, but in theory, I would be open to it. But it seems like it even goes beyond just the context of structured clone, but, but again, I'm not closed to the idea.
MM: Okay, I think we have enough agreement that there's no problem going forward on this with an agreement to explore whether there is such a sweet spot.
SYG: And if I can call it call on some folks here. I know. That the shadow Realms champions in the Salesforce, folks are interested in this topic and should they have an interest in helping out here and extending structure clone in this way. I would welcome concrete use cases.
CP: Yeah, we are interested.
LEO: Yeah, we can we can Define as be part of the conversation. So I want to explore that and I want to further discuss this with Mark, maybe during the ses meetings because I also think like going if anything from like a static. Production from when a proxy object is out feels like too much magic right now. And think userland membrane systems can still take care of this but it's something I should probably move this discussion to make sure I am on the same day I get on the same page with Mark first. But I'm also an agreement of not doing much for proxies when they are found in an structure cloning abstraction. Other than just like static extraction of the values.
SYG: Okay. Yeah, that sounds like this question for the next step after getting this pull down into tc39 level, in separate document. So the next concrete, Next Step here will be. This is not a proposal so I don't really know what our process should be. But I'm going to treat it as a call for reviewers for this separate document. In addition to editorial review. So, any I wouldn't like Mark to be the one of the reviewers when this separate document was prepared. I like to at least two other reviewers.
MM: I mean, so I volunteered to review. I just want to say, I'm not sure how much time I will have altogether. So but certainly enough time to contribute some as a reviewer.
SYG: Thank you.
CP: I can review it as well. I also have a clarification question. It was my assumption that the biggest challenge for implementers was hitting user land code in the structured clone code path. Can you confirm that this is not really an issue anymore?
SYG: I unfortunately cannot confirm that is going to be a non-problem going forward. But I mean, it's engineering, I suppose. It'll have to be looked at, right? But I don't think It's like so architecturally, impossible or something. it's kind of undesirable, but that's a separate thing.
Okay, so that's the end of the queue. Do you want to proceed?
SYG: Yeah, I mean it's not a proposal. So I reaffirmed the consensus that I want and laid out the next step. So hopefully those are clearly recorded for the burden notes in The Next. Step here to repeat is to present draft of the separate document that pulls down the structure, clone algorithm from the HTML spec into a TC39 own document with the necessary editorial changes to make it the more better than, how HTML folks have written it. And then getting getting that reviewed. And I guess approved. The host is, it is very tc39 and then the step after that would be for interested parties to propose changes. To the structured clone algorithm.
MM: I'm in favor.
- Draft a separate document with structured clone, owned by TC39 but not initially part of 262, with necessary editorial (but not normative) changes.
- Interested parties to pursue changes to structured clone after that