diff --git a/meetings/2020-07/july-20.md b/meetings/2020-07/july-20.md new file mode 100644 index 00000000..62429729 --- /dev/null +++ b/meetings/2020-07/july-20.md @@ -0,0 +1,542 @@ +# July 20, 2020 Meeting Notes +----- + +**In-person attendees:** + +**Remote attendees:** +| Name | Abbreviation | Organization | +| -------------------- | -------------- | ------------------ | +| Yulia Startsev | YSV | Mozilla | +| Robin Ricard | RRD | Bloomberg | +| Mark Cohen | MPC | PayPal | +| Bradford C. Smith | BSH | Google | +| Chip Morningstar | CM | Agoric | +| Mark S. Miller | MM | Agoric | +| Myles Borins | MBS | GitHub / MSFT | +| Shane F. Carr | SFC | Google | +| Sergey Rubanov | SRV | Invited expert | +| Ujjwal Sharma | USA | Igalia | +| Philip Chimento | PFC | Igalia | +| Richard Gibson | RGN | OpenJS Foundation | +| Nicolò Ribaudo | NRO | Babel-InvitedExpert| +| Istvan Sebestyen | IS | Ecma | +| SongYang P u | SYP | Alibaba | +| Waldemar Horwat | WH | Google | +| Rick Waldron | RW | Bocoup | +| Jordan Harband | JHD | Invited expert | +| Justin Ridgewell | JRL | Google | +| Devin Rousso | DRO | Apple | +| Keith Miller | KM | Apple | +| Michael Saboff | MLS | Apple | +| Chengzhong Wu | CZW | Alibaba | +| Marja Hölttä | MHA | Google | +| Rick Button | RBU | Bloomberg | +| John Lenz | JJL | Google | +| Felienne Hermans | FHS | Leiden University | +| Leo Balter | LEO | Salesforce | +| Mattijs Hoitink | MHK | Apple | +| Mary Marchini | MAR | Netflix | +| Rob Palmer | RPR | Bloomberg | + + +## Adoption of the Agenda +No objections to adopting the agenda as proposed. + +## Approval of the minutes from last meeting +No objections to approving the minutes from the previous meeting. + +## Next meeting host and logistics +BT: The next meeting will be remote. More to come. + +## Secretary's Report +Presenter: Istvan Sebestyen (IS) + +- [Slides](https://github.com/tc39/agendas/blob/master/2020/tc39-2020-036.pdf) + +IS: (presents slides) ECMAScript 2020 has been approved by the Ecma GA on June 16, 2020. Many, many thanks to everybody in TC39 who has made this possible. Otherwise the GA was via conference call, very short. For TC39 relevant: to elaborate a liaison Agreement with CalConnect was encouraged by the GA. + +## ECMA262 Update +Presenter: Jordan Harband (JHD) + +- [Slides](https://docs.google.com/presentation/d/1O8wGWehzMhqb_Jz2JfmyUxyUepxanc8sEVMlTRUVnfo) + +JHD: (presents slides) + +## ECMA402 Update +Presenter: Shane F. Carr (SFC) + +- [Slides](https://docs.google.com/presentation/d/1C54jVjcuE27wq658CbMi0KEfa5ded_WIWvdq1JP8QDI) + +SFC: (presents slides) + +WH: Does #471 affect output or only avoid errors? I looked at it, it’s full of code so I couldn’t figure out what the effect of that change was. Is it only to avoid range errors or does it affect the way things round? + +SFC: It only affects the RangeError, there is no change to the rounding behaviour. The current problem is that if you have this code, this throws a range error because the currency EUR requires two fraction digits, but you set maximumFractionDigits to 0, and that’s a conflict. However, if your currency had been JPY, for example, then there wouldn't have been a problem since the maximumFractionDigits is already 0 for that currency. It doesn’t fix any other behavior other than eliminating this RangeError. maximumFractionDigits will win out and override the currency. The current workaround is to specify both minimum and maximum at the same time, but that’s undesirable. + +``` +new Intl.NumberFormat("en", { style: "currency", currency: "EUR", maximumFractionDigits: 0 }); +``` + +DE: There's a presentation coming up about this on the agenda. Let's defer this discussion. + +WH: My question is answered. + +SFC: Can we call for consensus? I was not aware that there was a separate agenda item for 471. So how about consensus on 459? + +[silence] + +SFC: I’ll take that as consensus. And we’ll get consensus on 471 when it comes up later. + +### Conclusion + +Consensus on PR 459. + +## Test262 status update +Presenter: Rick Waldron (RW), Leo Balter (LEO) + +- [slides](https://docs.google.com/presentation/d/1tsqTUZioHi8YxRF_CapxcZTjZQYDClEgXOFUm0W4gHg) + +RW, LEO: (presents slides) + +### Updates by the numbers, since last TC39 Meeting... + +113 new test files +92 commits +50 Merged PRs +26 Closed issues + +### General Outstanding Updates + +Coverage improvement for Atomics, e.g. relaxation and waitAsync +Coverage improvement for Promise functions +Intl on the fast track +`eval?.()` w/ further discussions in this TC39 meeting +Improvements to IsHTMLDDA +Improvements to Optional Chaining tests + +### Meta: Renaming master branch to main + +The etymology of "master" in git branch name conventions has been traced to the master/slave metaphor. +Tracker issue: https://github.com/tc39/test262/issues/2699 +Current status: Test262 default's branch is now `main` + +### Extras + +Improved language in tests removing usage of blacklist/whitelist. +Thanks to Tierney for pointing those out. + +## ECMA404 Update + +Presenter: Chip Morningstar (CM) + +BT: Do you have slides? + +CM: No, I didn’t have time for that. + +CM: Imagine, if you will, a blank screen. + +CM: And that’s it! + +BT: Okay, thank you for the update on ECMA404. + +## Update from the Code of Conduct Committee +JHD: There was a tense discussion on the pipeline repo which Aki was able to step in and moderate. Otherwise, it's been uneventful. + +## Retroactive consensus on Unicode 13 property names and aliases (#1896, #1939) +Presenter: Michael Ficarra (MF) + +- [PR #1896](https://github.com/tc39/ecma262/pull/1896#issuecomment-642301441) +- [PR #1939](https://github.com/tc39/ecma262/pull/1939) + +MF: We originally did this thinking that it was entirely an editorial change. We brought this to the committee asking for an expedited process, but the committee actually decided to do the opposite and treat these updates as normative changes. In the end we never got consensus on the actual normative changes, so this item is asking for consensus for these changes that have already been merged. If there is no consensus, we will back them out. + +BT: Can you give a description of the PRs? + +MF: We include Unicode data in three tables in the spec and use it in RegExps. The committee decided we want to pin that data instead of referring to the latest Unicode data, because that's the way that engines will implement their unicode support. + +MF: I didn't consider that some delegates might be missing context from the last meeting, and don't have materials prepared. If anyone feels they are not informed enough, I can put some slides together and bring this back for the next meeting. + +BT: Does anyone have any questions on these PRs? + +[silence] + +MF: Okay, great, thank you. + +BT: Consensus that these two PRs stand as merged. + +## Specify \8 and \9 in sloppy (non-template) strings (#2054) +Presenter: Ross Kirsling (RKG) + +- [PR](https://github.com/tc39/ecma262/pull/2054) + +RKG: (presents PR) + +WH: What is the polarity of the changes? The presentation was unclear. You mentioned that you’d make an exemption for strict mode in Annex B. What does that mean? + +RKG: We can’t quite hear you WH, but I can understand from the text version on the queue, asking whether this affects strict mode. The user-visible impact is just on strict mode, that \8 and \9 become a syntax error in strict mode only. The polarity is confusing because the way we specify this is by allowing \8 and \9 in sloppy mode via B.1.2. + +WH: Will \8 and \9 continue to be errors in strict mode? + +KG: Strict mode is unchanged, these will still be errors. The hope is that engines that currently allow them in strict mode will prohibit them because they will be explicitly forbidden. + +DE: This investigation was really great and I'm glad this can now be standardized. I support consensus. + +BT: Okay, any objections to merging this PR? + +[silence] + +BT: This PR is good to go. + +## Adding Reflect[Symbol.toStringTag] (#2057) +Presenter: Jordan Harband (JHD) + +- [PR](https://github.com/tc39/ecma262/pull/2057) + +JHD: (presents PR) + +KG: To be clear, this is asking for consensus not just for this object, but for this to be what we do going forward as well. + +My position is that I don’t think it hurts anything to make it more obvious if you accidentally end up with the `Math` object in a variable that you then stringify, you know that it’s the `Math` object rather than `[object Object]`. That’s already the case with the `Math` object and it seems like it would be good to add it to other objects. It seems like it's helpful in some situations and never harmful. I'm in favour of this. + +SYG: I'm not asking for you to do this work, but have you looked if there are namespace objects in upstream specs that would need this added? + +JHD: The reason Domenic filed the issue [tc39/1970] is that the web platform is inconsistent and wants to be consistent. Of the three web namespaces WebAssembly, console, and CSS, WebAssembly gets a toStringTag, and the others do not. So if we decide that it should be added - which is Domenic’s recommendation from the HTML side - then the web platform would align in this way. + +SYG: Thanks for the list, I’m also in favor, and we should make sure that the other specs standardize toStringTag. + +BT: Any concerns? + +[silence] + +BT: Sounds like consensus. + +## Should eval?.() be direct eval? (#2062, #2063) +Presenter: Ross Kirsling (RKG) + +- [Issue #2062](https://github.com/tc39/ecma262/issues/2062) +- [PR #2063](https://github.com/tc39/ecma262/pull/2063) + +RKG: (presents PR) + +MM: First, let me clarify that with regard to the specific syntax on the table, I don’t care, in the sense that I don’t think that people are going to be accidentally writing this, so the hazards of having it mean the wrong thing is not a big issue. But the reason why I’m going to spend airtime debating is because of the issue of taking this as a precedent for a general policy, in particular what the consideration should be, and whether or not it should be a syntax error. + +MM: One of the criteria that we have applied and should continue to apply is what I’m going to call the hierarchy of painful surprises. If there’s a programming construct that some people who have never seen it before will assume means one thing, and some people who have never seen it before will assume means something else, then whichever one of those choices we make, some part of that population will be surprised. With something like optional chaining, it’s not a rare construct, and the thing that has a potential surprise has tremendous utility. So the cost of making it a syntax error is incredibly high. Once it becomes available in the language, it will be used a lot, and those who use the language will rapidly become familiar with it. + +MM: With -2**3, the issue for me was not that the person might make different decisions based on whitespace. The issue was that the surprise in both directions would lead to programs silently proceeding with wrong data, leading to painful runtime surprises possibly after code is deployed. The utility of allowing it (i.e. the cost of disallowing it with a syntax error) was very small. The extra cost of having to put it into parentheses to disambiguate it was very small and it avoids anyone having to face the cognitive overhead of remembering which of these two choices to take. The eval?. is not going to be common, it’s going to be very rare, when you’re reading someone else’s code you’ve probably never seen it before, so the reason I don’t care is that you’re not going to assume what it means either way. + +BT: Point of order, there are 2 minutes left in this timebox. + +MM: I’ll get to the punchline. A SyntaxError is an error during development time that is low cost even if you're surprised by it. The common reaction is “well that was rejected. How do I write the program I intend so it’ll be accepted?” The costs are low, the benefits are high. In this one I don’t care, but in general I think that’s a principle we should come back to. + +WH: For here, my opinion is that we should not make any changes, we should keep `eval?.` indirect. There’s lots of operators you can pass `eval` through that turn direct eval into indirect eval, so I think we should keep it simple and say that if you pass eval through any operator it becomes indirect. We should not make this into a syntax error any more than we should make `(0, eval)` a syntax error. + +SYG: I’m leaning - not strongly for - making it a direct eval. I am strongly opposed to making it an error, though, for the same reasons as WH. My priority here is consistency with the mental model that we’ve been teaching for optional chaining. With that being a very common feature that people will use, I think aligning with that, it would seem correct that eval?.() should be direct eval in that optional chaining just decomposes. I don’t think normal devs think about direct vs indirect eval, but I think they will think about ?.() as calling something if it's defined (not nullish), so that's the reason I'm leaning towards direct. + +JHD: When someone's using optional chaining, I do think they're thinking "this is the same as if I didn't put the ?, if the thing is not null or undefined." I don't think they're thinking about direct or indirect eval, though. Typically, when I’ve seen that explained, it’s that only if you’re typing literally `eval()` that it’s direct eval, and anything else is indirect. My understanding was that that decision was a way to web-compatibly remove as much direct eval as possible. It was a priority for the committee at the time to eliminate direct eval. If that's true, then making it direct eval would be adding a new source of direct eval, and invalidating the usual explanation of what direct eval is. It lightly seems to me that indirect would be the better choice, because anyone who wants direct eval isn’t going to expect eval to be nullish. + +MM: I was there at the time, and JHD is correct. We were trying to minimize direct eval because it's dangerous and strange. + +SYG: I think from an implementation point of view, minimization isn’t as important as having it be syntactically analyzable, which was the purpose of that split. And from that perspective, eval?. is still completely analyzable. + +BFS: [inaudible] (queue question: “reason to want to perform anything except direct eval in same source location?”) + +RKG: I'm not sure I have an answer for this. + +BFS: [in chat]: agree with JHD, can skip + +JRL: Want to remind everyone that this will affect future syntaxes such as the pipeline operator. Future things that also perform a call operation should also follow this, like `'source_code' |> eval`. That should also follow whatever precedence we set today. + +BT: RKG, did you get what you needed? + +RKG: Sure, I see a trend towards preferring to indirect, which I guess I’m okay with. I suppose I could rephrase to ask if anyone would object to direct. + +WH: I would object to direct. + +MM: I would also object to direct after hearing Justin's point. + +RKG: Okay. + +### Conclusion + +Keep spec as it is (indirect eval). + +## Forbid Numeric Separators in NonOctalDecimalIntegerLiteral fractional / exponent parts +Presenter: Leo Balter (LEO) + +- [Proposal issue](https://github.com/tc39/proposal-numeric-separator/issues/49) +- [262 issue](https://github.com/tc39/ecma262/issues/2090) + +LEO: (presents issues) + +WH: What would happen if you wrote `07e1_0`? + +LEO: I haven’t prepared everything - sorry, I’m trying to refresh my mind, but if we tackle this question do you mind if I take a note? I know so far it’s not implemented, or… + +???: It appears to be an error. + +LEO: Yeah, so `07.1` is an error, legacy octal digits cannot have fractional or exponential parts. So exponential operators are not allowed in legacy octal numbers. + +WH: Why not disallow `08e5`? + +LEO: This is something that has been there since forever. NoOctals allow exponential parts. I’m not sure if changing this will break the web, I haven’t done any research into whether we can remove exponential parts. + +LEO: So should TC39 work on a fix for this, or just go as it is today? NoOctals are ridiculous but I’m not sure if people are using them today. This is too much of a syntax patch for 262 to be worried about ??? being valid in ??? parts. + +WH: Since `07e1_0` or `07e(anything)` is an error, my preference would be to disallow these weird non-octal numbers with exponents or fractions altogether, if it's possible. + +LEO: Here is my follow-up slide that I just created. I’m not proposing for this thing to happen - I just wanted to point out there is an issue related to numeric separators and NonOctal numbers. But honestly, I agree with WH and SYG. + +WH: This is the first time I’ve heard of those legacy non-octal numbers allowing fractions but only if you include a number greater than 7 before the fraction. If there is a reason to keep then then we should work that out, otherwise we should get rid of them. + +LEO: [inaudible] + +LEO: What I want is to not block numeric separators from advancing to stage 4. The status quo is ??? and we can follow up with a broad solution, if we should be disallowing ???. Can we get a ??? for what I’m asking? + +RPR: What LEO says is that this is not going to block the numeric separators proposal and he will follow up with a separate proposal on this? + +LEO: Yes. + +?: Do we have an agreement? + +WH: What are we agreeing to here? We’re only discussing LegacyNonOctals, not numeric separators. So what is being proposed? + + +LEO: I’m asking to not block numeric separators from advancing to stage 4, because a change would ??? and I’m not really a big fan of that. Also we can tackle a follow-up for a better solution to disallowing exponential parts - perhaps fractional parts as well - from NonOctals, which I believe is also what WH and SYG expressed as what they would want. In this case we would not try to fix numerical separators on Non-octals and ??? and in this case the issue should be closed + +WH: I’m fine with that. + +SYG: I’m also fine with just allowing it. + +RPR: Sounds like consensus. + +LEO: PR will be closed, numeric separators will be unblocked on this matter. + +## Cognitive Dimensions of Notation: a framework for reflecting on language design +Presenters: Yulia Startsev (YSV), Dr Felienne Hermans (FHS) + +- [slides](https://docs.google.com/presentation/d/1OpKfS5UYgcwmBuejoSOBpbgsYXXzO0gG7GJHo65UXPE) + +YSV, FHS: (presents slides) + +WH: I don’t understand your definition of Viscosity. You said that eliminating types reduces viscosity yet removing types removes the possibility of finding all places that need to be looked at when revising data structures so it makes it harder to modify data structures. + +FHS: It’s an interesting question. We will go into detail on this dimension - YSV will give some specific JS examples, which may give you more information. You can definitely disagree on whether something will increase or decrease viscosity. It’s really about the ease of changing things, where you might be thinking more about error-prone-ness. It’s definitely true in general that we don’t agree whether something increases or decreases a dimension. It’s not a measurement, it’s meant to be a jumping point for these discussions. + +WH: I’m still unclear by what you mean by Viscosity. + +[crosstalk] + +FHS: Can we defer that question until after YSV has shown the concrete examples? + +WH: Sure, I can wait. + +YSV, FHS: (resume presenting slides) + +YSV, FHS: WH, did that clarify your confusion? + +WH: No, in fact you’ve now made the confusion worse. You used Impact, I have no idea what it means, other than getting the sense that positive Impact is good. + +FHS: I think what YSV meant by impact is that when, for example, comparing function syntax and arrow syntax, making a decision between those two options will impact a certain dimension. Impact is not necessarily good or bad. Imagine a language where you only have the function syntax with explicit returns, versus a language where you only have arrow syntax. Either decision will have impacts on visibility. + +WH: So is Impact a dimension or is it just that something affects something else? + +FHS: Yes, just that something (a new language feature) affects something else (visibility, readability, error-prone-ness). It’s just meant to give us an idea of what language changes can affect, and for whom. + +WH: Back to the original question, what are the definitions of the dimensions? They are unusably fuzzy right now. + +FHS: I totally understand. The purpose of this presentation is not to go over all the dimensions because it would be too large. The idea of today is to give you a sense of what the framework is and how some of the dimensions could apply to JavaScript. + +WH: I have more to say but I’d prefer to wait until after the presentation. + +FHS: (resumes presenting slides) + +SYG: Thanks for the presentation. It seems most of these dimensions are focused on syntax-like or notational features. But implicit in this - even for stuff we design purely as syntax features - their semantics directly affect how they’d be rated on the dimension. And there’s a lot of leeway there. For example, given the same syntax, if I change the semantics, it could have a significant impact on some of the dimensions. How is that handled in the framework? + +FHS: I don't think I'd say that it's purely about syntax. Syntax, or even a diagram if you take it outside of programming languages, always means something. (???) Maybe the question I should have started with is that as computer scientists we are always focused on whether we can measure something with numbers. This framework is more a way to make sure that we discuss the right things. So maybe I say, hey maybe this syntax has this impact, and then you say well maybe it wouldn’t have this impact because of this aspect of the semantics. (???) + +SYG: This would help us have a shared language with the PL community. But coming from ACM on programming languages, I am not familiar with this framework of languages. Which PL community were you referring to? + +FHS: It’s not necessarily the PL community as in PoPL, it’s more at PPIG (Psychology of Programming Interest Group) for example. This is one of the conferences where much of the work in this area has been appearing. But also for example, the international conference for program comprehension that looks at existing comprehension/codebases (...???). So maybe it's less PoPL side of programming and more ??? that I'm referring to. I do think it's sad that the PoPL crowd doesn't embrace this yet. + +SYG: I'm unfamiliar with that side of PL academia. I'm more familiar with POPL, PLDI, etc. Are there papers from the PPIG side for example, that have had impacts on academic prototypes, industry prototypes, etc, where they put this framework to work and build things out and see how it goes? If so I’d love to hear more about that. + +FHS: Some of my work, which I showed here, designing an alternative interface for spreadsheet formulas, is being picked up by Microsoft Excel. Also lots of the evolution papers might not necessarily impact the design of a programming language, but they might impact the design of an API, or the design of how an IDE works to help with understanding. Because if a language has low visibility, then an IDE might help increase that. (???) It's probably because this framework is not so very well known, and also this type of research is not very well-regarded by the technical side of the programming language design community. There's some part of people who publish in PoPL who would say oh, well we just design programming languages, whereas people in software engineering like to look at how people actually use programming languages. + +CM: First of all, very interesting talk. Certainly TC39 has no shortage of peculiar local jargon, though I’m not sure any of the examples you gave are actually examples of that, because most of those are importations from outside TC39. I think there's an anthropology dimension: someone will take things from another group they're a member of, and it will spread like contagion. And I think tracing the patterns of those might be interesting. But the thing I wanted to focus on was error-prone-ness. I think it's a slippery idea. A lot of language design features, you might think of them as speed bumps, because they increase the probability that you'll make certain kinds of errors that are easier to deal with, and decrease the probability that you'll make certain kinds of errors that occur later down the road and are more difficult to deal with. A lot of the programming tools and IDEs and things we've been developing have been designed to try to front-load things, so you tend to have more errors earlier but they’re simpler and easier to deal with. So I think error-prone-ness is way too slippery to be tossed off as a dimension in the way you have. + +FHS: Yeah, so I can be brief. I think the only thing I can say there is that error proneness can be clearer than things we use now like “foot-gun” which has the same slipperiness. + +CM: Footgun is… it has an extended penumbra of cultural meaning. But that refers to something where it's not only easy to make a mistake, but it leads you down a garden path to making decisions where you'll be sorry later. + +YSV: We’re focusing very much on specific dimensions, and I think one thing that was very interesting when I started looking at the framework is that many communities develop their own dimensions as they go. But the framework has three parts: there’s the dimension, there’s the user, and there’s the activity. And having a list of activities that interact in this space. And not all dimensions interact in all spaces equally or in the same way. +And for me what was really interesting was the emphasis that this framework puts on how people experience a programming language. Specifically, when we design, we design for its use, and it's being used by people. The emphasis in this framework on the user, who the user is, and what they're doing would be useful when we are evaluating and designing and asking questions. I see the framework as a starting point for asking questions, like how is this affecting people, and who is it affecting, and what can we find out about those things. + +FHS: For anyone remaining on the queue, please reach out through the discourse page (link?), IRC, email, or the August 27 call (details?). + +### Remaining queue: +1. New Topic: This will lead to time-consuming taxonomical debates. (WH) +2. New Topic: These words seem more precise and easier to learn than our current jargon. I support gradually adopting these terms. (DE) +3. New Topic: While this introduces a more formal framework to discuss language constructs, the impact is still subjective. (MLS) + +## Class static blocks for Stage 2 +Presenter: Ron Buckton (RBN) + +- [proposal](https://tc39.es/proposal-class-static-block/) +- [slides](https://onedrive.live.com/view.aspx?resid=934F1675ED4C1638!291940&ithint=file%2cpptx&authkey=!ADFod3jufA89iM8) + +KG: About private declarations in particular, I think that most of the examples with private declarations, I feel like those would be nicer using private declarations outside of classes - that proposal. In particular - + +RBN: This example? (link) +``` +private #x; +class C { outer #x = 1; } +class D { constructor(c) { c.#x; } } +``` + +KG: Yeah. I don’t find myself concerned about giving both read and write access given that it’s the same source file, and I’m not concerned about hoisting the definition out so you can talk about it, because that’s already a normal pattern with variable declarations that you’re closing over. I do think that wanting to do all of the initialization as part of the class body - especially with regards to static fields - those are reasonable things to want out of this. So I’m okay with this, I don’t feel strongly because most of what I would use it for would be solved by private declarations instead, but I’ve used similar features in other languages. + +RBN: One thing that I neglected to mention in the slides: we've been having some discussions in the decorators group meetings about alternatives for decorators. Some of which will possibly be discussed in tomorrow’s meeting. One of the proposals we've been discussing is one which would theoretically make heavy use of static blocks, which was a motivation for us to bring this back into discussion. Whether or not that will be discussed in the decorators presentation I’m not sure, but there are other reasons we’re looking into bringing this up (back?). + +MM: I'm curious about the scoping of the class name. You mentioned that you refer to the class as `this`, which is fine, and you have to figure out what the binding of the class name is. But I know from function declarations, the binding of the function name to the function inside the function is a separate binding from the one outside the function, because the one outside the function is assigned to, and the one inside the function is the original one. +I assume that's true for class declarations itself? + +RBN: Actually that’s not correct. The name of a function declaration - we’ve run into this in TS with regards to class declarations - the name is only in the outer scope, so references to that function inside the declaration change if you replace the function name outside the scope. In a function expression, the name is bound inside the function immutably. Classes are doubly bound. They are bound both inside the class declaration methods themselves, and in the outer scope. We ran into this with decorators because if you try to reference the name of the decorated class inside of the class, that replaced the class declaration, because if you have a subclass that overwrites the binding of the class, then it is not reflected inside the class. +So classes have completely different semantics when it comes to binding names to bodies inside the class than outside. + +MM: Thank you for that clarification, very surprised about functions but that’s fine. Since classes do have this double binding, you could have the class name be bound to the class when you're inside the static block, but still have it be temporal deadzone outside the class until the class is initialized. + +RBN: That is feasible, but there are some caveats as well. Class expressions and default class exports can be unnamed. I don’t believe your question was specifically around whether or not we should use “this”, but there are going to be cases where there is no name being referenced. + +MM: This part, I have no argument with, I think it's the right thing. I'm saying the class name could be available inside the static block even though outside the class as a whole, it’s temporal deadzone until the class is initialized. + +RBN: That would likely be the case. Following along with how class definition works, the name would exist, but it’s not actually bound with a value until the definition has completed evaluation, because of how the double-binding works. + +MM: I like that double-binding, is that in the proposal now? + +RBN: Double binding already exists. I'm trying to find out how to fit it properly into the spec text. Generally the evaluation of these statements would happen after the outer definition has been evaluated and TDZ is bound, so I’m still trying ???. + +MM: So, that part I very much object to. I think the class name outside the class should be in TDZ until the class is initialized. + +RBN: No contention about that at all. I agree that’s the case. + +MM: Oh! Okay then I misunderstood something. + +RBN: That's how it currently works. I'm trying to say the class will be TDZ outside the class definition until the class is fully initialized. Which should align with how static fields are initialized. + +MM: Great. I very much support this for stage 2. + +SYG: I really do like the multi-step static initialization. I think that alone is enough motivation for something like this. My one comment right now is - and as folks have pointed out this is not a stage 2 blocker right now - I’m unconvinced by the special `var` treatment. I would like to think of this as not a function boundary but a block that runs. So, to have vars not escape the static block seems weird to me. I'd like to understand the motivation for that better, for Stage 3. + +RBN: My question would be, how would you imagine that `var` would work in that case? Would it lift out of static block into the surrounding function scope? + +SYG: Yes + +RBN: I’ll be honest, if I could’ve written this as `static(){`, then I would have, but that's already legal JS +Because it has special semantics around how `this` works, because otherwise who knows what `this` would be referring to, and then we have the complexity around what happens with return, await, yield. I saw on IRC that there’s some discussion about the class access expressions, that one, I may eventually bring back, but that one had some strange things around evaluation, since its main motivation was around private static and subclassing. +So again the main reason that it’s essentially treated kind of like a function but I can’t put parens in because it would conflict with existing syntax, and as such vars would not be hoisted out. + +SYG: So you really want this to be thought of as a static constructor, not a static block. + +RBN: It is essentially a static constructor, since you can have an instance method called static on a class. + +SYG: I have to think about that some more. I'm okay with the idea of a static constructor but I have to think about it. But again, not a Stage 2 blocker. + +RBN: And much of the references I have on the explainer page are to prior art with static constructors in languages like C#, Java, etc, and this is trying to mimic that and provide some of the same capabilities. + +WH: I agree with RBN about not hoisting `var` out of a static block. + +YSV: I’m sorry to be the one to say this, I know that you were mindful of this being a little late, but unfortunately because it was late, I wasn’t able to review it, the SpiderMonkey team wasn’t able to review it, we've put a number of proposals through the ringer for Stage 2 advancement. +I wish I didn’t have to say this would be blocking, but unfortunately I need more time to review it thoroughly. + +RBN: I would like again to restate that this has had no substantial change in syntax or semantics since stage 1. If you do feel the need to block based on time, I understand, it was my own fault, but I just wanted to make clear that there have been no major changes since stage 1. + +YSV: We didn't have enough time to review the Stage 1 proposal, since we have limited time. When something is proposed for Stage 2, it becomes higher priority. + +DE: I think this is a really great proposal. I’m definitely sympathetic to YSV’s concerns, it’s hard for everyone to review the stage 1 proposals, but if it weren't for that, I'd be in favour of this going to Stage 2. I agree with this idea that it's not only useful for things in private scope, but also logically grouping things in the class so it’s easier to understand. I was surprised by the `var` scoping as well, but I don’t see it as fatal, and it’s definitely not a stage 2 concern. So once this has been proposed with enough advanced notice for stage 2, I’d be in favor of it going through. + +### Conclusion + +Not advancing at this meeting. + +## Host hooks for Job callbacks +Presenter: Shu-yu Guo (SYG) + +- [Slides](https://docs.google.com/presentation/d/19S97ZqhibJABqzeP5ZU6Flk6TVgWzXuvJWFbNTTfpWs) +- [PR](https://github.com/tc39/ecma262/pull/2086) + +SYG: (presents slides) + +WH: If I understand this correctly, you get the realm passed through from the caller of something like `setTimeout` (on the “How does this work?” slide) to the bound function? + +SYG: That’s right. How WebIDL specifies this is that every time you pass a callback to a WebIDL interface that ???, it captures a tuple with a function object and the incumbent ???. + +WH: And if `bound` is from a different realm than the one in which `setTimeout` is called, which realm does it run in? + +SYG: It will always run in its own realm. But ??? It’s really arcane, but due to legacy reasons, there are two parallel stacks of realms that are used for different things. And the incumbent was not hooked up correctly. ??? It’s only really weird when it’s a native function, like a platform-provided or host-provided function. So WebIDL already does this - APIs like setTimeout already capture the incumbent. What doesn’t capture the incumbent is ECMA262 APIs that interact with ???. Right now, that’s Promise. So the behavior of `bound` in this code (link?) is different from the behavior of `bound` in this code (link?), except in Firefox which does implement WebIDL semantics. + +SYG: (resumes presenting slides) + +BFS: I’m a little bit curious about the host-defined options. I think the expectation is to virtually always use `GetActiveScriptOrModule`. + +SYG: For the dynamic import case? + +BFS: Sure. + +SYG: That is the plan, though I think on the HTML side some editors and Chrome engineers are trying to simplify this by combining it into an incumbent-like concept, so you can key the active script off the incumbent. + +BFS: I know in node we’re not set up for that. That wouldn’t work for us at least how we’re currently designed. My main curiosity is one, if you do indirect eval on this thing I guess it would basically cascade? Would that mean that in order for you to polyfill something that inherits something - so setImmediate for example is not really available in browsers, it accepted a string argument, so it was enqueueing a job - how could you have that interoperate in the same way? The GetActiveScript will be your polyfill's code or the eval's wrapper (???) + +SYG: The question about setImmediate is that it does not take a callback, it takes a string? + +BFS: The issue is that you’re tying the callsite that queues the job to ???. But if you polyfill something, you’ll always get the polyfill’s callsite. + +SYG: I don’t really know how that works today for web APIs, because this is the status quo today for web APIs that take callbacks. I guess polyfills don’t apply the same way, because if you’re polyfilling, there’s no way to tell the browser or engine that it’s not user code. So when your polyfill code runs, no matter what you do, it'll look like user code. If you’re polyfilling, unless there’s some extra-language way to tell the engine that your polyfill code should be considered native code, so maybe that's not a very satisfying answer, because it sounds like you can never polyfill this correctly. But on the other hand, this is so edge case-y I don’t think it’ll really matter. + +BFS: I spent some time in the last week sorting through this. Overall I think it's the right direction, but I think we shouldn't move forward in this meeting. Overall that is the right direction but we need to fix some edge cases but if it's so edge-casey, do we need to fix it? If it's not polyfillable--we usually take a stance of allowing polyfills of things. We could even do it offline; that's my only concern. If there's consensus besides that, that's good. + +MM: I am against this proposal. I don't want to see this move forward at all. The legacy behavior of the browser here is one of those things where the HTML spec can say purposeful violation, but there should not be any such mechanism in the TC39 spec because it shouldn't be something that any other host should consider hooking. This notion of "incumbent" is dynamic scoping, and it's incoherent. The polyfill example shows the incoherence of it. + +SYG: I see, what I take issue with in that response, while it's legacy in the sense that new APIs are not supposed to rely on the incumbent machinery, we did specify dynamic import with this dynamic scope like behaviour. + +MM: I’m sorry, I suspect it is a misunderstanding of dynamic scoping + +SYG: the baseurl for a dynamic import, you need to determine it when there is no user code on the stack. As shown in this example here, where you can cause a dynamic import to happen when there is no script on the stack. Hosts need to be able to determine when that is. I would be disappointed that ecma262 would not consider it and I would want to point out that Firefox has been shipping this behaviour for a long time. It's not completely a legacy thing that we're trying to phase out. + +MM: Let us take a good look at the semantics of dynamic import offline. The only sane answer for the base URL of dynamic import, which is that the eval evaluating the string came from some Realm, so we'd talk about the base URL of the Realm where the eval came from. + +SYG: that is the semantics and that is the thing that this host hook would do + +MM: That semantics is lexical. It doesn't need a host hook. The semantics is that the realm is carried around in the eval, and the eval captures the realm it was created in. + +YSV: It's been a bit mischaracterized as Firefox being the only browser doing this. Chrome does implement this partially. So we’re not just aligning with Firefox, if we were to align with one of the other browsers, that would have to be discussed in more detail. The discussion between the browsers has been that this is the simplest way to align. + +SYG: That's correct. If there's no JavaScript on the stack then we are aligned. (???) + + + +SYG: The conclusion is that I will chat with BFS about the polyfill point and will talk with MM about dynamic import but I don’t really know what conclusion to get there + +MM: The issue is understanding what dynamic import does according to the EcmaScript spec, because if it implied dynamic scoping, the language would be badly broken in ways we never intended. + +### Conclusion / Resolution +- Meet together offline to continue discussing the issue + +## Handle awkward rounding behaviour +Presenter: Ujjwal Sharma (USA) + +- [PR](https://github.com/tc39/ecma402/pull/471) +- [slides](https://docs.google.com/presentation/d/1QGUTz61o-X_HEgYrkTUXtScoRpu_KhXsoKxGyMQJthc) + +USA: (presents slides) + +SFC: I'm really happy with the work USA has been doing on this and +I think it definitely fixes a bug. It’s never good when the same code works in some locales and not in others - this code can throw an exception in some locales and not in others. So I’m very happy with the work USA has been doing in this PR. + +USA: Thank you SFC. I believe I can ask for consensus pending the remaining editorial changes and the test262 PR. + +[silence] + +RPR: Congratulations, you have consensus. + +### Conclusion/Resolution +- Consensus diff --git a/meetings/2020-07/july-21.md b/meetings/2020-07/july-21.md new file mode 100644 index 00000000..3409ea61 --- /dev/null +++ b/meetings/2020-07/july-21.md @@ -0,0 +1,912 @@ +# July 21, 2020 Meeting Notes +----- + +**In-person attendees:** +None :( + +**Remote attendees:** +| Name | Abbreviation | Organization | +| -------------------- | -------------- | ------------------ | +| Mathias Bynens | MB | Google | +| Yulia Startsev | YSV | Mozilla | +| Rick Waldron | RW | Bocoup | +| Mark Cohen | MPC | PayPal | +| Rick Button | RBU | Bloomberg | +| Chip Morningstar | CM | Agoric | +| Mark S. Miller | MM | Agoric | +| Richard Gibson | RGN | OpenJS Foundation | +| Marja Hölttä | MHA | Google | +| Waldemar Horwat | WH | Google | +| Michael Saboff | MLS | Apple | +| Philip Chimento | PFC | Igalia | +| Chengzhong Wu | CZW | Alibaba | +| Robin Ricard | RRD | Bloomberg | +| Mattijs Hoitink | MHK | Apple | +| Nicolò Ribaudo | NRO | Babel - Invited Expert | +| Sergey Rubanov | SRV | Invited Expert | +| Robert Pamely | RPY | Bloomberg | +| SongYang Pu | SYP | Alibaba | +| Jordan Harband | JHD | Invited Expert | +| Bradford C. Smith | BSH | Google | +| Justin Ridgewell | JRL | Google | +| Zibi Braniecki | ZBI | Mozilla | +| Sven Sauleau | SSA | Babel - Invited Expert | +| Istvan Sebestyen | IS | Ecma | +| Devin Rousso | DRO | Apple | +| Michael Saboff | MLS | Apple | +| Myles Borins | MBS | GitHub / MSFT | +| Shane F. Carr | SFC | Google | +| Mary Marchini | MAR | Netflix | +| Rob Palmer | RPR | Bloomberg | + +## Promise.any & AggregateError for stage 4 +Presenter: Mathias Bynens (MB) + +- [proposal](https://github.com/tc39/proposal-promise-any) +- [slides](https://docs.google.com/presentation/d/1PcfPP5nLVG8w5OosQt5PWwOmFUPuD5pg1rgGaF1JVis) +- [PR](https://github.com/tc39/ecma262/pull/2040) + +MB: (presents slides) + +MB: Any objections to stage 4? + +[silence] + +RPR: You have consensus, congratulations. +### Conclusion/Resolution +- Stage 4! +## Strictness check for object's SetMutableBinding +Presenter: Leo Balter (LEO) + +- [PR](https://github.com/tc39/ecma262/pull/2094) +- [slides](https://docs.google.com/presentation/d/1O_YdntfiZMTsxX_2FPk1YZypEy1vncL3X1NCg-vmC1E) + +LEO: (presents slides) + +WH: What should happen if the original binding was removed and then another binding was created and put back in its place? + +LEO: For ???, we just would - if it does have this binding, if the object environment record will have this binding or not, anything after that will go through Set for the value. If it does have a new binding and say it’s a known configurable one or a known ??? one, then ??? it's not something we do today in ES but in my opinion it's a userland problem. +For me, in my personal opinion, it’s a userland problem. KG has raised that it’s an inconvenience …? People are using proxies and like tricking us, we can still be tricked by proxies where this binding is not present, it still might save a ReferenceError in strict mode. It’s still a userland concern in my opinion. + +WH: If there is a property the first time you checked, before this code runs, then the property gets deleted and put back. Are the implementations expected to write to that property, or is it somehow bound to the first property? + +KG: They're expected to write to the property. + +WH: Is this observable in other ways than just getting the error? It looks like you added a HasProperty call so proxies can observe this. + +LEO: We can observe this through Proxies. + +KG: [example] If you do `with`, and then you have a new proxy to introduce the proxy into your scope, and you enter strict mode inside of the `with` - because this fix is for strict mode code - you would observably print the `has` check twice, once when you’re doing the initial lookup and the delete itself, and then once when you write… actually maybe it’s three times. There’s not currently agreement between the engines on what to do. I'm not worried about this case, because if you put a Proxy in your `with` handler then you should expect to see some checks happening and I don't expect anyone to be broken by those checks. + +WH: That’s a fun example. I’m just curious how stable this fix is with respect to fixing implementations’ concerns. Are we going to be tweaking it for a while still? I am in favor of this, I just want to know how stable this fix is. + +KG: I think it depends on how willing implementations are to change their behavior of `with` proxy, and I’m not sure. I observe that they’re all currently different today. + +WH: Thank you. + +KG: Certainly if you don’t have a proxy involved, this will match web behavior across implementations except 262 and one case in XS. + +LEO: Yes, my goal is to match web reality. And also consistency with other parts of SetMutableBindings as well. + +MM: The code in the real world that this most reminds me of is CP’s eight magic lines of code, which is the basis of the SES shim, where we use exactly a sloppy `with` on a proxy to emulate a global lookup, and then within there we use a strict function, and then further within that we do a direct `eval`, which isn’t relevant here. One problem that we ran into, and I'm wondering if this semantic change might fix it, is there's a peculiar exception in the semantics that we cannot faithfully emulate: if you look up an unbound variable, you get a ReferenceError, but if you do a typeof of an unbound variable, if the expression is just a variable expression, the expression evaluation doesn’t cause a reference error, but rather the typeof of that expression gives you back undefined. We’ve looked at what the traps are on the proxy for those cases, and there’s no way from the handler to emulate both behaviors faithfully. You have to emulate one and be inaccurate on the other. Does this change help in any way with detecting the difference in variable lookups for the purposes of normal expression evaluation vs for the purposes of `typeof`? + +KG: No. This change is scoped strictly to when you are performing SetMutableBinding. + +MM: Only for assignment. Ok. Ok. Ok, thank you. + +SYG: I’m not sure if I missed this, what is the proposed behavior for your example? + +KG: For my first proxy one, I’m honestly not sure. I don’t remember all of the places that the `has` trap is reached. + +SYG: Ok. But in any case, what I’m trying to confirm is that because of proxies, all engines - all browser engines - do have work to do here? + +KG: Safari might not. + +SYG: Ok. + +KG: But it would be - the `has` trap would be triggered at least twice, once in the initial lookup and once in the assignment. Yes. I should also point out that there are a lot of cases where the reference type, which is sort of what’s involved in this, doesn’t match engine behavior. It’s one of the oldest web reality issues on 262, and this fixes it in one particular case. So yes, engines would have work to do, but engines already have a bunch of work to do if they want to be correct about all the edge cases for references. + +SYG: To confirm again, this is for the object environment records, which are only `with` scopes and not global scopes? + +KG: It’s also global scopes, but in global scopes the `has` check is not observable. + +SYG: OK. I don't care about the performance of `with` scopes and I don't imagine anyone else cares. If a naive implementation of extra `has` checks here regresses global property lookup, that would be bad, but we’ll see I guess. + +KG: I don't think this change implies any required changes for global properties. Engines already do what this PR is asking for, for global variables. + +SYG: Can’t you - if you install a proxy somewhere in your global environment chain, can it become observable then? + +KG: Is that a thing you can do? + +SYG: I mean, you can get the global object and then you can install a proxy in its prototype chain. + +KG: Isn't it immutable? I thought the global object was an immutable prototype exotic object at least in the web platform. + +SYG: Hm. Okay, well I’ll follow up on the thread if we get around to it and find issues, I guess. + +LEO: SYG, do you want to follow up with tests and then we can nail down the expected behavior that way? + +SYG: I'm in support of this PR, I'm just saying that it may have performance repercussions that we need to look at. Hopefully it doesn't. + +LEO: You prefer to hold on on this PR for now? + +SYG: No. I prefer that we agree and merge this PR. As the example shows, in the weird let's-make-things-observable-by-Proxies case, we don't have interop. + +LEO: Does anyone have any objections to merging this PR? + +WH: The audio broke up so I couldn’t tell what we’re supposed to be agreeing to, please repeat it. + +LEO: For now, what we’re proposing is to agree with the current behavior, we will eventually have tests for this to catch up with how this is implied in proxies, but from my understanding of what SYG says, this is already better progress for interoperability. + +WH: By current behavior do you mean current spec behavior or current implementation behavior? + +KG: The proposal is to get consensus for this PR. + +WH: I’m in favor, then. + +LEO: Any objections? I am still asking for consensus. + +[silence] + +LEO: I believe this is consensus. + +RPR: Yes, consensus on this PR. +### Conclusion/resolution +- Consensus on the PR. +## Intl.ListFormat for Stage 4 +Presenter: Zibi Braniecki (ZB) + +- [proposal](https://github.com/tc39/proposal-intl-list-format) +- [slides](https://docs.google.com/presentation/d/13gxxnt-JMuWXJhzwuU2jtBRZ8RGJgJ0Y8RsIvHEQU7k/edit#slide=id.p) + +ZB: (presents slides) + +ZB: Stage 4? + +[silence] + +RPR: You have stage 4. +### Conclusion/resolution +- Stage 4! +## Intl.DateTimeFormat dateStyle/timeStyle for Stage 4 +Presenter: Zibi Braniecki (ZB) + +- [proposal](https://github.com/tc39/proposal-intl-datetime-style) +- [slides](https://docs.google.com/presentation/d/1USMb1b_1zDMAlw3Aw5k9DpqZsZ3NS_q9gOyhRCQc-qg) + +ZB: (presents slides) + +ZB: Stage 4? + +SFC: I’m really happy with this proposal, and what ZB has done to move this proposal forward. The open questions with Temporal now that we can get this to stage 4 - they’ll be able to work on that much more effectively. The one question I wanted to point out is that there’s some editorial issues - ZB has fixed all the normative issues, but there are a couple of editorial issues that were raised yesterday. I think we can fix the editorial issues separately from Stage 4. I very much support moving this proposal to Stage 4. + +ZB: Yes, it is my intention to fix the editorial issues reported this week. + +RPR: Given that, last call for any objections to stage 4? + +WH: Can you describe the nature of the editorial issues? + +ZB: There is one with several spelling issues, a missing `then` in a branch, one step has been moved to an `if-else` instead of kept before the loop, and there is some question about internal slots and how we store calendar-independent data in internal slots, because the PR was written before we merged a PR that shifts from using the gregorian calendar for internal slots to supporting many calendar systems. So I have to update the internal slot here. And the last one is that there is a question about how we should act when a user requests a field which we do not have data for. The common logic in 402 is that we throw a TypeError in initialized date-time format independent of whether the field is needed. And the PR does not follow that logic, so we agree that we’d just update the PR to be consistent. + +WH: Is the last change editorial or is it user-visible? + +ZB: If we merge it without fixing it, it would be user-visible, but all browsers implement it with the spirit and not the letter, so we have to just update the letter. + +WH: Thank you. + +RPR: Any objections to Stage 4? + +[silence] + +RPR: Congratulations, you have stage 4. + +### Conclusion/resolution +- Stage 4! + +## Fix Function.toString for builtins +Presenters: Gus Caplan (GCL), Jordan Harband: (JHD) + +- [PR](https://github.com/tc39/ecma262/pull/1948) + +GCL, JHD: (presents PR) + +JHD: Note that this means the presence of items in the intrinsics table is normative. My interest in this PR is that it removes the coupling between the table and the toString output, and just says that toString of builtins always have to include the name. This seems to be what engines already do and I think is what users would expect. + +GCL: This PR would make SM correct and JSC and V8 incorrect. They technically already are but it's just specified weirdly. + +JHD: Although I want this change to land in some form, is there a reason to not include the `get` and `set`? Because that would seem to match user concerns. + +GCL: I would like to include them but it seemed that there was previous consensus to not include them. + +JHD: Was that from before the toString reform? + +GCL: I’m not sure. Is MF here? + +MF: I think you’re right, but I’d have to check the notes. Personally I’d prefer to not include them, I think users would expect something that could have been a portion of a valid source text there. + +SYG: For non-builtins, for non-native functions, it does print `get set`? Or is it not supposed to print `get set`? + +GCL: If you did a method definition? + +SYG: Yeah like if I manually wrote an object definition that says `get foo`, I think SpiderMonkey also prints `get` in that case. + +MF: I can answer what the specification says. + +SYG: Please. + +MF: The specification says that for a getter, the toString output is the source text matched by that getter. What we’re talking about here is just synthesizing Function.prototype.toString output for builtins. We have the function keyword always. + +SYG: Don’t people think of getters as having `get`? Yes it’s true in the technical sense that ???, but since user code ??? + +MF: You said that a user might expect `get` to appear for built-in getters. My question for you was: instead of the `function` keyword or alongside the `function` keyword? + +SYG: I was thinking "instead" but I guess that's not on the table. + +MF: It may be possible. If we wanted to do that. + +SYG: I guess ideally I would think it's most intuitive that it aligns with user getters and setters, but yes now that I’m reading #1941 more closely, the `function get`, that’s weird. That should not be there. + +WH: I have the same concern as SYG. I would expect this to have the syntax of a getter except that inside the body it would have `[native code]` instead of user code. + +GCL: I can’t comment on the web compatibility of this change, but I know that I have written code that assumes that the way it's done in SpiderMonkey is how it should look, so I'm not sure it's feasible. + +WH: OK. It’s an interesting dilemma. + +JHD: It seems like a builtin should - except for the native code part, which is going to make a syntax error, and has to - it seems like the code around that should roughly match what a user types in if they were implementing the builtin themselves. So I would expect a getter to match the source text - so "get name" because that's what a user would have typed. So it feels like it would be nice to me if we could make the spec do that, because that, to me, is the intuitive thing. + +GCL: You could think of it as, you defined a function named size and then used it in a property descriptor. + +JHD: Certainly. Yeah and in that case, it wouldn’t have the `get` keyword, it would just be the SpiderMonkey example, so I see the appeal there. But to me, the most common user pattern is not going to be Object.defineProperty, it's going to be typing it in a class or an object literal. + +KM: How did the code assuming Firefox's behavior work in other browsers? + +GCL: I assumed that all the outputs would begin with the keyword `function`. + +KM: Would that work if you had user code with a getter? Because that wouldn’t have the `function` keyword. + +GCL: I don't know. It was just an off-the-top-of-my-head example. + +KM: Sounds like that code doesn’t work in JSC or V8, or that code wouldn’t work if you ever got a user getter. + +GCL: I can't imagine it would have been the best. I can't comment on whether this would work, I can't collect feedback from browsers. + +KM: there’s definitely a web compatibility risk, I agree. But it seems like that code might be problematic already, so it might be hard to have working code that does that. + +GCL: I agree. + +SYG: Relaying a point from a colleague: if we get rid of the get and set keywords now, the higher level question is - who are we trying to serve with "toString"? If it's round-tripping through an "eval" that's not possible anyway. If it's diagnostics, ??? If you get rid of `get ` and `set`, I imagine it’s common for getters and setters to share the same name, so if you print it out and there's no `get` or `set` in the name, how do you know which is which? I think that’s an argument for whatever we do here should probably keep `get` or `set` in the name. + +GCL: I’d be fine with consensus on removing `function` or even keeping `get` as it is right now, I just don’t know what the effects of that would be. + +DRR: I don’t know if this is pre-empting, but basically knowing what we should have depends on knowing who the customer is, right? Is this user-facing? I don’t know that I would ever care to look at this and see that this is what’s happening. I don’t know if I would ever directly invoke the getter’s `toString`. To me this is more like an interface thing, so other code can interpret it if you really want that to happen. +Code can take a hard dependency on this in some way. + +KM: The main place where I would see this coming up in a user-facing way is in a stack trace. There’s probably some web API that does this, probably pluginElement or something horrible. It seems like you would want to know if it's a getter or a setter. I guess you could look at the callsite, but it might not be totally obvious from looking at the trace itself. + +DRR: I think that’s a fair point. + +MF: I think there's a lot of webcompat issues. We don't have the data to make any decisions about representing native functions like user getter/setters. We did a lot to try to specify the native function grammar while the Function.prototype.toString proposal was in progress. There were a lot of calls to lock it down further, like with locking down whitespace. That couldn’t be done reasonably due to not having enough data. I think this is a fruitful discussion and we can try to improve this area of the spec, but I think we can also get what GCL is looking for today done without solving that issue. + +GCL: You’re saying to move forward with this as it’s written, and deal with method definition syntax as a separate item? + +MF: Yes. And possibly further specifying the spacing used as well. Those are ways we can improve it. + +SYG: To clarify, what are you proposing we move forward with? We do not change anything about the name, just the intrinsic table thing? + +GCL: We’re saying move forward with the PR as it’s currently written. So it removes the `get/set` to update it to what native `function` is supposed to say, and then a further PR could be to update that to use getter / setter syntax. + +SYG: That's kind of weird, right? + +KM: I feel like we're going to change it and then hope it's web compat? I would rather see what JSC prints than not have the get or set at all. + +WH: I agree. + +MF: This doesn’t affect stack traces. + +GCL: Yeah, engines can do whatever they want with stack traces. + +KM: I would rather have the name be the same as the name from the `toString` though, otherwise people might be confused. + +GCL: The `name` property will still be "get size". The difference is what the toString output is. This basically decouples the `toString` output from the exact value of the `name` property. + +SYG: It's still weird to say, let's merge this thing that explicitly is known to work in one browser and we're going to keep investigating if it's possible for other browsers to follow suit. +Not like we have already agreed that the other browsers are going to move towards either keeping or getting rid of the keyword, it seems like that’s what we should be going for. + +GCL: If browsers are willing to say they're going to work with us to get the data needed to find if we can make these changes that's not unreasonable. From this point I'd like to figure out what we're going to do to fix the thing where the spec does not do the thing it's supposed to do. If that means merging this as-is, that’s fine, if that means gathering more data, that’s fine. But I don’t want to just say we’re not going to merge this and leave it at that. + +SYG: I agree; concretely I see two problems: the first is that we have inadvertently made the well-known intrinsics table normative. Part of what this PR does is to fix that issue, but a side effect of the fix doesn't have consensus from the browsers in a compat point of view. +Is there a way to split out the part that makes the table no longer normative? + +GCL: I am not sure. I mean the reason that this is something that the browsers have to worry about in the first place is because of this native function syntax. So JSC and V8 are already violating the syntax laid out here, regardless of the fact that the prose here tried to apply the value of the `name` property, which wasn’t correct. I don’t know how to make this change in a way that doesn’t have them still violating it, because the native `function` syntax isn’t that. + +SYG: I guess one way would be to- so the point is that JSC and V8 currently do not follow that anyway? Or is there some wiggle room? + +GCL: The problem is basically that the specification said to use the initial value of the `name` property, and that includes `get` and `set`, correct. But the native function syntax does not allow that. So the spec conflicted itself. But we had concretely agreed on the native function syntax, so it was more a misunderstanding I think. + +SYG: Ok, then pending compat data, I’d be most comfortable with saying somehow that the string `get` or `set` may appear. + +JHD: To clarify, you’re saying you’d like to leave both of those variants valid to get this PR merged, and then lock it down later? + +SYG: Right. I don't want to lock it down in this way, which says that the "get" or "set" must not appear, especially given that the temperature of the room is that we don't have consensus to remove those. + +KM: I agree with SYG. I think we should leave both valid until we can figure out something more locked down. I think it’s kind of a user regression to not have the `get` or `set`. + +GCL: So, consensus on making this change but allowing the "get"/"set" to optionally appear after "function"? + +MF: This change would be still inconsistent there though. Because we have the actual slot for initial name right now, that’s fully specified, and I believe what’s being asked is for it to be un-specified. + +GCL: Right, I’d have to make changes to this PR again. I’m just saying from the observable perspective, we’d want this to be the initial name that optionally includes `get` or `set`. + +SYG: Yes, I am asking for a relaxation of something that is fully specified but is in this particular case contradictory in some way. + +MF: Yes the current spec is contradictory. The proposed spec is not contradictory but too strict, and so what we’re asking for is to relax it some amount to allow for freedom of implementation. + +SYG: Right, and I think that would be a good starting point for us to then work together to gather compat data. + +GCL: So do we have an agreement? + +KG: I don’t want to say that there’s consensus on any particular thing without having a PR in front of us. It sounds like people are in general in favor of a change that relaxes the requirements on the `name` slot, and then locks it down further, but I don’t think we can say we have consensus on that without having it in front of us. + +GCL: ??? + +JHD: Web reality… + +SYG: Since KG wants to see these changes in front of him, would you be okay with us editing this and bringing it back with a short timebox on thursday? + +RPR: Are you happy with that? + +GCL: Yeah. + +## WeakRefs for Stage 4 / CleanupSome for Stage 2/3 +Presenters: Daniel Ehrenberg (DE), Yulia Startsev (YSV) + +- [WeakRefs proposal](https://github.com/tc39/proposal-weakrefs/) +- [CleanupSome proposal](https://github.com/codehag/proposal-cleanup-some) +- [PR](https://github.com/tc39/ecma262/pull/2089) +- [slides](https://docs.google.com/presentation/d/1NYhEELzOnhJGU7inKz0r0TrEa0h33krr1nEb3X_ze5w) + +DE/YSV: (presents slides) + +KM: WeakRefs landed in JSC! There are just some bugs to fix. + +DE/YSV: (presents slides) + +MM: You’ve changed my mind. I originally was against splitting up cleanupSome because of the wasm use case. I like your rationale for why to postpone it. I'm wondering, with it postponed, we'll gain experience as to how well we can do without it. It may be one of those you-ain't-gonna-need-it (YAGNI) things, where we find that we don't need it in the end. So I would recommend bumping cleanupSome back to Stage 2, and even consider never advancing it if we consider that life is ok without it. I support advancing WeakRefs to Stage 4. Congratulations on changing my mind. + +DE: Thank you MM. I want to point out that when we’re talking about the Wasm use case, the use case for cleanupSome is really particular to particular instances the Wasm long-jobs use case--not just where you are doing calculations and communication with SharedArrayBuffer, but also where you are synchronously calling out to JavaScript. So it is quite specific. It might be more valuable to invest in wasm long-jobs to yield to the event loop. I'm not a Wasm expert but I've heard some exciting ideas in this space. + +MM: That would be great, I did not hear about new ideas of Wasm yielding to the event loop + +DE: I don't know where the right pointer is. + +YSV: I have a couple of details as well that I can find for you. + +WH: I don’t understand MM’s point, under what scenario don’t we need cleanupSome when wasm never yields? + +MM: Wasm would still yield to the event loop when the wasm stack goes empty. The concern is that you take old C code and port it to wasm and it runs as a big sequential program, because that's how C programs work. Even though that case remains just as bad, given that we're going to spend some time with wasm without cleanupSome, we'll see what people do to try to restructure their wasm computations to yield to the event loop more often. And it sounds like there are some ideas to help wasm do that that I’m not aware of that might be stronger. It's often the case that when you live with a constraint you find pleasant ways to adapt to the constraint. It's one of those things where I'd like to see what people come up with and how people adapt to the pain the long-running wasm computations still cause. + +MM: WH, does that answer your question? + +WH: [pause] That answers the question. I don’t like the answer because I don’t like causing people “pain”, but it answers the question. + +YSV: I might also be able to help here. We've found that the way people have been writing wasm has been different from what I expected, which has also shifted our thinking about cleanupSome. +For example when they’re taking existing C++ libraries for use in wasm, they’re not splitting it up in a way that works for the web, and eventually it gets abandoned. So that was an interesting way to see how people are using wasm currently, and it’d be nice to get more time to observe those behaviors before committing to a design. + +LEO: If we move cleanupSome to stage 2, I just want tc39 to signal what to do with test262. +We can keep them as they are today, not touched, but we can also work on handling removing the tests and re-adding them when it’s convenient. + +MM: Having the tests continue to be publicly available but still on a branch or something - what is test262 policy with regards to tests being on the main branch versus the stage of the thing being tested? + +LEO: Policy is that test262 is the place for tests for things which reach stage 3 and also PRs which are not merged but still have consensus. +We don’t have much of a policy yet, we’re building it organically, for when things move back from stage 3 to stage 2 or 1. So we need to make an understanding. + +DE: I want to make a suggestion that test262 should use a feature flag. +There could be a list maintained of which features are not stage 3, so it would be easy for engines to mask out all features that are not yet stage 3, so then we could also merge tests in before stage 3. + +AKI: You took the words right out of KM’s mouth! He had that reply on the queue. + +LEO: if I’m not wrong as far as I know all of the browser engines have future or future flags at least for folders + +SYG: I think DE is saying associating stages with feature flags, which we do not have today. I support that idea. + +KM: Is that useful? + +[inaudible] + +KM: You’re just not going to run tests that you haven’t implemented. I’d want to make sure my implementation doesn’t spuriously break. + +YSV: We haven’t yet decided if this will be stage 3 or stage 2. Test262 and the feature flag proposal are important but maybe it should be discussed separately from the proposal. + +DE: I think we could follow up on this on the test262 issue tracker. I like MM's suggestion of Stage 2 for cleanup some and Stage 4 for WeakRefs + FinalizationRegistry without cleanupSome. + +SYG: It sounds like you're asking for stage 2 for cleanupSome. Does that retain the normative optionality? + +YSV: I would say it is unchanged from what we agreed to with WeakRefs so far, so cleanupSome would remain normative optional. + +DE: The best thing if we go to stage 2 is to file issues about this sort of thing on the cleanupSome repo. + +AKI: Does that answer the question enough to talk about consensus and move on? + +DE: SYG, any thoughts on that answer? + +SYG: I am all for stage 4 for WeakRefs without cleanupSome and stage 2 for cleanupSome + +AKI: Consensus? + +[silence] + +AKI: I’m going to call that yes. + +### Conclusion/Resolution +- Stage 2 for cleanupSome +- Stage 4 for WeakRefs + FinalizationRegistry + +## Logical Assignment for Stage 4 +Presenter: Justin Ridgewell (JRL) + +- [proposal](https://github.com/tc39/proposal-logical-assignment) +- [slides](https://docs.google.com/presentation/d/1rq448C-mzxWzBs6RTInczGTjs4xv5gQenDJY1fGogX0) +- [PR](https://github.com/tc39/ecma262/pull/2030) + +JRL: (presents slides) + +JRL: Stage 4? + +WH: Does named evaluation apply to all the operators or only some of them? + +JRL: All the operators. So `&&=`, `||=`, and `??=` will all do proper named evaluation. + +WH: What about the existing ones like `+=`? I’m not sure it makes sense for them though. + +JRL: None of those do named evaluation because they coerce their argument to numbers. + +WH: Thank you, that answers the question. + +AKI: Consensus for stage 4? + +[silence] + +AKI: Congratulations! Another one! Yay! + +### Conclusion/Resolution +- Stage 4! + +## Decorators status update +Presenter: Chris Garrett (CHG) + +- [proposal](https://github.com/tc39/proposal-decorators/) +- [slides](https://slides.com/pzuraq/decorators-3cb407) + +CHG: (presents slides) + +WH: What does “downlevel” mean in this presentation? You used it several times and I couldn’t figure out what it was referring to. + +CHG: It’s a term we coined within the decorator group. Every single decorator usage would have to be compiled to the polyfilled version, even if it potentially was using a native decorator, in other words "downlevelled." + +WH: I'm still unclear as to what “downlevel” means here. + +CHG: Basically if you were in a case where you had a mix of native and non-native decorators they had to apply, they would have to transpile all of the decorators - because there is presumably no easy way to un-transpile a decorator which has already been transpiled. + +WH: Why can't the transpiler transpile only some of the decorators? + +CHG: Because the syntax itself, when used, would not necessarily be compatible with the polyfill or transpiled version. + +JHD: WH the first thing is that in your deps graph, you will have non dependency code using transpiled code. Before the feature is available to you on your platforms, you will be using Babel or something to transpile the decorators in native syntax. + +WH: By “native” you mean decorator syntax or existing ECMAScript syntax? + +JHD: At the point where the platform is able to change from transpiling the decorators to actually shipping the decorator syntax, the dependencies will contain a lot of decorators that are still transpiled. My constraint is that those need to interoperate. Separately, one potential path is to use those transpilation tools to convert third party tools to uplevel it. + +WH: Another point on the first slide that I didn't quite understand. You talked about “byte size”. Did you mean byte size of objects? + +CHG: It’s just the byte size of decorated values in general that are using decorator syntax + +WH: So, you're concerned that if you decorate an object, then the object will require more bytes to store in memory? + +CHG: I’m sorry those are the bytes for the output syntax actually + +WH: You mean outputting the object via, for example, JSON? + +CHG: One solution proposed is that decorators would be a reserved syntax that isn't actually implemented in JavaScript, and have build tools compile decorators into JavaScript, and let the ecosystem figure out what it should mean, and ship that over the wire. If that were the solution we're gonna go with and we’re always going to solve the byte size problem. It would result in much larger class definitions, because in a lot of cases, you're decorating a field, which turns a field into a getter and setter, and that getter and setter would have to be transferred over the wire. Even minimized, that will be 10 times the size. (gist: https://gist.github.com/pzuraq/6c2ff5594bf16f9693a7d9131855ee2d) + +WH: Ah, I think you mean the byte size of the transpiled code, is that correct? + +CHG: Yes. And one other proposal is that it is always transpiled, that we never standardize on a decorator syntax. + +WH: From the slides and presentation I got the completely wrong idea of what you meant by “byte size”, so it was hard for me to follow the presentation. Thank you for clearing it up. + +DE: A lot of people are talking about tooling solutions, as CHG mentioned in the byte size discussion, even in tooling a lot of these constraints still exist. I want to raise another one. Constraint #2 basically this gets at decorators being transpilable in a single-file mode. If you want to transpile decorators differently based on whether they add metadata, make fields into accessors, etc, you either need some cross-file communication, or you need to add runtime overhead conditionally. So, the constraints are still in conflict even in a pure tools mode. Personally, I'm optimistic that we can find some of these constraints that can be relaxed to find a solution. We’ll have to relax some of the constraints on whether we put this in tooling or in the language. My hope is that this presentation will illustrate the contradictions and get people thinking about which concerns do we really care about, which concerns can we relax. Then we can find more solutions. + +CHG: DE summed it up very well and we’d like to continue in that direction and the group will continue to work that way + +## NumericLiteralSeparator for Stage 4 +Presenter: Rick Waldron (RW) + +- [proposal](https://github.com/tc39/proposal-numeric-separator) +- [slides](https://docs.google.com/presentation/d/1rLT5m3d0yk2KMlka4KZKf2uz9oITdpfr6evAV_jaKcc) +- [PR](https://github.com/tc39/ecma262/pull/2043) + +RW: (presents slides) + +RW: Stage 4? + +WH: You mentioned in the presentation something about underscores in unicode escape sequences in a failing test. Can you explain? + +RW: That’s not my problem, that’s V8 failing a test. + +WH: My understanding is that we are not allowing underscores in unicode escape sequences. + +RW: That's correct. + +[Background noises from somewhere drowning out the meeting. Notetakers can’t hear what’s being said and are asking for clarification.] + +WH: I think I can summarize the situation. We’re not allowing underscores in unicode escape sequences. V8 is allowing them and therefore failing the test. V8 should fix this. Is that correct? + +RW: Presumably that’s why it’s failing, correct. Everyone else is throwing the correct SyntaxError. + +WH: Yes. Sounds good! + +RW: Cool, thanks man. I can hear the enthusiasm in your voice. + +WH: Yay! + +RW: Mark it down, WH just said “yay”, I want that in the notes. + +RW: So do I have stage 4? + +[silence] + +RPR: Congratulations, you have stage 4. + +### Conclusion / Resolution +- Stage 4! + +## Slice notation for Stage 2 +Presenter: Sathya Gunasekaran (SGN) + +- [proposal](https://github.com/tc39/proposal-slice-notation) +- [slides](https://docs.google.com/presentation/d/1EBpiGuYn2ChDvcd67fpz6gGY14kO8VCuAKOhFMxOqEQ) +- [spec](http://github.com/tc39/proposal-slice-notation) + +SGN: (presents slides) + +SGN: asking for stage 2, do we want it in the language or not especially the : symbol for that notation + +JHD: I did file an issue a week or so ago. I think the strings, you have an example it’s like .slice so you would expect that to work on strings and it would be bizarre for it to not work on string. It is not going to block for stage 2 but it would make it less useful and would make me block in the future. + +SGN: I don't have a strong opinion on this; I'm happy to discuss this more. We can discuss it in stage 2 and come to an agreement. + +JHD: To be clear, I’m not blocking stage 2, but I want to reserve the right to block for stage 3 on that later, so it’s something we should get to quickly. + +BFS: I just want to state a little counterpoint. I’m very concerned about slice notation for strings. It seems if we do slice notation, slice doesn’t match iterator, in particular you’re iterating over the code points rather than the characters really. I agree it can be done at stage 3 but I don’t want to commit to be done for string slices. + +SGN: Again we haven’t discussed this at all, and there’s a lot of time to discuss it. I think we should discuss it, it’s an important point, I will update the issue to reflect your thoughts on this. + +KM: My topic is a continuation - in no way am I blocking stage 2, but I’m wondering if it’s worth working with other HTML standards organizations for getting slicing on other DOM collections. Just something to look into. + +SGN: definitely a good idea and follow on with an issue to track that down + +GCL: About the `Number.range` example, I believe you could apply that to all iterators, or many- I think all iterators using methods that already exist on iterators like `drop` and `take`. So it would be interesting to think about it in that context rather than just number ranges. + +SGN: ok, so are you imagining symbol.slice to be in the iterator prototype? + +GCL: Maybe, I'm just throwing the idea out there. + +SGN: For sure. I think we should definitely explore expanding the scope of this to be on different kinds of objects, and also the HTML collection stuff that KM mentioned. Very good points, thank you. + +YSV: it’s not clear what problem we’re solving that isn’t solved by slice. I understand the development ergonomics point, but I'm not sure that it's enough. For example we’ll be introducing a new syntax that doesn’t exist in the language before. +And this will introduce a learning burden, and unless people are working with this frequently, they may not learn exactly what this notation means, so for example you have one example that’s `[number:]`, this may have a very similar problem as slice with one argument. So I’d like to see a stronger motivation, because at the moment I’m not convinced that this should go into the language based on its current motivation. + +SGN: For me the main motivation is developer ergonomics. For someone that's used to it in other languages this is a known feature (?). If there’s a way for us to figure this out, I’d be happy to do that, I would like to do that, I want to understand is this paying(?) for the cost. I agree with you, that’s why I brought it up as a big issue in the proposal. I share this concern as an implementer, I don’t want to implement random crap no one will use. I definitely hear your concern and is my concern as well but I can’t find a quantitative way to define if this is useful. Lots of people are saying this is cool I would use this. But again, that’s not enough maybe? I don’t know. Maybe it is. But I also don’t know why it’s not good enough, we’ve had pretty simple proposals that add simple sigils that are shorthand for `&&` or `||`, or things like that. Why is this different? + +YSV: I would say that the difference here is - with logical assignment, you’re referring to logical assignment, right? - logical assignment made a lot of sense because it was a common operation that was quite long to express, and it made that concise. I'm not convinced that this improves legibility beyond for slicing: we already have a well-known method named slice. Visually speaking, there’s noise that you could confuse the two of them if you’re reading quickly. But I wonder if those drawbacks aren’t ??? new syntax that is doing the same thing. To answer your question about what level of vetting we would need to see, I would be interested if this use case can be maybe if this takes us beyond slice or has overwhelming support for this. + +SGN: The overwhelming support is- my intuition for that was coming from looking at other programming languages, and pretty much every other mainstream programming language has support for slicing. + +YSV: Arguably we do have support for slicing, just in a different form. + +SGN: No, I mean syntax. Most of the languages do have syntax for slicing. Maybe different syntax, but they have realized that this is something that programmers do often and that they need syntax for it. +That’s sort of my thinking approaching this- I think this was some feedback I got last time as well, which was is this something that’s actually useful, and all I could do in response was to look at the other programming languages that JavaScript developers use, and ask if they have support for slice syntax, and the majority of them do. + +LEO: Should we have an incubator call about this very topic? I definitely have some of my own point of view where we have positive developer feedback and experience from other languages. And also how I see this with regard to other syntax features that we’ve introduced in other years. So I think this is a much more deterministic ???, and there is much more we can discuss in an incubator call. + +SGN: I think that’s a good point. + +KM: I have a personal preference towards not using a slice property name but probably because I have personal disliking against ??? + +WH: I have similar views to YSV, I feel like this is adding a bit of complexity into the language. In particular it’s adding syntax for something that can relatively easily be done without needing new syntax. A couple years ago we had some pushback to these little syntax proposals. It’s completely different from logical assignment, which simplified the language by making all of `+=`, `|=`, `||=`, etc. work, which improved orthogonality of the language. +On the other hand, with x[a:b] you have to remember which things allow the single argument in brackets x[a] and which things allow two arguments in brackets x[a:b]. +And those are likely to be different sets. And then I see that we’re discussing that slicing a string should index by unicode characters, so if you apply s[a:b] to a string, you get indices by unicode characters, but if you apply s[a] to a string, you’d get indices by code points, which would be terribly confusing. + +LEO: (queue reply: This improves Developer Experience) + +DRR: To further WH’s point, the fact that slice already exists as a method and has the semantics I intend means that this is a nice-to-have for me. With this syntax, when I show it to people, they’re like “oh cool, I can get the last element of an array”, but then it was weird, because everyone would realize that, oh wait, I still have to re-index with 0 to get the last element. Maybe this leads into SYG’s topic, but the fact that you can’t do a negative index on these things makes it a little confusing. I know that there is a related proposal that we'll discuss about later, but I think that that is something to consider. + +SGN: Can you repeat more concisely the problem? + +DRR: I think the fact that you don’t have negated indices is a slice concern + +SGN: But we do, though, because it behaves exactly like slice. + +DRR: You have negated element index for slice, but not for element access. I’ll yield to SYG. + +SYG: I don’t have a strong opinion on slice notation but I want to raise a concern. Regular indexing with brackets a[-1], for example, means a thing that we can't change. It doesn't mean, look up the relative index, which is why there's the .item() proposal. The issue with slice notation natively supporting negative indexing with a colon is that it no longer composes well with single-argument brackets, and we can never make it compose well. That may be related to YSV's learnability concern. If you learn slice notation, you might think that you can remove the : and it works, but it doesn't. + +SGN: I kinda see that but again this is similar to trying to spread in an array or key lookup and I’m unsure where to draw the line. I guess one concern is that we’ve always done `toString` to whatever we’re looking up in a keyed lookup, and we’re going to change that now. + +BT: We have to move on. Can you summarize your takeaways? + +SGN: Heard YSV and WH that they’re not convinced, and positive feedback from others so I have hope so I will follow up with YSV and WH for more discussion. + +WH: I and YSV were not the only people who expressed concerns. There were others as well. + +SGN: I will talk with the others as well. If anyone else has strong opinions, please contact me. + +### Conclusion / Resolution +- Remains at Stage 1 +- SGN to follow up with people who have concerns + +## Temporal stage 2 update +Presenter: Philip Chimento (PFC) + +- [proposal](https://tc39.es/proposal-temporal/) +- [slides](https://pipobscure.dev/slides/temporal-2020-07/) + +PFC: (presents slides) + +YSV: Thanks, one thing I’d like to suggest is to translate the survey so that we get more feedback on other calendars. We do have a few delegates now from China, and they may have some hints about what to do there. It may also make sense to translate it into Japanese, as they use a different year system, to get more diversity in the kinds of responses you have. + +PFC: That's a really great idea, thanks. + +## Import Conditions for Stage 3 +Presenters: Daniel Ehrenberg (DE), Sven Sauleau (SSA), Dan Clark (DDC), Shu-yu Guo (SYG) + +- [proposal](https://github.com/tc39/proposal-import-conditions) +- [slides](https://docs.google.com/presentation/d/18THsm_ZAog70m0ZlEokRCfyrarMiA1yr6YDAvFXjVNU) +- [spec](https://tc39.es/proposal-import-conditions) + +DE, SSA, DDC, SYG: (presents slides) + +JHD: I wanted to put a +1 for assert, I originally said if because it made more sense just given the keywords and making a conditional. +There has been some confusion expressed in the repo, where folks thought that "if" means that the import wouldn't happen if the conditions aren't met. +Which is essentially the semantics that `assert` already has. So I’d prefer to see that change happen. + +DE: I want to go back and say that we have two PRs open right now, that the champions are totally open to land. One changes the `if` keyword to `assert`, the other makes it so that when you have an object, when you have `type`, you can have single or double quotes around the type, so that it can be just similar to object literals. We’re interested in the committee’s feedback on these, and we are happy to conclude Stage 3 being conditional on landing one or both of those. + +JHD: Thank you. + +CM: Wanted to make sure I understood correctly that you’re talking about a mutable object consisting of some JSON data. That seems like an obvious pathway to interference between modules. It seems dangerous. I don’t like that. I think I understand your motivation, but I'm not sure that it overcomes the potential bug-proneness sitting there. + +DE: I could see that. What do others on the committee think? + +MM: I very much have the same concern as CM. I like the phrase is, “If it’s not fresh or frozen, it’s rotten.” If it was fresh so that every import site would get its own, then it wouldn’t cause interference. But there are worse problems with that so I’m not suggesting that. If you just make it transitively frozen, then this avoids the interference. It's not being read by JSON.parse, where each callsite of JSON.parse gets a fresh object that you can freeze. I don’t see any reason not to transitively freeze it and if it was something else I wouldn’t see why not to. + +JHD: JSON modules in node for CJS always had this property, bringing in a mutable object, just like the default for every module. I think the vast majority of people do not bother to freeze them, and they haven’t run into these issues. That’s just the way JS works, things are mutable by default. The other option here is to freeze the object yourself if that’s a concern you have. + +MM: You'd have to Object.freeze it before anybody else has the opportunity to get that object. + +JHD: Your `Object.freeze` call would happen after all the import calls have happened, but since your `Object.freeze` call would run first, before any other user code, it would be indistinguishable to later code that it was ever mutable in the first place. + +MM: How do you get your Object.freeze call to run first? + +JHD: The same way you do any initial lockdown of the environment. + +CM: Here it is data that has been interpreted and is given back as an object + +JHD: For a known JSON module specifier, it’s trivial, and I’m happy to talk about it offline. But like you said CM, if it’s just a regular object literal, it would just be mutable unless you froze it. + +CM: If I did that, then I could freeze it before sharing with someone. Here, I don't get the opportunity to freeze it before it gets shared. Modules can defend themselves, data can’t. + +DE: I want to raise one possibility, which is to decouple JSON modules from the import conditions proposal. Initially, we were just proposing import conditions abstractly, and we added JSON modules to standardize as much behavior across environments as possible, to address concerns about divergence. We could bring import conditions to Stage 3 and leave JSON modules behind, maybe at Stage 2, while we continue to work on it. I think a stage 2 proposal would serve the same purpose of making it clear to the ecosystem that TC39 intends to develop JSON modules, avoiding divergent behavior. That would also unblock other module types like CSS and HTML modules from being developed. + +RRD: I guess I have a small addition to this, about the syntax you put in the slides. By decoupling the JSON loading from syntax, ??? we could basically try to get into a situation where you could use import from something JSON, assert type being JSON, with importing it as Record & Tuple. All of that in a single instruction, so we can basically do what is being suggested so far. It's just something I wanted to put on the table, I don't know if it's necessary. + +BFS: Currently, by default, JS modules and to some extent wasm modules don’t have this frozen-like behavior. I would agree with most of the desires being stated about JSON modules, but I think that freezing and doing other things like Records and Tuples it's a different issue than trying to be creative about how we handle JSON. JSON has very historic meanings, people expect it to act very specific ways, and it would be odd to me for us to not have this kind of special level of care for other kinds of modules we’re also talking about, potential things like HTML modules, which may or may not be considered data, and I just don’t think that we want to apply that on a per-data basis. ??? But I agree the issues are real. + +SYG: want to strongly agree with DE here on the decoupling, json modules are an addon but not an impetus around modules. +And given that there are legitimate concerns around JSON modules, I strongly agree that we should decouple them instead of hold up the whole thing. + +MM: I was preparing to make a passionate plea that JSON should return records and tuples instead of objects, but if we can postpone the discussion about JSON modules that's my preference. Let’s just leave JSON behind for this proposal. + +JHD: Around the caching semantics stuff and the proposed HTML compromise, my concern has been primarily about making sure that various parts of the ecosystem correctly interpret our intent here even if it’s difficult to normatively specify it. I’ve had a lot of discussions with SYG, DDC, MBS, and some other folks, and the solution we seem to have come up with is that HTML doesn't have to potentially obey the restriction, but it still has to conceptually be the same module. So I want to thank everyone involved in those discussions because it seems like we’ve come up with a workable compromise that appropriately informs the ecosystem of the intended limits of this feature. + +BFS: I just want to state that the wording of compromise no longer has guarantees about when you remove the condition. When we were talking about checks at the last plenary, we were also talking about a personal opinion of mine which is that we don’t really desire this in node. Effectively, the last plenary we talked about this, if you had `with type JSON` at the time, removing it essentially was a no-op if you did negotiation of the content type and checks without the import condition. This actually changed with this compromise, so that removing a check is effectful- + +DE: This compromise permits hosts to omit support of a ??? +It would follow this condition if hosts completely omit conditions from the cache key. Hosts _may_ take it as part of the cache key. + +BFS: ??? have them take it as part of the cache key- + +DE: this would have no particular effect on node because ??? and this is discussed in the HTML thread that just because it’s permitted doesn’t mean that an environment couldn’t do something like normalize the condition into some other state before forming the key or making conditions from the key. I think this would still permit node to have it's behavior, while aligning in practice with HTML. + +BFS: I would agree but that seems a bit evasive + +DE: How so? + +BFS: It seems to be moving the statement that HTML simply won’t diverge, not that they can’t diverge. Which we don’t have guarantees about. I think we should just add a "should" clause to this. That they “should” do, effectively, what you said they won’t do. If we can’t enforce it that’s one thing and that is fine to me but we should make sure this is not the case + +DE: What do you think of this note at the bottom, which says “???”. Is this distinction [crosstalk] + +BFS: ??? I think the phrasing on the bottom is confusing, but as long as it's revised it should be ok. + +DE: Okay, we can have a follow up to- + +BFS: It is not a blocker but I think we need to have a call + +SYG: To add to the normalization, the lack of a condition: maybe we would like to normalize something. This relaxation does not mean that the lack of a condition has to be recorded as a lack of a condition, the host can normalize it. + +BFS: That is concerning to hear actually, but we can talk about that later, none of this is blocking, it’s just about phrasing. + +SYG: Sounds good. + +DE: It seems like the exact wording of a recommendation in a note vs a "should" normative text is something we could iterate on during stage 3. + +BFS: I’d agree. + +WH: A couple things. I don’t take a position on the desirability of whether or not this should or should not go into the language, but as was mentioned earlier in the presentation, it bothers me that you don’t have reviewers and are trying to go to stage 3 without reviews. Just in a few minutes during the discussion I was able to find bugs like that this proposal breaks existing code. + +DE: Can you elaborate on that bug? + +WH: For example: +`import "foo" +if (x) …` + +DE: I don’t think it would because the `if` keyword has to be followed by a `{`. + +WH: Do you understand when semicolon insertion inserts a semicolon? If you have `import "blablabla"`, line break, `if (`... + +DE: Right, right! Would you be satisfied by the switch to `assert` because it would solve that by requiring no line break before the `assert`? + +WH: Yes, it can be fixed with a [no LineTerminator here], but it bothers me that this proposal didn't have reviews. + +AKI: We have SYG, who has reviewed this? + +SYG: I guess I missed that bug in the syntax. But from the semantics side of HTML, I have reviewed it, and it’s sound. + +WH: Okay. + +SYG: Covers my point as well. + +AKI: From an educational point of view, I like "assert" a lot. + +DE: I’d like to propose the following resolution: we don’t have reviews yet as well as having a bunch of changes as well. There seems to be a lot of interest in splitting off JSON modules into a separate proposal so that we can think more about this mutability issue, and I say it would make sense for that to be a stage 2 proposal. And finally about the quotes around the properties, does anyone in the committee have opinions about this? Because we also have to decide about whether to land that PR. I want to propose that we land that PR and allow quotes, but continue to ban numeric literals in this context. And I’m wondering if people have concerns with stage 3 with those changes queued? + +JHD: If we do split it, would they be re-merged before we would try to make the import conditions to stage 4? My hope would be that both advance together to signal to everyone in the ecosystem that these things go together, and to ensure that no hosts ship a key that would conflict with JSON modules in the meantime - my hope would be that they advance somewhat together. + +DE: For the latter concern, I think that maintaining a stage 2 JSON module proposal would prevent this problem: it would be weird for hosts to do that while this proposal is ongoing. I don’t want to take a position on whether JSON modules or HTML modules or CSS modules are more important, I think they’re all important and I want to see them all happen. I disagree both with JHD’s and SYG’s statements about one or the other being the "real" goal. I'm not yet convinced that we need to tie JSON modules together with import conditions for Stage 4, but I agree that JSON modules should be supported the same way across environments, and to support that, that `type: json` is something that TC39 intends to work on. Maybe we could lay that out clearly in the import conditions README? + +JHD: that seems fine, I was just asking to figure out a course of action + +BFS: I feel quite strongly that you should allow quotes, in particular because for the dynamic import form you'll accept runtime objects. + +DE: Yes. + +BFS: And so the ability to provide properties that are only picked up in one form seems very problematic. I don’t feel the same way about symbols. This came up with module export names with people using unicode and non-identifier names. And so I feel very strongly you should allow strings in order to allow those specific values to exist as the key. + +DE: That makes sense to me. Thanks for your feedback. + +DE: Do we have stage 3 reviewers, we need at least two. + +BFS: I'll do it. + +WH: I’ll review the syntax aspect. Just ping me when things settle down. + +DE: That’s two. Should we record SYG as well? + +SYG: I’ll be happy to review but since I’m working on part of the proposal I don’t know if that counts. + +DE: Let me recap what the potential conclusions are. One is that we switch `if` to `assert`. One is that we permit the quotes around the property keys, either single or double quotes, but not numeric or computed properties. One is that we decouple JSON modules, and will make a new Stage 2 proposal so that we can iterate on the immutability questions. And finally, that we merge this relaxation of the constraint on host caching, taking care to reword the language here, to emphasize that hosts should return "morally" the same module regardless of the import conditions. Does anybody have any concerns with this course of action, concerns that you would have for stage 3 given that? + +[silence] + +DE: Okay, thank you very much. + +### Conclusion / Resolution + +Land patches for s/if/assert/ and permitting quotes around condition keys +Split JSON modules into a separate Stage 2 proposal +Land weakening of the host constraint, iterating on the wording in cooperation with SYG and BFS +SYG, BFS, and WH to review before Stage 3 +Proposal remains at Stage 2 + +## Intl.Segmenter for Stage 3 +Presenter: Richard Gibson (RGN) + +- [proposal](https://github.com/tc39/proposal-intl-segmenter) +- [slides](https://docs.google.com/presentation/d/1LOOt4WPvQdOK3banHkz1V8sdl8Z-7Z9jXBRRS9Ek8-M) + +RGN: (presents slides) + +DE: You referred to the string getter as superpower, and I wanted to express reservations about that characterization. There was that previous exotic internal slot hazard discussion - we discussed this more in the SES strategy meeting. MM is here, so he can talk more, but what we arrived at is that internal slots with objects are not dangerous if accessed from `this`. https://github.com/tc39/proposal-intl-segmenter/issues/96#issuecomment-661008571 + +RGN: It would impose additional work for what have been referred to as “near membranes” in the SES call. But the change was primarily about ergonomics, avoiding the internal slot use wasn’t a motivating factor. I’m willing to back off on the characterization. + +MM: I can clarify. I raised the near-membrane issue. Near-membranes are CP’s invention. He got on the call to clarify the constraints. The internal slots create extra work only if associated with undeniables (NB: objects accessible via syntax). Intl.Segmenter does not couple these to any undeniables. That said, my aesthetics is still to prefer to avoid them, but at this point that’s a mild aesthetics and not an objection. + +DE: My aesthetic for me is to prefer internal slots, following the pattern established in ES6. I really like that this proposal improved a lot in ergonomics compared to how it was when I was championing it. So I’m really in support of stage 3 for this proposal. + +SFC: With the segments objects being iterables rather than iterators, I agree with RGN, in favor of the current status. If the `Number.range` champions, or anyone else who has thoughts on iterators, it’d be good to hear thoughts on that. We've seen some of them on the issue tracker in https://github.com/tc39/proposal-intl-segmenter/issues/120, but right now the plan of action is to move forward with the Segments object. By approving stage 3, it means that as a committee we’re okay with moving this forward with the segments object. We can maybe change it later but if we don’t we’re still happy with it + +AKI: Stage 3? Again? + +[silence] + +YSV: I’d like to explicitly say I support stage 3 and congratulations. + +AKI: Congratulations! + +### Conclusion/Resolution +- Stage 3! + +## Iterator Helpers update +Presenter: Adam Vandolder (AVR) + +- [proposal](https://github.com/tc39/proposal-iterator-helpers) +- [slides](https://docs.google.com/presentation/d/1YNLzi_ENRtxp5bjhXMUplQ0VIQBUFLyucbNFt_oaNgQ) + +AVR: (presents slides) + +AKI: Do we have any volunteers for stage 3 review? + +RGN: I’m willing to review. + +LEO: Are tests ready? + +AVR: We have a set of tests we’ve written for the firefox implementation. They’re currently being cleaned up, and I’ll hopefully be able to open up a PR to get them merged into test262 especially when it goes to stage 3. + +AKI: Any other stage 3 reviewers? + +MPC: I’ll go for it. + +JHD: I’m happy to review it if needed, but I have to review it anyways for editor stuff. I’d rather give the opportunity to someone else if they’d like. + +AKI: Do we need a third stage 3 reviewer? + +MF: I think two should be sufficient. + +### Conclusion +* RGN and MPC are reviewers + +## .item() for Stage 2 +Presenters: Shu-yu Guo (SYG), Tab Atkins (TAB) + +- [proposal](https://github.com/tabatkins/proposal-item-method) +- [slides](https://docs.google.com/presentation/d/1N-oXRRKDA7patBA4HIYkzN67j1pbyOxuDZoYRvPFmuA) + +SYG: (presents slides) + +SYG: Stage 2? + +TAB: First, thanks so much for presenting this for me, for doing the useful committee work for me. One concern I had when reviewing the spec is that the clamping behavior for negative values prevents you from trying to access a non-existing index. And that does exactly match how `slice` resolves its negative indexes, but `slice` won’t actually give you the first element unless you have an interval between the two values. If you use `-1000, -1000` with slice, you’ll just get an empty array. So it seems to me we should clamp to -1, ??? eagerly return ???. + +SYG: That's a good point, I missed it while copying the clamping from slice. We can’t make it -1 and probably have an explicit path to return undefined. +Also I see in the chat that TAB said that I misspoke, and that ObservableArray is a Proxy around arrays. + +TAB: the alternate possibility is to allow to dispatch whatever value you want. +We could just let negative numbers go negative, and it’ll try to fetch the string value `-1000`, just like fetching index `1000` on a length 10 array. + +SYG: Are folks ok with iterating over these concerns during Stage 2? + +BFS: Yes, we can iterate in stage 3. + +RGN: I’d like to express my support for this proposal. This looks good to me, I like iterating on the edge cases in the staging process, and I’m willing to review. + +SYG: thank you, for the second reviewer, can I call you out KM since you seemed excited? + +KM: I can do it, that’s fine, sure. [crosstalk] the price you pay. + +LEO: I will review it no matter what. [crosstalk] From the test262 perspective this is a pretty easy one and I’d like to ??? everything. + +SYG: Thank you very much. + +JHD: To clarify for me and the notes, what are the things that are still open for stage 3? TAB you talked about the clamping stuff + +TAB: Basically just the clamping stuff. + +MLS: These corner cases are for stage 2 right? So before stage 3? + +JHD: Correct. + +### Conclusion/Resolution +- Stage 2! +- RGN, KM, LEO to review for stage 3 diff --git a/meetings/2020-07/july-22.md b/meetings/2020-07/july-22.md new file mode 100644 index 00000000..dd27309a --- /dev/null +++ b/meetings/2020-07/july-22.md @@ -0,0 +1,674 @@ +# July 22, 2020 Meeting Notes +----- +Delegates: re-use your existing abbreviations! If you’re a new delegate and don’t already have an abbreviation, choose any three-letter combination that is not already in use, and send a PR to add it upstream. + + +**In-person attendees:** + +**Remote attendees:** +| Name | Abbreviation | Organization | +| -------------------- | -------------- | ------------------ | +| Yulia Startsev | YSV | Mozilla | +| Jack Works | JWK | Sujitech | +| Richard Gibson | RGN | OpenJS Foundation | +| Waldemar Horwat | WH | Google | +| Marja Hölttä | MHA | Google | +| Pieter Ouwerkerk | POK | Stripe/RunKit | +| Chengzhong Wu | CZW | Alibaba | +| Bradford C. Smith | BSH | Google | +| Istvan Sebestyen | IS | Ecma | +| Chip Morningstar | CM | Agoric | +| Justin Ridgewell | JRL | Google | +| John Hax | JHX | | +| SongYang Pu | SYP | Alibaba | +| Leo Balter | LEO | Salesforce | +| Daniel Ehrenberg | DE | Igalia | +| Nicolò Ribaudo | NRO | Babel - Invited Expert | +| Hemanth HM | HHM | PayPal | +| Ben Newman | BN | Meteor/Apollo | +| Jordan Harband | JHD | Invited Expert | +| Bradley Farias | BFS | GoDaddy | +| Mattijs Hoitink | MHK | Apple | +| Sergey Rubanov | SRV | Invited Expert | +| Devin Rousso | DRO | Apple | +| Michael Saboff | MLS | Apple | +| Shane F. Carr | SFC | Google | +| Mary Marchini | MAR | Netflix | +| Rob Palmer | RPR | Bloomberg | + +## Ergonomic brand checks for private fields for stage 3 +(Jordan Harband, JHD) + +* https://github.com/tc39/proposal-private-fields-in-in/issues/7 + +WH: I’m only “halfway” a reviewer for this one. I reviewed this proposal but couldn’t get a rendered version of pull request 1668 which this proposal depends on so I can’t check consistency of some of the grammar productions this uses. I asked for a rendered version of 1668 and was told that it wouldn’t be made available until other proposals get to stage 4. This makes it hard to review this proposal. + +[JHD presents slides] + +JHD: It would be great to get WH’s opinion on the record about whether this is appropriate for advancement. + +DE: Apologies for the legibility of the class feature proposals—I’ll get that fixed up by next TC39 meeting. I was hoping it would get to Stage 4 first, but that didn’t happen yet. I’ve reviewed the spec text and JHD and I have discussed it, I didn’t sign up as a reviewer, but I’m happy with the way it’s organized. The set mechanics seem to land well with the current structure. + +WH: I am comfortable with this going to Stage 3. I’d like to see the unified grammar for all the class proposals this depends on and am frustrated I couldn’t get a rendered one, but this is not the fault of this proposal. This proposal seems simple enough that I’m comfortable with its advancement. + +KG: I’m also comfortable to sign off on this. I have editorial concerns with control flow here, relying on abrupt completions, which I’d like to see refactored. But the current text is sufficient for implementation. + +JHX: What about the potential confusion with the current syntax and the concept models? If we will have first-class private proposal, I wish it could be advanced to a stable stage before this proposal would go to Stage 3. I think it has many relationships to other proposals and they will affect each other. + +JHD: Certainly my proposal entirely rests on the class fields proposal, and it cannot advance beyond it. IF there will be changes in the class fields proposal, then this proposal would be impacted. +To the confusion point, and to your question in the queue which is about the private declaration proposal, the README explains that there are no conflicts. If #foo will be a first-class value instead of a syntax error, then the "in" operator will just work as it works with symbols and strings. + +DE: I discussed with JHD the possible conflicts with other proposals, and I’m happy with the way the considerations this proposal has made. I don't see a risk of conflicts. + +JHD: Given the support from DE and the question from Hax about interaction with private declarations, I want to ask if we have support for Stage 3. If the class fields proposal significantly changes, I would be happy to bring this back to Stage 2. Does anyone object to Stage 3? + +JHX: I still don't think that my concern is solved. The confusion is about first-class private symbols: if there will be such thing, I think it should be advanced to Stage 1 or 2 before that this proposal moves to Stage 3. + +JHD: Just to understand what you are saying: if that proposal advances, then you are comfortable with moving this to Stage 3 because they would play well together? + +JHX: I don't have the confidence that the current syntax would work without it. The overloading of "in" is a little bit confusing because the lhs of in has always been a value. First-class private symbols will probably make it clear, but I don't know if they will be there. This is a blocking issue. + +BT: We are overtime. Maybe you two can discuss this offline and then update the notes. + +### Conclusion/Resolution +* Will be discussed offline + + +## Upsert (now renamed emplace) updates ~& for Stage 3~ +Presenter: Bradley Farias (BFS) + +BFS: (presents slides) + +* [proposal](https://github.com/tc39/proposal-upsert) +* [slides](https://docs.google.com/presentation/d/16PtTpuvkTFycaaqkk5XGZRPLNwzUrzBuN9y7VSrGX9k/edit#slide=id.p) + +WH: I find that the “emplace” name is very confusing, as well as the changes to turn this from using a couple parameters to an options bag. Both of those produce clashes: In C++ “emplace” is a lower-level functionality than “insert”, whereas this is higher-level functionality than you would get from insert or update. + +BFS: I’d be open to another term. + +WH: I just find the name “emplace” very confusing, coming from the C++ world, because it stands for a different concept. + +BFS: I don't agree with that statement, but agree that it could be confusing. + +WH: The other clash I see is that this proposal was changed to use an option bag, which seems overkill for something with only two parameters. Had we been using option bags for other methods like `slice`, where it’s useful to disambiguate between using the start-and-end or start-and-length, then this would be more consistent. But using an options bag in one method when similar methods do not use one seems like a clash. +For both of those reasons, I'm not in favor of this any more. I was earlier, but this is now too complicated and too confusing. + +BFS: Can you explain what you meant by "clash on options bag"? + +WH: The confusion is that you're now introducing a new style of invoking methods using options bags instead of parameters, so now you have to remember which things use options bags and which things use argument lists. + +BFS: We have a blocking concern on using parameters. + +WH: Yes, and this is a blocking concern on using options bags. It's overkill in this case. + +BFS: Given any method in this language, we already need to know the type of it's parameters. + +WH: If we were using options bags consistently, then things like .slice() should use options bags. Since it's not, we shouldn't use it there. + +BFS: [interrupts] + +WH: I don’t want to debate this here. We have a long queue; let’s let others speak. + +MM: Generally with options bags, the choice to provide parameters with an options bag is driven by a certain expectation of supporting introduction of new options over time. +Code written for later versions that recognise new options would still work in older versions, where these options would just be ignored. I don't think that kind of evolution expectation is an issue with regard to this operation. I also want to draw a hard distinction between option bags and handles. Maybe proxy handlers should have been an option bag with eager sampling, but the key thing there is the `this` binding. The fact that it's always looked up on demand is (???) the handle object is an API. I think it's important to keep those psychologically very different from each other. So I agree with WH that the option bag in this case is overkill. + +BFS: We have a comment in the repo about using what we call this param, let’s say a “handler”, as the "this" value in order to achieve a specific use case. We didn't initially put it in the spec text, and this is where we got the comment that people wanted it. + +MM: If you have the `this` value, and you have much more static expectations evolving in the API over time, and if it's looked up in a normal method lookup method on each use, then it's a handler, not an options bag, and my previous comment doesn't apply. But an options bag would be overkill. + +BFS: I think that this goes down to the need of writing it down in a "terminology" section somewhere. It's a terminology problem. + +MM: Ok + +TAB: I very much appreciate this feature. Just because updating when the values are already present is super useful, and annoying in expressions where you have long map names. But I don't like that you need to provide an insert. Sometimes I want to update myself without proving a `get`. Having to provide a dummy value for the insert doesn't seem an ergonomic thing to do. And that would tell the stitch type checker that the return type might be a string, and that's just as random and unwanted as assuming that `undefined` is part of the type signature. If I know personally that there is a value there, I can make my typechecker understand it. But I don't think we should be forcing everyone to put an insert handler just to satisfy type checkers. + +BFS: In the readme, you'll see an example that doesn't have an insert() method in the handler. It's just called if the value is missing. If you are only trying to perform an update, .insert() will only be looked up lazily. You can omit it. + +TAB: OK! That completely solves my concern. So it will throw if you have a missing value. That's great. + +JRL: Can we just pass the options bag in the constructor? Many suggestions in the repo are about having a default value for missing elements in the map: if the key is not there, .get() will return the default value. + +BFS: We did have this suggestion, but I have concerns about this: you can perform m.has() and get "false", but then m.get() would return something different from "undefined". There is code on the wild that relies on this contract, and adding the constructor parameter would change the contract when it's passed to other things. + +JRL: OK. + +BFS: It's not to say that other languages don't do that; it's just that we already have a contract with `.get()` that we have to satisfy. + +TAB: Python has both of these. I use them both regularly, and they are not in conflict. I think we should still pursue default semantics via the constructor separately, but it should not fight with upsert. I want them both. + +YSV: We are speaking about this feature in a specific situation. We don't have something like Python's getDefault, or setDefault, or DefaultDict. These are things missing in the language, but we are currently talking about introducing .emplace(). I think I would be more pliable to the idea of emplace (or a different name) if we had the others. With BFS we have been talking about examples in the wild about this type of code. I investigated the TS codebase or other places where the pattern of updating or inserting occurs, and I think that .getDefault() would better match these use cases. So, I feel that we should do getDefault(), and that getDefault() should take precedence over this proposal. + +BFS: To be clear, .getDefault() is just not providing an .update() parameter to this. + +YSV: I would find stretching .emplace() to do .getDefault() be very user-hostile. +You would be using this one thing to do those three things, whereas each of those things should be separate methods. + +BFS: I am opposed to single responsibility, as documented previously. + +YSV: We should have single responsibility for this. + +BFS: Then we might be blocked. + +JHD: Proxy-like handler pattern is bizarre and should not be propagated. A proxy around an object is often a stateful thing that it's trying to track things in an object, while in this case I don't understand that the argument would be for having a stateful handler. And similarly, by not using the handler pattern, we can do eager retrieval of the methods, which can allow for early validation. + +BFS: We had a comment about why people wanted to use a stateful handler, and we have a comment about why people don't want to have eager lookups. So, I guess you consider not having the `this` value more important than those two? Is that correct? + +JHD: Yes. + +BFS: So if we move forward with this proposal, you want to require that `insert` exists? + +JHD: No, if there is an object containing functions, I'd want "options bag" semantics and not "proxy handler" semantics. As far as whether it's present or not, that depends on the semantics of the methods. If `insert` is always needed, it should always throw if it's missing. If it's not always needed, it should be validated; for example, if you pass an array, it should throw. In every code path, the function that are passed in should be either "function" or "undefined", or they should throw an exception. + +BFS: That's how it's specced. + +YSV: The problem with the object was the cost of the object allocation. It isn't an objection, it’s an observation. + +YSV: Proposal is very opinionated on how code should be written when this may be a matter of taste. For example, you can't insert an object that's then updated. You would have to do 2 calls. In the examples you provided me, they would have to insert a value that would then be updated. Additionally, the update() forces people to do everything inside the update function, but we've seen that things like `await` have been very popular in allowing people to do operations in line with the rest of their code. + +BFS: In the FAQ we have some responses about that. You don't have to do 2 emplace calls. If you need to do it in both .insert() and .update(), you can just allocate the pattern eagerly. + +YSV: That isn't always the pattern people want to follow in their code. It's an opinionated pattern of coding. + +BFS: Update could call this.insert() if it needs the initial value, since the receiver is the handler. + +YSV: I consider what we're doing here is, since we're not giving the other tools building blocks for this, we're tying peoples hands to code in a very specific way. + +BFS: That's the intent of this proposal, to avoid the problems I'm describing. + +YSV: I would say that those problems might be unique to the codebases you have worked on, and that they might not be shared globally. + +BFS: That is understandable. + +BFS: So we have a lot of conflicts about people wanting specific behaviors or not wanting the proposal, so I think we are going to consider this blocked for now. We can follow up on the repo. If you wanted a change, please open an issue. +We have to agree either to solve problems with different priorities, or just to abandon it. + +### Conclusion/Resolution +Follow up on conflicts on the repo. + +## Number.range for Stage 2 +Presenter: Jack Works (JWK) + +* [proposal](https://github.com/tc39/proposal-Number.range) +* [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.p) + +JWK: (presents slides) + +JHD: When we say "iterable", it's not really being used as a noun; it's an adjective. “An iterable” refers to the things that are participate in the iteratable protocol. A Map, Set, etc., are iterable; they have that protocol. For Number.range, the only way it could return an iterable is if it returns a new type of object and _then_ that object would be iterable. We have no precedent in the spec for returning a plain object just to have an iterable. It would be very strange to do that. For all the cases people have advocated for re-usability, stick `()=>` in front of it, and it becomes re-usable. It just seems really weird to me if this returns a plain object instead of adding a new kind of object. + +JWK: If we make it a class, then is it okay for it to be iterable? + +JHD: If we had a Range class with instances, it would make sense for Number.range to return that and then that object would be iterable. But I don't see the necessity to have a Range object. + +MM: I use "iterable" as a noun. I find the idea of this operation to be counterintuitive and hazard-prone. An iterable seems to me to be exactly right, and I certainly agree English-grammar wise it’s an adjective, but in a programming language, it’s coherent. That said, the iterable in question here saying that the iterable is a range object is fine with me. It's still the case that the collection that the object is not mutated. + +GCL: I think the issue is not returning an iterable to itself. The problem that I see is that we have a cohesive set of patterns that we have established in the standard library, and that we have tried to take advantage of the iterator helpers proposal to sort-of keep these patterns… it's about reusability, and that's the argument we had on whether it should be iterator helpers or iterable helpers. The question was whether it should be reusable or not. +So, like this slide shows, reusability should be sticking an arrow function in front of it. In terms of the pattern it creates here, you have a global constructor like NumberRange, or you have a constructor on Number.range that returns an iterator. + +JWK: Yes; arrow functions solve the problem. But I think people might forget to do this. + +GCL: We have a lot of evidence otherwise, from the iterator helpers proposal. + +JWK: Can you share a link? + +GCL: Yeah; I'll send it offline. + +MPC: I'm in favor of `range(n) => range(0, n)`. There were several solutions proposed in the issue for this. I would be very strongly opposed to the single argument version implying "n to infinity". I would find it very confusing. I'm in favor of range(n) implying from 0 to n. + +JWK: I didn't make the 0-to-n decision now. If everyone's okay with that, I'll make range(n) mean range(0,n). + +MF: I strongly favor requiring both arguments. There are two very reasonable interpretations of the single argument. I see no reason why we should choose one over the other. + +JWK: Is n-to-infinity more usable than 0-to-n? + +MF: It's not based on the usefulness, my comment is based on what people might expect when reading it. + +JWK: If people can't get a strong clue for this, maybe we require both arguments. + +DE: I raised concerns about using an iterator in the issue tracker. I'm happy with the idea of omitting zero, but it doesn't seem essential. +Number.range as an API doesn't represent ranges in general. It would need to have .contains(), etc. This is just an API to get the iterator, and it seems ok that it returns an iterator. I think it's important that we move forward on this proposal, because it's an important part of the JavaScript ecosystem and it works well with other proposals like iterator helpers. + +TAB: The many times I wrote range() for myself I just used a generator. These are the semantics that most people would expect, so I'm strongly in favor of just returning an iterator for that reason. + +JWK: I see the view that only JavaScript experts will see this as a generator, because we implement it as a generator. But people new to JS may think that this might be re-usable. They don't think about how the range function should be made. + +TAB: I think that range is one of the simplest possible generators you can write. So if you know what a generator is at all, you're probably already familiar with a range generator. + +JHX: I strongly prefer iterable. JWK has also worked on a compat reasons document, which investigates many more programming languages. The table in the repo shows that only Rust is using iterator-like semantics, but Rust is very different from other languages because of the strong compiler that protects the programmer from not using the iterators incorrectly. +All the other languages in the list use the Iterable semantics: I don't see any strong reason why we should use something else for .range(). The motivation of range is so that you can do like in Python, for convenience. These experiences are signal that programmers will very likely expect it to be an Iterable, or they don't notice the difference between Iterable and Iterator, so in that case, Iterable is more secure for them. For the userlang, if we check for example lodash, it returns an array which is similar to what Python 2 did. In Python 2, range returned an array, and in Python 3, switched to an iterable. +Also ReactiveX/IxJS, which is mentioned in the iterator helpers repo as prior art, they use the iterable semantics. I think we can check more userland libraries to see what was meant by programmers, and what programmers want. Finally, I don't think the arrow function fixes the reuse problem, because the range has many arguments. If you want to reuse it, you need to create a function with all these arguments. It's likely that you need to add many arguments. So it's likely that they need to wrap a function with no arguments at all, or just to make an iterable object for it. I don't think arrow functions really solve the problem for reusing ranges. + +BT: We are out of time. + +SFC: Do we have consensus? + +WH: No; we still have several items in the queue. There is a completely different issue no one has mentioned yet that I wanted to discuss. +### Conclusion/Resolution +* No consensus for Stage 2 +* Needs more discussion that didn't fit the timebox. + + + +## await operations for Stage 1 +Presenter: Jack Works (JWK) + +* [proposal](https://jack-works.github.io/proposal-await.ops/) +* [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.g89f56b0333_1_40) + +SYG: I don't think new syntax is warranted here. What these new operators would do is let you avoid typing `Promise.` something. That doesn't seem like it justifies the extra syntax. If we were to add more complex or combinatorial behavior, it would justify something more sophisticated than just omitting `Promise.`. + +JHD: In V8, await is different from calling .then() because the "await" syntax allows more optimizations and it's different with stack traces. It seems like we can make the DX much better here for folks that need to use promise combinators. + +SYG: You said 2 things: the first is the stack trace; the other is the optimizations. The advantage of the optimizations is that it saves you the lookup of Promise. Maybe there's a little optimization advantage, but it doesn't seem compelling. For stack traces, the current combinators' stack traces are lacking and it won't be fixed by introducing new syntax. It seems to me that it's impossible to fix the stack traces, I could be persuaded, but I don't know that's the case. + +JHD: I’m assuming that since stack traces are optimized for `await` but not for `.then`/`.catch`, that it is indeed impossible to fix the non-syntax cases. + +YSV: +1 on SYG's position. + +JHD: The original async/await proposal had `await*` for Promise.all, and i don't remember the exact reason for removing it but what I recall is that one of the objections was not being compatible with `Promise.race`, or possible future combinators (and we since added two). One of the advantages of this syntax to me is that it is cleanly forward-compatible if we were to add other combinators. + +LEO: This is a very compelling proposal for me, and it deserves further investigations as Stage 1 requires. There are a lot of issues here; I don't like the current proposed syntax. I could think of some `await*` that would come from `Promise.all` that could fetch things better. There are a lot of things I would like to keep discussing about this, but we don't have enough time during these meetings, and I would love if we could set this to Stage 1 to discuss it more. + +JKW: Yeah; we can discuss syntax later, of course. + +DRR: I like the idea of this - it's cute. But we have to anticipate only unary operators. One thing we see on the TS side is that we have these unary operators that you prefix with some sort of syntax, and one of the questions that comes up often is "what if we had this other operator", but then it's different because it would accept two values. +You can just say "well, we won't create operators that take 2 args in the future". You would introduce some imbalance, but you really have to expect that these operators could come up in the future. + +JKW: I added this because I think the matrix of the four combinators all have one argument, so I think it’s safe to do that. + +DRR: You could make a reasonable argument like "even if in the future we'll have a binary operator, we don't have to (???)", and that's ok for me. + +DE: I agree with others that this proposal improves ergonomics. It's hard to explain to beginners why you have to write `Promise.all` instead of awaiting each function as you call it, which serializes unnecessarily. This proposal might attract people to use more efficient code patterns. + +DE: I'm wondering why the original values are used, rather than the current ones. The semantics proposed during this middle spec, where it uses Promise.all but uses internal Promise things. This means that it adds undeniables, but also is influenced by monkey-patching Promise.prototype.then, etc., so it doesn't seem like we gained much by making an undeniable. + +DE: I support this proposal for Stage 1, because this kind of feature to await a sequence of promises is a request I have already seen frequently before. + +JKW: I think SYG suggested to remove some subclassing in the language. + +DE: Yeah; in the future, this could be observably equivalent to `await*`. + +JHD: If we used `await*`, how do you do Promise.race semantics? + +DE: I think the Promise.all semantics are just higher priority than the other three combinators, so I disagree with the previous objections for lack of generality. Really, I'd be OK either way on the various syntax forms. I don't have strong objections to the syntax proposed. I'm just not convinced by the arguments of one or the other proposal being unacceptable. + +JHD: "original values" is how `await` already works, for `PromiseResolve` and `%PromisePrototypeThen%` + +DE: Promise.all doesn't use the original values internally, it does various property accesses. That's not what you want if you need something reliable, e.g., top-level await does not use Promise.all for this reason. + +BT: Any objections to Stage 1? + +SYG: I would like, for Stage 2 and beyond, this ergonomics point of people accidentally doing serial await, an area where this proposal would concretely improve, I would like to understand that better before Stage 2. That seems to be an empirical claim, I would like to see some examples. Right now the motivation is just "it would be nice to be able to do it". I want to understand better the ergonomics improvement. + +LEO: I suggest an incubator call for this. + +BT: Stage 1? + +[no objections] + +### Conclusion/Resolution +* Approved for Stage 1 +* Follow up in a possible incubator call + +## Array.prototype.unique() proposal for Stage 1 +Presenter: Jack Works (JWK) + +* [proposal](https://github.com/TechQuery/array-unique-proposal) +* [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.g89f56b0333_1_150) + +JWK: (presents slides) + +WH: I looked at how it's specified, and I find the behavior confusing. Depending on how you call it, it sometimes canonicalizes -0 to 0 and sometimes not. I find that very confusing. + +JWK: We can update it to a more consistent behavior + +WH: I would very much like it. The current definition sometimes modifies the values instead of just uniquefying them. + +LEO: It's not clear to me when we say that it's confusing. This is considering the whole set of options in this space, and that's fine for Stage 1. We would need to solve these questions before Stage 2, but it's not a problem we have now. + +MF: In general, I'm in favor of adding something that accomplishes uniquing to the language. I wanted to point you toward a possible additional API, (https://es.discourse.group/t/array-prototype-uniqby/138). The one you've covered takes a function with one parameter, and the other option is that we have a function of two parameters that returns a boolean. We may want to consider that alternative or even both, as they each have their pros and cons. + +JWK: Let's bring this to the issue tracker. + +JRL: Please remove string/number/Symbol auto-function behavior. This is something that people liked when we added it to underscore/lodash, but we should add this call style to all methods at the same time, like map. Adding this only to unique is not a good idea. + +JWK: I agree, I will remove this part or split it into another proposal. + +KG: +1 to JRL, except that I don't think that this [referring to auto-function behaviour] should be added in general. + +JHD: +1 also. + +SFC: I have a meta-question about this subject: there are a number of proposals out there there are adding features, or syntax, that are already possible to accomplish with the existing constructs of the language. On one hand, we could do something like Ruby and add every function that might be needed. On the other hand, we can just add a basic set of utilities that people can compose. Where is the line between what fits into the language and what doesn't? + +MF: This is something that people often need to implement. + +KG: It doesn't always make sense to add operations that can be written based on the existing things (like .filterMap), but when the operation in question is a relatively primitive tool, like flatMap or unique, even if it's something you can implement in terms of existing operations it seems like something we should add. + +SFC: I posted in the repository one line that solves the problem in ~20 characters. + +KG: That doesn't make it trivial. + +LEO: To answer the question from SFC, I don't see the problem with discussing new features that are composition or things we already have, especially when they are already common in other languages. I know that there is a ???, and that's why we discuss things here. + +LEO: Potential web compat issue. e.g. https://mootools.net/more/docs/1.3.2.1/Types/Array.Extras#Array:unique. I anticipate that if we go with this feature, I strongly believe that we might find compat issues and we should think about an alternative name. + +JWK: I did a quick check, Mootools are adding it the same way as flatten (enumerable) so we must choose another name. + +BT: JWK is asking for Stage 1. Any objections? + +[silence] + +### Conclusion/Resolution +* Stage 1 +* The name might not be web compatible + + +## Record and Tuple for Stage 2 +(Robin Ricard (RRD) , Nicolò Ribaudo (NRO) and Rick Button (RBU) present) + +* [proposal](https://github.com/tc39/proposal-record-tuple) +* [slides](https://button.dev/talks/record-and-tuple-tc39-july-2020.pdf) + +SYG: Is Object.is checking for identity or simply conflating +/-0? +RRD: Not identity. + +SYG: If there are two separate literals also Object.is, if they don't contain +/-0? +RRD: Yes + +WH: Does `==` do exactly the same thing as `===` when applied to records and tuples? + +RRD: Yes + +WH: I like how you dealt with ±0. It’s very important to not silently alter values stored into records and tuples, and this proposal avoids that. The proposal diverges from existing practice by making a record containing `NaN` equal to itself. While different, I see the rationale for it and I don’t think it will cause significant problems. + +WH: I see that element order is significant in the Record equality algorithm and you sort elements by their property names when creating the Record. As long as the property names are strings, you can always sort them, so that works. Do you have any plans for allowing record property names that are something other than strings, like symbols? + +RRD: Good point. Two things. First, last meeting, it's not in the slides, but you can't use symbols as keys in records. Second thing is, the way records are created when we create those literals is that they're stored as a sorted list of keys. You can create them in any order, and in the spec, we sort the keys before creating the structure. + +WH: OK, sounds good, thank you. + +BFS: I would avoid comparing the record and tuple equality with maps, because maps normalize. You might want to note it somewhere. + +RBU: Yeah; if you create a record with `-0` and then access the field, you get back `-0`; it's only equality that differs. + +RRD: It is not exactly the same from what we expect it to be. + +JWK: For the symbol prototype, it sounds like it's not possible to add it in the future? If you add a reference like the virtual DOM… ??? + +RBU: If we eventually decide to go with..that will prevent us from virtual DOM, the only thing that will be restricted is allowing them as keys themselves, it would still work. + +KG: I am in favor of this, but it is not obvious to implement it in a performant way at all. I would like to hear it from implementors before advancing to stage 3. + +RRD: We have started reaching out with the implementers. + +YSV: We have some concerns and we have ideas before stage-3; We are in touch regarding the implementation difficulties but they have addressed the motivation concerns which we raised. At present we are satisfied, but the proposal will need to be proved in terms of implementability. + +POK(?): I have been watching this proposal with little discomfort, if this can be implemented in our scope of small embedded devices, I am ok, or else I am concerned about what it justifies. I am huge proponent of immutability in JS, like deeply frozen object, supporting the lang for that is welcomed, but not everything that we bring here at the cost of that, I am not objecting to moving to stage-2 but we need more to answer before progressing. + +DE: Possible developer expectation of sub linear comparison and structure sharing. I would be interested to learn more about the concerns. + +YSV: I want to echo Moddable’s comment here. The implementation burden here is high, and this proposal should demonstrate its usefulness. Given the amount of work that this will take, this can be done in stage-2. I am sensitive to the need of the champions to have buy in from the committee to do this work. + +JHD: Clarification on Jack’s topic, since keys are sorted, and there is no possible way to sort Symbols, does that mean Symbols could never be Record keys, even in a followon proposal? + +RBN: Yeah; we would need a way to sort symbols in a side-channel. + +JHD: So unless we solve that, the path is closed to symbols as record keys. + +DE: I'm fine with this conclusion of not having symbols as record keys, but I'm not convinced about the sort order of symbols being a communication channel. I wouldn't be surprised if we found that it would be okay if we made a global increment counter to sort the symbols. I'm not convinced that it will always be a problem. + +MM: I don’t feel I should do an example now, but there is a side channel, I will provide the example. + +DE: You have provided the example, but the actual communication is missing. [We can discuss with offline as well] + +MM: The example is communication. I agree this is a post-stage-2 concern. + +DRR: Concerns with cognitive overhead of deciding between objects and records. I think as we've look at this, there is a little bit of potential decision fatigue if you have to decide if you're passing objects or records. Maybe that's not as much of a user concern. But if you are using a static type checker, then you need to be able to predict whether or not you're going to pass an object, record, or potentially both. Maybe from the type system perspective, that's not something where you'll have to find a good workaround. But it is something that might end up frustrating users quite a bit. I hope that we can find something there. + +RBN: Your concern is valid, that Robin mentioned, but I am interested to know more about TypeScript. RRD said at the top of the presentation that records and tuples are intended to be parallel with objects and arrays in terms of prototypes, methods, etc. I would like more feedback from TypeScript about how this interacts with type systems. + +RRD: I see a record as a subset of what an object could do (?). We can go over this at another moment. + +DE: I think RRD and RBN are articulating an interesting hypothesis. We heard from FHS about doing research to investigate these hypotheses. I think that this is a mental model that jibes with people would be tested. I also think we need to investigate type systems. If some type system is interested. + +DRR: If we aren’t shipping at stage-3. It is fine to wait to stage-3. We can also collaborate more with the proposal. + +RRD: That's very good for us. + +DRR: We would entertain a pull request, for example, and then discuss as we have implementation. Either way would work. + +SYG: I'd like to say that we will review; V8 is neutral on the implementability of it. We need to do more research here. V8 will research and comment on the implementability before stage 3. I think getting implementer sign-off is important before going to Stage 3. + +DRR: Yes, thank you, we will work with you. + +LEO: Shu, for clarification, so you mean you're reviewing during stage-2, right? + +SYG: During Stage 2 before advangement to Stage 3. + +LEO: Thanks! + +MM: As someone who advocated for different equality semantics, I'm happy with this proposal. + +WH: I am also sensitive to equality concerns and I am very happy with this too. Please don't change it, which might reopen a Pandora's Box. + +RBU: It would be during implementation phase feedback. + +WH: Yes, I don’t know if we’ll run into implementation concerns. We will cross that bridge if we run into problems, but I’m hoping we won’t need to cross any further bridges. + +RBU: Yes, we too. +### Conclusion/Resolution +* Approved for Stage 2! +* Reviewers: BN, SYG, ?? + +## Symbols as WeakMap keys for stage 2 +Presenter: Daniel Ehrenberg (DE) + +* [proposal](https://github.com/tc39/proposal-symbols-as-weakmap-keys) +* [slides](https://docs.google.com/presentation/d/1AofgrikRJp4vTc_tqlchDk4DU9p4eqZdyxnlrFEYsvc/edit#slide=id.p) + +GCL: I like this proposal regardless of records and tuples, and want to see it more forward. But, I don't think this proposal solves the records and tuples use case. (1), when I want to store an object inside a record, that you have to set up a weak map with symbols. (2), it does not compose well when you have multiple records from different places. Basically, records and tuples, even with this proposal, doesn't seem feature-complete to me. I would hope that from my perspective that boxing gives challenges, but I would be interested to hear if that's a must-have thing or a nice-to-have thing. In terms of providing features to most of JavaScript, boxing seems to be a win. Maybe SES has to deal with another weird thing. + +DE: One to the realm and one to the object that is pointing, about sharing things across, I have an idea, it is kina vague, if someone exposes an npm and everyone who uses and doesn’t care about isolation, it should be simple, but we need to investigate in practice. + +GCL: I can say that I don't think the npm solution is good, because not all JS environments feed from npm. Second, I know there's been issues in the past about widely used modules having different versions, which creates its own set of problems. + +DE: That’s a good point. + +DE: I think a lot of these use cases will come up within a framework or library, and I think a framework or library can create its own map of symbols and objects. + +GCL: I agree that the vast majority will be in a single code unit and the shared use case is also a thing and we should design for it. + +DE: Yeah, I see that concern. + +GCL: I'm curious about… can someone who works directly on SES answer whether or not the delete is a nice to have or a necessity? + +MM: It is a necessity to keep hidden primordial state out of primordial prototypes and their methods. There is some hidden primordial state that we have found coping strategies for, like Date.now and Math.random, but these are on constructors and their methods (Date.now) or simple global namespace objects (Math). Within a realm, these can be per-compartment, but they must share realm-wide prototypes that must remain state-free. The primordial prototypes and their methods remain completely free of hidden state. + +MM: Note that TC53 is standarding on SES as the base JavaScript for embedded devices. Moddable is building a specialized SES machine, compatible with TC53, for use in embedded devices. Google, Agoric, Salesforce, Node, and MetaMask all found that there is a tremendous amount of normal JavaScript code that runs compatibly under SES. If it becomes the case that common programming patterns no longer work in SES, then it will no longer be true that enormous quantities of normal JavaScript code are compatible with SES. + +GCL: With the Mapping through Realm, if a Box was unable to unbox when called when the current realm is not the Realm the Box was created in. + +MM: Moddable is a single-realm JS implementation (for memory overhead reasons). When the prototypes are frozen, you can isolate subgraphs within a realm very easily, with little memory overhead. But only if the objects they necessarily share are state-free. + +BFS: Looking back at the composite keys proposal, there is a workflow you can use to store the data on objects rather than on the realm. Interested parties should follow up offline w/ me. + +YSV: We're now accepting symbols through Symbol.for(). I know MM was a strong proponent for not having permanent entries in the weakmap. I would like to hear what the argument that convinced him on this is, beyond wanting to avoid having long-lived keys in a WeakMap. + +MM: I don't like registered symbols being weakmap keys, initially against that. The usability of trying to distinguish what can be done w/ a symbol regarding being registered or not causes bad surprises. There is a fundamental cross-Realm memory leak problem here, with a primitive (the registered symbol) that is immune from GC while the weakmap exists. Tradeoff is eating the cost of the memory leak. + +YSV: My understanding here is that this proposal is partly to address the issue in Record & Tuple about accessing objects from immutable structures. This would make that possible, but one thing that came out of our review of R&T is whether it needs to be a primitive, or whether we can some up with another way to address this. If R&T is not a primitive, we would be able to solve this issue in another way. I'm wondering if we can think about it more, given the concerns you just raised. + +DE: Why this has to do with being a primitive: === is reliable, this isn't something we should overload with an object operation. Objects are compared by identity, everything is compared to only be equal to exactly what it is. If it is the same record and tuple contents it is the same identity. This is just like strings, JS programmers are familiar with it. In addition to equality, the distinction of deep immutability is important. Side-effects and defensive copying come up a lot in JavaScript. With deep immutability being important we need a quick way to check if something is deeply immutable, one way to tag this is the primitive/object split. Building on the concept of things like Strings being a comparable immutable value. + +So I think it's possible that there are other options, and we should keep looking at other options in Stage 2, but this is the best one that we have that brings those qualities together. + +YSV: My concern is that we will agree to this, find another solution to the problem space, and still push this forward without revisiting the change in motivation. What worries me is that many people have said that this would be useful outside of R&T. The current way that WeakMaps work is important, and I’m not convinced we should give that up lightly, since it’s different from using long-lived global objects. It’s much easier to make a mistake with a Symbol that you assume is going to be garbage collected especially given that there is no way for users to distinguish between registered and unregistered symbols. So I'm a bit uneasy for those two reasons. There's a lot of pull to look at use cases outside of R&T, which means we lose our focus and that would be problematic. + +DE: I don’t think registered symbols are important for R&T. Registered symbols are supported in Records to maintain consistent support for symbols. + +YSV: In general, I would like to spend more time with this. + +JHD: This feels useful and motivated to me whether or not it is used by R&T. We have objects and primitives and we also have things that have identity. I have use cases for this. I want to put objects and symbols in a WeakMap and not just objects. I would like this regardless of if it is useful for Records and Tuples. + +DE: It would be great to document those use cases better. We should make a list on the repo and integrate them into the explainer. I would appreciate if you could provide those examples. + +JHD: Okay; I'll try to follow up. + +WH: A tiny point of order: Link to this spec on the agenda is broken. It produces an error message. + +DE: Yes. We’ve been having problems with diffs. [Gives alternate instructions on how to get to the spec.] + +YSV: For me, what's important is *what* we intend to get to Stage 2. Because stage 2 signifies we have a problem that we want to solve, it’s important to know what problem we’re solving here. Need more investigation into problems this would solve. But I don't feel super comfortable saying that this should go forward on its own merit yet. That's why I want to clarify what the motivation is exactly. + +DE: Other delegates have said we shouldn’t let this advance past R&T. I'm in no rush for this proposal; I'm fine making it dependent on R&T. I believe the R&T proposal stands on its own merit but I am happy to keep these proposals in lock-step. + +YSV: What I meant was, I am uncomfortable with this in relation to R&T, but I wasn't going to block on this as I understand the motivation and what would be agreed to in stage 2. However the current discussion around this proposal is that the technical solution has its own use cases and stands on its own merits, but I don't understand what those use cases are yet or what the motivation is as this wasn’t in the proposal. This means that the problem space we are agreeing to in stage 2 is different. I consider it an important invariant that Symbols are never in WeakMaps, one that we shouldn’t give up lightly, without specific motivation. + +DE: I would be happy to keep this at stage 1 and learn what we can do to fix these concerns. + +RGN: Records and Tuples definitely can move independently of symbols-in-weakmaps. + +DE: Can you elaborate on why? + +BT: No, because we are out of time.= +### Conclusion/Resolution +* No Stage 2 advancement +* Work to make the motivation more clear +* Follow up more on use cases / motivation on the proposal repository + +## JSON.parse source text access for Stage 2 + +* [proposal](https://tc39.es/proposal-json-parse-with-source/) +* [slides](https://docs.google.com/presentation/d/1MGJhUvrWl4dE4otjUm8jXDrhaZLh9g7dnasnfK-VyZg/edit?usp=sharing) + +RG: presents slides +MM: I don't understand the motivation for the serialization slide, the enhanced replacer. If there is a reason to allow it to generate JSON. What is the motivation on the replacer side? + +RG: Motivation hovers around BigInt , the JSON I received I would like to generate values of the same fidelity. + +MM: I can see this applies to the leaves, I don't see why this would apply to Objects and Arrays. If it only applies to the leaves we could validate it easily. + +RG: Ok with restricting to keys, but not a fundamental concern. We need an extension here to make it work because if I return a String from the replacer it will generate a string value in the JSON. + +MM: I understand that. The motivation only applies to leaves. Trying to protect the validity of the string when we have a high speed JSON parser. + +RG: Not clear on the concern. I'm comfortable limiting it to leaves, but I need to distinguish if the output of the replacer is raw. + +MM: [rawTag] doesn't need to be a special symbol? + +RG: right now we can return an object with arbitrary properties (by the existing mechanics), but we need a way to signal that the output is raw. + +MM: Ok, now I understand the motivation of the rawTag symbol (an out-of-band mechanism to indicate the result is raw). Still going to take the result and validate it will a JSON parser, correct? + +RG: Yes + +MF: I'm unconvinced we need to be able to generate any valid JSON. If you do want to pursue this you should split the deserialization and the serialization. I am all for the deserialization improvements, but not for serialization. + +YSV: Feels risky that we’re using JSON.parse to do non-JSON-y things. + +RG: response to that, JSON has always been defined to mean something but not the particular limits of any particular language. For better/worse numbers in json are of arbitrary precision + +CM: JSON is a language independent format, even though it has roots in JS. The current JSON API is a particular mapping between JSON and the JS data types that existed when the JSON API was defined; it doesn’t give us a good way to exploit the full expressive capability inherent in the JSON data format itself. It has bugged me that BigInt is not reconcilable with the current JSON API; ever since BigInts were added to the language I've been thinking about this problem. I believe the approach being taken in this proposal is the right one: the key is not to reconsider the JSON data format definition, since that is fixed, but to look at the process of serializing and deserializing. However, I'm not necessarily happy that this is the right API to do that. In particular, the mechanism it presents for identifying the context being used for interpreting data based upon where one is in some more complex data structure feels like something potentially awkward and error prone. I would like to talk with you further on strategies for doing this, as I’ve been noodling on this problem for some time. + +RG: I would very much appreciate it. + +SYG: JSON.parse is pretty performance sensitive. There is an argument that the most sensitive cases will not take a reviver. It would be good to verify that. It would be good to get benchmark/metrics on people that are using both JSON.parse and a reviver + +RG: I am glad you brought that up. The explicit question was brought up and answered that as soon as you bring a reviver into the mix, you are already in the slow path. But any further data on that obviously wouldn’t hurt. + +RG: The part that matters the most to me is the deserialization, so that part specifically is what I'm after. I'd like to get a sense of what other people feel about keeping serialization and deserialization in 1 proposal. Community feedback seems to be to keep them coupled, but there is no inherent reason why they have to be. + +MM: Now that I understand what you were showing I'm in favor of keeping them together. I don't like the serialization API as was presented. + +RG: I specifically am not married to the API. Stage 2 is a commitment to solving this problem space somehow. This feels like a stage 2 concern. + +MM: I support stage 2 + +MF: I'm pretty uncomfortable saying we are solving a valid problem with the serialization proposal. If you want to keep them together we need to make a stronger argument for serialization. + +RG: could we do that in stage 2 + +MF: I don't think that's appropriate for a stage 2 concern. + +WH: Just like MM, I would very much prefer to keep the proposals together, since they address how we encode and decode JSON values of greater precision than IEEE double supports. You need both to be able to communicate such values. + +JRL: I'm confused what serialization solves for this proposal. For stage 3, we need much better examples of what serialization is actually trying to do. + +RG: In that example, we’re trying to preserve the precision of a BigInt being serialized. Without this facility, you would either see a 1 followed by a bunch of zeros, or a string with quotes inside it. + +MF: This could be represented in other ways than a number in JSON. You can use a 2-layer approach where you describe the type of everything you're encoding using a wrapper. + +RG: It sounds like you are assuming control over how the output of JSON.stringify is consumed. This is not always the case: scientific, 3rd party APIs, etc. The serializer often does not have control over the JSON schema. + +MF: I understand. + +JRL: not blocking stage 2 but need better examples before stage 3 + +### Conclusion/Resolution + +Stage 2! + +Reviewers for stage 3: MF, WH + +## Arbitrary Module Namespace Identifiers + +Presenter: Bradley Farias (BFS) + +* [proposal](https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers) +* No slides, just showing spec text changes + +MM: Curious about why you sometimes mention Unicode and sometimes mention UTF-8. + +BFS: The spec text doesn't mention UTF-8. I mentioned it to ensure that it's compatible with WASM, which exports UTF-8 names. + +RGN: The concept within Unicode that we’re looking for is “well-formed Unicode.” That covers all forms of Unicode (UTF-16, UTF-8, etc.). Also, I agree this proposal can manifest as a PR. + +### Conclusion/Resolution +* This can be presented as a "Needs consensus" PR +* Will need to be approved in a future committee meeting + + +## Host hooks for Job callbacks (consensus-seeking continuation from day 1) + +* [PR](https://github.com/tc39/ecma262/pull/2086) +* [slides](https://docs.google.com/presentation/d/19S97ZqhibJABqzeP5ZU6Flk6TVgWzXuvJWFbNTTfpWs/edit?usp=sharing) + +SYG: Addressed concerns with concerned parties. The two new host hooks that I am proposing will be browser only. The prose now says that hosts that are not browser must follow the default behavior. I also added a note that any host cannot override behavior that ECMA262 specifies. The concern here was from mark that this would allow dynamic scoping. With that, I would like to ask consensus again for adding these two host hooks for adding callbacks that are passed by apis asynchronously. That is promises and finalization registry. Any objections? +### Conclusion/Resolution +* Host hooks for job callbacks has Consensus + + +## Function toString for builtins (consensus-seeking continuation from day 1) + +Presenter: Gus Caplan (GCL) + +* [PR](https://github.com/tc39/ecma262/pull/1948) + +GCL: What was discussed last time was to explicitly allow the `get` and `set` in the syntax. That has been changed. This solves the issue that was raised. I am once again asking for consensus on this change. + +WH: What would the output be? + +GCL: the keyword `function` followed by the keyword `get` or `set`, followed by the usual output. + +RGN: Having it specified like this results in the observable difference between user code and native code? + +GCL: That is also my opinion but that wasn’t the goal here. The goal here is to align with implementations. + +RGN: Does this do that? + +GCL: yes + +WH: I'm fine with this as an initial step. I'd like to see the syntax unified between user code and native code, but I understand that this would require research into web compatibility. Longer term I would prefer to get rid of the "function" keyword if we can and change `function get name …` to `get name …`. + +JHD: I agree with WH. We should land this now, but it is important to do the follow up. + +GCL: Does anybody object? + +Robert: No objections, you actually have consensus this time. + + +GCL: Whoo! + +[no objections] + +### Conclusion/Resolution +* Consensus to merge the PR diff --git a/meetings/2020-07/july-23.md b/meetings/2020-07/july-23.md new file mode 100644 index 00000000..5b1f62a3 --- /dev/null +++ b/meetings/2020-07/july-23.md @@ -0,0 +1,651 @@ +# July 23, 2020 Meeting Notes +----- +Delegates: re-use your existing abbreviations! If you’re a new delegate and don’t already have an abbreviation, choose any three-letter combination that is not already in use, and send a PR to add it upstream. + + +**In-person attendees:** + +**Remote attendees:** +| Name | Abbreviation | Organization | +| -------------------- | -------------- | ------------------ | +| Yulia Startsev | YSV | Mozilla | +| Waldemar Horwat | WH | Google | +| Jordan Harband | JHD | invited expert | +| Marja Hölttä | MHA | Google | +| Chengzhong Wu | CZW | Alibaba | +| Mark Cohen | MPC | PayPal | +| Chip Morningstar | CM | Agoric | +| Mark S. Miller | MM | Agoric | +| Richard Gibson | RGN | OpenJS Foundation | +| Dave Poole | DMP | Apple | +| Michael Saboff | MLS | Apple | +| Bradford C. Smith | BSH | Google | +| Justin Ridgewell | JRL | Google | +| Istvan Sebestyen | IS | Ecma | +| Pieter Ouwerkerk | POK | Stripe/RunKit | +| Ujjwal Sharma | USA | Igalia | +| Sergey Rubanov | SRV | Invited Expert | +| Mary Marchini | MAR | Netflix | +| SongYang Pu | SYP | Alibaba | +| Devin Rousso | DRO | Apple | +| John Hax | JHX | | +| Shane F. Carr | SFC | Google | +| Rob Palmer | RPR | Bloomberg | + +## Examining Structural Racism in TC39 +Presenter: Mark Cohen (MPC) + +- [issue](https://github.com/tc39/Reflector/issues/305) +- [slides](https://docs.google.com/presentation/d/1i9-VCNi4KZNisntn9TTCFaZhrPwMQr4XuYEqHBg7pAE) + +MPC: (presents slides) + +LEO: Regarding outreach, I’d like to express how this is very positive, because I’ve seen, as an ESL speaker myself, it was basically led by DE and Carridy, we could give feedback on something we were working on, and also get feedback from other ESL speakers, from those who wouldn’t be able to participate in TC39 since it’s conducted in English. I have been also working on outreach work for communities in Brazil or people who speak Portugese, and for me it's just a generalization of the Brazilian community, yesterday we had a discussion about working on a new feature for the language, and we had feedback from a person about how to contribute and read the spec. I have a lot of feedback, and I can delay discussing this to later. This would improve representation at TC39. + +AKI: To everyone: if you have questions about this type of things, don’t ask your friends of color, don’t put that burden on them, please come talk to me, or find other white folks doing anti-racist work. It's ok to be vulnerable when asking these questions. There is the #tc39-inclusion channel on freenode that you can join. + +MPC: Thanks everyone, and please come to #tc39-inclusion to continue the discussion + +## *continuation* Ergonomic brand checks for private fields for stage 3 +Jordan Harband (JHD) + +- JHX’s position: https://gist.github.com/hax/5e94c7959703ea95d4ff9c9deac12988 +- (no slides) + +JHD: JHX and I talked about this offline to discuss their objections. + +JHX: My point is about the syntax. I don’t like the syntax, ??? +At least, there is a line between two worlds. One is . which is used more statically, and now if we also want to overload "in"... It doesn't match the other two syntaxes. If we had reflection then we can overload all three, since then I think it would be ok. +I think that there is a connection between the reification proposal and this one. At least the syntax should be the same, and if there is no reification I cannot accept the overloaded "in", because it would just add new confusion by not following the pattern of the original "in", `[]` and `.`. If we eventually have the reification, I’m ok with the current syntax. I discussed this in our company and this is what we think about it. + +DE: You talk about consistency, but I don't understand the inconsistency. The proposal of JHD seems in line with the decisions about private fields. For the thing about reification, I see how these proposal are related but I think this proposal makes sense on its own. Can you explain why the reification is a requirement? + +JHX: I think we can check our documents about that. If we use the object access syntax, `#x in obj` should map to `obj[#x]` not `obj.#x`. We shouldn’t add new ad hoc rules; this is not a good thing. + +JHD: There’s two worlds we’re talking about, one where the reification proposal doesn’t advance and one where it does. If it does advance, #x would be a private symbol (based on the current shape of that proposal), `obj[#x]` and `obj.#x` would work identically, and `#x in obj` would work as JHX expects. In that world, when reification happens, everything is that consistent. + +JHD: If it _doesn’t_ happen, what pieces of that world are missing, and what happens when a user runs into them? If they type `#x` by itself (not in front of `in`) or in square brackets, they’ll get a syntax error. Which seems consistent with other places in the language that have “missing pieces” that are errors. + +JHD: If we don't do reification, than obj[#x] would just be a syntax error everywhere, and tools would just crash. It's not possible to get it wrong. +As for many things in the language, if a developer might expect something to work but then it just crashes early, it's something we have generally considered acceptable. + +JHD: It might be different if we knew reification was never possible, in that world we’d have to address this problem now, but since work is being done on reification, it may not be a problem that needs to be solved. + +JHD: The committee already made a choice about private static ???. You could make a table, see that there is a missing piece, try to use that and it just crashes. And that's something we have been considering acceptable. + +JHX: When we overload the `.` the private fields use a very different matching/semantics (?) of the property. +We current don't have a simple line that if you only use the obj.#x and do not care about reification about #x it's ok. Now we overload the second one, the "in" syntax, which is much dynamic and it calls to reification. This does not only give you a syntax error, it makes the mental model more complex. This is the concern, and I think that we can not accept that. +If we reification there would still be a different line between the syntaxes, but this proposal is in the middle of them. + +SYG: My understanding of the linked document is that it uses a farly pedantic understanding of the semantics of the "in" operator, where the LHS is any dynamic value. +In my experience, this is not the mental model of developers. You are not checking if that value exists in the object, you are checking if it exists as a _key_. This proposal is not at all inconsistent, it makes it _more_ consistent because… obj.#x looks like a property access, and I feel like allowing it on the lhs of "in" would make it more consistent. + +MM: I support this proposal, but I think that the discussion of the interaction with possible reified private names was too simplistic. If you'll be able to reify them, they wouldn't be private symbols because of security reasons. +It would be more something like a PrivateName object, which is a weakmap-like object. This proposal would preclude the #x syntax from being how you reify a PrivateName. +There’s a nice symmetry to this proposal: obj.foo asks obj about foo; obj.#foo asks #foo about the obj; "foo" in obj asks obj about foo, and #foo in obj asks #foo about obj. There is a left-right inversion in both cases. + +The only cost of this proposal is that it prevents #foo as being the syntax for reification. + +BFS: In particular, if on the LHS you just have the token "id", then the token "in" and then the token "obj", I would want computed accesso for that case. However, if you have a string literal on the lhs, you can then use dot access. + +You can use it, but if you're using . access in particular--currently our private state only uses . access. You have to use .#id. There's an argument that we can state about computed access, but that's only if we have a proposal that can state that we can put in computed access. + +I really think that this is a constraint on future proposals and not on the current one. I would like to understand the research that the current proposal has done to ensure that these positions are still valid for future proposals. + +The objection isn't for the current proposal, but rather it creates requirements for future proposals. Although there's a valid objection, it is not actually on this proposal. It would be a burden on the ability to reify private names. + +There is no clear reason why it clear rea + +DE: maybe at this point summarize consistency argument: + +Private fields and methods follow this consistent logic that the semantics are in parallel to ordinary properties and methods. In the syntax, they have a subset of the semantics. Cases with private fields or methods except for a few edge cases that includes weakmaps and ??? + +In general, the semantics are parallel to ordinary properties. This furthers that analogy, by continuing to be analogous to normali properties and it would make sense. +I don’t see a lack of consistency, I don’t think there is a blocking issue raised, I haven’t heard one. + +JHD: I ask again for stage 3, I guess the only one blocking was JHX, what do you want to do for this proposal + +JHX: I still think that it's a blocker issue. I maybe need to think about it more, and we'll see if I can change my idea. + +DE: I think the way we work in tc39, we ask if somebody has a reason to block a proposal, we need to have reasons to block a proposal. JHX's concerns are based on misunderstandings, and I don't think our process has blocks without reasons that aren't justifiable. +I'm wondering how that affects it. + +JHX: I think I have given the reason. I still think there are consistency problems, and what I’m asking for is if we have the reification, I’m OK with that, but if we don’t have reification, I don’t think we should overload `in` because it increases inconsistency. + +DE: We discussed this at length in the core private fields proposal. + +Many people with peop ??? + +JHX: It's not about that. If we already overload the dot, then at least there is a line: you only use the dot form. + +This is a step from dot form and dynamic form with brackets +??? + +If we only overload one and not the other, then it doesn't match the existing syntax of . and []. It increases the mismatch. + +DE: we have 3 different syntactic constructs than with the # +You can have # after . or in a field/method declaration. Putting it in "in", it just increases the consistency. It’s not specific to just after the doc because this is used in definitions + +JHX: I’m not sure how it could increase that. I’m focusing on `in`, `.` and `[]`, it’s not about the dot, it’s about the bracket. + +DE: the consistency argument of dot corresponding to brackets was raised in the private field proposal. The committee's current consensus for the stage 3 proposal is that we made the tradeoff that it's only permitted using dot access, not through square brackets. So that private name work in this way and they have a subset syntax and correspond well to JHD’s proposal. + +JHD: In other words, all the things that are more advanced than this proposal have not considered what you have talked about as a mismatch. Myself and other folks consider this to increase consistency than decrease consistency, if there is a mismatch created by an earlier proposal it should be addressed by that proposal but in a world where that proposal exists this proposal makes sense. + +Assuming that reification doesn't advance or advance in a way that doesn't make sense with this syntax for you, I think that it would be a loss for the language. + +SYG: I have heard many counter arguments to the consistency concern that JHX has raised from me, DE and other folks. +I’m not really hearing why those counter arguments are not enough to cover why this is not enough and I will be disappointed to see this blocked because of that consistency argumrnt + +I see sufficient care to address the point and to explain why it is infact consistent. We can disagree on that, but I’d like to see a counter to the counter arguments on why this is inconsistent. + +MBS: Can we ask JHD to finalize this discussion? + +JHD: I'd like to ask to extend the timebox of 5 minutes. This is a concern that could impact other proposals. + +MBS: Unfortunately, we don’t have time to extend this, just one minute. + +JHD: When somebody withholds consensus for a proposal, +especially when we are at stage 2, the reason for whitolding advancement usually needs to be something clear and actionable for the champion. I’d need to have something actually to do to solve your concerns. +I’m gonna ask again for stage 3, and if someone goes against I’d ask for actionable feedback. + +JHD: Any objections? + +[silence] + +JHD: I’ll be happy to work with you JHX during stage 3. + +### Conclusion/Resolution +- ~~Advance to stage 3?~~ Nope, challenged in IRC + +## Async Context updates & for Stage 1 +Chengzhong Wu (CZW) + +- [proposal](https://github.com/legendecas/proposal-async-context) +- [slides](https://docs.google.com/presentation/d/1Ef2JI4ntkWd-M8fDqOGZGGh7CiPD05L39CZRSv1II_0/edit?usp=sharing) + + + + + +CM: Can you describe what it is that this does, and how it does it? “The problem with being confused is that, first of all, you’re confused,” and I’m confused. + +DE: I wanna suggest that people take a look at the readme and they described APIs and what APIs does + +CZW: last time there was a major security issue with async hooks and the ability to run callbacks. Now, there are these objects which are async locals. + +CM: Rather than explaining this in terms of how it differs from the previous proposal, let’s talk about it in its own right. First with an example of how it gets used? + +CM: wanted a walkthrough of the examples + +DE: sounds like a good plan to me to do that before going to queue items + +[Presents slide 13] +https://docs.google.com/presentation/d/1Ef2JI4ntkWd-M8fDqOGZGGh7CiPD05L39CZRSv1II_0/edit#slide=id.g86607955ef_0_435 + +CZW: This is an example of a tracking server, with AsyncLocal stuff. Getting the request object for each incoming HTTP request. So, we do a lot of Async operations and here we can get the context from the async local. And there are no additional params to the function, so the request is lost. + +[Presents slide 14] +https://docs.google.com/presentation/d/1Ef2JI4ntkWd-M8fDqOGZGGh7CiPD05L39CZRSv1II_0/edit#slide=id.g4446cf2007b006c1_0 + +We can get the exact initiating request from the database. So this can address the issue. + + + +CM: In this case, when we call `getContext`, where does `getContext` get the context from? What asyncLocal object is being used? Is it a global variable? Where is the scoping control? + +CZW: Each instance of asyncLocal has to declare their own instance, and the instances will not conflict with each other. + + +CM: So the context is being held in a variable inside the context.js module? I’m just trying to understand the scoping behavior. I’m not sure thrashing through this is the most productive use of the committee’s time. + +CZW: So we in Node.js handle the request concurrently. One request may be active for a short time, and yield for the I/O operation. In the access of the request object, in the context for the global, they may conflict with each other because they are concurrently accessed. Async logic flows let each request store things. + +CM: If I understand, previously we were keeping it in a global, and now we’re keeping it in a module scope var in context.js but there is nothing in the queryDatabase call. If someone else invokes import `queryDatabase`, whose execution is interleaved with this, there’s a hidden dep between db.js and context.js module and that ambient state is being passed between both implicitly. + +CZW: The db.js has to explicitly depend on context.js to get the state passed through. + +CM: gonna have to think about this one some more; I think there are some not very good engineering practices in this example, and it’s hard to separate those from the proposal itself. I’m not sure thrashing trying to understand the proposal in real time in front of everybody is worth their time. + +WH: A lot of us are in the same boat. + +GCL: If this helps for those of you who are confused about what async local storage is. In Node, we have Async hooks, which track when promises are created, resolved, or rejected. When the promise goes through fulfillment or rejection, and through the fulfillment queue. One level up abstraction of this is AsyncLocalStorage, where you store the state of these promises. Having an async local instance means that you must explicitly participate in holding this data and if you do async code, async stuff that access your data, ??? One of the big reasons this is useful is application performance management (APM) and tracking how resources are used and how long they are being used. Basically one of the big reasons for async hooks and async local storage is to track the reading of async files, HTTP requests, and then, recording that data. But one of the problems here is that, doing this without support from the engine, (or even with the support of the engine in the case of Node), when the abstraction has to be such that it is not part of the language itself, but some kind of sidechannel thing, results in a large amount of overhead and I think there was an issue in node.js that reported 99perc overhead when using async local storage. By adding this to the language itself, we can integrate these behaviors directly into the language itself and get rid of the overhead. + +CM: That has a little bit of a "doctor it hurts when I do this" vibe. What you're saying is, it’s very expensive to do this thing you shouldn’t do. In the example in front of us here the database module is completely non reentrant in a dangerous way so I’m very concerned + +DE: For the reasons Gus explained, I think this is an important problem space, I think this is a really important problem space and there were examples where people were saying “I don’t really understand where scopes are made…” The fact that you have these distinct AsyncLocal object seems like a good basis for figuring out these details. I’ve worked in other programming languages that have dynamically-scoped ??? and they seemed useful. We have a presentation of incumbent realms and better tracking about baseUrl and imports. I think the underlying primitive is really something like this. I know there are problems for us to work out, I know there are a lot of problems to solve and figure out before stage 2 but it seems to be a very important problem for us as a committee to solve. + +SYG: I want to push back a little about what DE said about incumbents—I think there’s a big difference between fully defined semantics and exposing programmatic control with something similar to dynamic scoping, even when the concepts are similar. +I really could not understand the audio but one of the main thing is the removal of the async hook but the dynamic scoping thing remains and it is still not addressed, which was the main committee concern last time. And that’s it + +CZW: AsyncLocal needs to be explicitly referenced to get a value or to change it. The dynamic scoping issue DE mentioned, ??? Dynamic scoping for the issue correctly ??? + +SYG: I did not understand, sorry + +CZW: Explicitly reference to get the value and there is a better asynclocal ??? Has to be triggered by referencing a single instance. So ??? AsyncLocal provide any dynamic scoping (it was very difficult to understand with the audio feedback) That’s my point for the concern + +MM: I will keep it short, because of sound issues my understanding is incomplete, but this still seems like dynamic scoping. The behavior of a callee depends on elements of a calling context that are not explicitly passed as calling arguments. And any such implicit context breaks many algebraic properties of the language. The question is, can a closure capture the dynamic context that is relevant at a given moment in time? Both the answer “yes” and “no” lead to unpleasant consequences. There is no good answer to the closure question when you have dynamic scoping. We have a large complex language that already has a complex computational model for people to form intuitions, and adding dynamic scoping to it pushed it too far. I am against seeing anything like this advance. + +CZW: Async local storage can be treated as a value store, where the value has to explicitly reference the variable. It can also get and set the global. It is also possible to not set it in the global, I’m unsure what issue can be with asynclocal and async scoping. Since the async local has to be explicitly referenced in the code, So, I’m not sure if this can solve the concern. The async local itself has to be explicitly referenced, to set the value or get the value. It can be treated as an exclusion global. + +MM: If I understand correctly, I do agree that that’s an improvement. The old proposal was more like Common Lisp dynamic variables. The new version is more like Scheme fluid variables. Both are examples of dynamic scoping but scheme’s was the cleaner approach. I appreciate that. But both still suffer from the fundamental problems of dynamic scoping, for example, the closure question. + +GCL: When you say you have a problem with the intermediate closure, are you saying that even if it were available, it would not be used correctly? + +MM: The second. Both answers are wrong, but in opposite ways. If you say the closure can’t capture the dynamic context, you have one set of problems, if it can, you have the opposite set of problems. The real problem is the introduction of dynamic context at all into a lexically scoped language. + +GCL: Got it, thank you. + +DRO: This is not an objection. It is a question. I am not sure how any of this is not already doable with existing language features. It seems like AsyncLocal is just a wrapper around a static global, that you can get and set with function wrappers in those specific circumstances. Is there anything special about AsyncLocal that isn’t just a wrapper around a value? I'm fine with introducing a language construct that it's already doable with other language constructs, and I just want to understand what makes this special. + +CZW: The difference between asynclocal and a global is ??? the global may be overwritten by another js execution and they are interleaved in the async operations. They can be kept safely in the async local. It’s not accessible from another execution or another request—they are different for each run of the request. This is different from the global, which is global to every execution. + +DRO: Is it accurate to say that the same asyncLocal variable effectively has multiple values depending on what async flow you are in? + +CZW: Yes. + +DRO: I think that is a potential point of massive confusion for developers.It breaks the expectation that one variable has one value. Now you can have an AsyncLocal, and in your debugger, you switch to one promise exec to another and something that should be global is now something completely different. + +CZW: before the feature we had to implement the same function in the host nod.js and it is hard to have devtools understand that concept. It will be harder to implement without the concept existing in the language itself. This would expand the use-case by adding the ability to the language. + +DRO: Right, but getting it into the language still requires that developers understand why it's there. There’s still that first part of explaining to developers this is one reference to multiple values. + +CZW: this is not a new concept, there are many prior art on this , an??? Language like java, I’m believing it would be possible since there are many prior art examples for this + +BFS: I have two responses. One, This can't really be done in existing language constructs, this requires some specific hooks. We had a normative PR for browsers needing for their realm. It’s not something realistic or something anyone would want to use.Two - per the multiple values thing. I am not entirely sure I agree with the statement that a variable must hold a single value. Variables change over time, they can change because of their closure, you see this happen all the time. That doesn’t seem out of line with existing things we’ve designed. + +WH: I also had a hard time following the presentation due to audio quality issues. From what I think I understand, I have the same concerns about dynamic scoping that MM and SYG had. I can’t tell for sure, but this looks like Dynamic Scoping, and I would not like to see that in the language. + +MBS: CM are you ok deferring your question? + +CM: My topic entry in the queue, “thread local may be a good point of comparison”, captures what I had to say. Thread local is indeed a feature that many languages have, but it’s still a very bad idea. This proposal seems to have the analogous features with the analogous hazards. + +MBS: Any final decision or consensus? + +AKI: It seems like it. + +MLS: I agree. + +YSV: We have hitten an invariant here that was not written down. A later presentation will cover this. + +### Conclusion/Resolution +- Not going to stage 1 + +## *continuation* Ergonomic brand checks for private fields for stage 3 + +JHX: I wasn’t able to respond earlier; I would like to object to this proposal in its current form, because it seems that obj[#x] will never happen. We can try to find alternatives in the future. + +JHD: to summarize: JHX believes that there should be an invariant that `x in o` implies `o[x]`, and this proposal does not support that in its current form. I will be discussing this with JHX over the next two months, and will bring it back for discussion in September with a longer timebox. + +### Conclusion/Resolution +- Does not yet advance; remains at stage 2 +- No consensus yet on this invariant in either direction + +## Flex Incubator Calls to weekly meetings +Leo Balter (LEO) + +LEO: I’m proposing weekly incubator calls. SYG has been organizing these meetings, and I’d like to have more. +Agreement? objections? + +YSV: I kind of am overburdened by meetings. Having them biweekly works for me, once a week would be hard. + +SYG: Part of the intention of incubator calls is that because they are so focused on a particular topic, delegates shouldn't be responsible for attending every single one. + +I understand that as implementers our nets are wider and feel more responsibility to attend all of them. + +YSV: I feel like I have a responsibility to attend all of them, actually. + +SYG: I understand that for myself too, as the V8 representative, as I should have some familiarity in what's going on since we'll eventually be going to implement that. +I want to understand how the other people in the room feel, because I would preferably not want you to feel that way. +I feel like delegates have different areas of interest + +LEO: I think that incubator calls are good when we have very specific meetings for specific things. +Not just like having freq ad-hoc conversations, today let’s say today we have temporal and decorators topics, but I had a specific question about realms and we used the call to discuss that and define next steps. +While for some bigger topics we can have this, for other smaller topics or specific points incubator calls are very helpful, because it provides a space for these things. + +I do not know want to make implementers feel to be overburdened byt hose calls and it could alleviate burden in tc39 meetings before going to the meetings + +SYG: I want to apologize for how badly I’ve been scheduling the calls. + +Specially for the last one where I misread my own doodle, it is not a skillset that I have to smoothly schedule things. + +Having a weekly cadence sounds good to me, but I would like someone else to sign up as an additional facilitator to help with scheduling and running the calls. + + +LEO: I’m in this spot although I feel like I’m pretty bad to do this, I hope someone else could help here. I don't think that I would do a very good job, but I can try if there is noone else + +MF: I think LEO might have misunderstood the written topic. What I’m suggesting is that we schedule those meetings in pre-dedicated timeslots, but not necessarily every week. + +LEO: A fixed schedule still brings a problem regarding availability. If we have some cadence, we can expect people to be available. +YSV is basically saying that people try to make themselves available for these meetings. + +SYG: I think you are still misunderstanding. I think that what MF is saying is if the list of what to discuss in incubator calls exceeded the time we have, then ??? + +MF: In practice it may be the same—if we have a weekly cadence, but no topics for that week, we’ll cancel it. I think we should take a more pessimistic approach where we assume no content and then fill it in as needed. + +SYG: ??? that seems the most sensible point for us to fill in the schedule. + +MBS: I have seen in many cases that if you keep up a regular cadence and then drop things if they are not needed, it ends up working better. If you have like one hour per week dedicated to this,... YSV, in your case if you know that there is this possibility at a fixed time every week and then it can be cancelled, ??? +If we’re not proactively chartering off that time, it’s more likely not going to happen at all. + +YSV: I guess I should also respond to that. I would be more open to this if there is demonstrated pressure to have more meetings rather than doing it preemptively. I would prefer not to have it aggressively scheduled and then cancelled, but I'm open if it _has_ to be done on a weekly basis because we need it. + +I’m also concerned that if we’re doing too much work between meetings that the meetings themselves will be overburdened. + +LEO: I would just stay with the bi-weekly meetings. Incubator calls are really important for me and I would like to have more of them. Also, I'm not retracting what I said to SYG about helping facilitating. + +SYG: would be much appreciated + +YSV: side channel on IRC, I want these to be successful and I am not going to help as an implementer as much as I could if it is a weekly meeting. I'm not blocking this from being a weekly meeting. + +LEO: I don't feel like we should feel pressured. The concerns are valid, and my goal here is to recognize that these meetings are great. +Let’s continue the biweekly and if we can in the future see that there is an overflow we can bring this back and discuss this again. I still want them to be weekly but I don’t want to put pressure. + +DE: It's a lot of work to run these meetings: I run other meetings… Also, it’s very good to have volunteers to have co-facilitators, but I have been failing a bit on this one. +I wanted to help with this but I dind't have enough time. I want to disagree with the assertion that more work between meetings would increase the load of work we have during meetings; we have seen that it's the opposite. +Also, Implementers shouldn't feel pressured to come to every call outside the meetings. They already don't participate in many of those calls and we don't want to make anyone feel pressured to do so. + +AKI: keeping with fortnightly meetings unless it becomes more important to switch to weekly + +YSV: It sounds that I'm the only voice here saying that weekly is a problem. If people want to do it weekly, please go ahead. + +LEO: you’re important for us so I don’t want to go forward if you don’t want to. + +I'm not comfortable proposing a change if you are discomfortable with it. It's important for me that people are onboard, and I would prefer to wait. + +AKI: We can discuss this in an issue further. +### Conclusion/Resolution +- Incubator calls remain bi-weekly + +## Incubation call chartering +Presenter: Shu-yu Guo (SYG) + +SYG: At the end of each plenary I call out a few proposals that could benefit from a higher frequency feedback loop. To either hear feedback or iterate feedback and bring it back to committee. First, overflow: the security model that we want JS to have. This is a conversation for plenary but it would be good to hash out preliminaries in a call first. That is overflow due to scheduling mishaps. Before I get into nominating specific proposals, with a fortnightly cadence, we usually have 5-6 slots depending if the plenaries are farther apart. So I think a comfortable number of proposals is probably 6. So with that, `Number.range` is probably the first one I’d like to have an incubator call for. There was a lot of back and forth between the iterator and iterable design. There were a lot of voices on either side, so that’d be a good thing to hash out. If the stakeholders for that are still on the call, champions, it would be good to get confirmation to participate with `Number.range`. I think await operations could also use some feedback given that there were some concerns about the DX improvement of these await ops, and if we should have them, if we should have something that’s just for Promise.all, or if we should not have them at all because maybe the DX thing is not as clear cut as we thought. So the second is await operations. The third one is Array.prototype.unique. Everyone seemed to agree from my reading of the room that having a unique operation on arrays would be useful, but disagreed on the particular semantic and especially the proposal as currently written. So that’d be a good item to get feedback on. Right now we have 4 items, to recap, security, Number.range, await operations, and Array.prototype.unique. Are there other proposals that people would like to discuss? I know LEO said earlier in the meeting that there are a bunch of proposals that he wanted to see discussed in the calls, do you have anything to say? + +LEO: I cannot list them together here. I did not take note of them, but I also - if I remember correctly. It actually depends a lot on the actual champions for each proposal, if they feel comfortable as well being at the incubator calls. + +RBU: For the record and tuple proposal, we already attended one for the deep path properties subsection. We have some initial conclusions from that, but I don't know if it’s worth attending a second round, I don’t know if it’d be useful if the same people attend. + +SYG: If there's no additional point of request for feedback from the champions we don't need to revisit in so short a time, especially since they haven't come back to committee. + +I think if there is a particular topic - because Records & Tuples are so big - if there’s a particular topic that the champions want to request feedback on, that’d be good, but otherwise I think records and tuples as a whole is probably not a good use for the calls. + +RBU: I will take a look at our list of things that might need to be discussed and I will report to you. + +SYG: Sounds good. I think the final one I'm on the fence about: does anyone feel like they would benefit from discussing slice notation? Are there topics of contention that we could hopefully get ahead of if we work them out in the incubator call? Here, unlike consensus, silence would mean “no”. So if no one feels strongly then we don’t need to charter that proposal. + +LEO: It's hard for me to tell anything because I don't know if the champion of slice notation is here. If we want to tell anything else of the things that are overflowing from this meeting, I wonder if DE would like to bring some discussion for the pipeline operator- + +DE: I don't know - I would be open to a discussion of the pipeline operator. I don't know how to work through the current thing. If people are interested in discussing that, the incubator call would be a good place. + +SYG: The bar would be a concrete request for feedback. It sounds like we're still kind of unclear on what the concrete points of feedback are. Then I propose that we stick with the current 4, which is a lighter load than usual, which should be fine. To recap, those four are security, Number.range, await operations, and Array.prototype.unique. I will make an issue and then ping all the known stakeholders, and then if you’re interested please just add yourself to the issue. The process here is that by default, the times are 9-10 PT, which is a bit late for APAC, but for EMEA and the Americas that’s kind of the sweet in between time that’s reasonable for both European folks and American folks. + +DE: Was there an idea to discuss the async local storage proposal? + +SYG: No one proposed that, but if you are we do have two slots. + +DE: Can we follow up offline? Is it ok to add these things between meetings, or do we have to decide now? + +SYG: I’m totally fine if other folks are to have it be fully fleshed out - especially since we have free slots - so if we add async context, it’ll be scheduled after all the other ones chartered today, and pending if it would be agreed on. + +DE: We'll follow up by email. + +SYG: There's another one from MF on the JSON.parse proposal. I imagine the focus is the serialization part, not the deserialization. + +MF: It could benefit from further specification of the exact mechanics of the deserialization part, too. + +WH: I understand three of the proposals but not the fourth. You said there’s a proposal for discussing “security” without providing any details. What specifically about security would we be discussing? + +SYG: It's not a specific proposal but a topic of discussion that came up in IRC/plenary. What should the security model of the JavaScript language - as we consider proposals and deliberate them, what should the security model of the language be? It's not a concrete proposal but I wanted to get some preliminary discussion started among stakeholders before we bring it to plenary. + +WH: Okay thank you. + +SYG: So we have two additions, one is kind of contingent on signing up of the stakeholders from async context, and the second one is JSON.parse. Are all the stakeholders of JSON.parse on board? If so it doesn’t have to be contingent, we can just have it. Is RGN here? + +RGN: Yes, absolutely, sounds good. + +SYG: So we have five confirmed ones and one we'll follow up on. Look out for the Github issue. + +MM: I want to expand on the question that was answered between WH and SYG. A lot of what the security thing has been about and what I expect the incubator call to be about is an issue of terminology, as well as, of course, what we should do. Historically there has been a persistent misunderstanding on different groups using the word "security" to mean different things. The SES group, for example, has been shifted to the term "integrity" to avoid these misunderstandings. Part of the incubator call on this topic should be in fact to clarify “security” vs “integrity”, so at least within the context of these discussions, we know we’re meaning the same thing by the same words. This is a tricky issue. + +SYG: Thank you. Ok, I think that's it. Be active on the Github issues if you're interested in any one of those six topics. Also there's a TC39 calendar, if you're not signed up, please do. + +## ResizableArrayBuffer and GrowableSharedArrayBuffer for Stage 1 +Presenter: Shu-yu Guo (SYG) + +- [proposal](https://github.com/syg/proposal-resizablearraybuffer) +- [slides](https://docs.google.com/presentation/d/17QwbVQEYClzfCDGgWyZg0V_zTC1DWsNwPWvJPuXIqRg) + +SYG: (presents slides) + +WH: I had difficulty following because of some points of confusion so I may need to recalculate what I think based on the answers to a few clarifying questions I have queued up. + +WH: You mentioned that WASM can grow buffers. Can it shrink them? + +SYG: WASM cannot shrink them, no. + +WH: You mentioned that auto length tracks the length automatically and detaches the buffer whenever a portion of the TypedArray would become out of bounds. Those are mutually exclusive - you can do one or the other, but you can’t do both, so I don’t understand how you’re doing this. + +SYG: I think the miscommunication, the TypedArray does not detach the buffer, it acts as if the buffer were detached if due to a resize event any of its portion goes out of bounds. + +WH: Yes, but then I don’t see how it can track the length, because whenever you shrink, some portion of a resized buffer will always go out-of-bounds so the TypedArray will get detached. + +SYG: Ah, I see what your point is, yes. For auto length TypedArray views, if it is a non-zero offset, shrinks that shrink earlier than the non-zero offset detach it, any other shrinks don’t detach but just change the length. For fixed-length TypedArray views, I hope that there is no confusion. + +WH: Yes. OK, thank you. + +[folks just deleted several intervening items from the queue, so back to WH] + +WH: I’m looking at it from a usability point of view, the devil is in the details. You said it’s not observable whether this is done by memory reallocations or just by remapping address space. That’s a nice theoretical view if you never care about performance, but for things like this it matters whether operations are constant time or linear time in the size of a buffer. So I see scripters discovering some things like, well, is this usable if you resize frequently or not? An implementation which takes linear time to resize will preclude a script from actually using the resize facility very often. + +WH: A separate issue is what’s reasonable to ask for as the maximum length. If I ask for four gigabytes as the size limit, is that feasible or not? You’ll get Hyrum’s Law effects here. + +SYG: Those are good concerns. To the first one, am I giving complexity guarantees. I haven’t given it much thought. Probably not. But I do expect the engines to align on the implementation strategy of in-place growth, for the same reason. So like you said, someone who is doing linear resizes will be at a competitive disadvantage. The as-ifness that I highlighted is to give a pass to things like WebGPU. If WebGPU vends you a resizable arraybuffer that is not created by the user, it is free to use this interface to explain certain things that the interface already allows to express. But like it will basically give you a differently-backed buffer, which happens to be, observably, outside of timing, resizable array buffers. I don’t expect there to be significantly different implementation strategies for user-created resizable buffers. + +WH: What will the guidance be for specifying the maximum length? What will we tell users they can put in there in practice? + +SYG: That’s also a good question, I don’t have a good answer for you now, I’d like to work with partners and engine folks in stage 2 to come up with a sensible thing to prescribe there. + +WH: Thank you. + +JHD: You said, I have a big arraybuffer and a TA looking at the end, and I shrink the buffer, and the TA is out of bounds. + +SYG: It’s like a latch. It’s one-way. It's not going to become valid later. + +JHD: The question is if I later grow the TA is it going to come back? + +SYG: No + +JHD: Ok, thank you. Next, definitely a stage 2 concern, not worth bikeshedding, but is there a reason that it has to be a global or could it be like Proxy.revocable? + +SYG: I don't have an opinion here, I'm fine with whatever we reach consensus on. + +LEO: I just think there - when we are talking about this, those seem like niche specific problems. I don’t have any specific objections, but out of the flexibility as we write ECMAScript, that’s not only implemented in web browsers, etc, I wonder if this can be something we consider implementation optional, as Intl is today. I’m not sure, I’ve been thinking about how I like the way JavaScript is implemented today in Moddable, and I’m not sure it requires features that seem too specific like this. I totally understand why it is important to release the feature natively. + +SYG: If there's concrete pushback from the Moddable folks and engines with significantly different tradeoffs from the browser folks I would like to hear them. I would like to try for this to be not optional. I think we’ve already decided on a direction with ArrayBuffers that we do care about in-memory manipulation of binary data, and that has enabled whole classes of applications. I think that it directly led to WASM. If we didn't have that, we wouldn't have had asm.js and we wouldn't have WASM. I think more expressive buffers to enable more use cases is a direction we are set on, I don’t want this extra expressivity to be optional if we can help it. But I’m a realist, so if people actually cannot implement this, then we’ll talk about optionality. For GrowableSharedArrayBuffer, it will be the same as SharedArrayBuffer in terms of availability. It's behind COOP/COEP on the web or whatever flag it is on node. + +LEO: Okay, thank you. + +YSV: This is just a comment, we have no concerns about stage 1. Our experience with ArrayBuffers was very difficult. There is hesitation, but we are interested in ???. + +SYG: 100%. This design already looks pretty different from my initial design after talking to the Chrome security engineers and the people who architected the arraybuffer stuff in V8. +I expect some worry in all the other engines given how battle-hardened these paths are. I want to talk about this with all the other engines, basically. I'm hoping the implementation plan I laid out, if we can make these separate code paths, that will lessen a lot of the worries. But yeah, the worry is there, it’s not just for Firefox, it’s also for chrome. + +YSV: I would love to continue that conversation as this moves forward. + +PHE: I’m really pleased to see this topic being addressed. It solves a problem for low memory devices. I personally ran into a case this week where we would need resizable array buffers. I understand why you are focused on performance and resize-in-place. To complete the picture, from our perspective, we would never do that. Our array-buffers are typically stored in relocatable memory so that we can compact. We don't even have an MMU to fragment. And so, that’s fine, that will work with this proposal, in what you’ve said I’ve heard you say that the specification wouldn’t require specific requirements to resize in place, and I think that intent is good, I only bring this up to make sure we keep that up through the process. I think there is more work to be done on views, we use data views heavily and they have - it is a fair question to ask if they should have an auto-tracking behavior, it doesn’t have to be addressed here. There’s also an interesting question about TypedArray’s subArray method, which could arguably also take up an auto-tracking behavior, but since the start and end parameters are optional, you couldn’t take the strategy laid out in the constructor. + +SYG: Thank you for the comment, these are great points. I would like to work with you, or anyone else. You have a different implementation constraint. I would love to work with you. I do admit that I did not provide a complete thinking through of all the views, and there’s no way we can advance without that. + +JRL: Clarifying question from the earlier topics on TypedArray that’s pointing at a ResizableArrayBuffer. You’ve said that if the TypedArray were ??? by something, and then if the ResizableArrayBuffer were to shrink, but earlier you said that ResizableArrayBuffers can’t shrink, so I’m confused as to how you get an out-of-bounds here. + +SYG: ResizableArrayBUffers can shrink. THe idea is that you don't have to decommit your physical pages when you shrink, you just change the length or something. I think the shrinking is important to explain the repointing use case that WebGPU has, but I'm not putting a particular implementation constraint. Notably here, you can throw OOMs on both grows and shrinks. So if you choose to implement resize shrinking via realloc or something, and that throws for some reason, you’re allowed to propagate that up to the user. I think that is important but if folks feel strongly about shrinking about non-shared buffers I hope you reach out. + +MLS: SYG, you specified the current and max length. Do you see the max as something the engine must honor in the future? Or is it just kind of like an upper bound ??? request, and you throw an OOM if you can’t honor it? + +SYG: Are you asking what the pedantic normative thing should be or what I think will happen in practice? + +MLS: The pedantic normative. + +SYG: The pedantic normative thing is that I want it to be completely up to the host. Because both the resize and the constructor can throw, one strategy can be that you optimistically agree to any byte length. The other end could be you try to commit everything up front and resize never throws. But I want to give implementations the full spectrum of choices here. + +MLS: The reason I ask is that we saw early on with a lot of WASM programs, they just ask for a full 32-bit address space, which is counterproductive to other running WASM processes. So, I'm wondering if the API could encourage programs to be responsible in their requests. + +SYG: That feels like maybe one of the things that we as browser implementers could coordinate in a non-normative way in the same way that we coordinated not diverging too badly on WeakRefs and Finalizers. + +MLS: Yeah, that is fine. + +GCL: Love this proposal. I want to say - wherever this proposal goes in the future, should still try to fix the WASM detached buffer problem. To make sure that we are up front about that. + +SYG: For sure, and I’m in regular discussion about this with the emscripten team, the WASM tooling team at Google, as well as the WASM standards team. + +SYG: Ok, so do I have Stage 1? + +AKI: Do we have consensus on Stage 1? + +WH: I think you do! + +### Conclusion/Resolution +- Stage 1! + +## Documenting invariants +Presenter: Yulia Startsev (YSV) + +- [repo](https://github.com/codehag/documenting-invariants) +- [slides](https://docs.google.com/presentation/d/1a9-E87grtSbFGTHMfEJJoVjbHbSTe2PH_ed8StssZ_w) + +YSV: (presents slides) + +JHD: I'm very strongly in support for documenting these. There are a lot of invariants that are not documented, and they shouldn't be broken just because there isn't the person advocating for them during the meeting. It will be useful for the reverse. There are a lot of people who believe there is an invariant, but there isn’t one. Thank you YSV for doing this work. + +YSV: I'm happy to hear that. + +WH: I like documenting these. I’m curious what your notion of an invariant is. Some things I would consider an invariant is that the grammar be LR(1.5), aside from a few trivial adjustments for readability. Another invariant would be that there is no place in the language where both a division and a regular expression are allowed at the same time. And I hope it’s clear why you would want to enforce such an invariant. Would such things be candidates for the invariants list, or would they be too low-level? + +YSV: Thank you for bringing that up. I would consider that a "should" based on the arguments you made in the issue. It seems like in the issue, it seemed flexible to do something different here. But because the spec is currently written in that way, I think it would be useful to document that. You mentioned that there are a few places where this isn’t true, so it would fit into a “should” and then we’d have an allowlist for the APIs that don’t conform to that invariant. + +WH: I think I wasn't clear. The spec conforms to the invariants, but you have to transform the spec slightly to get that invariant. So it’s not a “should”, I’d consider it a “must”. + +YSV: I think that can be considered an invariant, especially if you are reading the spec and making decisions on the basis of it. And I would say that you have done that, especially given that you’ve opened issues. So that would be a candidate for an invariant. As I mentioned, it can be anything that is true about the specification now, or something that was true, that was changed, we recognized it was an issue, and going forward we want to maintain that invariant. So both can definitely be candidates for invariants. + +WH: Ok, thank you. + +SYG: I think you asked for clear dangers, we should be conscious about what we consider an invariant vs emergent behavior. There are properties that are true today in an invariant manner that are true of the spec that are not worth documenting. It seems very easy to backport rationale. If you put a property in front of someone, and ask someone to come up with a reason, they can come up with a reason. + +YSV: That’s a very good point. + +SYG: So I think the rationale point is really key here, we have to be really careful. + +YSV: I consider the rationale to be crucial to this, and hope that we can add rationale for the invariants we already have. One of the reasons why I want us to start having this discussion is so that we do start talking about the invariants that we are bringing up to the committee. So that either- and I think we will have to come up with a process for rejected invariants that people deem important that are not held up by the committee, those should be recorded as well. That is a good point. I don’t have an idea yet about how we are going to do that. + +SYG: Thanks + +BFS: I’d second YSV’s point about personal vs plenary acceptance, we can state many things about emergent behavior, but I think no matter what we do, people will hold a personal level for invariants, but I think this is more about doing this as a community at the plenary level. So even we one of us considers something emergent, others may find it a personal invariant that they don’t wish to be broken. + +SYG: I think that makes sense. I think the plenary thing is important. I guess I was warning against- that people approach this in good faith and not try to pursue personal invariants by backporting rationale. + +SYG: What is your envisioned process for relaxing must/must-not invariants? +I’ll give you an example, a couple years ago I think we could have easily said something like "shared memory will not happen", and then the market changed and we decided to have this tradeoff. + +YSV: Do you happen to remember what the rationale for excluding that was? + +SYG: Channels, timers, like MM was saying algebraic properties, I’ll let other people take over. + +WH: I was one of the people trying to exclude shared memory because it provides a very high resolution timer. + +YSV: I see. + +MM: There were many reasons not to do shared memory. BE famously said this was an “over my dead body” issue, I was taking a similar position, not just for a timing issue, but prior to shared memory, we had a very robust concurrency model, communicating event loop concurrency, where different agents are only asynchronously coupled to each other. It was exactly a irresistable market pressure---the desire to run games written in C in the browser---that forced our hand. + +YSV: I see. In the “documenting invariants” repository, there is a section called "abandoned invariants", and what I'd hope to do more in the section is to document what has been the process to abandon them. My imagined process, which is different from the one we may come to, is one similar to the process to introduce an invariant. To remove an invariant, you would bring a normative PR and challenge the rationale based on this set of conditions. Not sure yet if that will be how it is in practice. + +BFS: Sure, we actually had another example of what we considered as - we haven’t adopted invariants as a plenary - when we passed through the hashbang grammar, there was an invariant that you could append comments safely at the beginning of any source text that was already valid. From there, we had a discussion about the rationale, which was there, to prepend license comments, was of higher priority than the ability to integrate with shell scripts. And so we’ve had this kind of back and forth before, I think we can just set up a model similar to that and look back at all those examples similar to that where we’ve done that in the past. + +YSV: I agree with that, it is a good idea. + +SYG: My response to what YSV said was that I'm mainly worried about extra-process bureaucracy here. In those cases it usually behooves us to move faster. And if extra bureaucracy means we spend an extra year relaxing an invariant and then move on with the feature, that might be bad. + +YSV: That's a good point, and now that I'm thinking about it I'm wondering if it wouldn't be appropriate for an invariant to be relaxed in the process of moving forward a proposal. + +THe process that I’m seeing right now is that we have a number of invariants that aren’t written down. We need to write them down. But I think it could be that a proposal itself is evidence that an invariant should be relaxed. I’m not too sure yet all of my thoughts about this. + +SYG: Thanks, I do agree that it should be important to make implicit invariants explicit. + +RKG: So there’s the long ongoing desire to document rationale and the way that we do things, and this is I guess based on EIM invariants being very useful to broaden and codify. But of course there’s a lot of things that we seek to uphold that - you wouldn’t be able to call the syntax budget an invariant in any meaningful way. It's curious like… I'm guessing that the boundary is fairly fuzzy. This connects to the question of emergence as well, because there’s certainly going to be concerns that become more or less meaningful in a given context or a given time. This is exclusively for something that's solid and clear and defensible enough to be put in spec text, right? + +YSV: Yes. I guess you are also referring to the rationale project from last year. + +RKG: Right. + +YSV: Thank you for bringing that up, that’s another case of me trying to make sure we’re writing things down. One way that you could phrase this is that this is a more immediate goal, and it doesn't exclude from the work of writing down the irrationale. THat work would still be ongoing, to help us understand our goals, I think the rationale project is useful for that, whereas this is for understanding how we constrain our design. + +YSV: (resumes presenting slides at “Addendum: Clarifying the process”) + +YSV: I would like to ask for the temperature of the room on this. + +AKI: You are always so thoughtful about this kind of things that I'm sure that many would like to read this before making a final decision. + +CM: I just want to endorse your proposal YSV, in the whole vein of documenting our invariants, these are sort of meta-invariants, and I like that we have this quite a bit. + +WH: I like the idea, I don’t agree with the content. This is too strict and it’s different from what we’ve actually been doing in practice. We’ve blocked things from stage 1 for stage 2 reasons if we really thought they wouldn’t have much of a chance to advance past stage 2. But that wouldn’t be allowed under this proposal, so we wouldn’t be able to do that. + +YSV: That's good feedback. Do you have other comments about the other stages? + +WH: I have had only a few minutes to look at this document so far. I would not be okay with this becoming the official policy at the moment. + +YSV: Just to make it clear, the feedback I'm looking for is not if this should become the new document. It's more about if people are open to iterate on this and modifying the process document. + +WH: Given that clarification, sounds good. + +MM: I just wanted to speak in support of this, I was about to say more but the back-and-forth between YSV and WH clarified everything I was going to say, so I’ll just say I support it. + +SYG: My question was clarified as well: you want the temperature check to see if folks are open to reviewing. + +YSV: Yes, and with the idea that if you’re up for reviewing, we would be open to adding something to this effect. + +SYG: I am in support of that, though I’m not sure on what timeline you’re looking for. This needs discussion with other web standards folks at Google for instance, to see if this is a direction that’s desirable for TC39 with respect to the rest of the web standards world. + +YSV: I'll make this available tonight so that you can do that at your pleasure, and I will tell you when I bring it back. + +JHX: I want to show my support of this. I think this is really helpful to the newcomers. And I feel in previous meetings some proposals advance under a different standard, which is very confusing. So I think that this is very helpful. + +MF: You said that you’d like this to be made public soon. I’m all for doing work in a publicly visible way, but I don’t think I want to have the feedback discussion and everything- I don’t want to have public participation in that. What venue are we going to be using for feedback? + +YSV: I wasn’t aware that it would be an issue. I was thinking to do it as a PR, which would be public. Alternatively what I could do is send each person a copy so that they could give me feedback, or aggregate anonymous feedback, or I can share this document and you can leave your comments on there. + +MF: I would prefer a form of feedback where we could collaborate. Something like a PR but in a private repo under the tc39 org so that all delegates could participate. + +YSV: Would it make sense then for me to do this on the reflector temporarily, and then once we’re happy with the words, we can move it somewhere else? + +MF: It works for me, I wonder if anyone else has some ideas. + +MBS: I wanted to clarify if the concern is with the conversation happening where it can happen publically, If we are looking at doing this privately, I think there is a tiny bit of a gray area where we find ourselves in where we would be mostly talking about process, but if we end up talking about technical things, I’d like to make sure we’re consistent. So I wanted to clarify if the concern was about the conversation being private, or it being read publicly. + +MF: My concern was with general public contribution. I don’t think it is necessary. I am fine with the general public being able to view our conversation. + +YSV: That is a good clarification, thank you. I will think about this. I’ll post this on the reflector. + +Remaining queue: +1. Reply: We could limit participation in a PR by locking it (MBS) +2. New Topic: where is its home? (AKI) + +### Conclusion/Resolution +- We will start work on documenting invariants. +- We will start iterating on the process documentation on a private Github repository. + +## Many specific invariants to consider +Mark S. Miller (MM) + +- [slides](https://github.com/tc39/agendas/raw/master/2020/07-slides-some-invariants.pdf) + +JHD: The typeof ===/== invariant. People have a wide assumption that they are interchangable. Eslint has the eqeqeq rule, it doesn’t autofix. I think it is an important invariant to maintain. + +MM: + +BFS: There is ecosystem reliance on emergent behavior as if it were an invariant. Particularly minifiers. I think it would be important to evaluate the current ecosystem tooling. While we may want to keep invariant themselves somewhat private while we discuss them, we need to do an ecosystem audit before add invariants for operators in particular. + +JHD: There are a lot of places they are accessed on things that aren’t the receiver, every time a regex is passed into a string for example. + +MM: If there are enough of them, it would mean it isn’t an invariant. + +JHD: I don’t think it is invariant at all. I would love to discuss offline. diff --git a/meetings/2020-07/summary.md b/meetings/2020-07/summary.md new file mode 100644 index 00000000..d9dbddfd --- /dev/null +++ b/meetings/2020-07/summary.md @@ -0,0 +1,89 @@ +# Summary for the 77th meeting of Ecma TC39 + +Ecma Technical Committee 39 held a four day meeting hosted remotely on July 20th - July 23rd, 2020. [Agenda can be found here](https://github.com/tc39/agendas/blob/master/2020/07.md). + +## Broad presentations + +- [Cognitive Dimensions of Notation: a framework for reflecting on language design](https://docs.google.com/presentation/d/1OpKfS5UYgcwmBuejoSOBpbgsYXXzO0gG7GJHo65UXPE) by Yulia Startsev and Dr. Felienne Hermans +- Examining Structural Racism in TC39: [issue](https://github.com/tc39/Reflector/issues/305), [slides](https://docs.google.com/presentation/d/1i9-VCNi4KZNisntn9TTCFaZhrPwMQr4XuYEqHBg7pAE) +- Documenting invariants (Yulia Startsev): [repo](https://github.com/codehag/documenting-invariants), [slides](https://docs.google.com/presentation/d/1a9-E87grtSbFGTHMfEJJoVjbHbSTe2PH_ed8StssZ_w) +- Many specific invariants to consider (Mark S. Miller): [slides](https://github.com/tc39/agendas/raw/master/2020/07-slides-some-invariants.pdf) + +## Updates + +- [ECMA-262 Editors Update](https://docs.google.com/presentation/d/1O8wGWehzMhqb_Jz2JfmyUxyUepxanc8sEVMlTRUVnfo) +- [TC39/TG2 - ECMA-402](https://docs.google.com/presentation/d/1C54jVjcuE27wq658CbMi0KEfa5ded_WIWvdq1JP8QDI) +- [Test262](https://docs.google.com/presentation/d/1tsqTUZioHi8YxRF_CapxcZTjZQYDClEgXOFUm0W4gHg) +- Decorators status update: [proposal](https://github.com/tc39/proposal-decorators/), [slides](https://slides.com/pzuraq/decorators-3cb407) +- Iterator Helpers update: [proposal](https://github.com/tc39/proposal-iterator-helpers), [slides](https://docs.google.com/presentation/d/1YNLzi_ENRtxp5bjhXMUplQ0VIQBUFLyucbNFt_oaNgQ) +- Upsert (now renamed emplace) updates: [proposal](https://github.com/tc39/proposal-upsert), [slides](https://docs.google.com/presentation/d/16PtTpuvkTFycaaqkk5XGZRPLNwzUrzBuN9y7VSrGX9k/edit#slide=id.p) +- Flex Incubator Calls to weekly meetings: TC39 decided to continue incubator calls bi-weekly by default, and might extend to weekly meetings on demand. + +## Advancing Proposals + +### No Stage + +- Arbitrary Module Namespace Identifiers: [proposal](https://github.com/bmeck/proposal-arbitrary-module-namespace-identifiers). Consensus, but this is becoming an immediate PR to ECMA-262 without full proposal process due to its size. + +### Stage 4 + +- Promise.any & AggregateError: [proposal](https://github.com/tc39/proposal-promise-any), [slides](https://docs.google.com/presentation/d/1PcfPP5nLVG8w5OosQt5PWwOmFUPuD5pg1rgGaF1JVis), [tc39/ecma262#2040](https://github.com/tc39/ecma262/pull/2040) +- Intl.ListFormat: [proposal](https://github.com/tc39/proposal-intl-list-format), [slides](https://docs.google.com/presentation/d/13gxxnt-JMuWXJhzwuU2jtBRZ8RGJgJ0Y8RsIvHEQU7k/edit#slide=id.p) +- Intl.DateTimeFormat dateStyle/timeStyle: [proposal](https://github.com/tc39/proposal-intl-datetime-style), [slides](https://docs.google.com/presentation/d/1USMb1b_1zDMAlw3Aw5k9DpqZsZ3NS_q9gOyhRCQc-qg) +- WeakRefs + FinalizationRegistry (but cleanupSome demoted to Stage 2): [WeakRefs proposal](https://github.com/tc39/proposal-weakrefs/), [CleanupSome proposal](https://github.com/codehag/proposal-cleanup-some), [tc39/ecma262#2089](https://github.com/tc39/ecma262/pull/2089), [slides](https://docs.google.com/presentation/d/1NYhEELzOnhJGU7inKz0r0TrEa0h33krr1nEb3X_ze5w) +- Logical Assignment (`x ||= y`, `x ??= y`, `x &&= y`): [proposal](https://github.com/tc39/proposal-logical-assignment), [slides](https://docs.google.com/presentation/d/1rq448C-mzxWzBs6RTInczGTjs4xv5gQenDJY1fGogX0), [tc39/ecma262#2030](https://github.com/tc39/ecma262/pull/2030) +- NumericLiteralSeparator: [proposal](https://github.com/tc39/proposal-numeric-separator), [slides](https://docs.google.com/presentation/d/1rLT5m3d0yk2KMlka4KZKf2uz9oITdpfr6evAV_jaKcc), [tc39/ecma262#2043](https://github.com/tc39/ecma262/pull/2043) + +### Stage 3 + +- Intl.Segmenter: [proposal](https://github.com/tc39/proposal-intl-segmenter), [slides](https://docs.google.com/presentation/d/1LOOt4WPvQdOK3banHkz1V8sdl8Z-7Z9jXBRRS9Ek8-M) + +### Stage 2 + +- String/Array/TypedArrays `.item()` for Stage 2: [proposal](https://github.com/tabatkins/proposal-item-method), [slides](https://docs.google.com/presentation/d/1N-oXRRKDA7patBA4HIYkzN67j1pbyOxuDZoYRvPFmuA) +- Record and Tuple: [proposal](https://github.com/tc39/proposal-record-tuple), [slides](https://button.dev/talks/record-and-tuple-tc39-july-2020.pdf) +- JSON.parse source text access: [proposal](https://tc39.es/proposal-json-parse-with-source/), [slides](https://docs.google.com/presentation/d/1MGJhUvrWl4dE4otjUm8jXDrhaZLh9g7dnasnfK-VyZg/edit?usp=sharing) + +### Stage 1 + +- await operations: [proposal](https://jack-works.github.io/proposal-await.ops/), [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.g89f56b0333_1_40) +- `Array.prototype.unique()`, [proposal](https://github.com/TechQuery/array-unique-proposal), [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.g89f56b0333_1_150) +- ResizableArrayBuffer and GrowableSharedArrayBuffer: [proposal](https://github.com/syg/proposal-resizablearraybuffer), [slides](https://docs.google.com/presentation/d/17QwbVQEYClzfCDGgWyZg0V_zTC1DWsNwPWvJPuXIqRg) + +## Non Advancing proposals + +- Class static blocks for Stage 2: [proposal](https://tc39.es/proposal-class-static-block/), [slides](https://onedrive.live.com/view.aspx?resid=934F1675ED4C1638!291940&ithint=file%2cpptx&authkey=!ADFod3jufA89iM8) +- `cleanupSome` detached from the WeakRefs proposal and demoted to Stage 2: [proposal](https://github.com/codehag/proposal-cleanup-some), [slides](https://docs.google.com/presentation/d/1NYhEELzOnhJGU7inKz0r0TrEa0h33krr1nEb3X_ze5w) +- Slice notation for Stage 2 (`arr[1: 4]`): [proposal](https://github.com/tc39/proposal-slice-notation), [slides](https://docs.google.com/presentation/d/1EBpiGuYn2ChDvcd67fpz6gGY14kO8VCuAKOhFMxOqEQ) +- Import Conditions for Stage 3: [proposal](https://github.com/tc39/proposal-import-conditions), [slides](https://docs.google.com/presentation/d/18THsm_ZAog70m0ZlEokRCfyrarMiA1yr6YDAvFXjVNU) +- `Number.range` for Stage 2: [proposal](https://github.com/tc39/proposal-Number.range), [slides](https://docs.google.com/presentation/d/116FDDK2klJoEL8s2Q7UXiDApC681N-Q9SwpC0toAzTU/edit#slide=id.p) +- Symbols as WeakMap keys for stage 2: [proposal](https://github.com/tc39/proposal-symbols-as-weakmap-keys), [slides](https://docs.google.com/presentation/d/1AofgrikRJp4vTc_tqlchDk4DU9p4eqZdyxnlrFEYsvc/edit#slide=id.p) +- Ergonomic brand checks for private fields for stage 3 (continuation from day 2): tc39/proposal-private-fields-in-in#7: https://gist.github.com/hax/5e94c7959703ea95d4ff9c9deac12988 +- Async Context for Stage 1: [proposal](https://github.com/legendecas/proposal-async-context), [slides](https://docs.google.com/presentation/d/1Ef2JI4ntkWd-M8fDqOGZGGh7CiPD05L39CZRSv1II_0/edit?usp=sharing) + +## PRs w/ consensus + +- Retroactive consensus on Unicode 13 property names and aliases: tc39/ecma262#1896, tc39/ecma262#1939 +- Specify \8 and \9 in sloppy (non-template) strings: tc39/ecma262#2054 +- Adding `Reflect[Symbol.toStringTag]`: tc39/ecma262#2057 +- ECMA-402: Allow Collator to get collation from option: tc39/ecma402#459 +- ECMA-402: Handle awkward rounding behaviour: tc39/ecma402#471 ([slides](https://docs.google.com/presentation/d/1QGUTz61o-X_HEgYrkTUXtScoRpu_KhXsoKxGyMQJthc)) +- Strictness check for object's SetMutableBinding: tc39/ecma262#2094, [slides](https://docs.google.com/presentation/d/1O_YdntfiZMTsxX_2FPk1YZypEy1vncL3X1NCg-vmC1E) +- Fix Function.toString for builtins: tc39/ecma262#1948 +- Host hooks for Job callbacks: tc39/ecma262#2086, [slides](https://docs.google.com/presentation/d/19S97ZqhibJABqzeP5ZU6Flk6TVgWzXuvJWFbNTTfpWs/edit?usp=sharing) + +## PRs rejected or without consensus + +### Should `eval?.()` be direct `eval`? + +Links: tc39/ecma262#2062, tc39/ecma262#2063 + +Mainstream browsers were shipping `eval?.(str)` as a direct eval, using the function scope similarly to `eval(str)` but spec says it is indirect, and code evaluates using the global scope, similarly to `(0, eval)(str)`. TC39 decided it continues to be _indirect eval_, without changes to the specs. + +### Forbid Numeric Separators in NonOctalDecimalIntegerLiteral fractional / exponent parts + +Link: tc39/ecma262#2090 + +The numeric separators are forbidden in legacy (_Annex B_) number notations, like non-octals `081`. Although, TC39 will not disallow separators in the exponential parts and fraction parts of these legacy numbers due to current implementations support and excessive tailoring of the spec text. This means `08.1_0` and `08e1_0` are allowed and will remain allowed by the specs. Non octals are only possible in non-strict mode anyway. + +