2020-04-01 [17:27:27.0000] https://github.com/tc39/proposal-pattern-matching/issues/155 [17:30:19.0000] I mean I could be interested in co-championing [17:30:34.0000] I've never done it and I do feel excited about the feature [17:30:57.0000] I'm worried about needing to bikeshed about it with the entirety of the internet [17:31:03.0000] but that's really my only worry [17:31:08.0000] there are some really interesting items on the queue for decimal. It'd be great to have a short extension to talk through the queue if we have time. [17:32:30.0000] rkirsling: that is very much likely to be the job [17:32:40.0000] rkirsling: including, managing opinions on github [17:32:55.0000] rkirsling: happy to move you to the top list tho if you like :-) [17:33:05.0000] 😭 [17:33:09.0000] lmk [17:33:22.0000] I'll sleep on it and get back to you [17:33:25.0000] kk, no rush [17:47:10.0000] rkirsling: I volunteered as well, because I'm pretty good at sifting thru and rejecting bad opinions. ^_^ But if you want the experience, absolutely go for it. [17:47:49.0000] doesn't have to be mutually exclusive, right? 😅 [17:47:58.0000] I could probably learn from you folks on that [17:52:49.0000] (basically the notion of a "champion group" is what's heartening me into wanting to do this :p) [18:18:22.0000] also is the whole group being replaced? [18:18:30.0000] including Brian and Sebastian? [19:14:15.0000] neither has been involved in the proposal for a long while; if either is interested in resuming they’ll be welcome [19:28:26.0000] fair enough [20:59:05.0000] fwiw, I was also coming in picturing this as a "champion group". I definitely don't have the requisite experience to champion alone, but I'm very passionate about the feature and would like to contribute. [21:00:23.0000] sgtm [22:54:35.0000] sffc mathiasbynens gibson042: I have slides for tomorrow: https://docs.google.com/presentation/d/1COuuP_0fxK_s8-H8AScDMjMzKSEiAlAnOi4snP-OiHY/edit?usp=sharing [22:54:55.0000] the summary of which is, I would like both kinds of escape to work in both kinds of regex [22:56:51.0000] I realize there are consistency arguments against each of the possible kinds (except `\u{}` in `u`), but to my mind weighing those against the advantages of a.) making tooling simpler and b.) not spending more time on this topic, and in light of the expectation that this will affect very few users except tool authors, it comes down in favor of just making them all legal [22:57:21.0000] this is not to say that I disagree with the consistency arguments, just that there are other goals which I think should outweigh them in this particular case [22:57:50.0000] if you have thoughts on this I'd be happy to discuss more before it comes up again in plenary [22:58:32.0000] (or, of course, once it has come up again in plenary, just, it would be ideal to resolve this in advance) [23:03:22.0000] (I love the subtitle, hehe) [23:08:35.0000] Bakkot: I appreciate the heads-up, will take a look today [23:09:42.0000] mathiasbynens also we agreed to revisit for half an hour tomorrow [23:10:00.0000] hoping we can get things to a point where we don't need the full time [23:10:23.0000] _really_ hoping we get to a point where we don't need more than that, because that will force an absolutely excruciating process discussion [23:19:12.0000] Bakkot: I said (in plenary) yesterday I don't intend to block and that still stands. I do disagree with what you propose but I can live with it. I'd like to say on the record that imho it's a mistake to expose the concept of surrogates in more places but then that's that. there's other (imho better) ways to support ASCIIfiers, and I don't buy the argument that tools should be able to do things without the [23:19:12.0000] need to tokenize/parse [23:19:55.0000] mathiasbynens ok, thanks for feedback [23:20:24.0000] fwiw the "expose the concept of surrogates in more places" feels pretty weak to me if we are in agreement that almost no actual humans will ever be exposed to this case [23:21:32.0000] (though, the point in my slides is that the question of surrogates in `u`-mode regexes should not have been considered open, so either way that's a mistake we're already mostly committed to) [23:25:44.0000] I don't think "it should not have been considered open" is entirely fair. I'm one of the NCG champions and clearly I thought the goal was to match identifiers and disallow individually-escaped surrogate halves (IESH). (in the original comment thread you can see me and Jakob even push back against allowing identifiers in the first place -- why would I then be okay with identifiers-but-also-IESH?) [23:28:09.0000] it is hard to read the spec text which got consensus as intending to treating `\uLEAD\uTRAIL` as different from `\u{}` in `u`-mode regexes; also, there are shipping implementations which make the assumption that they are legal. [23:28:31.0000] I feel like these are pretty good reasons to regard it as not being open [23:28:32.0000] Bakkot: littledan explicitly said he didn't think the IESH case through here: https://github.com/tc39/ecma262/issues/1861#issuecomment-604120402 [23:29:29.0000] yeah, but we often get consensus on things which not everyone has thought through, and that doesn't automatically mean they're open [23:29:44.0000] even if it turns out there's a genuine point of unclarity nearby [23:31:10.0000] my intent with raising this issue was only to settle the point where the current spec text does not have one natural interpretation (even if it is technically not completely specified), which I hold is the case only for non-u regexes [23:31:25.0000] Bakkot: this is a case where no one thought it through. the author said as much and the co-champions and reviewers were weary even of the current behavior, so definitely weary of IESH. the spec is incoherent, as you said [23:32:28.0000] here the incoherency is only because it is not obvious how to interpret SV of `\uHex4Digits \uHex4Digits` when those happen to be lead and trail [23:32:54.0000] it _is_ obvious how to interpret SV of `\uLead \uTrail`, and engines implemented that behavior [23:33:49.0000] Bakkot: I see how your current patch is the smallest possible change to fix the spec, I'm not debating that [23:35:41.0000] I'm explaining the history and the author's intentions. no one _wanted_ \uLead\uTrail to work in NCG names, and some people (myself included) back then pushed back even on trying to match identifiers [23:36:02.0000] Yeah, I get the history and the original intent [23:36:21.0000] but we have shipping implementations which match the intent one would read in the spec text [23:37:29.0000] and at least one committee member who has expressed that he _does_ want \uLead\uTrail to work in NCG names, so it's not obvious that we would not have ended up here anyway if the issue was raised at the time [23:37:47.0000] for this reason I think it makes sense to consider the question not to be open _for the purposes of this bugfix PR_ [23:38:34.0000] and if we want to revisit the consensus spec text to make it match what you intended to mean rather than what it is currently being read to me, by shipping implementations, we could do that, but it is not what I would consider to be in scope _for this PR_ [23:39:17.0000] *"rather than what it is currently being read to mean", not "to me" [23:39:21.0000] Bakkot: i'm confused, don't shipping impls have to change anyway if your proposal goes through? [23:39:39.0000] shipping impls have to make some new things legal, not make any currently legal things illegal [23:40:06.0000] i don't think that's much of an argument in this case [23:41:18.0000] the cases where they would be changing are specifically the ones where there is no single natural interpretation of the current spec text [00:04:30.0000] i disagree that “making tooling as simple as possible” is a goal [00:04:48.0000] you disagree that it is _a_ goal? [00:04:56.0000] you think it ought to get literally no weight? [00:05:31.0000] it can get some weight, but we’re overvaluing it here imho [00:05:35.0000] if an asciifier gets the program `foo.𐊧` what does it produce? [00:05:54.0000] foo['\uwhatever'], presumably [00:05:58.0000] something like `foo['\uD800\uDEA7']` right [00:06:07.0000] but anyway if we are overvaluing it what are we overvaluing it relative to? [00:06:19.0000] yeah so the simple asciifier that doesn't need to parse anything doesn't exist [00:06:36.0000] yes, asciifiers have to at least tokenize [00:06:42.0000] but, like, they do [00:06:44.0000] I have seen them [00:06:46.0000] in production [00:06:47.0000] i think it's fair for tooling that operating on source code to be able to tokenize that source code [00:06:49.0000] bespoke asciifiers [00:06:53.0000] _at banks_ [00:06:58.0000] yes but they don't also have to parse regexes [00:07:08.0000] they also, emperically, don't parse regexes [00:07:23.0000] very few parsers parsed regexes until quite recently [00:07:41.0000] can you point to a few of these asciifiers btw? just curious [00:07:49.0000] no, they are customers [00:07:57.0000] do you know of any opensource ones? [00:08:01.0000] I end up seeing a lot of enterprise JS toolchains [00:08:08.0000] that take JS source text as input [00:08:12.0000] not off the top of my head; you could probably find some if you google [00:08:21.0000] google? what's that [00:10:01.0000] uglifyjs2 takes an `ascii_only` option [00:10:21.0000] to me, symmetry between the `𝒜𝒜𝒜` in `/(?<𝒜𝒜𝒜>.)/u` & `match.groups.𝒜𝒜𝒜` weighs much more heavily than the notion how simple asciifiers could be, precisely because that symmetry is visible by humans [00:11:05.0000] https://github.com/mishoo/UglifyJS2/blob/0d820e4c0a7a1b1eeee25fb632b9496a9780b28a/lib/output.js#L109-L119 [00:11:19.0000] mathiasbynens but... that will work in all cases, no one says that shouldn't work [00:11:25.0000] so I am confused why it is relevant [00:11:37.0000] that symmetry will always be present [00:12:00.0000] Bakkot: by symmetry I mean that whatever I put there instead of `𝒜𝒜𝒜`, it should work [00:12:11.0000] Bakkot: your proposal breaks that [00:12:24.0000] no human will put surrogate pairs there, so no human will be exposed to that asymmetry, so why does that matter? [00:12:47.0000] Bakkot: heh, uglifyjs2’s ascii_only apparently breaks the simple `foo.𐊧` case (it outputs `foo.\ud800\udea7`) [00:12:54.0000] so it sounds they have bigger problems than this [00:13:20.0000] yeah but we don't need to make their tools more broken [00:13:35.0000] does no human debug the bundle that is deployed to production ever? [00:14:56.0000] occasionally, but not by editting the source [00:15:08.0000] and the group name allows multiple representations anyway and no one says it shouldn't [00:15:13.0000] so there is no possible new confusion here [00:16:10.0000] by allowing \uLead\uTrail we’re introducing yet another representation though [00:16:23.0000] one that breaks the symmetry [00:16:34.0000] we could choose not to do that [00:17:06.0000] how will the user be exposed to the fact that it breaks the symmetry? [00:17:29.0000] they would have to write `match.groups.\uLead\uTrail` and find that it fails. but they are not going to write that. [00:17:45.0000] so they will not be exposed to the fact that it breaks the symmetry. [00:17:54.0000] so, why doe that matter? [00:20:14.0000] they would if they happen upon source code of the form `/(?<\uLead\uTrail>.)/u` which you want to make valid [00:20:23.0000] sure that code probably wasn't written by a human [00:20:57.0000] it's not unreasonable to want to copy-paste the group name and place it `match.groups.` [00:21:28.0000] that’s how people use NCG [00:21:30.0000] if it has a backslash in it, i think it is [00:21:46.0000] that identifiers can have escapes is arcane nonsense that no normal human ever thinks of [00:22:13.0000] yeah if it has a backslash they're going to put it in a computed property in a string and it will work just fine [00:22:25.0000] because both forms of `\u` are legal and do the right thing in string literals [00:22:32.0000] that’s what i’m saying. currently this confusion doesn't exist in this case. copy-pasting just works [00:22:39.0000] it works but no one would try it [00:22:45.0000] right, nobody would try it [00:22:55.0000] because no one thinks you can have backslashes in identifiers [00:23:01.0000] it has a backslash, they'd assume it would be a syntax error as a dot, because it's *utter insanity* that it's not [00:23:43.0000] ok so let’s look at the current situation [00:24:00.0000] I would give at least even odds that not more than a dozen humans will ever do that copy-paste individually escaped surrogate pairs for the rest of human existence. and the experience of those people will be, they get a syntax error, and put it in a computed property and go about their day. [00:24:11.0000] the only way there'd be a backslash in the name currently would be if it used \u{…}, right? [00:24:15.0000] `var π` is reasonable, `var \u03c0` should never have been permitted [00:24:27.0000] mathiasbynens depending on what you mean by "currently" [00:24:45.0000] ljharb: but asciifiers!!1 [00:24:51.0000] in shipping implementations, no, that's false, they can have the individually escaped surrogate pairs [00:25:04.0000] in non-u regexes [00:25:45.0000] we’re discussing the spec change [00:26:05.0000] you are asking about "the current situation"; I'm asking which definition of current are you using [00:26:45.0000] the current spec [00:27:10.0000] ljharb `var \u03c0` needed to be permitted because asciifiers are an extremely widely used and critical part of the internet infrastructure, despite mathiasbynens's sarcasm [00:27:29.0000] Bakkot: and that scenario should never imo have come to pass :-) obv the ship has long since sailed [00:27:39.0000] ljharb yeah, like, in the shift-JIS days [00:27:42.0000] _long_ sailed [00:27:44.0000] if the current spec doesn't even allow \u{…}, then the symmetry holds [00:27:59.0000] if the spec were to allow \u{…}, the symmetry would still hold [00:28:07.0000] mathiasbynens the current spec is incoherent for non-u regexes, so it can't be said to allow or disallow either [00:28:13.0000] ok I guess it actually can be said to disallow `\u{}` [00:28:18.0000] for non-u [00:28:55.0000] but I am willing to go along with this for the sake of argument [00:29:00.0000] Bakkot: but that would make asciification impossible for that case, right? so a no-go [00:29:31.0000] only if the spec allows \uLead\uTrail, the symmetry is broken [00:30:20.0000] yes, I agree with this [00:30:37.0000] I just don't get why we should prioritize this particular edge case of symmetry that not more than maybe a dozen people will ever run into, over, for example, not causing further breakage in uglifyJS's actual, existing implementation [00:30:58.0000] ljharb: you’re saying escape sequences in identifiers are weird. also i think surrogates are weird. this is the combination of those two [00:31:07.0000] I understand that the symmetry is nice [00:31:12.0000] I was a mathematician, once upon a time [00:31:17.0000] (I miss those days sometimes) [00:31:20.0000] mathiasbynens: surrogates are very weird, but people run into 💩 problems a LOT more often than they'd ever run into escapes in identifiers [00:31:40.0000] like, "not infrequently" compared to "basically never" [00:31:51.0000] emojis are super on trend [00:34:33.0000] mathiasbynens: anyways obv both are weird, but so are regexes in general because of the same allowing-escapes bs [00:34:49.0000] imo the non-weird thing would have been, no escapes at all, but it's also far too late for that [00:35:39.0000] Bakkot: we agree that this particular case is an edge case. but the symmetry itself is super common: I posit that people think of the `FOO` in `/(?.)/u` & `match.groups.FOO` as “the same thing” [00:35:59.0000] when there's no escape sequences involved, granted. [00:36:15.0000] I dispute that anyone's mental model extends to cases where there are escape sequences. [00:36:18.0000] Bakkot: no, in general [00:36:22.0000] i'm talking generally [00:36:24.0000] and here you’re adding a gotcha to that [00:36:27.0000] then no, disputed. [00:36:59.0000] but, like, ok, if we grant that for the sake of argument, then what? [00:37:12.0000] they will never, ever be exposed to the fact that this absurd edge case breaks that symmetry very slightly [00:37:13.0000] how is this disputable? it’s true in today’s spec, and you’re wanting to add an exception to this [00:37:15.0000] so _why does it matter_ [00:37:37.0000] mathiasbynens your claim was about what how people think [00:37:43.0000] the spec is not especially relevant to that question [00:37:46.0000] how people think is definitely not related to what the spec says [00:37:51.0000] not tightly coupled, anyways [00:38:10.0000] i'd claim that no muggle has escape sequences in their mental model [00:38:25.0000] you brought up escape sequences, which is arguably a spec thing [00:38:55.0000] yes, and you brought up people's mental models, and the intersection of those two things is approximately empty [00:38:58.0000] this entire discussion is about something that simply doesn't exist in normal people's mental model [00:39:48.0000] I agree! which is why I don't get the “when there’s no escape sequences involved” counterargument [00:40:01.0000] most people wouldn’t think of that [00:40:16.0000] most people would not realize that is a possible thing [00:40:22.0000] so their mental model would not cover that case [00:40:24.0000] well it isn’t currently [00:40:43.0000] that’s my point [00:41:04.0000] sorry, I don't see it [00:41:05.0000] let’s keep the mental model simple [00:41:13.0000] the mental model remains simple [00:41:21.0000] because zero people will run into this edge case [00:41:23.0000] zero [00:41:38.0000] even by accident. nobody looks at code that's output by tooling. [00:42:05.0000] (some people look at code that's output by tooling but running in to this requires not just looking at it but editting it in a very particular way) [00:42:15.0000] as someone who works on DevTools I cannot disagree more strongly [00:43:52.0000] I do not agree with jordan's claim [00:44:08.0000] but reading code output by tooling is not sufficient to run into this edge case [00:44:19.0000] that is, to notice the asymmetry [00:44:41.0000] you have to actually then go and try to write an escape sequence in identifier position [00:44:59.0000] would uglify users typically end up with `match.groups.\u...` in prod code? [00:44:59.0000] which is not going to be a thing very many people try [00:45:07.0000] I feel confident in this claim [00:45:48.0000] rkirsling: after setting ascii_only to true on https://skalman.github.io/UglifyJS-online/, enter `foo.𐊧` [00:46:00.0000] rkirsling: it produces `foo.\ud800\udea7;` which is invalid [00:46:25.0000] should be `foo['…']` [00:46:51.0000] hmmm [00:47:15.0000] hm, that's for v3 [00:47:18.0000] v2 has the same problem? [00:47:27.0000] yeah I mean the fact that `foo.\u...` is so surprising would lead me to want this discussion to be centered about _bracket_ access working correctly [00:47:34.0000] mathiasbynens while we're on this subject, the fix to uglify is to make it aware that it needs special treatment for non-BMP code points in identifiers [00:47:35.0000] https://github.com/mishoo/UglifyJS2 is the one everyone seems to be using in my experience [00:47:52.0000] except if we disallow `\u\u` in regexes [00:47:57.0000] in which case the fix is also then "parse regexes" [00:48:10.0000] which, like [00:48:14.0000] that is a hell of a lot more work [00:48:46.0000] (parsing to the point where you can identify a capture group name is substantially less work, but not totally trivial) [00:49:39.0000] I feel like this, alone, out to outweight the <12 people who will ever notice the asymmetry you are concerned about [00:49:41.0000] I’d prefer [a few tools having to do a little bit of extra work to produce correct output] over [exposing surrogates in more places in the language, breaking symmetry between group names in patterns and the way their groups property is accessed] [00:50:06.0000] I just do not understand why you care about this symmetry so much [00:50:33.0000] can you give me an estimated number of people who you think would ever, ever run into the asymmetry? and what the negative consequences you think they would then suffer is? [00:50:37.0000] seems like i care more about the language and people reading code [00:50:37.0000] whereas you prioritize making things easy for tooling [00:50:49.0000] I care about _users_, first and foremost [00:50:50.0000] i'm a little confused about why you're focusing on dot access specifically [00:50:53.0000] which means _not breaking tooling_, yes [00:51:08.0000] because then websites break and people cannot get into their pharmacy [00:51:29.0000] mathiasbynens but also, I reject your dichotomy [00:51:39.0000] I care about the language and people reading code a great deal [00:51:39.0000] however [00:52:02.0000] I don't think this will affect basically any readers of code, and very very few writers of it [00:52:08.0000] i didn't say that you don't care about these things (i know you do!) [00:52:56.0000] I care more about readers than I do about tooling, as a rule. however, it is possible for an effect on readers to be so small that it is outweighed by the effect on tooling. as here. [00:53:49.0000] tbf the fact that we do bring these very different perspectives to the discussion is really important [00:54:28.0000] the pressure to rush the decision in today's session was very strange to me [00:54:37.0000] (like, at the end of the day in particular) [00:54:38.0000] rkirsling it comes from ecma basically [00:54:49.0000] rkirsling we want to cut the spec, because ecma wants that and no one wants to fight them [00:54:51.0000] ack. I understand your point, we just disagree about this. I think we’re overindexing on “tooling simplicity” here. [00:55:05.0000] rkirsling and waldemar doesn't want to cut without resolving this. [00:55:20.0000] mathiasbynens ok, so, concretely, can you give me an estimated number of people who you think would ever, ever run into the asymmetry? and what the negative consequences you think they would then suffer is? [00:55:27.0000] Bakkot: yeah it's the last bit there that seemed more subjective [00:56:09.0000] mathiasbynens and, like, the reason I care about simplicity is that tools like uglifyjs have fewer bugs if there are fewer dumb edge cases, which means that _fewer websites break_, and that is a thing which I think ought to be given at least nontrivial weight. [00:57:21.0000] yeah, I understand that, and I agree we don’t want to break websites [01:00:49.0000] (don't forget to rest up for another full day, folks 😁) [01:00:56.0000] (g'night) [01:01:45.0000] mathiasbynens ok, so... [01:04:34.0000] if you agree that reducing risk of tooling bugs ought to get nonzero weight, then the point we disagree on is, does this outweigh the damages of some number of users being exposed to a very slight asymmetry between `/(?.)/u` and `match.groups.FOO` [01:04:42.0000] my position is, the latter number of users is very, very small [01:05:10.0000] and so it is hard for me to understand how it could possibly end up with more weight than the to my mind fairly substantial risk of broken websites [01:05:41.0000] (and also the harm to the users exposed to that asymmetry is very slight, much less bad than e.g. not being able to load their pharmacy's website) [01:06:50.0000] anyway yeah I've got to sleep; I'll read any overnight messages in this channel in the morning [01:19:05.0000] The current proposal is being presented as the only solution that supports ASCIIfiers. The slide deck and Waldemar's plenary comments from yesterday strongly imply so. But that's not the case: we could instead a) allow \u{...} in non-`u` group names b) ban astral group names in non-`u` RegExp (whether they're escaped or not; engines already do this) [01:20:14.0000] I'm starting to like option `b` more and more. I think it resolves your concerns as well, and it nicely fits with the rest of the `u` flag which unlocks various types of Unicode support including `\u{...}` [03:12:25.0000] Bakkot: for when you wake up, I wrote this down in a bit more detail: https://gist.github.com/mathiasbynens/1c320ad5cc2361bf2bfc32c5b903b2dc I *think* proposal 2 resolves all our concerns [03:12:36.0000] proposal 3* [05:11:34.0000] moved it here: https://github.com/tc39/ecma262/pull/1869#issuecomment-607207764 [06:29:57.0000] Bakkot: the last slide claims that a code point interpretation for `/(?<\u{1d49c}>.)/` benefits tooling... how do you figure that? [06:33:33.0000] why can't we allow surrogate pairs to be moved to Identifier grammar outside RegExp as a 4th approach [06:34:13.0000] it would increase symmetry it seems to the same level as other ideas *and* allow surrogate pairs in named capture group ids [07:38:15.0000] bradleymeck: agreed, that's an option too. personally i don't think exposing surrogates in more places is desirable [07:40:56.0000] mathiasbynens: undesirable or unacceptable? [07:41:45.0000] I think compromise is fine and doubt the impact of allowing surrogates as binding identifiers to be serious in real world, but it would make things very consistent across contexts [07:42:59.0000] another way to put it: if it is possible in *some* situations, but not in *all* situations. is there good reason to keep inconsistency [07:44:04.0000] bradleymeck: several ES2015 features worked to remove the need for surrogates [07:44:21.0000] mathiasbynens: the need, not the capability to use [07:44:37.0000] bradleymeck: sure, because of back-compat. we would if we could [07:46:04.0000] mathiasbynens: I mean... thats kind of the ASI argument of some people, but we still go out of our way to support it when possible [07:46:08.0000] bradleymeck: this is like proposing to make some newer ES2020 APIs return `NaN` instead of throwing exceptions [07:46:36.0000] mathiasbynens: no, it is not. NaN has actively harmful / bug introducing effects historically [07:46:47.0000] bradleymeck: and surrogates do not? [07:46:50.0000] how is allowing surrogates introducing bugs [07:47:03.0000] aesthetics are bad, I'd agree [07:47:27.0000] surrogates are a common source of security issues [07:47:53.0000] i'm talking about surrogates in general, not specifically this allow-escaped-surrogates-in-identifiers thing [07:48:18.0000] then give that angle as a reason for wanting inconsistency [07:48:31.0000] right now it hasn't been brought up as a reason to want inconsistency [07:48:44.0000] that seems a good reason [07:49:01.0000] just as ascii source text is a good reason to allow things [07:49:24.0000] to be fair, I wasn't expecting this to be controversial and was assuming it to be widely known [07:49:41.0000] surrogates are an objectively bad thing [07:49:45.0000] i get that we're stuck with them in JS [07:49:46.0000] mathiasbynens: I've personally not had this issue come across my work [07:49:58.0000] so, thats probably similar for others [07:50:29.0000] we don't manually write the pairs though generally at work [07:50:52.0000] bradleymeck: for example, you used to be able to crash-and-reboot-loop any socket.io server simply by sending it a JSON payload containing a lone surrogate [07:51:29.0000] sure, but thats a different vector i'd think [07:51:43.0000] lone surrogates are invalid characters, and cannot be represented in UTF-8 (that's why WTF-8 is a thing) [07:51:52.0000] to my knowledge, the id in the capture group could not be a lone surrogate [07:52:13.0000] and even with \u{ you could send a lone surrogate on a truncated packet to socket.io [07:52:19.0000] it cannot. i'm explaining why surrogates are a Bad Thing we should avoid whenever we can in general [07:52:22.0000] (if you do something like send the JSON of a groups obj) [07:52:54.0000] oh, i'm just talking about surrogates in general [07:52:55.0000] mathiasbynens: if the grammar does not allow the problem you describe of lone surrogates, is it applicable here [07:53:11.0000] bradleymeck: there's nothing about \uXXXX\uXXXX that is somehow worse than what's already there in the language [07:53:37.0000] i'm just saying... this is a known bad thing. ES2015 worked hard to hide it as much as possible from users. [07:53:38.0000] any split character would be problematic from my understanding of the socket.io problem (which I have encoutered!) [07:54:00.0000] bradleymeck: yes, split/truncation is a common way to hit this indeed [07:54:06.0000] we still prevent split characters in the grammar [07:54:19.0000] yes, i get that [07:54:24.0000] so, I'm unclear on how any ban actually removes a problem [07:54:29.0000] again i'm not talking about this particular change [07:54:31.0000] the problem doesn't exist [07:54:50.0000] i'm not claiming it removes a problem, i'm claiming it's a better solution than the alternatives [07:55:05.0000] because we can get there without exposing surrogates (a Bad Thing!) in more places [07:55:25.0000] we are still introducing the split character problem in that location in your solution [07:55:38.0000] i don't see how your solution is any better at a glance given your concern of security [07:55:40.0000] how? [07:55:59.0000] \u{ can still produce characters that split when serialized and are sent over the wire [07:56:07.0000] that is the concern of socket.io above [07:56:08.0000] no, nothing about this change involves security. surrogates in general are tricky security-wise. there's nothing special about this one new change [07:56:30.0000] so, if you allow \u{ you have the same issue as \u\u [07:57:14.0000] so, if they have the same issue, why are you against \u\u in this context [07:57:56.0000] we have a choice here. one option exposes the idea of surrogates to the user in syntax, the other doesn't. [07:58:24.0000] yes, but people are claiming that inconsistency with existing features is problematic [07:58:40.0000] how is my proposal 3 inconsistent with any existing feature? [07:59:31.0000] it's consistent with the ES2015 `u` flag, and the \u{...} it enables [07:59:44.0000] mathiasbynens: per waldemar's view the (?.) id is a string->identifier, this leads to thinking that (?.)id should function the same for some `id` [08:00:06.0000] having id do things in 2 different parts is the crux of the complaint of inconsistency [08:00:23.0000] while it is arguable we do want inconsitency [08:00:30.0000] i have not seen why in this context [08:01:19.0000] not sure i understood that correctly, but let me try [08:01:43.0000] in ES2015, the `u` flag by design enables `\u{...}` syntax. in non-`u`, `\u` just means `u`, and so `\u{` means `u{` etc. [08:02:33.0000] following that logic, it seems reasonable to restrict the use of \u{...} within a capture group names to `u` regexps as well [08:03:19.0000] the mental model then remains what is has been since ES2015: the `u` flag enables `\u{...}` syntax throughout the pattern [08:04:09.0000] however, the counterpoint is that for non-`u` regular expressions you could make any given source text of a regexp into ASCII previously [08:04:57.0000] waldemar's view that "regexps should be like strings" can never be reached, because \u{...} works in all strings but not in regexps unless they have the `u` flag [08:05:10.0000] bradleymeck: you can still do that with proposal 3 [08:05:14.0000] even if `u` enables `\u{`, that has been broken and the question is how to alleviate that. a set of constraints has been asserted that it must function the same inside capture groups as outside, and that it must allow ascii representation of astral characters [08:05:41.0000] mathiasbynens: you can, but not under the constraints that keep being requested [08:06:12.0000] we need to identify which constraints we want to keep; we do not need to assert that there is one obvious solution [08:06:13.0000] bradleymeck: i don't see why not? [08:06:58.0000] astral identifier symbols do not work in group names within non-`u` regexps, whether used directly or through escape sequences [08:07:30.0000] if setting the `u` flag enables their use, that again fits nicely with the ES2015 `u` flag [08:07:51.0000] because it enables astral support in various regexp pattern contexts [08:08:07.0000] mathiasbynens: /(?astral)/ currently does not behave similar to /(?<\u{}>\u{})/ or /(?<\u\u>\u\u)/, the constraint is that the name should behave the same in both places and allow astral group names [08:08:24.0000] mathiasbynens: this is not about stating that `u` enables things [08:08:41.0000] that doesn't relate to the goals [08:08:45.0000] bradleymeck: where does this constraint come from? [08:09:09.0000] why would you expect astral symbols within a non-u regexp to work? they don't work in any other context? [08:09:12.0000] mathiasbynens: waldemar's desire to have an asciifier that is context free within a regexp source text [08:09:45.0000] i included asciified output for proposal 3 [08:09:51.0000] mathiasbynens: they work if they aren't escaped [08:10:07.0000] mathiasbynens: but it breaks the same behavior desire [08:10:37.0000] there isn't a desire for all things to behave the same, but for there to be some way that does behave the same [08:11:05.0000] bradleymeck: what makes you say "they work if they aren't escaped"? the current spec? implementation reality? [08:12:45.0000] as i said in the proposal, engines don't support `/(?<𐊧>.)/` (although adding `u` makes it work, as you'd expect) [08:13:35.0000] so asciifiers don't even have to worry about this case. the transform I described takes care of it and preserves the early syntaxerror [08:15:28.0000] mathiasbynens: the concern is /\ud835\udc9c/.test('𝒜') does produce an astral character [08:15:45.0000] so inside the capture group id it doesn't behave the same [08:16:13.0000] i'm having to re-read various slides and things so sorry if my responses get more spaced out (probably good though as this seems somewhat heated) [08:16:47.0000] so, enabling pairs means pairs are always reliable [08:16:55.0000] we cannot make \u{ always reliable due to history [08:17:57.0000] given all of these requests, I don't see a clear argument against allowing these. we can regret the situation, but i don't see a firm reason it makes things worse than status quo [08:19:36.0000] stating that we don't want to allow astral character in non-`u` seems an odd stance [08:20:09.0000] so if we do want to allow them, the desire for what we support is the question [08:20:32.0000] bradleymeck: why? that's literally how non-`u` regexps behave w.r.t. astral symbols [08:20:38.0000] we can support only \u{ which means an inconsistency, we could only support \u\u which is legacy, or we could support both [08:21:43.0000] there is no expectation that astral symbols, anywhere in a pattern, behave intuitively in non-`u` regexps [08:21:58.0000] that's part of the reason the `u` flag was added, so we could fix those things [08:21:59.0000] mathiasbynens: that is not the opinion of all people involved [08:22:08.0000] so it isn't something we can assert [08:22:21.0000] this is fact :/ [08:22:22.0000] this is ECMAScript history [08:22:25.0000] this is ES2015 [08:22:52.0000] it is not the opinion of all people involved, change their minds or document that expectation so that forward moving PRs like this can reference it [08:23:14.0000] we can actively debate the history here which is an issue in itself [08:23:30.0000] i'm less interested in the history debate [08:23:59.0000] i didn't expect it to be a debate tbh [08:24:30.0000] bradleymeck: thanks for helping me understand this! [08:24:50.0000] mathiasbynens: either way, add a spec note about your intent in a separate PR and it might help us in the future [08:26:46.0000] here's a list of places where astral symbols don't work as expected in non-`u` regexps: https://mathiasbynens.be/notes/es6-unicode-regex the ES2015 `u` flag fixed astral support in `.`, quantifiers, character classes, character class escapes [08:27:27.0000] astral symbol support is known to be missing in non-`u` [08:28:37.0000] expecting them to work within non-`u` named groups does not match this [08:52:45.0000] bradleymeck: tried to clarify by posting https://github.com/tc39/ecma262/pull/1869#issuecomment-607332117 [09:04:34.0000] Bakkot: what do you mean by "another"? I don't understand which other requirements are not met [09:04:37.0000] https://github.com/tc39/ecma262/pull/1869#issuecomment-607335146 [09:06:12.0000] mathiasbynens "another" meaning "I think we should not make life harder for chinese-language users" [09:06:21.0000] this, I admit, was not a previously raised requirement [09:06:28.0000] I just think it ought to be important [09:07:59.0000] gibson042: you're right that allowing `\u{}` in group names in non-u regexes does not make tooling all that much easier. but it has the advantage of allowing people who do, for some reason, need to escape their non-ascii characters in the group name to do so without having to think about surrogate pairs [09:08:00.0000] things are already broken in non-`u` though, that's why `u` was introduced. we cannot fix non-`u` behavior [09:08:05.0000] and I see very little cost to allowing it [09:08:41.0000] mathiasbynens: yes, but we don't need to make it _more_ broken. the regex behavior itself we cannot fix, but we can avoid breaking how names in regexes work. [09:09:08.0000] which are more about what the language allows you to write than about how it works. [09:10:02.0000] it's already this broken in reality [09:10:07.0000] a user who knows that non-u regexes match one code unit at a time could still easily be surprised that named capture group names, which have nothing to do with how the regex behaves, also have this sharp edge [09:10:23.0000] yes, I agree it is already this broken in reality, I just think we ought to regard that as unacceptable [09:12:05.0000] non-`u` is unacceptable tbqh [09:12:10.0000] meh [09:12:15.0000] people will continue using it forever [09:12:18.0000] even me [09:12:36.0000] I use regexes to process non-textual data stored as a sequence of 16-bit values [09:12:44.0000] I realize this makes me a bad person but you can't stop me, nyah nyah [09:13:02.0000] what's up with "regexen" btw? been meaning to ask since i saw the slides [09:13:08.0000] old habit [09:13:21.0000] one ox, two oxen; one regex, two regexen [09:13:30.0000] ooh TIL [09:14:00.0000] (ox -> oxen is one of english's many atypical pluralizations and does not actually generalize to this case, I just think it's funny) [09:33:40.0000] gibson042: actually, allowing `\u{}` in group names in non-u regexes does make tooling easier in that a more sophisticated tool, which parses and serializes the regex, can serialize group names using an off the shelf identifier name serializer. yes, it could also serialize them in a different way, but why require that of them? [09:50:53.0000] mathiasbynens: If the committee's position is that `\uLEAD\uTRAIL` in u-mode regexes has already achieved consensus and is therefore not up for revisiting here, are you then OK with my "just allow all the escapes" proposal as the next best thing? or would you have another preference? [09:51:24.0000] that doesn't save anything because the tool would _already_ need that "different way" for astral characters in the rest of the regex [09:53:05.0000] it's not that they'd have to implement the other behavior as well, it's that they'd have to realize they needed to use it [09:56:02.0000] what's gained by asciifying `/(?<𝒜>𝒜)/` to `/(?<\u{1d49c}>\ud835\udc9c)/` rather than `/(?<\ud835\udc9c>\ud835\udc9c)/`? [09:58:51.0000] what's gained is that the tool does not have to realize it needs to use different behavior for this identifier as it does for other identifiers, and is therefore less likely to have a bug which could cause websites to break. [09:58:53.0000] Bakkot: wait when did this achieve consensus? [09:59:04.0000] mathiasbynens when we accepted the current spec text. [09:59:16.0000] mathiasbynens I realize you don't regard that as having achieved consensus, but other people do. [09:59:22.0000] is that regex valid or not defined [09:59:32.0000] the one without the escapes [09:59:39.0000] devsnek WHO KNOWS [09:59:41.0000] I would say valid [09:59:47.0000] in the spec [09:59:47.0000] mathiasbynens would say not, and that it should not be [09:59:54.0000] depends who you ask [09:59:56.0000] Bakkot: I don't mind \uLEAD\uTRAIL within named groups as much tbh, I do think we should not add this in more places [10:00:03.0000] like in generic identifiers [10:00:13.0000] I would say definitely valid despite a slight underspecification [10:00:48.0000] Bakkot: and as you know, i'd prefer if we didn't have it, for symmetry [10:01:00.0000] what's happens if I run the spec through a magic program that generates a js implementation [10:01:11.0000] devsnek: engine262 [10:01:22.0000] lol [10:01:26.0000] pretty sure _you_'re the compiler [10:01:29.0000] devsnek: that program fails because the spec makes reference to an operation which is not defined [10:01:39.0000] fun [10:02:31.0000] so the question is what would it do if it were defined [10:02:44.0000] yeah [10:02:46.0000] in that case i'd ask [10:02:56.0000] why we would want /(?<𝒜>𝒜)/ to be valid [10:03:06.0000] `let 𝒜` is valid [10:03:19.0000] Bakkot: also generally i'm more interested in what implementation reality says than what a buggy spec says. ideally we'd align the spec with reality [10:03:36.0000] but the main reason is that we actually want `let 𨭎` to be valid [10:03:44.0000] mathiasbynens that would mean allowing \uLEAD\uTRAIL in u-mode regexes [10:04:18.0000] devsnek: or rather, I want `/(?<𨭎>.)/ to be valid, though mathiasbynens does not [10:04:50.0000] if we can't agree that it should just be identifier everywhere i'd say we should do whatever makes the most sense for +U regex [10:05:07.0000] Bakkot: "that would mean allowing \uLEAD\uTRAIL in u-mode regexes" yeah, see my answer above [10:05:08.0000] "the tool does not have to realize it needs to use different behavior for this identifier as it does for other identifiers" but it must process the regex to even _know_ that it's looking at an identifier [10:05:13.0000] devsnek you're coming into this after, like, twelve hours of argument [10:05:16.0000] which is not required in the other case [10:05:16.0000] yeah i know [10:05:26.0000] gibson042 right, but maybe it does; some tools do [10:05:42.0000] tools which don't can continue not doing so [10:05:50.0000] because \uLEAD\uTRAIL is legal [10:05:51.0000] in my proposal [10:06:11.0000] in what sense is it a benefit to not use functionality that must necessarily be present? [10:07:39.0000] it is a benefit to websites when webpages work. webpages are more likely to work when tooling has fewer bugs. tools are less likely to have bugs if they don't have to realize that they are required to use one particular plausible strategy rather than another plausible strategy. [10:08:08.0000] even though those tools might already have both strategies _implemented_, they still have to realize they need to use one or the other. [10:08:43.0000] my preference, given that the cost to users of allowing both is very, very small, is to make it so they do not have to realize this, so that tools are less likely to have bugs. [10:08:44.0000] it's dangerous to use \u{ because that won't work throughout the regex [10:09:14.0000] any tool that uses that for group names seems more likely to use it for match characters, where it will cause bugs [10:09:15.0000] yes but if they have parsed the regex and are now serializing it, they might plausibly reach for their already-on-hand identifier serializer for the group name in particular. [10:09:38.0000] but I think I get you now, thank you [10:12:10.0000] Bakkot: \uLEAD\uTRAIL does not need to be legal to get the tooling property you desire, right? [10:12:54.0000] well with "proposal 3" at least [10:12:56.0000] mathiasbynens there is another tooling property I desire, which is that tools which do _not_ parse regexes are _also_ less likely to have bugs [10:13:04.0000] with proposal 3, yes [10:13:08.0000] Bakkot: yes, without parsing/tokenizing [10:13:24.0000] Within any regular expression literal with the u flag, escape any astral symbol as \u{…} regardless of the context. [10:13:24.0000] Within any regular expression literal without the u flag, escape any astral symbol as \uXXXX regardless of the context. [10:14:10.0000] it sounds like proposal 3 is _really_ close to what you want [10:14:10.0000] yes; my objection to proposal 3 is that extending weird limitations to on chinese users who are not even using escapes is bad [10:14:22.0000] I hold that preference more strongly than any other I have expressed [10:14:28.0000] oh right the new goalpost [10:14:31.0000] yup, sorry [10:14:32.0000] weird that it didn't come up before then [10:14:40.0000] didn't realize this was a point there was any disagreement on [10:14:47.0000] no one had previously proposed something which would violate it [10:14:47.0000] Can we move this to #tc39? [10:15:09.0000] I did not imagine anyone else would fail to hold this preference [10:15:13.0000] I imagibe there will be talk of Records and Tuples [10:15:17.0000] sure [10:15:23.0000] Thanks! [10:15:27.0000] I wish Norbert Lindenberg was here [10:16:03.0000] does one RefCollection suffice across the board? [10:16:53.0000] I mean I guess it would have to, never mind [10:17:41.0000] ooohhh lenses/prisms? :-) [10:18:44.0000] seems like epicycles to me... [10:19:14.0000] oh, this is not what I was expecting [10:20:11.0000] let's take questions on the queue [10:20:42.0000] `{ …record, fieldToDelete: undefined`? [10:20:47.0000] `{ …record, fieldToDelete: undefined }`? [10:21:14.0000] i'm confused, is this "update" also introducing 2 new stage 0 proposals? [10:21:41.0000] ljharb: There's no process for introducing/promoting proposals to Stage 0; they're sort of already at Stage 0 by virtue of having interested champions, right? [10:22:05.0000] littledan: by convention, stage 0 proposals get presented to the committee [10:22:18.0000] 🙃 [10:22:21.0000] these weren't linked from the agenda, and the title implied nothing but an "update", which doesn't require review in advance [10:22:23.0000] we could consider them pre-Stage 0 then; I was unaware of that convention [10:22:40.0000] ljharb: i have a list of reasons that refcollection shouldn't exist here so it might not be a problem [10:22:54.0000] littledan: i'm saying that dropping a bomb of 2 new proposals, without adequate notice, means that people have not had any time to review them before we're expected to discuss themn [10:23:05.0000] totally unrelated to stage entry requirements [10:23:22.0000] and both of these seem large enough to warrant their own discussion and timebox [10:23:32.0000] I dont' think they're really introducing them now [10:23:39.0000] alluding to them is doing that [10:23:40.0000] They're just pairing down the initial proposal [10:23:49.0000] is it OK to call for feedback on something asynchronously and present it at another meeting for further discussion? [10:23:56.0000] "We removed this part to simplify" [10:24:03.0000] … maybe i'm also confused, are either of these two capabilities something that was actually part of "records and tuples" in the first place? [10:24:09.0000] they seem like new things since the last time it was presented [10:24:21.0000] these haven't been part of any version of the proposal that was presented to the committee [10:24:21.0000] obv if it's just factoring things out, then my concern doesn't apply [10:24:23.0000] ok [10:24:25.0000] so they're new things [10:24:28.0000] not paring down records and tuples [10:24:53.0000] Spread was in the Oct meeting [10:25:02.0000] `RefCollection` is new [10:25:03.0000] do you mean `with`? [10:25:07.0000] basic spread sure, but not that lens things [10:25:10.0000] Ahh, that's what it was. [10:25:12.0000] in this case, I was mistaken [10:25:31.0000] The "how do I mutate a record" was part of the Oct meeting [10:25:36.0000] right, sorry [10:26:22.0000] btw you can put a new topic if you're not replying to a thing we're currently discussing due to a TCQ item [10:26:28.0000] how to mutate a record. Maybe `record = #{ ...record, foo: record.foo + 1 }`? [10:26:44.0000] rbuckton: Yes, that's possible with this proposal [10:26:48.0000] (without any of the follow-ons [10:27:37.0000] (imo it wouldn't make any sense if that wasn't possible in this proposal directly) [10:27:43.0000] presumably Mark is referring to destructuring [10:27:44.0000] ? [10:28:05.0000] mark is talking about destructuring, i believe [10:28:22.0000] should clarify [10:28:25.0000] ie `const { a, …rest } = #{ a: 1, b: 2 }` produces a `rest` non-record object [10:29:05.0000] With pattern matching, something like `when (#{ a, …rest}) -> rest` might be able to return a record. [10:29:09.0000] I think that's Mark's point. [10:29:44.0000] imo that would only be possible if `const #{ a, …rest } = #{ a: 1, b: 2 }` worked [10:29:49.0000] maybe add it in that another stage 0 proposal `#{...rec, delete x.y.z}` [10:29:50.0000] s/would/should [10:30:49.0000] shu: RefCollection does seem to be polyfillable, yes [10:30:57.0000] to your userland question [10:31:14.0000] no, RefCollection is not polyfillable [10:31:30.0000] littledan: is it not essentially a WeakMap? [10:31:31.0000] a core part of it is that it's possible to "garbage collect" unreachable symbols [10:31:34.0000] with some additional methods? [10:31:42.0000] it cannot be expressed by a WeakMap, since WeakMaps cannot have symbol keys [10:31:51.0000] benjamn: WeakMap strongly holds its values [10:31:52.0000] jackworks25: I have a proposal for `{ a, x.y.z }`(meaning `{ a, z: x.y.z }`) that I need to get back to at some point. [10:31:53.0000] but, the keys need to be symbols, not objects, so that they can be contained in a Record or Tuple [10:31:59.0000] but it would only need _object_ keys [10:32:02.0000] ljharb: That's not relevant, since what we're looking for here is symbol keys [10:32:05.0000] symbols would be the value [10:32:15.0000] symbols don't have well defined gc semantics [10:32:20.0000] this issue came up with symbols as weakmap keys [10:32:31.0000] I don't see how to do that. I think we need a mapping from symbols. [10:32:42.0000] we need a bidirectional weak mapping, really [10:32:54.0000] littledan: that's only true because of the deref method, right? [10:33:13.0000] if the mapping was not reversible, we wouldn't need symbol keys? [10:33:23.0000] I have another drafting proposal might also need the help from RefCollection, actually it (my drafting proposal) also use Symbol to refer to internal objects [10:33:42.0000] sure, you could say in general, "if we didn't need to query a datastructure, just add to it, then we could simplify its representation" [10:33:47.0000] rbuckton: is there a draft, I was working on a proposal on similar lines :) [10:33:49.0000] littledan: i'm confused [10:34:08.0000] littledan: the example i saw was mapping function to a symbol [10:34:09.0000] if you want to associate a unique unforgeable symbol with any object reference, you can use a WeakMap [10:34:10.0000] Michał Wadas or Sathya Gunasekaran in here? [10:34:24.0000] shu: You need to be able to dereference the symbol and get the function again [10:34:37.0000] > You need to be able to dereference the symbol and get the function again [10:34:49.0000] that's something we could debate [10:35:03.0000] howdoi: I presented it a few years back: https://github.com/rbuckton/proposal-shorthand-improvements, but it wasn't taken for stage 1. [10:35:19.0000] arguably, if you can turn the symbol back into the original object, then the record/tuple isn't really immutable, because it still logically contains the objects [10:35:21.0000] benjamn: If you have another idea for how to meet this use case, it'd be great to discuss in an issue in the RefCollections repo [10:35:34.0000] let's listen to devsnek on this (talking now0 [10:35:40.0000] I don't understand that argument... the mutable stuff is all contained in the RefCollection [10:35:41.0000] rbuckton: oh yeah! I recall seeing this. [10:36:08.0000] What was the reason it wasn't taken for stage-1? [10:36:41.0000] RefCollection will not work very well when passing throughout a membrane it seems! [10:36:46.0000] howdoi: IIRC, some concerns about the value of the feature and some issues with runtime semantics. [10:36:59.0000] I believe that should be implemented in user-land [10:37:00.0000] caridy: I think it should work well with membranes--the membrane can wrap the RefCollection itself, mediating any dereferencing of symbols [10:37:09.0000] oh, okies... [10:37:11.0000] howdoi: I based it off of C#'s similar feature `new { a, x.y.z }`. [10:37:11.0000] we cannot implement RefCollection in userland, unfortunately [10:38:27.0000] rbuckton: hoping that we will get more consensus sooner. [10:38:47.0000] @littledan, can you provide more details on how the membrane will handle a r/t with a refCollection on it? [10:38:59.0000] Wasn't there a proposal for a `Symbol` static method that could create a symbol for a set of objects which would be similar to `RefCollection`? [10:39:19.0000] how would the membrane get the RefCollection? [10:39:33.0000] seems like it would only see output from it in most cases [10:39:43.0000] well, how would the other side of the membrane get the RefCollection? [10:39:50.0000] presumably that access would be mediated by the membrane [10:40:07.0000] rbuckton: compositeKey [10:40:12.0000] That's the one. [10:40:13.0000] the foremost problem is that the idea of collecting symbols is not something that all implementations inherently have [10:40:30.0000] Do any? [10:40:35.0000] most do [10:40:43.0000] because they're just heap objects [10:40:52.0000] but you can also implement them as immediate values [10:41:02.0000] you can go look at the symbols as weakmap keys issue for more info [10:41:40.0000] under this limitation, refcollections are a permanent leak [10:41:42.0000] well, implementations are allowed to leak everything, sure [10:41:56.0000] that's not a very good language design though [10:42:00.0000] the unique thing about symbols is that they give identity while being a primitive [10:42:05.0000] "sucks if your implementation isn't how v8 does it" [10:42:09.0000] does someone have the link to refcollection? [10:42:18.0000] `record.with({ x: { y: { z: 1 } } })`? [10:42:18.0000] shu: https://github.com/rricard/proposal-refcollection [10:42:27.0000] RefCollection is just a `Map`, though [10:42:28.0000] https://github.com/rricard/proposal-refcollection [10:42:35.0000] Why couldn't the entire thing be reclaimed at once? [10:42:43.0000] note, this readme is relatively early, still iterating on elaborating the explanations [10:43:24.0000] it seems like RefCollection is a WeakMap that allows Symbol keys [10:43:58.0000] and maybe also other primitives [10:44:25.0000] It's just a `Map` [10:45:42.0000] and a not removable Map [10:46:09.0000] ReadonlyWeakMap<*, >? [10:46:11.0000] What do you mean by removable map? [10:46:13.0000] Ohh [10:46:28.0000] A ReadOnly Map, yes. [10:46:34.0000] Also not changeable [10:47:21.0000] drousso: That was answered earlier in the presentation [10:47:29.0000] oh? [10:47:41.0000] i came in late 😅 [10:47:42.0000] Since ReadOnly Collections don't propose a array or object, they don't overlap [10:48:11.0000] It seems like RefCollection could build on a ReadOnlyMap, per above [10:48:12.0000] the readonly collections proposal states "all EcmaScript enumerable collections" [10:48:42.0000] which I read as including tuples for sure, and possibly records [10:49:22.0000] Neither is a collection [10:49:36.0000] Though I understand the confusion [10:49:46.0000] benjamn makes a good point [10:50:13.0000] Don't we already have significant runtime experience already? [10:50:20.0000] Immer and Immutable.js, etc [10:53:19.0000] the idea of both of those proposals existing separately doesn't seem good to me either [10:53:32.0000] (readonly collections, I mean) [10:53:45.0000] but separate development and syncing later might be good? [10:54:06.0000] unless I'm confused about goals somehow. it was sort of stated as if obvious [10:55:27.0000] it's odd to me that a `Map` can create a readonly snapshot, but that an `Object` can't [10:55:51.0000] err, well it could if the proposal is approved 😅 [10:56:09.0000] isn't that Object.freeze? [10:56:12.0000] ^ [10:56:35.0000] doesn't that modify the object itself though? [10:56:40.0000] not create a readonly view? [10:56:48.0000] err, not "modify" but "freeze" [10:57:18.0000] drousso: wait, how can you make a read only map? [10:57:26.0000] all Maps and Sets are unstoppably mutable [10:57:26.0000] (oh never mind, this readonly collections proposal is way different than the title suggested) [10:57:29.0000] https://github.com/tc39/proposal-readonly-collections [10:57:31.0000] ah in the proposal [10:57:32.0000] yes [10:57:40.0000] kk [10:58:27.0000] drousso: `Object.freeze(Object.create(Object.getOwnPropertyDescriptors(obj), Object.getPrototypeOf(obj)))` [10:58:52.0000] that's just as much a read only snapshot of an object as FixedMap eg would give [11:00:07.0000] rickbutton: you should change your abbreviation from RBU to BTN ;) [11:00:18.0000] that is such a good idea [11:00:20.0000] totally gonna do that [11:02:49.0000] thats a readonly snapshot not but doesn't readonly proposal do a view? [11:05:18.0000] In the slice syntax proposal I proposed adding an `Interval` type (similar to C#'s `Range` type) that could encapsulate a range and would be iterable. [11:05:38.0000] bradleymeck: ah maybe it also has a view, sure [11:05:44.0000] someone is echoing and should mute [11:05:57.0000] jack is echoing [11:06:35.0000] the meeting host should be able to mute if needed [11:08:21.0000] https://github.com/Jack-Works/proposal-Number.range/issues/17 [11:08:58.0000] mpcsh: does it not already mean [0, 10) ? [11:09:10.0000] ljharb: last entry on the slide [11:09:15.0000] mpcsh: ah ty [11:11:18.0000] for reuse, you can also prepend `() =>` [11:11:25.0000] ^ [11:11:28.0000] ie `() => Number.range(x, y)` is infinitely reusable [11:22:39.0000] haxjs: would you like to update your acronym / registered name for the notes? if so, here's where to change: https://github.com/tc39/notes/blob/master/delegates.txt#L145 [11:26:54.0000] haxjs can you add a link for these slides to the agenda please? [11:34:02.0000] ystartsev: this proposal does have a repo, it just wasn't linked [11:34:16.0000] ljharb: fair [11:34:23.0000] i looked for it but didn't find it [11:34:53.0000] in general, objecting based on a lack of materials is a stage 2+ thing [11:35:13.0000] because stage 1 is about exploring a problem, and historically we haven't felt advance materials were required to illustrate a problem [11:35:48.0000] so i don't have a strong opinion on that, but i think this conversation could be a lot better had those materials been present [11:36:11.0000] also if i remember correctly there were issues with this last time and it didn't reach stage 1? [11:36:16.0000] i agree with that for sure [11:36:41.0000] ystartsev: correct [11:37:02.0000] was this the proposal that got rejected? [11:37:06.0000] shu: i think it'd be like, `Promise.resolve` would expect a `this` argument, so it could throw a better error message if none was provided [11:37:09.0000] there were two very similar ones IIRC [11:37:11.0000] Yah, the requirement to patch every platform feature to add the check makes this difficult to accept for me. [11:37:16.0000] rkirsling: not rejected, but no consensus for stage 1 [11:37:21.0000] I'm not sure if this should be #tc39-delegates or #temporaldeadzone, as I'm on the fence as to how serious I am about this, but: `"use strict this"`? [11:37:21.0000] I thought the "explicit `this` param" got rejected [11:37:28.0000] rkirsling: that's a different one [11:37:32.0000] err yeah sorry, rejected is the wrong word [11:37:37.0000] yeah I know [11:38:28.0000] i guess we could set a flag for every function? [11:38:47.0000] notes say for "this reflection", https://github.com/tc39/notes/blob/master/meetings/2020-02/february-6.md#conclusion-3 "waiting for additional clarification of intent of proposal and renaming explainer." [11:39:11.0000] ystartsev: the proposal last meeting was an own data property, initially populated by the presence of `this` in a non-arrow function body [11:39:16.0000] ljharb: thanks [11:41:35.0000] it isn't clear to me -- will this throw if a function called from a function has a this requirement? [11:41:38.0000] can think an explicit `this` to be a syntax sugar to `if (this === undefined) throw TypeError()` 🤔 [11:41:54.0000] shu: consider `function foo() { return () => this; }` [11:42:09.0000] for example `function foo() { bar()}` `function bar() { this + 1)` [11:42:12.0000] ystartsev: i believe it'd be, code could decide to throw if given the wrong "this-accepting" kind of function [11:42:17.0000] and we are only checking foo? [11:42:18.0000] `foo` has a `ThisRequired`, but the arrow it returns does not. [11:42:22.0000] I think it's like, if I'm a library, and I'm getting a callback, I can query the callback to see if it expects a this, and if I don't intend to give it one I can throw a nice error? [11:42:22.0000] very important to note is that nothing about foo implies it is supposed to be given a this value [11:42:29.0000] it could be called `getFunctionThatReturnsUndefined` [11:42:44.0000] exactly what bterlson said, i think [11:42:52.0000] remaining questions https://snaps.akibraun.com/6qaoe.jpg [11:43:07.0000] js is a dynamic language, validation of arguments is dynamic [11:43:18.0000] if you expect a this value you should validate it, not make someone else do it [11:43:21.0000] bterlson: that is a question about programmer intent, not syntactic presence of something that gives you the receiver [11:43:36.0000] for example if you do Map.prototype.set.call(5) [11:43:43.0000] like if your code has an if (rareCondition) { doSomething(this) }, now it's an error? [11:43:51.0000] ^ [11:44:13.0000] the proposla isn't that we do any error throwing [11:44:16.0000] in the language [11:44:21.0000] as far as I understand it [11:44:27.0000] the proposal exposes something that you can't make any decision from [11:44:30.0000] i think the user has to throw themselves [11:44:32.0000] functions can optionally use `this` tho [11:44:34.0000] right, but the only motivating use i saw was to check it and throw [11:44:38.0000] given the information "this function syntactically contains this" [11:44:40.0000] i can make no decision [11:44:45.0000] about whether the function should be given this [11:44:49.0000] and i don't think that is a useful reflection to make a decision on, right [11:44:55.0000] ^ +1 [11:45:07.0000] the function could be using `this` to throw if this is not undefined [11:45:18.0000] which brings me back to "the function itself should validate its this value" [11:45:28.0000] right, if I decided to throw as a library author if a user gives me a callback that references `this`, I would be making the choice to throw on functions with work with or without this [11:45:40.0000] yeah i would also agree with that... it seems like something that should be done by the author [11:45:41.0000] The issue is that by the time the function is invoked, we've lost the location of where the function was passed. [11:45:43.0000] FWIW I am not arguing in favor of this proposal, merely explaining my understanding [11:45:50.0000] `addEventLister` being the prime example [11:46:19.0000] https://github.com/tc39/proposal-hashbang/issues/18 [11:46:20.0000] I can pass a cb that requires a `this`, and by the time the event listener fires, I now have to track down where I forgot to bind the cb. [11:46:30.0000] rwaldron: to be fair, i have one on the agenda for today :-p [11:46:39.0000] if the contract your framework's higher order functions should or should not expect to be called with a receiver, then that's up to the framework imo [11:47:16.0000] rwaldron: also, private methods was on top of private fields [11:47:16.0000] jridgewell: if it's about forgetting to bind for native methods, how would you adopt this? monkeypatch all the native methods? [11:47:32.0000] i feel like a better solution would be to add a property that states whether a `this` was bound [11:47:35.0000] Yes, which I think is the biggest downside to this proposal. [11:47:40.0000] bradleymeck: hashbang is shipping everywhere, I think (whether that actually matters or not) [11:47:43.0000] shu: it is up to the framework? Frameworks query function arguments whether they create `this` references [11:47:49.0000] and decide what to do with that info [11:47:51.0000] that way, when the function is passed in, it can be checked [11:47:54.0000] rkirsling: not safari stable [11:47:55.0000] Hax's idea is, they throw [11:47:59.0000] Having to monkeypatch `addEventListener` (and every plaform API) is a huge burden [11:48:01.0000] jridgewell: i think that's just a dealbreaker [11:48:02.0000] sorry, they CAN throw [11:48:16.0000] I agree [11:48:21.0000] jridgewell why does `addEventListener` _have_ to have a `this` though? [11:48:34.0000] i add event listeners all the time where I don't want a `this` [11:48:40.0000] s/want/care about [11:48:56.0000] `class Foo { method() { this.doSomething(); } }; addEventLisener('click', foo.method)` [11:48:59.0000] ljharb the class private split was a strategic and intentional move because it was otherwise very large surface... this isn't that. [11:49:08.0000] But I see what you're saying. [11:49:27.0000] bradleymeck: even in 13.1 from last week? [11:49:33.0000] jridgewell yes, that's a valid case, but I would argue that that's the programmers error [11:49:39.0000] > i add event listeners all the time where I don't want a `this` [11:49:39.0000] If you have a `this` in your function's code, I think it's reasonable to assume that you want a `this`. [11:49:49.0000] rwaldron: agreed, as somewhat was the "in" feature being removed from the main class fields proposal [11:49:54.0000] rkirsling: at least in REPL it isn't [11:50:06.0000] i could just as validly have `addEventListener("click", function refresh() { /* do static things */ })` [11:50:06.0000] If you don't have a `this`, then the proposal wouldn't have returned `true` and the API wouldn't have thrown [11:50:18.0000] Yes, and your case is handled. [11:50:26.0000] ah i see what you mean [11:50:31.0000] `if (thisIsNeeded(cb)) { throw error }` [11:50:39.0000] bradleymeck: yeah I wouldn't expect that to work unless web inspector wants it to; lemme make a test page and check [11:50:41.0000] You `cb` doesn't need a `this`, so it doesn't throw. [11:51:08.0000] rkirsling: does it not execute as a Script? [11:51:15.0000] ljharb I just went to write almost the same topic question [11:51:20.0000] oh right I can eval [11:51:32.0000] To be clear, I don't support the proposal (due to the burden of monkey patching everyting), I just understand the desire. [11:51:34.0000] jridgewell how do you know for a fact that my callback _needs_ `this`? [11:51:36.0000] what if, make # a valid comment starter if it appears at the line start? [11:51:48.0000] jackworks92: that's what the second half of this proposal is [11:51:57.0000] oh no, please not that [11:51:59.0000] bradleymeck: eval works [11:52:15.0000] hashbang should only be allowed at byte 0 of a source text [11:52:19.0000] ^ [11:52:32.0000] `#` being a comment start creates a huge ASI for private fields [11:52:44.0000] jridgewell: queue that? [11:52:46.0000] what about UTF BOM devsnek [11:52:47.0000] I'm actually startled that devtools allows it [11:52:48.0000] jk [11:52:50.0000] The when they convert from external to inlined scripts [12:01:55.0000] fun fact: it's not even possible to inline arbitrary JS into HTML without changing its semantics [12:02:09.0000] because tagged templates and [12:02:40.0000] also Function#toString [12:02:59.0000] sure but let's please pretend that doesn't exist [12:03:11.0000] michaelficarra: tentatively yes, if haxjs is interested. bear in mind that's like 5am his time. [12:03:17.0000] 'delete Function.prototype.toString' [12:03:39.0000] It seem very hard for me to explain the problem in english :( [12:04:03.0000] (actually it's 3am) [12:04:34.0000] confession: I have used /\bthis\b/.test(Function.prototype.toString(func)) before [12:05:08.0000] jackworks92: how many hours before morning is it? because isn't all of china on the same timezone, which means some parts wake up at different times than others? [12:05:33.0000] sorry, Function.prototype.toString.call(func) [12:05:58.0000] obviously has false positives, and doesn't work for native functions [12:06:06.0000] i believe hax is in the same timezone as me, sunrise at around 6am so it's 3hrs to morning [12:06:34.0000] gotcha [12:08:21.0000] 🙈+1 hard to understand the english questions by hearing but I checkout the meeting notes, fortunately most of the questions are already discussed on github [12:14:01.0000] I recently started working on an early draft of a proposal for `struct` (as a mechanism for implementing value types). If you are interested in contributing, please send me a message. [12:16:41.0000] `struct` as value types? what different with the record proposal? [12:17:11.0000] i really want enums [12:17:17.0000] oh i guess i could propose that now [12:17:18.0000] devsnek: I'm working on that too... [12:17:26.0000] or you could [12:17:38.0000] i want like.... rust enums though [12:17:42.0000] devsnek: I have one already, planned to present it a year ago but held off due to some discussions with others on the committee. [12:17:46.0000] devsnek: there be dragons on `enum` TS already took that space and it would be hard to convince people to reuse it [12:17:56.0000] i don't care what TS did [12:18:00.0000] others do [12:18:02.0000] +1 I like the rust style enum [12:18:06.0000] 🤷🏻 it's a separate language [12:18:10.0000] rbuckton: i'm interested in something like `struct`s for shared memory and layout guarantees, was thinking of resurrecting typed objects [12:18:13.0000] they can keep using their enum until the end of time [12:18:19.0000] devsnek: not really a separate language [12:18:21.0000] devsnek: have you seen how Scala handles object-oriented pattern matching? [12:18:26.0000] devsnek: doesn't matter, if it influences people it influences people. [12:18:27.0000] rbuckton: what did you have in mind? [12:18:36.0000] rbuckton: I'd claim it is increasingly divergent [12:18:37.0000] i've never used scala [12:18:43.0000] if ts wants to keep adding things that aren't types [12:18:50.0000] i don't think we should feel constrained by it [12:18:56.0000] jackworks92: The record proposal only allows for key-value pairs. The `struct` proposal is for full-featured values with methods similar to `Number` and `BigInteger`, as a possible route for `Decimal`. [12:19:01.0000] typescript style enum is some kind of too weak, they doesn't have rust style tagged union that can contain data in it [12:19:17.0000] devsnek: that isn't the consensus though, some people do feel like accommodating TS is important. [12:19:22.0000] yeah if we just do c style enums [12:19:26.0000] that would be a loss [12:19:35.0000] oh, you're not talking about Rust enums and pattern matching [12:19:40.0000] or are you? [12:19:44.0000] jackworks92: I think what you are descirbing is the pattern matching proposal? [12:19:59.0000] the algebraic data type style enum? [12:20:01.0000] pattern matching is a good thing to use with that kind of enum [12:20:06.0000] keith_miller: yes [12:20:11.0000] but you don't need pattern matching to enjoy that kind of enum [12:20:16.0000] though its slightly harder [12:20:20.0000] keith_miller: yes [12:20:38.0000] bradleymeck: isn't that basically making ts normative without the tc39 process [12:20:55.0000] devsnek: nope, just saying the design space is occupied [12:21:02.0000] for anyone who cares, Scala lets any object implement an `unapply` method to define how it interacts with pattern matching: https://docs.scala-lang.org/tour/extractor-objects.html [12:21:02.0000] by what, i don't use ts [12:21:11.0000] unapply is neat [12:21:12.0000] jackworks92: https://github.com/tc39/proposal-pattern-matching [12:21:14.0000] shu: `struct` as a way to define user-defined value types like `Decimal`, with support for both mutable and immutable structs, copy-by-value semantics, contiguous chunks of memory, backed by ArrayBuffer or SharedArrayBuffer [12:21:15.0000] devsnek: others do, so it remains occupied [12:21:27.0000] but scala makes for very poor precedent [12:21:28.0000] for anything [12:21:29.0000] ever [12:21:35.0000] like if i said we shouldn't do something because clojurescript has it [12:21:41.0000] people would probably kill me [12:22:00.0000] now now, we'd just ignore you [12:22:01.0000] devsnek: you could do that, we can just find a new design [12:22:19.0000] devsnek: I can't tell; do you sincerely not understand where the people who place nonzero weight on TS precedent are coming from, or do you just disagree with them? [12:22:43.0000] rbuckton: let's talk. for sharing them we probably need something more performant than wrappers around SABs [12:22:49.0000] devsnek: There's nothing saying that TypeScript's enum design can't evolve. Currently its limited to a fixed set of values in its domain, meaning that there's still some room to improve/change the design. [12:22:51.0000] I mean I disagree that TS should not stop us from taking a different design [12:23:03.0000] err I disagree => I think [12:23:35.0000] ts have tagged union now but the syntax is too long, have to write normal object with a tag `{kind: 'a', data_a: number}|{kind: 'b', data: number}`. I'd like to have a simpler way of defining and writing it (like in Rust), e.g. `enum MyData { a{data_a: number}; b{data_b: number} }; const x: MyData = MyData.a({data_a: 1})` but ts won't do that [12:23:36.0000] violates ts design principle [12:23:38.0000] Bakkot: i think saying "x language that compiles to js has x so we can't occupy that space in js itself" is not acting in good faith [12:23:43.0000] rbuckton: recreating the struct wrappers on all your threads is going to going to eat a big chunk of performance you'd hope to gain from shared memory [12:23:53.0000] devsnek: "not in good faith" is an extremely serious accusation [12:23:55.0000] But the reason I haven't yet proposed `enum` is exactly this discussion. There are design decisions and questions to resolve before I feel the proposal will meet the needs of the community and the committee. [12:24:08.0000] devsnek: you can make a different enum, just not overlap the design [12:24:38.0000] rbuckton: did you see that ljharb is taking over championing pattern matching? [12:24:46.0000] shu: True. I haven't delved into that corner of the design yet. However, this is roughly analogous to every realm getting its own `Number.prototype`. [12:24:51.0000] benjamn: yes. [12:24:54.0000] Bakkot: i can't see how the argument creates productive discourse so... [12:25:10.0000] devsnek: language evolution for JS is fundamentally different from language evolution for basically any other language, because it has a level of unprecedented interop as one of its most core value props [12:25:32.0000] interop sure, but if you go through a compiler [12:25:48.0000] think about the constituencies [12:26:02.0000] like if you can just block tc39 movement because you can create something similar somewhere else [12:26:13.0000] like how people were doing Array.prototype.smoosh to stop tc39 from using it [12:26:20.0000] shu: Another part of the current `struct` draft is support for syntactic operator overloading. I'm talking with littledan about it as well. [12:26:27.0000] it's not something existing that blocks it, it's ecosystem pervasiveness [12:26:39.0000] if a delegate blocks because of it [12:26:47.0000] that's a pecularity of TC39 [12:26:52.0000] which is what was brought up above [12:27:11.0000] it is extremely not a good precedent if "TS did it therefore JS can't" becomes a thing [12:27:20.0000] but i don't think it's ever that black and white [12:27:35.0000] rbuckton made a really great point above about TS enums being able to evolve to something more like Rust enums [12:27:36.0000] i was responding to the above point that js couldn't deviate from ts enum semantics [12:27:38.0000] the first time that came up, we explicitly noted it as a one-off [12:27:42.0000] typescript is an important part of javascript ecosystem, we should avoid to break them if there is better way to do it if it is possible (like, change another keyword for the proposal) [12:27:44.0000] and then it came up a second time [12:27:51.0000] jackworks92: it doesn't break them [12:27:55.0000] with the current TS syntax continuing to work [12:27:57.0000] you have to run ts code through a compiler to get js [12:28:13.0000] its not breaking [12:28:32.0000] it's definitely not ideal for them [12:28:37.0000] 🙈 [12:28:41.0000] TS users are sometimes part of the JS ecosystem, and TS build output is. but TS itself is a different language. [12:28:58.0000] i'm willing to say they're part of the js ecosystem in more than their compiler output [12:29:03.0000] (not a superset of JS, but if anyone wants to debate that let's go to another channel) [12:29:06.0000] but if they add things that aren't types [12:29:12.0000] they should be prepared to clash with js [12:29:19.0000] i don't see how this discussion is any more productive [12:29:50.0000] shu: i was concerned about someone saying that people would likely not accept semantics that deviate from ts [12:30:02.0000] which seemed problematic in a larger sense to tc39 [12:30:03.0000] devsnek: will you start a rust style enum proposal? I'm happy to see that [12:30:06.0000] certainly nobody thinks TS compat should have no weight [12:30:19.0000] jackworks92: there's already 2 enum proposals, i'd love to see "not a third" :-p [12:30:43.0000] i would consider their design as valid in the design space but i would be very uncomfortable with the idea that we have to do enums the same as ts or not at all [12:30:45.0000] devsnek: people plainly stating their sincerely held opinions about which factors are important in JS's evolution is not bad faith even if you don't agree with them [12:30:46.0000] oh i didnt see them in the proposals list [12:31:15.0000] devsnek: If you'd like, take a look at https://github.com/rbuckton/proposal-enum and contibute to the issue tracker your thoughts about rust-style enums and perhaps we can find a way to incorporate that capability? [12:31:26.0000] Bakkot: you don't think "the same as ts or not at all" isn't a regressive pattern? [12:31:42.0000] I don't know what "a regressive pattern" means [12:31:47.0000] like [12:31:51.0000] harmful to tc39 process [12:31:54.0000] jackworks92: rbuckton's, and https://github.com/rwaldron/proposal-enum-definitions [12:32:29.0000] I don't think it's harmful to the _process_; I think it would lead to worse outcomes than a more flexible position, but that is true of any position I disagree with. one can hold that position in good faith. [12:32:46.0000] ljharb, jackworks92: rwaldron and I discussed our proposals and my current proposal is designed to mostly incorporate his (with a few exceptions). [12:32:46.0000] also no one stated that as a fully general ultimatum. [12:33:02.0000] devsnek: i feel like you're mostly arguing against a strawman [12:33:03.0000] rbuckton: that's great, i'd love to see rick's archived with a note to that effect then :-) [12:33:35.0000] shu: i suggested something about enums and was warned that people would be unlikely to choose it because ts does something else [12:33:36.0000] even web compat issues, given compelling reason we want to do something, warrant investigation into how bad the breakage is [12:33:50.0000] i've heard TS concerns brought up but never in the context of the TS way or not at all [12:33:54.0000] ljharb: Mine hasn't officially subsumed his, though I believe we were moving in that direction. [12:34:04.0000] shu: that's what i'm responding to [12:34:28.0000] also as i keep saying, it's not breakage because ts is a different language, it has a compiler [12:34:34.0000] fundamentally, if we can do a feature in a way that doesn't cause misery for millions of devs, that seems good to argue for? [12:34:36.0000] rbuckton jackworks92 confirm. [12:34:43.0000] devsnek: yes, because in this particular case people think that the breakage is not worth it, not because of a fully general "TS or not at all" ultimatum [12:34:49.0000] rbuckton: gotcha [12:34:53.0000] s/people/some people/ [12:35:02.0000] Bakkot: but there isn't breakage [12:35:08.0000] devsnek call it whatever you like [12:35:13.0000] the choice of noun here is not important [12:35:13.0000] ts can keep using its enums [12:35:19.0000] oh afterall, ts can make a breaking change or add a compiler options to switch to ES semantics [12:35:35.0000] and its not like they don't already have a bunch of flags for switching things to es semantics [12:35:39.0000] devsnek yes, but with other costs [12:35:48.0000] as a pragmatist, i'm not sure what airing an ontological disagreement on what constitutes "breakage" will help. surely not TS's product direction or their delegates' concern for their own users [12:36:00.0000] mostly to users, who know have to know about two kinds of enum [12:36:03.0000] this is a real cost. [12:36:07.0000] bringing up this cost is not bad faith. [12:36:20.0000] right, that is the primary charge for a standards body [12:36:21.0000] maybe ts should not have added enums then lol [12:36:31.0000] but they did, that is the world we live in now [12:36:34.0000] why do we have to back ourselves into this corner is my point [12:36:37.0000] devsnek: Ideally we can come up with a solution that works for everyone. In general we'll make requests if a proposal introduces a feature that could be conflicting, or introduce compiler flags to opt into the ES-specific behaviors when that's not possible (such as the Set vs Define argument re: class fields). [12:36:56.0000] there is `namespace`, `import x = expr` in ts already so it's already "3 kinds of module" need to know for ts users [12:37:23.0000] devsnek: why do we have to care about TS? we don't _have_ to. we can do whatever we want. some people do care, mostly because they foresee actual people being worse off. they are allowed to care about this. [12:37:30.0000] browsers should not have done stupid function-in-block semantics, let's break people depending on that behavior because browsers did a bad thing [12:37:37.0000] so 2 kinds of enum is okay to me [12:37:50.0000] bterlson: browsers are very different from everyone else tho [12:38:13.0000] Bakkot: i think we actually do have to :P [12:38:23.0000] Bakkot: i don't think we should care about ts more than ts cares about js [12:38:28.0000] shu it's not a requirement of our process document, is mostly what we mean to say [12:38:34.0000] Bakkot: indeed that i agree with [12:38:58.0000] devsnek sure, you are allowed to hold that position. but other people can disagree with that position in good faith. (or, also, disagree about how much TS cares about JS). [12:39:03.0000] jackworks92: I'd like to avoid two kinds of enum if we can find a way to support both in a single design. [12:39:12.0000] ts will follow the es semantics so there isn't too much things to worry about [12:39:14.0000] I guess I'm mostly just making a snarky point that it's not the typescript team that pays the price for decisions we make, mostly it's developers who do [12:39:49.0000] bterlson: that is fair [12:39:53.0000] bterlson: well, as a capitalist, i should hope the TS team will also pays the price eventually in losing users and getting defunded [12:39:54.0000] and us apparently [12:39:54.0000] bterlson: Doesn't that cut both ways though? [12:40:07.0000] rbuckton: yeah, maybe a ts (syntax level) compatible and enhanced enum is great [12:40:08.0000] bterlson: but JS users also thus pay the price for decisions the TS team makes [12:40:14.0000] ^ [12:40:34.0000] why do you think the venn diagram of JS users and TS users is not mostly a circle [12:40:42.0000] bterlson: and while that's a power/risk/responsibility tc39 members and browser makers are widely agreed to have, i don't think the wider community would imbue the TS team with that power [12:40:48.0000] shu: it very much is not, in my experience [12:40:54.0000] shu most people continue not using TS, I can tell you from experience talking to a lot of developers at, like, banks [12:40:55.0000] yep, it's how ecosystems work. We also pay the price for decisions library authors make, or browsers, or frameowrks, etc. etc. It's a giant pile of complex tradeoffs. [12:41:01.0000] fair [12:41:09.0000] but proposals aren't often blocked because lodash did it differently [12:41:11.0000] Bakkot: oh really? what's the overlap in your experience? [12:41:29.0000] i'm just not happy with the idea that i would have to use worse enums because of a language i don't even use [12:41:35.0000] (the runtime semantics of TS enum (two-way binding for int enum) is not good for me) [12:41:36.0000] Anyways, if you're interested in contributing to my draft `struct` proposal, it can be found here: https://github.com/rbuckton/proposal-struct. Its in its infancy and no where near ready to be presented (there's a lot of holes to fill in and bikeshedding to do), so nothing in the design is currently set in stone. [12:41:37.0000] i'm not angry at typescript itself [12:41:40.0000] shu: outside of large companies, i think it's much closer to "minimal overlap" than a circle. [12:41:41.0000] shu maybe 20% of JS developers at non-software enterprises are using typescript, among those I have talked to as part of my job [12:42:03.0000] ah, i see [12:42:05.0000] 75% confidence interval is like 5%-40% [12:42:12.0000] big range [12:42:22.0000] confidence intervals should be large, people are bad at guessing [12:42:50.0000] make a virus that infects js software and detects if the code is similar to ts output [12:43:06.0000] oops wrong channel [13:00:24.0000] are people able to load drive.google.com [13:00:26.0000] reminder that Zoom resets your display name if you left and came back [13:00:33.0000] devsnek: yes [13:01:06.0000] weird [13:02:13.0000] also implemented in engine262! [13:11:14.0000] Is there a way to keep freenode from kicking me out every couple hours or so? It randomly disconnects and "reconnect" just hangs it. [13:11:49.0000] wsdferdksl: are you using the web client? [13:11:54.0000] Yes [13:12:08.0000] yeah I had the same issue when I was using it last meeting, it's just broken [13:12:21.0000] there's a bunch of free IRC clients [13:12:27.0000] I recommend using one of them [13:15:43.0000] I think Mark is saying: [13:16:27.0000] ``` [13:16:27.0000] promise.then(() => console.log(1)); [13:16:27.0000] / a cleanup cannot be scheduled here [13:16:27.0000] promise.then(() => console.log(2)); [13:16:27.0000] ``` [13:16:38.0000] yep, that's true today [13:16:50.0000] and will remain true [13:17:11.0000] But is he also saying that the first and second console logs must be scheduled first and second, and cleanup after both? [13:18:08.0000] i don't think he was saying that [13:18:16.0000] i only understood interleaving as synchronous interruption [13:18:30.0000] Ok. [13:18:38.0000] Then, yah, that would be very surprising semantics [13:18:51.0000] But I don't think the spec does that. [13:19:03.0000] So we should be good. [13:19:04.0000] there is nothing in the ecma262 side that guarantees both console logs be both scheduled before cleanup [13:19:08.0000] that's up to the host [13:19:24.0000] html happens to do this because cleanup is a task, not a microtask (what dan was saying about priorities) [13:19:38.0000] 👍 [13:25:48.0000] keith_miller: node also has workers [13:25:58.0000] devsnek: sure [13:27:00.0000] shu: were you going to suggest that cleanupSome checks [[CanBlock]] [13:28:35.0000] no [13:31:51.0000] What are the usecases for `cleanupSome`? [13:32:30.0000] jridgewell: something that doesn't yield to host safepoints [13:32:38.0000] like a tight loop in a worker [13:33:03.0000] Is there an example? [13:33:22.0000] Like, why is it critical to clean it up _now_? [13:33:28.0000] because it can never happen otherwise [13:33:39.0000] like if your worker is while (true) { ... } [13:33:53.0000] as long as you're in that loop the host can never perform cleanup callbacks [13:34:03.0000] Why is that an issue? [13:34:23.0000] If you're in a `while (true) {}`, you can never use Promises, etc. [13:34:24.0000] shu https://github.com/tc39/test262/pull/2531 review this now? [13:34:35.0000] Like, the whole JS ecosystem is broken with that. [13:34:36.0000] jridgewell: because if you're using weak stuff you expect your things to be cleaned [13:34:48.0000] rwaldron: yep, yes please [13:34:50.0000] and interactions with wasm, etc have this problem [13:34:58.0000] therefore we try to support it [13:35:25.0000] we could theoretically not have it [13:35:29.0000] but it would be kind of unfortunate [13:36:12.0000] wow this is giving me fomo [13:36:34.0000] oughtta dive into that Temporal repo more properly [13:38:16.0000] temporal is awesome [13:39:09.0000] I don't see why wasm has any less constraint to return to the run loop [13:39:31.0000] If your wasm source language doesn't return to the event loop you'll still be screwed [13:39:38.0000] someone needs to enable redirect to https on tc39's gh-pages [13:39:41.0000] because you can't get any events [13:39:48.0000] you don't need events [13:39:53.0000] you could be working with atomic shared buffers [13:40:00.0000] which is something that people actually do [13:40:04.0000] not sure if we explicitly wrote this in the slides, but Igalia has been working on this "in partnership with" Bloomberg :) just to make disclosure explicit [13:40:33.0000] but you know we love this and would probably be doing it in our free time anyway... [13:40:46.0000] (e.g., Ujjwal concretely did start on this in his free time before starting at Igalia) [13:40:50.0000] breaking: igalia and bloomberg conspiring to add usable datetime to js [13:40:53.0000] littledan: I think it was in the slides [13:40:56.0000] could be wrong [13:41:01.0000] oh good [13:41:02.0000] devsnek: the box is checked [13:41:18.0000] ljharb: i was able to visit tc39.es/proposal-temporal/docs with no https [13:41:20.0000] devsnek: and http redirects to https to me [13:41:24.0000] devsnek: ah, that's just for that one repo [13:41:28.0000] devsnek: every repo has to check it separately [13:41:30.0000] oh [13:41:32.0000] that's not great [13:42:07.0000] we should ask github to do something about that [13:42:21.0000] wait I thought we didn't want a new way to probe system time [13:42:49.0000] keith_miller: (to recap for channel:) how is interop risk due to depending on cleanupSome different than interop risk due to e.g. chrome always scheduling a cleanup task and running it and safari never scheduling? [13:43:07.0000] michaelficarra: i believe that if it's all under `Temporal.now`, and that's normative optional, `delete Temporal.now` would be sufficient for that concern [13:43:09.0000] shu: I think the difference is between doing it at a different time or not at all [13:43:23.0000] both are allowed by the spec but one is clearly not the intended behavior [13:44:34.0000] In other words, If WebKit is going to do something to stop cleanupSome on the main thread then that just won't work unless it's also implemented in V8 [13:44:59.0000] Since we can't throw we can only silently ignore it [13:45:22.0000] keith_miller: i'm not convinced the interop risk is different [13:45:34.0000] this sounds eerily similar to WebAssembly synchronous module compilation not working on the main thread in Chrome... [13:45:47.0000] littledan: But that throws right? [13:45:54.0000] yeah [13:46:07.0000] but there's no part of the spec that specifically allows for throwing, there [13:46:19.0000] anyway, the interop situation there is not great. I'd prefer to avoid if it possible! [13:46:45.0000] i'm still angry that chrome doesn't allow sync compilation [13:46:49.0000] this interop risk is also a risk for a single browser [13:47:15.0000] I thought it was a size thing? [13:47:21.0000] maybe I'm wrong though [13:47:29.0000] its a size but only enforced for the sync api [13:47:36.0000] the size is also small enough that only toy demos will be under the limit [13:47:56.0000] I think it's mostly for snippets not for whole apps [13:48:08.0000] or at least that was my understanding of why it's there [13:48:13.0000] i thought we (browsers) all signed up for educating devs in such a way that cleanupSome can be a nop at any time [13:48:16.0000] not arguing for or against it [13:48:17.0000] lol [13:48:26.0000] the logic for sorucemapping is too big for sync loading in chrome [13:48:31.0000] sourcemapping* [13:48:38.0000] and that's not a lot of logic [13:49:43.0000] shu: I mean "yes" but practically I doubt any dev expects only event loop to work if cleanupSome is available... In the end education only gets you so far [13:50:25.0000] like we could educate devs that they nest constructurs in functions but that doesn't mean everyone doesn't do that [13:50:37.0000] that they shouldn't nest constructors in functions [13:50:43.0000] keith_miller: that's qualitatively different than an inherently nondeterministic function [13:50:46.0000] err, feature [13:50:56.0000] keith_miller: let me separate the questions [13:51:10.0000] keith_miller: do you *also* object to the worker use case [13:51:57.0000] I don't particularly like it but personally I'll swallow it. [13:52:08.0000] I can't speak to the managers of WebKit though [13:52:09.0000] I'm surprised the era name is returned as "reiwa" instead of "㋿" [13:53:58.0000] hmm yeah I didn't think `reiwa` was a thing from Unicode's perspective [13:54:17.0000] when in doubt blame icu4c [13:56:27.0000] rkirsling: you mean the square era names in general? [13:56:59.0000] keith_miller: i would be very unhappy to hold this up on reopening the design question on cleanupSome, given i think the worker thing is a valid use case [13:58:27.0000] i know some people who would be very very sad if cleanupSome isn't available [13:59:39.0000] I mean I know people that will be very very sad if cleanupSome is available :P [13:59:54.0000] what's the argument against it [14:00:13.0000] that it can be used on the main thread? [14:01:15.0000] Where do we signup for temporal weekly meetings? [14:01:20.0000] michaelficarra: I mean specifically the romanized string like you said [14:02:02.0000] oh it shouldn't be [14:02:06.0000] I don't know where that came from [14:02:13.0000] keith_miller: okay, here's my proposal [14:02:14.0000] as devnsek says, probably blame ICU [14:02:23.0000] devsnek: That all the use cases for it on the Web are effectively just trying to not work well with the event model on the web. And by making that easier we also encourage other bad practices. [14:02:39.0000] i mean that's partially the motivation of web workers [14:02:41.0000] That's in addition to increasing the compatibility surface area of the proposal [14:02:44.0000] keith_miller: cleanupSome has valid use cases for both web workers and node workers, less so for main thread [14:02:46.0000] and no one was against web workers [14:02:53.0000] at least that i know of [14:02:57.0000] keith_miller: the spec currently already has allowance for cleanupSome to always be a no-op [14:03:14.0000] keith_miller: chrome and v8 will ship with cleanupSome being nop on the main thread [14:03:22.0000] keith_miller: we add this requirement in the HTML spec [14:03:27.0000] shu: chrome will or v8 will [14:03:35.0000] both? [14:03:43.0000] why not allow throwing if the host doesn't allow it? [14:03:53.0000] shu: we would not want to disallow it in node [14:03:58.0000] i don't think [14:04:01.0000] I second what devsnek said [14:04:20.0000] by main thread i mean align with [[CanBlock]] [14:04:27.0000] oh ok [14:04:29.0000] otherwise we would need to spawn up a worker every time we want weakrefs with computational-heavy scripts [14:04:32.0000] does node have any agents where [[CanBlock]] is false? [14:04:35.0000] i thought you meant by default 😅 [14:04:39.0000] no, i mean on main thread [14:04:46.0000] uh i don't think we expose that [14:04:53.0000] Atomics.wait exposes it [14:04:58.0000] Atomics.wait throws where [[CanBlock]] is false [14:04:58.0000] no i mean the ability to disable it [14:05:01.0000] ah [14:05:02.0000] shu: no, it is allowed [14:05:14.0000] we should absolutely not disable it in node [14:05:15.0000] an embedder could create an agent and do whatever it wants with it [14:05:31.0000] keith_miller: i can live with throwing when [[CanBlock]] is false in cleanupSome [14:05:45.0000] shu: Ok, let me get back to you tomorrow [14:05:47.0000] keith_miller: if apple agrees to that and we can settle this before the end of the meeting [14:05:56.0000] keith_miller: great, thanks [14:05:57.0000] or w/e people get back to me [14:06:01.0000] well... [14:06:29.0000] i don't have plans to wait another 2 months for resolution on this [14:07:04.0000] where do i send the cake asking apple to please not block cleanupSome [14:07:07.0000] I'm still highly confused as to the root concern. My understanding is that `cleanupSome` means "if there is any finalizer to run, can you please run them now". There is no guarantee there actually is any finalizers to run. Realistically in the main thread on the web, its really hard for a program to not yield to the event loop [14:08:02.0000] if it doesn't yield the user can't click anything [14:08:05.0000] mhofman: the concern is that apple wants cleanupSome to not do anything on the main thread because of the general philosophy you shouldn't do work synchronously on the web [14:08:06.0000] regardless of click handlers [14:08:10.0000] the page just freezes [14:08:35.0000] mhofman: and while the spec *does* allow cleanupSome to always nop, in practice this will have a large interop risk with Chrome, if Chrome *does* make cleanupSome run the finalizers [14:09:06.0000] like the reschedule problem with iterators [14:09:15.0000] my initial response is basically "that's what you bought into by using finalizers to begin with" [14:09:39.0000] i agree with shu there [14:09:41.0000] i appreciate the practical difference between "never/always" and different likelihood [14:10:31.0000] do engines really interrupt javascript execution to perform collection on the main thread. I know it's possible, but is it reasonable for a program to expect? [14:10:41.0000] it does do that yes [14:10:47.0000] minor GCs especially [14:10:49.0000] shu: Sorry I meant that as if people get back to me before tomorrow [14:10:56.0000] ah +1 [14:10:57.0000] I'll reply then [14:10:58.0000] lol [14:11:15.0000] MylesBorins condolences [14:11:18.0000] paths forward here are 1) throwing when [[CanBlock]] is false, 2) removing cleanupSome, or 3) the browsers come to a gentleman's agreement since the allowance exists in the spec [14:11:51.0000] i can live with 1), i think 2) is a non-starter for workers, and am also fine with 3) but apple might not be [14:12:15.0000] HTML could also spec it [14:12:20.0000] that's what i suggested above [14:12:26.0000] we leave cleanupSome as is, maybe add a host hook [14:12:36.0000] and HTML can decide to nop or throw on main thread [14:13:41.0000] either option will make testing interesting. Require to spun a worker to test `cleanupSome` [14:13:55.0000] testing this is pretty impossible [14:13:57.0000] shrug, we bought into that world already on the web [14:14:11.0000] where main thread and worker threads have distinctly different capabilities along sync/async boundaries [14:14:18.0000] speaking of which engine262 is reporting really low coverage levels for weakref stuff [14:14:32.0000] and i'm not sure why [14:14:38.0000] should investigate at some point [14:15:41.0000] half of the spec is impossible to test, especially after some of the more recent changes [14:16:03.0000] could make special cases for engine262 since it has deterministic collection [14:16:34.0000] hm i guess that's what the implementation contributed tests are [14:17:19.0000] we tried to come up with hooks that basically said "resolve when you collected this object". But since a collected object doesn't mean the registry cell / weakref has been emptied, you still can't test that [14:19:13.0000] you can have a test of the form "here's a hook which asks the host to do as much GC as it can and run all finalizers and so on, which the host is free to implement however it likes. after this hook, assert that _if_ the finalizer for X ran then the WeakRef for X is empty" [14:21:10.0000] that's sort of what we have isn't it [14:21:12.0000] $262.gc [14:24:08.0000] mhofman: Huh? If your finalize hook is called all weakRefs connected to that object should be cleared. Does the spec actually allow that not to be the case? [14:24:43.0000] keith_miller: as currently written that is required [14:24:53.0000] ok wew [14:24:54.0000] right, we'd need the following hooks: [14:24:54.0000] - obj has been collected [14:24:54.0000] - all cells have been emptied [14:24:54.0000] - all finalizers have been called (aka no more empty cells in registries) [14:24:54.0000] - a kept objects list has been emptied [14:25:08.0000] https://tc39.es/proposal-weakrefs/#sec-weakref-execution [14:25:18.0000] for a given set of objects S [14:25:24.0000] clear everything related to those objects [14:26:02.0000] keith_miller: yes, if finalizer is called, it means weak refs have been emptied, but it doesn't say that other finilizers for the same object has (or will ever) been run [14:26:04.0000] Don't you just need clear kept objects promise? [14:26:24.0000] why do you need to know whether an object is collected or not? [14:27:05.0000] how is the agenda item spelled wrong on TCQ? I thought it was pulled in automatically [14:27:08.0000] I guess I don't see why that's useful for testing (at least in the spec tests) [14:27:31.0000] michaelficarra: not sure but we also had Surrogate Paris yesterday [14:27:40.0000] you may not, but you need to know when the weakrefs have been emptied, and you need to know when all the finalizers related to an object have been called [14:27:51.0000] for an engine specifically I could see why you'd want to know if it so you don't have practical bugs [14:28:16.0000] if it has been collected* [14:28:29.0000] that's my sadness regarding the tests [14:28:41.0000] they're so loose they might miss bugs in the implementations [14:28:52.0000] ^ [14:28:56.0000] That's fair [14:29:19.0000] You could have non-normative tests that are much stronger but I don't think those can be part of test262 [14:29:27.0000] they can be in implementation-contributed [14:29:56.0000] I mean I just copied v8's tests and refactored them to work with JSC [14:30:05.0000] oh so [14:30:10.0000] well except for the ones that required precise GC [14:30:11.0000] if i made a cleanupSome test that always collects something... [14:30:16.0000] I really dislike the `#foo` = `this.#foo` shorthand. [14:30:32.0000] So, happy with this. [14:30:36.0000] keith_miller: bro what if cleanupSome in fact always triggered a major gc [14:30:49.0000] Lol [14:30:59.0000] shu: Only if it's Sync [14:31:16.0000] 🎉 [14:31:21.0000] yes the only implementation allowed is naive stop-the-world mark and sweep [14:31:29.0000] none of fil's snooty stuff here [14:31:45.0000] the only allowed implementation is engine262's where you sweep after every job [14:31:46.0000] better be precise too [14:32:52.0000] honestly y'all might enjoy this https://github.com/engine262/engine262/blob/1493ad798f84b74d5c2cb0a249d7222320fa67f4/src/api.mjs#L47-L144 [14:33:19.0000] shu: is it on purpose that the host hook is called for each cell in the registry instead of each registry [14:33:39.0000] what host hook? [14:33:48.0000] HostCleanupFinalizationRegistry [14:34:00.0000] if seven cells are empty in a registry that hook is called seven times [14:34:02.0000] instead of once [14:34:06.0000] where does it say that? [14:34:14.0000] oh, in Execution [14:34:24.0000] yeah [14:34:30.0000] not really, other than easier to spec [14:34:34.0000] this is non-observable [14:34:38.0000] right [14:45:42.0000] I am so excited for Compartments! [14:45:54.0000] bradleymeck can you link your slide deck when you are finished [14:45:58.0000] compartments ftw [14:46:10.0000] oh nvm no slides [14:47:50.0000] I only see two cursors in the Note Takers area. Do we need more help? [14:48:38.0000] i think we are ok [14:48:44.0000] the fact that people are already doing this in so many ad hoc ways is HUGELY comepelling [14:48:45.0000] k [14:48:52.0000] michaelficarra: +1 [14:57:19.0000] ystartsev: keith_miller: https://github.com/tc39/proposal-weakrefs/issues/197 [14:57:45.0000] dan had the good suggestion on making the method normative optional delegated to the host, like what we just did with the SAB constructor [15:00:24.0000] shu: What would be the process for requiring it? HTML would spec it? [15:00:44.0000] keith_miller: requiring what? [15:01:13.0000] requiring cleanupSome. [15:01:24.0000] Or are you saying that Safari could just not implement it? [15:01:28.0000] on worker threads? [15:01:31.0000] HTML would spec it [15:01:46.0000] HTML would say, main thread doesn't have cleanupSome, web workers do [15:04:39.0000] https://twitter.com/ljharb/status/1245472022697627649 asking for feedback on `#field in obj` [15:04:55.0000] there is a 3rd proposal, i guess, of cleanupSome being completely normative optional, but i am against that [15:06:34.0000] this proposal is really worked, and we're talking about way-beyond-stage-1 concerns right now [15:17:54.0000] are we planning on revisiting WeakRefs this meeting or should I check it off on the agenda? [15:19:10.0000] shu? [15:19:54.0000] i have asked MylesBorins to revisit, i consider it very high priority to get consensus from other browsers on what we will ship [15:20:16.0000] ok I think I missed that ask [15:20:19.0000] let me look at schedule [15:20:27.0000] akirose: bterlson: ^ just in case i'd like 15-20 mins to revisit weakrefs before end of meeting [15:20:52.0000] today's meeting? [15:20:57.0000] or the plenary [15:20:57.0000] no, today or tomorrow [15:20:59.0000] plenary [15:21:06.0000] err, not today, tomorrow [15:21:45.0000] copy that [15:21:48.0000] does littledan need to be present? [15:22:31.0000] shu and I have sync'd about this and I'm good to defer to him [15:22:34.0000] (if needed) [15:22:36.0000] ok cool [15:22:40.0000] I've added it to tomorrow [15:22:42.0000] I'm signing off in 20 minutes [15:22:43.0000] tyty [15:22:43.0000] after the vote before stomics [15:22:48.0000] (tomorrow I'll be here) [15:22:56.0000] yeah the atomics thing is bumpable [15:23:55.0000] ok [15:23:58.0000] it is on the agenda [15:24:01.0000] update in tcq + hackmd [15:24:58.0000] well glad I asked [15:28:00.0000] sffc's presentations are always SO easy to follow, I love it [15:30:55.0000] ^ [15:33:44.0000] Thanks :) [15:41:42.0000] import.meta queue from yesterday: [15:41:42.0000] New Topic: Do we need to worry about this prior to Compartments actually exposing hooks? Jordan Harband [15:41:42.0000] New Topic: I would prefer a stronger argument to preclude hosts from doing things because we can happen to enumerate use cases today [15:43:40.0000] that was me [15:49:03.0000] Merge now [15:51:38.0000] mathiasbynens sffc gibson042 wsdferdksl : ready to talk some more about escape sequences? [15:52:07.0000] Gotta do it, next on the agenda seems like a good time [15:52:25.0000] Let's go for it [15:54:32.0000] shu: BTW, have we discussed/considered for the STDLib subgroup to allow for specs that are written in JS with the ability to call into operations? [15:54:36.0000] I guess so [15:55:06.0000] keith_miller: i have proposed no restrictions on what proposals should be in the incubator calls [15:55:18.0000] keith_miller: except that they be "amenable to being iterated on in smaller groups" [15:55:37.0000] shu: Uhh, fair enough. I guess in a way this is independent of the calls [15:56:13.0000] keith_miller: the scope was widened to anything that's amenable to being discussed in smaller groups, not just stdlib [15:56:21.0000] since stdlib was hard to nail down and that seemed counterproductive to the point of the calls [15:56:40.0000] I was thinking about this in the context of making API design easier to spec because you can skip most of the annoyingness of current specciness [15:56:50.0000] shu: fair enough [15:57:34.0000] keith_miller: yeah i think that's an independent question, and can be done by example: after the first such proposal comes, it'll be a good blueprint [15:57:45.0000] If anyone has strong feelings (or any feelings) re: including import.meta in 2020, or just general process around that pleasel mk [15:57:46.0000] lmk [15:58:44.0000] is daniel rosenwasser on here? [15:58:55.0000] 404 [15:59:01.0000] shu: Yeah, true. [15:59:02.0000] IMO, having touched both the spec and the way JSC does self-hosted code. self-hosted is way easier to write and much clearer semantically. [15:59:18.0000] shu: I don't think he ever has been :( I don't know why [15:59:32.0000] Not that it has to be the same way JSC does it but just as an example [15:59:35.0000] keith_miller: there are counterpoints to that in V8, which has moved away from self-hosting [15:59:46.0000] I thought that was for perf? [15:59:58.0000] nooo this was good until this slide [16:00:19.0000] this slide must've changed just recently [16:00:46.0000] keith_miller: it's the same argument, right? part of the perf argument is the semantics that actual JS allows you to observe [16:00:52.0000] in case you hear anything, NYC is screaming again for the health workers [16:01:04.0000] keith_miller: though i don't know how JSC does it, if by that you mean a restricted subset... [16:01:17.0000] Oh, I thought it was perf because you had to parse it at runtime? [16:01:42.0000] i wasn't there for the entire discussion obviously, but i think it's just for finer control [16:01:52.0000] we do use a restricted subset, but we don't have a linter so it's tribal knowledge lol [16:01:56.0000] if i had to choose between torque and js self hosting i'd choose torque [16:01:59.0000] I mean it's somewhat restricted but only in that you can't use global variables [16:02:19.0000] keith_miller: yeah but we avoid let/const, e.g. [16:02:21.0000] v8 had so many perf cliffs from self hosting too [16:02:32.0000] remember when people avoided promises because they had to allocate those js arrays [16:02:39.0000] keith_miller: anyway i don't think we need to get into it now, but there are plenty of historical data points against self-hosting, and speccing things via JS [16:02:42.0000] rkirsling: That's just because our parser is slower at parsing let/const [16:02:42.0000] see: LAPIs [16:02:54.0000] and the deeply problematic getOriginals [16:03:16.0000] es4 was based on a reference implementation [16:03:21.0000] written in ocaml [16:03:21.0000] keith_miller: yeah true. do we have an idea for how to improve that? I know there was that one "huge file takes forever" ticket [16:03:27.0000] or something [16:03:32.0000] one of the MLs [16:03:34.0000] there could be a more expressive, less verbose JS-for-specs, but i wouldn't want it to be actual JS [16:03:37.0000] yeah, we just haven't done it [16:03:39.0000] k [16:03:52.0000] i had an idea [16:03:58.0000] of having a meta language that spec steps are written in [16:04:04.0000] which renders to proseish [16:04:16.0000] I also think it would be much easier for a webdev to read and understand [16:04:23.0000] if it were JS-like [16:04:35.0000] could point to engine262 sources [16:04:50.0000] but I don't think it has to be 100% JS tbf [16:04:55.0000] keith_miller: JS-like, sure, but not JS [16:05:18.0000] tc1337: specifying the language used to specify ecmascript [16:05:21.0000] like it seems reasonable to be able to get %Object% and access internal slots, create spec-internal records that aren't actual JS objects, reify control flow, etc [16:05:44.0000] we could reify internal slots as private symbols if we had private symbols :P [16:05:54.0000] i don't want a 3rd thing [16:05:57.0000] we have a thing right now with records [16:06:17.0000] keith_miller: using https://npmjs.com/es-abstract, you can already do that :-p [16:06:30.0000] (and theoretically, trivially transform that code into spec text) [16:06:59.0000] Yeah, but the point is somewhat that's not what's actually in the spec [16:07:28.0000] which leads to things like my promise issue [16:08:20.0000] what is your promise issue? [16:08:51.0000] shu: https://github.com/tc39/ecma262/pull/1912 (I forgot to add it to the agenda...) [16:08:56.0000] keith_miller: es-abstract's abstract op names are what's actually in the spec [16:09:18.0000] keith_miller: altho for IfAbruptRejectPromise and whatnot yeah, that's not easily done [16:09:38.0000] but the JS code that produces the spec code isn't and isn't used for updates [16:10:05.0000] like ecmarkup? [16:10:10.0000] mpcsh I would like to ask people to not argue about symmetry at all [16:10:21.0000] unless it's really important [16:10:27.0000] /me ljharb: looks [16:10:34.0000] Bakkot: yep, I was too busy notetaking to remove it from the queue. gone now [16:10:38.0000] thanks! [16:11:22.0000] ljharb: yeah [16:11:52.0000] ljharb: Maybe I'm misunderstanding how es-abstract works though... [16:12:11.0000] keith_miller: it's just JS implementations of abstract operations [16:12:26.0000] keith_miller: but if you write a spec polyfill with it, the spec text is remarkably 1:1 to the polyfill code [16:12:41.0000] keith_miller: except for a few caveat cases, which include any macros like IfAbruptRejectPromise :-/ [16:13:00.0000] engine262 only has a build step because of macros :( [16:13:04.0000] Bakkot: I might not put this in the queue, but that was a fantastic short-notice presentation. THANK YOU for your thoroughness and overall demeanor. [16:13:16.0000] ljharb: Right, I'd like to see the polyfill be closer to the source JS [16:13:21.0000] err [16:13:29.0000] gibson042: +1 [16:13:31.0000] spec be closer to the polyfill [16:13:48.0000] keith_miller: eg https://github.com/es-shims/Promise.prototype.finally/blob/master/implementation.js [16:13:58.0000] keith_miller: with this approach, i've found spec bugs in proposals [16:14:24.0000] ljharb: In which direction? [16:14:39.0000] like you've found bugs in the current spec text when translating to JS? [16:14:46.0000] or the other way around? [16:14:52.0000] keith_miller: yes, the former [16:15:15.0000] ljharb: I've found the same thing [16:15:24.0000] there are a lot of bugs in the spec [16:15:54.0000] devsnek's approach is much more extreme, writing an entire engine in JS :-p [16:15:57.0000] lol [16:16:09.0000] oh 100% I just think its easier to think about the JS source over the spec text itself [16:16:20.0000] with our current spec language [16:16:52.0000] so I wouldn't be opposed to allowing something a bit nicer for us and (hopefully) readers [16:19:01.0000] i'm supportive of a higher-level spec language but the observability questions need to be very clearly answered [16:19:32.0000] Yeah, I think it'd totally need to be a restricted set of JS [16:20:31.0000] how about c [16:20:36.0000] shu: but that's in some ways much easier to verify since we don't have to be complete in our analysis. [16:20:49.0000] YAY everything is legal! [16:20:58.0000] ^ tc39 out of context [16:21:01.0000] the tradeoff today is, it's easy to get something like a loop condition completely wrong, but hard to get something like get Object.prototype via the global scope instead of the actual Object.prototype wrong [16:21:20.0000] i don't want us to shift the tradeoff to be that it's now easy to get the second kind of thing wrong [16:21:42.0000] https://www.imdb.com/title/tt6110648/ [16:21:45.0000] shu: In JSC we have parsing assertions for things like that. [16:22:26.0000] If you don't have a variable named "Object" in the function you'll crash in the parser [16:22:43.0000] although we don't have something to stop you from doing %Object%.prototype [16:22:54.0000] keith_miller: i'm not convinced you can do all of this with parsing linting [16:22:55.0000] But you could probably assert for that too [16:23:05.0000] anyways, easier to comment on a concrete thing [16:23:12.0000] true [16:23:42.0000] Bakkot: for clarity in the notes, was the consensus that all four cases are legal implicitly assuming that this will be included in the 2020 spec cut? [16:23:43.0000] there's also metajs: http://int3.github.io/metajs/ [16:23:54.0000] mpcsh yes [16:29:34.0000] nice use of logical assignment 😎 [16:33:45.0000] 🧙🏼‍♂️ [16:39:26.0000] I kinda wish this part was recorded so I could watch again if I wanted to implement one of my proposals in engine262 [16:40:11.0000] michaelficarra: ditto [16:40:21.0000] jridgewell: I'm trying to fix up a stepper [16:40:45.0000] the readme also has a naive stepper impl for the debugger hook [16:40:46.0000] new requirement: stage 4 presentations must include live-coding the second implementation [16:41:46.0000] jridgewell: onDebugger() { debugger; } is enough [16:41:57.0000] but it isn't good at stepping (which is important) [16:42:03.0000] Where do I put onDebugger? [16:42:34.0000] jridgewell: https://github.com/engine262/engine262/blob/c5285227f26ef661fc6f3723df3b44489a12a42d/test/supplemental.js#L23-L26 [16:42:40.0000] but make your own agent XD [16:43:24.0000] If I add regexp match indices to engine262, would that meet the requirement for the proposal to advance to Stage 4? [16:43:34.0000] Can we add it to the website? [16:43:42.0000] rbuckton: the actual answer is "maybe" [16:43:51.0000] (since I have one impl right now, waiting on a 2nd...) [16:43:53.0000] a real stepper deals with the onNode hook, but i found i needed to also implement an exit hook not enter [16:44:03.0000] not just* [16:44:18.0000] rbuckton: what impl do you have? [16:44:40.0000] It's implemented in V8 behind a flag and has been for several months. [16:45:26.0000] V8 does not have an implementation we're satisfied with shipping [16:45:49.0000] i would not want that used to fulfill stage 4 advancement until we think it's in a shippable state [16:46:03.0000] jridgewell: noice [16:46:55.0000] Self hosted spec language [16:47:15.0000] That's real bootstrapping [16:47:46.0000] rbuckton: that said please express more pressure for another engine to implement it, to see if V8's performance regressions to which we have no good answers for are also a problem in other engines [16:48:05.0000] (i know you've already called for more engines to implement) [16:48:12.0000] maybe its the TypeScripter in me, but it feels like Engine262 at least needs JSDoc-style comments to indicate types. [16:48:21.0000] it probably is [16:58:40.0000] well done devsnek 👏 [16:59:01.0000] thank you 2020-04-02 [19:05:36.0000] shu: I commented on the github thread. I'll start working on the slides now [19:05:51.0000] 😬 [19:05:52.0000] keith_miller: :+1: [19:37:26.0000] `import.meta` has landed [19:39:31.0000] 👀 [19:47:34.0000] somebody's excited [10:01:52.0000] My computer KPed and is struggling to start [10:15:18.0000] +1 to "days are more destructive than hours" [10:15:55.0000] +2 [10:16:33.0000] +1 as well that a 3 day travel meeting requires up to 5 days blocked off [10:20:51.0000] and it's 1am now I'm very sleepy even I had go to sleep 8pm [10:21:45.0000] stay up for whole night for 4 or 5 days is not acceptable for me :( [10:22:32.0000] no matter how we structure the times, that's going to be a requirement for somebody [10:22:39.0000] during every meeting, i mean [10:23:54.0000] maybe should collect acceptable time range of everyone and try to find a way to let less people meeting in 0am to 6am [10:24:33.0000] what rude response was Waldemar referring to? [10:24:47.0000] michaelficarra: https://github.com/tc39/Reflector/issues/276 iirc [10:25:16.0000] jackworks7: agreed, node TSC has a tool that tries to minimize that, and takes into account everybody's timezone [10:25:26.0000] oh I see, I think it was just miscommunication [10:28:30.0000] yeah I was surprised by the callout [10:36:24.0000] +1 to waldemar/myles' point as well that the remote only works well because we have existing non-remote relationships [10:36:30.0000] this queue is too long :( but I'll repeat that hallway track doesn't work if it requires you to juggle multiple machines [10:36:41.0000] I have to say [10:37:12.0000] +1 ljharb [10:37:15.0000] Minecraft with appropriate mods might be a better choice than the hub [10:37:45.0000] rkirsling: also if the 1 hour break takes 40 minutes in food prep [10:37:55.0000] (for lunch) [10:38:13.0000] also no Wednesday dinner, which often was very productive [10:38:32.0000] a lot of proposals only exist because of discussion that happened at the dinners [10:38:32.0000] +1000 ^ [10:38:42.0000] yeah I thought that Weds dinner would've been the sole appropriate time FOR hubs [10:38:47.0000] but then it didn't happen? [10:38:56.0000] nobody showed up [10:39:02.0000] yeah the wednesday dinner [10:39:15.0000] I didn't show up because we just ended with no remark [10:39:29.0000] hubs is open whenever we're not in plenary, 24/7 :-p [10:45:46.0000] At TPAC/WC meeting last week (first time remote for everyone), we did 4 hours per day... worked well (although less people: ~25 delegates) [10:53:16.0000] rkirsling: srry i fell asleep :| [10:53:20.0000] for the dinner [10:53:33.0000] I *love* bterlson 's idea here! [10:53:46.0000] Node collaborator summits are awesome, and I think we could do a lot in something like this [10:53:52.0000] it could be adjacent to a normative plenary [10:53:55.0000] ystartsev: oh sorry, I wasn't mean to blame anybody :( [10:54:04.0000] 😅 [10:54:07.0000] thinking of it more like a "collaborator summit" i think is a great way to think of it [10:54:49.0000] also wanted to mention, lots of non-US countries have difficult border policies that would inhibit travel of TC39 delegates. In fact, I doubt there's any rich country we could choose in the world that everyone could just go to. [10:55:01.0000] I messed up by calling it a conf [10:55:07.0000] collaborator summit is a better term [10:55:18.0000] littledan: +1 [10:55:21.0000] bterlson: i like that idea a lot [10:55:45.0000] (multiple Igalians have had trouble getting into Canada for technical conferences, for example) [10:56:05.0000] +1 again, canada is not better than the US here [10:56:28.0000] i had top drop for a 1:1 for 30 minutes [10:56:46.0000] was there discussion around short-form vs long-form plenaries and where did folks land? [10:56:54.0000] Today is seems that Canada is easier. Back in 2013 it was not fun for me attending a Mozilla Summit there. [10:57:19.0000] shu: some preferred more days shorter hours, some preferred fewer days [10:57:41.0000] any clear minority or majority? [10:58:05.0000] not that i saw, but i wasn't keeping tabs [10:58:12.0000] shu IMO not in dense, definitely a subtopic that needs work in the current discussion [10:58:25.0000] sorry, in dense? [10:58:43.0000] it havent'been discussed extensively [10:58:44.0000] yeah, we had some discussion but we didn't have much of a conclusion or even a strong tendency in the room [10:59:16.0000] okay, thank you [11:02:03.0000] wsdferdksl: ebola doesn't have a cure or vaccine, and zero cases weren't required to avoid restrictions. i'm not sure epidemiologists would agree with your logic here [11:02:37.0000] this is not a productive discussion [11:02:45.0000] i suggest chairs get to dan's item [11:02:52.0000] fair [11:03:27.0000] this can be executive decisioned imo [11:03:52.0000] where can I subscribe myself to the Temporal weekly meetings? [11:04:55.0000] I agree. Its not about knowing what will happen and deciding what is best. Its about planning now based on our best guess. [11:05:23.0000] maybe I'm dumb, but if a country has 0 cases, we have rapid cheap testing available, and the country requires everyone entering its borders to test negative, can't we theoretically travel safely before a vaccine? [11:05:59.0000] its not that simple. tests might be inaccurate or take longer to get a result than we want to wait. [11:06:00.0000] michaelficarra: if you're healthy sure [11:06:17.0000] michaelficarra: we don't even need 0 cases, just thorough and rapid testing [11:06:22.0000] thank you for PoO [11:06:28.0000] and accurate ofc [11:06:31.0000] this subtopic needs to stop [11:07:13.0000] carriers exist with no symptoms. its not just about safety for us. its about all who we come in contact with while traveling, after traveling, etc. I for one wouldn't travel and put my family at risk [11:07:36.0000] ghmcadams: symptoms don't affect testing, just who you decide to test [11:07:52.0000] ljharb: you can get false negatives with current tests [11:08:01.0000] sure, current tests aren't good enough [11:08:15.0000] this line of discussion is an absolute waste of time [11:08:22.0000] yeah i don't think this is useful [11:08:35.0000] do we need another point of order? [11:08:38.0000] maybe he's done [11:09:27.0000] please, chairs, let's move to dan's item [11:09:30.0000] yes please [11:11:28.0000] here's ES2020 for folks' review: https://github.com/tc39/Reflector/issues/282 [11:11:51.0000] nice! [11:12:00.0000] ljharb: ebola is very different. This is not a productive discussion. [11:12:05.0000] MylesBorins: thank you, I also disagree [11:12:26.0000] wsdferdksl: agreed, neither are any claims from a non-epidemiologist on how epidemics work. [11:12:44.0000] re ES2020, for those who have had PDF complaints, please check the PDF - it's in A4, with page numbers and a clickable TOC [11:12:51.0000] ljharb: That's incorrect. [11:13:32.0000] It's unproductive to keep bringing up the claim about needing to be an epidemiologist to contribute to the discussion. That's false. [11:13:44.0000] ljharb please let me know what you've used for the page numbers, etc [11:13:51.0000] leobalter: adobe acrobat DC, free trial [11:14:51.0000] yeah, I wondered if there is something beyond acrobat for that. I don't want to personally pay for it to just print the PDF [11:15:10.0000] i printed to PDF just from my mac; then i edited it to add the 4 frontmatter pages, and add page numbers to pages 5+ [11:15:31.0000] we should figure out a better alternative. [11:15:32.0000] adding the pages i did in Preview; only the page numbers and editing text content required Acrobat [11:15:45.0000] you could probably make a script using pdfkit or something [11:17:30.0000] ljharb: the editors list is wrong [11:17:32.0000] should just have ecmarkup output latex and then run latex2pdf [11:17:47.0000] michaelficarra: for 2020? [11:17:55.0000] in the PDF download [11:18:11.0000] michaelficarra: we talked about that on the editor call; that the list would be updated for 2021, not for 2020 [11:18:33.0000] oh I forgot that [11:18:39.0000] okay that makes sense [11:20:57.0000] I'm very much in favor of cancelling the in-person plenaries ahead of time. Having to plan for and incrementally cancel meetings would be stressful and complicated. [11:20:58.0000] we have 60 people in this meeting, just ask... [11:21:15.0000] it sucks. i know it sucks. [11:21:21.0000] but it just… it is what it is. [11:21:31.0000] MylesBorins: i'm not a fan of shutting down any possibility of in-person meetings in 2020, i'm just acking the likelihood that they won't be possible [11:21:58.0000] I'm a big fan of providing certainty this year. We have enough to worry about. I'm not a fan of this situation. [11:22:07.0000] my (elided) queue item was that I can't wait until June to move on Tokyo in September.. I need to make a call on it within a month, as ~1k people /day are dying in NYC, and that call will 99.9% be => cancel [11:22:23.0000] asking here - can drop from tcq if answered [11:22:25.0000] the situation in budapest is also very problematic [11:22:33.0000] how much lead time is needed to plan an in-person plenary? [11:22:39.0000] ~180 days it starts [11:22:44.0000] ok, thx [11:22:48.0000] and it's not like we could move to Barcelona to solve the problems in Budapest! [11:22:54.0000] :P [11:24:19.0000] ljharb: I like the new PDF, I can upgrade from es2018 to es2020 now [11:24:24.0000] MylesBorins: i just hope that after covid is done and everyone's comfortable, we don't need consensus to restart in-person meetings [11:24:29.0000] jackworks7: glad to hear it! [11:24:31.0000] +1 to msaboff 's comment [11:24:47.0000] ++ [11:24:51.0000] ++ [11:24:53.0000] + [11:24:56.0000] :| [11:25:13.0000] 😛 [11:25:29.0000] one is unary one is binary [11:25:46.0000] 111 [11:25:59.0000] did we move from JS to BF as the language for this channel? [11:26:11.0000] can find a reason to make :| a valid opeerator? i feel like that emoji expresses my feelings while coding [11:26:12.0000] [>>++] [11:26:29.0000] just for curious, is there a diff between spec of last year and current year so that the implementer can know what details has changed in a year? [11:26:32.0000] I've always been partial to :/ [11:26:37.0000] littledan http://www.jsfuck.com/ [11:26:38.0000] ^also good [11:26:50.0000] LOL to Mark Cohen's queue item [11:26:57.0000] jackworks7: you can diff it using the github releases, and we also list important changes at the top of the document [11:27:15.0000] :(){ :|:& };: [11:27:48.0000] jackworks7: there's a "commits" link on the github repo [11:27:54.0000] jackworks7: also, the intro summarizes changes in each edition [11:28:06.0000] oh cool [11:28:12.0000] MylesBorins akirose shu can I ask a favor? [11:28:16.0000] jackworks7: but i believe most implementers don't use the yearly editions; the instant it lands in master it's in the languge [11:28:17.0000] what up [11:28:42.0000] jackworks7: git log --pretty=oneline --abbrev-commit es2019..es2020 | grep 'Normative:' [11:28:44.0000] Would we be able to do "Atomics.waitAsync error rejection PR" before my hard 5pm EST stop? [11:28:58.0000] ֶ👮‍♂️👉 #tdz [11:29:11.0000] rwaldron: weakrefs is more pressing [11:29:13.0000] ljharb a lot of tooling implementors do use the yearly versions [11:29:23.0000] ah that's true, eslint and babel and whatnot [11:29:24.0000] fair [11:29:43.0000] shu no doubt, but I was hoping that maybe MylesBorins wouldn't mind doing the process change topic at the end of the day [11:29:56.0000] tooling implementations need to stop using yearly versions [11:29:59.0000] rwaldron: i think we should consider waitAsync bumped until next meeting if schedule is tight. i'm also going to try to do the incubator call chartering in ~10mins [11:30:12.0000] rwaldron: ah okay, then the only constraint for me is weakrefs don't get bumped [11:30:16.0000] I think that process discussion will be super short fwiw [11:30:25.0000] shu I also need an answer on weakrefs <3 [11:30:32.0000] if think we probably can squeeze both in before lunch [11:30:47.0000] we have some extra time, just a matter of juggling around some things [11:30:58.0000] MylesBorins if shu agrees, then I would be very appreciative [11:31:15.0000] There's a 75min empty slot at the end of today [11:31:23.0000] We should have time for everything and then some [11:31:38.0000] yeah like i said it's all about juggling [11:31:40.0000] i'm happy to move waitAsync up and try to time it to 15mins, though i feel like it'll overflow to at least 20 or 25 [11:31:45.0000] want to do yours first? [11:31:46.0000] shu ? [11:32:01.0000] which of mine? [11:32:23.0000] the answer is yes though [11:32:25.0000] We have 25 minutes ish [11:32:29.0000] I'll move process discusssion [11:32:32.0000] MylesBorins if we could do both the weakrefs and waitAsync before I have to depart for child care, I would be ever so grateful [11:32:43.0000] weakrefs is going to need more than 25 minutes [11:32:53.0000] i can try to do either incubator call chartering or waitAsync in 25 minutes, so let's do incubator calls? [11:33:27.0000] err, i mean waitAsync? [11:33:37.0000] I don't know what the incubator calls topic is [11:33:41.0000] shu are you ok with me swapping incubator and weakrefs? [11:33:41.0000] yes waitAsync [11:34:12.0000] Here's my wishlist: can we do weakrefs and waitasync next [11:34:15.0000] MylesBorins: i'm not up to date on the ordering, what concrete times are we takling about? [11:34:22.0000] https://hackmd.io/8Ok_eshBSTCfd8Zh8crQ3Q [11:34:29.0000] stomics would be next [11:34:31.0000] with 25 minutes [11:34:34.0000] then lunch for an hour [11:34:38.0000] then weakrefs [11:34:49.0000] phonetically... stomics will come after whatever we do next [11:34:54.0000] -_- [11:34:56.0000] :D [11:35:00.0000] akirose gets me [11:35:21.0000] lol only begrudgingly [11:35:22.0000] MylesBorins: that looks okay with me [11:35:24.0000] we have 75m of extra time? [11:35:32.0000] rwaldron: nice [11:35:38.0000] :D [11:35:45.0000] yup [11:35:46.0000] rkirsling ^5 [11:35:46.0000] I moved stuff around [11:35:49.0000] PTAL [11:35:53.0000] 🎉 [11:36:29.0000] MylesBorins thank you so much [11:36:32.0000] rwaldron you will be done at 1:25 PT [11:36:35.0000] I really appreciate that [11:36:56.0000] devsnek: (re: tooling implementations need to stop using yearly versions [11:37:01.0000] And thank you to everyone else for being so flexible and accamodating [11:55:06.0000] While it possibly suffers from the same drawback as the `load` workaround, is it feasible to workaround with a `Atomics.wait` with a 0ms timeout for fail-fast, then call `Atomics.waitAsync`? [11:55:32.0000] that suffers the same drawback as the `load` workaround [11:55:49.0000] oh actually [11:55:58.0000] the actual problem is that you cannot `.wait` on the main thread [11:56:06.0000] the point of waitAsync is that you can do it on the main thread [11:57:02.0000] You cannot `.wait` on the main thread? or you "should not" `.wait` on the main thread? [11:57:44.0000] cannot [11:58:09.0000] it throws [11:58:13.0000] Ah: https://tc39.es/ecma262/#sec-agentcansuspend [11:59:06.0000] "the main thread" is an iffy way to describe it imo [11:59:12.0000] in node's main thread you can use Atomics.wait just fine [11:59:20.0000] Its agent dependent, so on the web you *cannot*, but in other hosts you might be able to. [11:59:36.0000] devsnek: that's why I was confused, as I've done this successfully in Node. [12:00:04.0000] had same confusion with shu yesterday :P [12:00:06.0000] sorry, I should have specified on the web, yes [12:00:28.0000] do things still ship Atomics.wake [12:00:41.0000] chrome does, looks like [12:01:09.0000] looks like everything still does [12:01:22.0000] For the uninitiated, Zalgo is: [12:01:23.0000] wasn't that supposed to be removed at the same time as SAB is reenabled [12:01:28.0000] https://www.irccloud.com/pastebin/p0JJpKT7/zalgo.js [12:01:34.0000] The logs must always be 'ABC' or 'ACB' [12:01:39.0000] littledan: by "no change" do you mean, sometimes throws sometimes returns a promise? or always returns a promise [12:01:48.0000] ljharb: Yes, unfortunately [12:01:52.0000] If it's sometimes one and sometimes the other, you've unleased Zalgo [12:01:59.0000] that it sometimes throws a promise, sometimes not [12:02:04.0000] so, tip of tree [12:02:14.0000] littledan: right, that violates the consensus/policy we all agreed on with async functions [12:02:18.0000] "no I hat thenables" +1 [12:02:20.0000] i'd consider that a blocker [12:02:24.0000] Returning a sync thenable doesn't solve Zalgo [12:02:36.0000] Much prefer the tagged/discriminated union approach [12:04:51.0000] the argument validation is definitely a problem [12:05:59.0000] If you're using `async/await` it's not that bad. I'd argue that returning `Promise | string` is worse. [12:08:39.0000] not that bad anyways imo; `result.async ? result.value.then(doWork) : doWork()` or similar [12:09:31.0000] -1 to zalgo by way of untagged union, +1 to tagged union [12:10:16.0000] lol, horrible idea: the string constants could instead be well-known frozen Promise objects ᕕ( ᐛ )ᕗ [12:10:36.0000] ljharb: I'd consign that one to #temporaldeadzone [12:10:47.0000] /me slinks away [12:11:05.0000] /s [12:11:35.0000] this is one weird api [12:11:39.0000] No kidding. [12:11:58.0000] atomics get weird fast [12:12:10.0000] Consensus is `Promise | "ok" | "not-equal" | "timed-out"`? [12:12:17.0000] no, consensus is tagged [12:12:23.0000] Ok, good. [12:12:41.0000] {async:true|false, value:"not-equal"|"timed-out"|Promise} [12:12:46.0000] { async: true, value: Promise } or { async: false, "ok" | "not-equal" | "timed-out" } [12:12:56.0000] oh yeah not "ok" in the last branch [12:13:00.0000] yeah ^ [12:13:41.0000] `{ async: false, value: "ok" | "not-equal" | "timed-out" } | { async: true, value: Promise<"ok" | "not-equal" | "timed-out"> }` [12:13:49.0000] `any` [12:13:56.0000] Why would `"ok"` not be valid if the timeout is 0ms? [12:13:59.0000] rbuckton: almost [12:14:07.0000] there is no promise resolution of "not-equal" [12:14:11.0000] there is no slow fail-fast case [12:14:18.0000] Ah, I see. [12:14:39.0000] wait shu can you give the actual correct type [12:14:42.0000] I keep confusing myself [12:14:46.0000] for which is legal where [12:15:20.0000] `{async: false, value: "not-equal" | "timed-out" } | { async: true, value: Promise<"ok" | "timed-out"> }` [12:15:38.0000] howdoi: if you send me your Gmail I'll add you to the Google Group which comes with the weekly meeting invite [12:15:39.0000] 👍 [12:15:58.0000] great [12:16:02.0000] for async:false to be able to return `"ok"`, the implementation would need to implement a microwait like `pause` to see if it got changed to the value you want in the 1microsecond OS quantum or whatever [12:16:07.0000] and that is just weird [12:16:16.0000] sffc: sure, thanks! [12:16:23.0000] and thus not allowed [12:16:27.0000] shu: Yeah, makes sense. [13:06:11.0000] we will resume in 5 mins [13:11:04.0000] weakrefs 🎉 [13:14:57.0000] are there any major engines where allocating an ordinary object isn't just incrementing a pointer [13:15:40.0000] only young generations tend to be bump allocated [13:16:00.0000] yeah i'm guessing the result of atomics.waitAsync would not be old generation :P [13:16:35.0000] almost always they will be young [13:17:07.0000] also there's no way that object allocation is going to be as expensive as a microtask tick from the application's perspective [13:17:17.0000] i know in v8 you can explicitly ask for young or old generation too [13:17:39.0000] actually i don't know if that's exposed to torque yet [13:19:42.0000] I noticed that today, people do not have their full name and company showing. Can we all make this change as we did on Tuesday? [13:21:23.0000] (in zoom) [13:22:08.0000] point of order raised [13:25:28.0000] Thank you, Myles [13:27:11.0000] Is there an example use case that needs sync finalization with long-running task? [13:27:23.0000] Like, games, but how are the games allocating JS objects? [13:27:31.0000] And why do they need to be cleaned up? [13:28:35.0000] jridgewell: right now they have to emit manual cleanup [13:28:41.0000] which can introduce subtle leaks and such [13:28:53.0000] Cleanup of what? [13:29:01.0000] The thing I don't understand is how they're using JS objects [13:29:15.0000] they're allocating memory in arraybuffers [13:29:21.0000] emscripten/wasm [13:29:28.0000] the memory has to be manually deallocated [13:29:47.0000] And they're sending individual array buffers to the main thread? [13:29:50.0000] no [13:29:52.0000] To do what? [13:30:06.0000] you have some native code that does things [13:30:15.0000] it uses a not shared arraybuffer as its memory [13:30:23.0000] when you pass a reference into that memory to js [13:30:27.0000] you have to manually track the lifetime [13:30:39.0000] finalizationregistry means you no longer have to manually track the lifetime [13:30:42.0000] Yes, I understand that part [13:31:00.0000] What I don't understand is how they're using the JS objects on the JS side of the bridge [13:31:18.0000] If they're sending something to JS, what do they use that for? [13:31:35.0000] you usually are wrapping a native lib and calling it from js [13:31:35.0000] Any explanation of that would be really helpful for me to understand [13:32:11.0000] like `{ ref: n, x() { _binding.x(this.ref) }` [13:32:22.0000] you have instances like that [13:32:30.0000] they're just wrapping native libraries [13:32:42.0000] like native addons in nodejs but using wasm/emscripten instead [13:33:20.0000] (native addons in node get weakref tracking btw) [13:33:40.0000] > you usually are wrapping a native lib and calling it from js [13:33:50.0000] Doesn't that mean you live in JS world, and are subject to the JS event loop? [13:34:00.0000] not inherently [13:34:08.0000] the applications are usually a lot more complex [13:34:40.0000] Is GitHub down? [13:34:50.0000] it is for me in SF [13:34:53.0000] yeah [13:34:54.0000] i think the emscripten repo might have some more in-depth examples [13:34:57.0000] yeah it seems down [13:35:08.0000] Lol, bad timing. [13:35:14.0000] sffc: https://www.githubstatus.com/ [13:35:31.0000] github pages is up at least😁 [13:35:55.0000] gist is down too tho [13:39:38.0000] +1 thanks gus [13:39:44.0000] lol [13:44:17.0000] a usable decorator api might start from a most scoped api instead of a least scoped api [13:44:31.0000] `const a = with operator Vector { v1 + v2 }` or something [13:44:40.0000] expands out to multiple statements [13:44:55.0000] but encourages you to keep it small so you don't slow down other operations [13:48:33.0000] s/decorator/operator overloading/ lol [13:49:50.0000] aren't the cases where you do a binary operator like `+` between a number and a non-number already not fast path because of `@@toPrimitive` and `valueOf`? [13:50:26.0000] depends on what you call fast path [13:50:48.0000] engines optimize based on whether those methods exist, have been modified, and whatnot [13:53:38.0000] https://tc39.es/ecma262/2020/ [13:53:43.0000] Couldn't they also optimize based on whether those operators are present on the object? [13:53:53.0000] rbuckton: there are cases where it is a non-fast path yea, but also cases where it is fast [13:54:30.0000] You shouldn't be able to add operators to an existing primitive, so `1 + 1` would always remain fast-path. [13:55:09.0000] https://usercontent.irccloud-cdn.com/file/uUWGvAJE/ECMA-262%2011th%20edition%20June%202020.pdf [13:55:14.0000] Depending on how the `struct` proposal I'm working on evolves, if operators are limited to only `struct` values then that becomes a specific heuristic that would reduce the need for a `with operators`-like syntax. [13:56:02.0000] yay expedited roll call [13:56:32.0000] i had to drop due to baby but wanted to say yes [13:57:03.0000] is that an official yes from godaddy [13:59:58.0000] Ok, I have to roll off for childcare now. Thanks everyone!! [14:00:08.0000] wycats: we are missing you this week [14:00:21.0000] MylesBorins: i assume applicant members don't count [14:00:29.0000] I don't think so [14:00:30.0000] 🎊 [14:01:27.0000] ljharb: how many pages this year [14:01:43.0000] 856 [14:01:47.0000] 860 pages in the PDF [14:02:05.0000] 4 cover, + 856 from the spec itself [14:02:10.0000] a good amount [14:02:29.0000] such spec [14:02:41.0000] 2019 had 764 of spec, 2018 had 801, 2017 had 881 [14:02:43.0000] many text [14:02:54.0000] 1000 by 2030 [14:03:00.0000] 46 of those pages are the table of contents [14:03:17.0000] ljharb wait, we were actually trending down for a while? [14:03:21.0000] btw you cannot re-log in to TCQ [14:03:24.0000] oh lol true, i didn't count TOC pages [14:03:27.0000] ljharb: the fonts in this pdf are iffy [14:03:30.0000] Bakkot: lol yes apparently! [14:03:36.0000] or at least rendered iffy [14:03:39.0000] so I recommend not closing tcq while github is down :) [14:03:45.0000] devsnek they look great to me [14:03:46.0000] devsnek:in the first 4 pages? or the rest [14:03:47.0000] https://gc.gy/53566426.png [14:03:49.0000] devsnek: ignore the first 4 pages [14:03:57.0000] hm [14:04:00.0000] these letters are too thin [14:04:18.0000] and the bold text for literals is too thick [14:04:41.0000] devsnek: https://i.imgur.com/yTTpqAt.png [14:04:43.0000] https://gc.gy/53566480.png [14:04:44.0000] looks fine to me [14:04:50.0000] hm [14:05:09.0000] maybe firefox then? [14:05:17.0000] linux woes? [14:05:29.0000] i don't have anything custom in linux fontstuff except for fira code [14:05:43.0000] linux has traditionally had problems with rendering [14:05:57.0000] why is it green [14:06:25.0000] well that shade of green [14:07:00.0000] historical reasons :P [14:07:09.0000] all color shades were chosen by me and brian 2-3 years ago in the print-only CSS to make the contrast better [14:07:17.0000] i see [14:07:20.0000] give me CSS diffs and i'm happy to change them [14:07:31.0000] nah its fine [14:07:32.0000] (the web colors looked bad on print, so i override them for print) [14:07:43.0000] was just curious [14:07:56.0000] the font thing is annoying though, can you use acrobat to save the fonts in the pdf [14:08:04.0000] not sure [14:08:10.0000] i've done that with illustrator before [14:08:16.0000] i've never used acrobat though [14:08:56.0000] ljharb 262 is 10x bigger than 402 [14:09:21.0000] but not 10x better [14:09:30.0000] but 262 is 1.5 times smaller than 402 [14:09:35.0000] but 402 weights much more in data for sure :) [14:09:40.0000] github is back! [14:10:53.0000] the size of 402 is hidden in phrases like "implementation- and locale-dependent" [14:23:46.0000] shu: can you put the link to these slides in the agenda and/or in the notes [14:30:48.0000] a few proposal repos need to be archived [14:31:13.0000] optional chaining, import.meta, nullish coalescing [14:31:15.0000] maybe more [14:32:13.0000] I kinda dislike archiving, because it prevents editing for misinformation while leaving it available for google, but i guess we're going with it [14:32:41.0000] i mean it puts a huge yellow banner on it [14:32:46.0000] we can always unarchive, edit, and rearchive [14:32:49.0000] hopefully people can make the connection [14:33:00.0000] i feel it's much better to discourage driveby issues on totally closed proposal repos [14:33:38.0000] devsnek the yellow banner does accomplish much of anything [14:33:54.0000] the inability to file issues and PRs is the important part [14:34:14.0000] devsnek: for import.meta, you should be an admin on that repo, so you can take care of it [14:34:20.0000] in particular, if I state a factual point in an issue, and the repo is then archived, and then I discover the thing I stated was in fact not true, the yellow banner will not inform people of this [14:34:42.0000] ljharb: i'm not [14:34:48.0000] Bakkot: we can unarchive, add your comment, and rearchive for that case [14:34:57.0000] devsnek: ping a chair, as champion you should be [14:35:13.0000] ljharb yeah with a bunch of overhead, and in the case where it is a member of the committee for whom this arises [14:35:28.0000] true [14:36:02.0000] however people much-later correcting incorrect statements on a merged proposal repo has not, in practice, happened; whereas the async/await repo continues to get people asking how promises work [14:37:00.0000] (it's just domenic manually handling everyone's http requests) [14:38:27.0000] ljharb yeah I do see the benefit [14:39:38.0000] I wonder if the github issue template thing lets you just not have any templates [14:39:58.0000] there's no way to disable issue filing, sadly [14:40:08.0000] you can turn off PRs, but then old PRs aren't viewable, which is bad [14:40:38.0000] archival afaik is the only way to prevent new content from being created while leaving all content publicly viewable [14:44:39.0000] ljharb you can't turn off issues entirely, but: [14:44:50.0000] see what happens when you got to open an issue on https://github.com/bakkot/misc/ [14:46:07.0000] sorry, you can turn off issues but that hides the existing ones [14:46:26.0000] Bakkot: oh damn i got bamboozled into the discourse [14:46:28.0000] I am much less worried about people creating spurious PRs than spurious issues [14:48:46.0000] in my experience when PRs are on and issues are off, people create a random file to simulate making an issue [14:49:04.0000] I suspect that would happen far less frequently [14:49:16.0000] stopping new issues is nice, but commenting on old ones is a bigger problem [14:49:52.0000] iow i think the problem i want solved directly conflicts with the ability you want retained :-/ [14:50:45.0000] hmm [14:50:46.0000] alas [15:09:21.0000] it is hard to know who is in the zoom call when they don't have full name and companies. Is that just me? [15:09:48.0000] ghermeto: add a point of order to the queue about it? [15:09:53.0000] We have asked many times for Full names and organization. [15:10:24.0000] Mine keeps getting cleared because I quit the call and rejoin... [15:10:37.0000] I wish I could set it for the call # [15:10:43.0000] yeah it's hard when Zoom resets it every time you leave... [15:11:36.0000] just added a point of order... is that too late? [15:11:44.0000] no [15:11:45.0000] thanks [15:15:00.0000] OT: I'm fighting to make my info show up right in IRC - anyone willing to IM me directly to hold my hand on this? [15:15:51.0000] brad4d: sure [15:16:19.0000] The BIS re-opened the public comment period for extension of the temporary general license [15:16:28.0000] I want to thank the note takers for this meeting! [15:16:30.0000] Are any Ecma members submitting comments? [15:16:39.0000] apaprocki: BIS? what license? [15:17:01.0000] the note takers provide an incredibly valuable service, and the quality has really been amazing lately [15:17:54.0000] ljharb: https://bis.doc.gov/index.php/documents/regulations-docs/federal-register-notices/federal-register-2020/2542-85-fr-17300 [15:18:39.0000] the 3rd text column on the 1st page [15:19:37.0000] oh god clicking this link is going to increment a counter [15:19:39.0000] a very small counter [15:19:44.0000] "223 downloads" [15:19:59.0000] lol [15:20:08.0000] you know somewhere in some damp basement are people in suits presenting pdf download statistics [15:20:45.0000] apaprocki: meaning, this is the way to submit comments to ask for more guidance? [15:21:27.0000] it would seem they'd be open to comments requesting clarification to make the situation easier... whether or not they do it is a different story [15:22:57.0000] right [15:23:05.0000] thanks 2020-04-03 [17:15:32.0000] shu: where will the incubator agendas be? I'm interested in helping with some of them, but probably proposal-specific. [17:16:40.0000] tc39/incubator-agendas [17:16:42.0000] gibson042: there is an issue in the Reflector with a link you can follow to the agenda (currently empty) in the incubator agendas repo [17:16:57.0000] that repo has a single pinned issue of which proposals are in the current charter [17:39:22.0000] thank you! [23:53:41.0000] Because Uglify's `ascii_mode` was mentioned [23:53:54.0000] I opened a PR: https://github.com/terser/terser/pull/631 [23:54:36.0000] Note, uglify is essentially dead. Terser is a fork that understands ES6+ syntax inputs [23:55:23.0000] s/`ascii_mode`/`ascii_only` 2020-04-04 [22:11:59.0000] I forget who we tag in for CoC violations, but https://github.com/tc39/proposal-pipeline-operator/issues/164#issuecomment-608972976 is definitely over the line [22:20:43.0000] (which was preceded by https://github.com/tc39/proposal-pipeline-operator/issues/128#issuecomment-608971535 and followed by https://github.com/tc39/proposal-pipeline-operator/issues/158#issuecomment-608975905, ftr) [22:54:50.0000] TabAtkins: thanks, i'll let someone else on the CoC committee hop on it, since i've already participated 2020-04-07 [10:15:06.0000] mathiasbynens: is there a reason that we wouldn't want something like https://github.com/orling/grapheme-splitter in the language? [10:53:05.0000] ljharb: that’s Intl.Segmenter [10:59:34.0000] mathiasbynens: right, but i meant directly on strings [11:46:20.0000] What are you asking for? [11:46:44.0000] what would you expect from implementations that don't include ECMA-402? [11:46:45.0000] What would "directly on strings" mean? [11:47:00.0000] like String.prototype.graphemes or something? [11:47:06.0000] sure [11:48:45.0000] I think that'd run a huge risk of breaking changes? [11:49:15.0000] Every time we update Unicode, you're `"foo".graphemes` could return something different. [11:49:22.0000] your** [11:50:13.0000] breaking changes as a result of updating unicode already happen and are already Fine™ [11:50:32.0000] the same could occur with code points, and *has* occurred with whitespace [11:51:45.0000] As a syntax change, early errors are easy to fix. [11:51:50.0000] This is a change in runtime behavior. [11:51:57.0000] Much more difficult to track donw. [11:53:02.0000] right, those already have happened and will continue to happen when unicode updates [11:53:15.0000] How? [11:53:20.0000] `.trim()` changed, for example, wrt the mongolian vowel separator in ES2017 iirc? [11:53:38.0000] that character got classified as whitespace, and then unclassified as it (or maybe the reverse, i don't recall) [11:53:48.0000] ie the meaning of `\s` in regexes changed [11:54:05.0000] so i don't think that "unicode changes" is an argument against adding any string-related features [11:54:11.0000] what is the benefit of having the api on string.prototype [11:54:20.0000] we already have the segmenter api [11:54:27.0000] devsnek: Intl isn't required, it's optional [11:54:36.0000] devsnek: so it's not guaranteed to be available [11:54:45.0000] the prototype method would have to be just as optional [11:55:03.0000] like toLocaleString [11:55:06.0000] ^ [11:55:14.0000] why would it have to be? [11:55:22.0000] code points depend on unicode, and Symbol.iterator is required [11:55:34.0000] (toLocaleString is also required, it's just that its behavior is impl-dependent) [11:55:48.0000] (and 402 overrides it when present) [11:56:48.0000] yeah but I don't believe XS uses ICU, say [11:57:52.0000] segmentation is locale-dependent, at least for words and sentences, so Intl.* makes sense [11:58:12.0000] having one type of segmentation on String.prototype.* and two others on Intl.* would be weird [11:59:04.0000] right, i don't think a generic segmenter belongs on strings [11:59:08.0000] ljharb: wait do you want [11:59:16.0000] but like you can iterate on chars, and on code points, i want to be able to iterate on graphemes [11:59:24.0000] Intl.Segmenter on String.prototype or [11:59:48.0000] the code point iterator [12:00:13.0000] ie, `'a🏳️‍🌈c'` is 8 chars, 6 code points, but 3 graphemes [12:00:26.0000] so i want an iterator that gives me 3 things and not 6 or 8 [12:01:14.0000] i realize this is a subset of what Intl.Segmenter does, but it feels to me like the subset would make sense directly on String.prototype, mandated (unless that, too, is locale-dependent?) [12:01:30.0000] splitting by graphemes needs locale data right? [12:01:50.0000] like you'd bring in the icu lib [12:02:02.0000] maybe? what locale data does it need [12:02:05.0000] at which point you'd expose Intl.Segmenter anyway [12:02:45.0000] does the data needed for splitting on graphemes equal the data needed for all of Intl? [12:02:53.0000] i'd assume it's a small subset [12:03:08.0000] i mean that's true for each individual item we ship in Intl [12:03:46.0000] though some are larger than others [12:04:45.0000] mathiasbynens: can you explain how splitting grapheme clusters is locale-dependent? [12:07:25.0000] CLDR contains data for grapheme clustering [12:08:07.0000] right but i mean like, there's graphemes that aren't clustered consistently across locales? [12:09:46.0000] https://unicode.org/reports/tr29/#Conformance [12:10:07.0000] > For example, reliable detection of word boundaries in languages such as Thai, Lao, Chinese, or Japanese requires the use of dictionary lookup, analogous to English hyphenation. [12:10:31.0000] It's not as simple as "does this char join with the previous char" [12:10:51.0000] There's not a property on the Unicode char that we could look at. [12:11:02.0000] word boundaries are tricky for sure, but ljharb is just concerned with graphemes [12:11:11.0000] right, i don't care about words [12:13:01.0000] > These algorithms can be adapted to produce tailored grapheme clusters for specific locales or other customizations, such as the contractions used in collation tailoring tables. [12:13:04.0000] > The following is a general specification for grapheme cluster boundaries—language-specific rules in [CLDR] should be used where available. [12:16:53.0000] stuff like 👨‍👩‍👧‍👦 is also an issue, dependent on env but not locale [12:20:26.0000] https://mathiasbynens.be/notes/javascript-unicode#other-grapheme-clusters [12:24:34.0000] "For a completely accurate solution that works for all Unicode scripts, implement this algorithm in JavaScript, and then count each grapheme cluster as a single symbol" [12:24:38.0000] sounds like it's doable [12:25:21.0000] oh here we go [12:25:39.0000] jridgewell's last quote above precedes this table [12:25:40.0000] https://unicode.org/reports/tr29/#Table_Sample_Grapheme_Clusters [12:25:47.0000] the last chunk of the table is locale-specific [12:26:17.0000] so we could have it on string, and let 402 fill it in for the last chunk [12:27:23.0000] or you could just use Intl.Segmenter [12:31:43.0000] https://www.irccloud.com/pastebin/TfliWeVm/simple-graphemes.js [12:32:00.0000] default rules for identifying grapheme cluster boundaries: http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundary_Rules [12:32:01.0000] PSA: please add incubator call items at https://github.com/tc39/incubator-agendas/blob/master/2020/04-14.md [12:32:27.0000] empty so far, i plan to add realms by EOD, but would like to give other folks a chance to add their items first [12:32:36.0000] they depend upon character property data, but are not locale-specific [12:32:52.0000] jridgewell: that doesn't yield anything [12:33:06.0000] Did for me [12:33:14.0000] I mean, it is a fact that https://github.com/orling/grapheme-splitter/blob/master/index.js is intending to implement the standard, and is <1750 lines with no deps [12:33:45.0000] and has no locale arg, I mean [12:33:55.0000] jridgewell: [...graphemes('🏳️‍🌈💩')]` gives me just a single white flag [12:33:56.0000] Oh, because I had a `Mark` char in mine. [12:34:32.0000] has there been any proposals so far to investigate improving ergonomics of `const` and `try/catch`? `let res; try { res = await fetch(url); } catch (e) { /* ... */ } /* res can be overriden */` [12:35:06.0000] mmarchini: ergonomics of statements in general [12:35:20.0000] mmarchini: do expressions [12:35:29.0000] yep [12:35:40.0000] mmarchini: https://github.com/tc39/proposal-do-expressions [12:35:42.0000] http://unicode.org/reports/tr29/#Table_Combining_Char_Sequences_and_Grapheme_Clusters [12:35:50.0000] Wanna code that table into a regex? [12:36:24.0000] jridgewell: did you just ask me to write a distributed map reduce function in erlang [12:36:33.0000] :-p [12:36:50.0000] do expressions implicitly returns the last expression, right? [12:36:52.0000] No, we have the ability to encode it with properties. [12:36:57.0000] I just don't wanna do it. [12:37:00.0000] mmarchini: not exactly [12:37:09.0000] but more or less yes [12:37:14.0000] jridgewell: was referencing https://lh3.googleusercontent.com/proxy/Qx2opykPRGCvHcvcqdfCxygjKoFmE4ZXMKuUB0fWV2KB2NMnAoS_AGBlt4M0k99imlqraTw2k55_y8oSNkD3iSgcFl2Bu9PYnsh9YNjfrpU8OrXZWcgi1emZvQ [12:37:18.0000] mmarchini: they work the same as what eval() returns [12:37:41.0000] shu: what's the process for adding things to "chartered proposals"? [12:37:49.0000] there's also the explicit resource mgmt proposal [12:37:59.0000] ljharb: you want to talk about another proposal? [12:38:14.0000] so the above would look like `const res = do { let res; try { await res(url) } catch (e) { /* ... */ }; res}` [12:38:28.0000] oh, I don't think I'm familiar with how eval returns [12:38:51.0000] mmarchini: you can get rid of the res variable [12:39:06.0000] ljharb: the current process is to wait until the next plenary. people said they didn't want to feel pressured to check on an agenda every 2 weeks, so the proposed process was folks are free to call out proposals they think should be discussed in the incubator meetings in between two plenaries [12:39:13.0000] `do { try { x } catch { y } }` [12:39:27.0000] shu: i don't have anything in mind, just was curious [12:39:35.0000] `const res = do { try { res(url) } catch (e) { console.error(e); undefined }}`? [12:39:40.0000] shu: oh I missed that point, that's good to know [12:39:40.0000] ljharb: and so the stakeholders would be able to get a heads up and agree to participating in the call until the next plenary [12:39:46.0000] mmarchini: console.error already returns undefined [12:39:49.0000] shu: gotcha [12:39:52.0000] right [12:39:59.0000] at that point [12:40:00.0000] `const res = do { try { res(url) } catch (e) { undefined }}` [12:40:03.0000] oops [12:40:08.0000] `const res = do { try { res(url) } catch (e) { console.error(e) }}` [12:40:10.0000] hum [12:40:11.0000] interesting [12:40:18.0000] i'd do `await fetch().catch((e) => console.error(e))` [12:40:21.0000] a little verbose, bot not bad [12:40:29.0000] but* [12:40:40.0000] gotcha [12:41:31.0000] indeed, devsnek's is better :-) [12:41:51.0000] do expressions are super useful but a lot of the examples could be easily reworked to be better, and not need do expressions in the first place [12:42:05.0000] there's also https://github.com/tc39/proposal-explicit-resource-management for `try (const ...) {}` though [12:42:30.0000] oh wait my bad [12:42:32.0000] that doesn't make the variable available outside the try [12:42:36.0000] yeah [12:42:43.0000] available outside with const, was the goal [12:42:47.0000] sorry [12:42:47.0000] i really want do expressions :( [12:42:51.0000] same [12:42:55.0000] ditto [12:43:10.0000] as long as they allow return and break and stuff that is [12:43:14.0000] without those they're useless to me [12:44:03.0000] oh, i want them to not have those things [12:44:14.0000] it doesn't even make sense for them to not have those [12:44:31.0000] it doesn't make sense to me to have an expression able to affect control flow (beyond throwing) [12:44:46.0000] it's a block [12:44:54.0000] that you can get a value out of [12:45:03.0000] right, the latter imo trumps the former [12:45:14.0000] things you can get a value out of, can't affect control flow, modulo exceptions [12:45:26.0000] i don't understand how "get a value out of" has anything to do with scope [12:45:45.0000] I find do expressions very confusing without explicitly return [12:45:51.0000] explicit* [12:46:08.0000] "it behaves like eval" will not be a valid explanation for most JS developers [12:46:12.0000] i think it's a valuable thing to know that `return`, for example, can't occur in expression position [12:46:21.0000] s/valid/didactic/ [12:46:26.0000] i'm just imagining how useless block expressions would be in rust if you couldn't break/return out of them [12:46:30.0000] devsnek: what are your use cases for do expressions that need these? [12:46:44.0000] that i want to return from a function or break a loop [12:46:52.0000] right but what would the code be [12:46:57.0000] it doesn't matter [12:47:05.0000] it doesn't have to be `return`, but making explicit in the expression what value is getting out would be important IMO [12:47:13.0000] it definitely matters - i can't conceive of when you'd need to return, or break, but also extract a value out of the code [12:47:32.0000] mmarchini: it couldn't be `return` due to confusion; but syntactically marking the value to get out would probably be tricky [12:47:33.0000] i wish github had better code search [12:47:43.0000] you should go look at rust code that uses block expressions [12:48:09.0000] different languages have different common use cases; i'd want an example in JS where you'd use this [12:48:19.0000] i have some logic [12:48:21.0000] inside a block [12:48:31.0000] that necessitates returning [12:48:41.0000] then why do you need to capture the value of the block [12:48:49.0000] ljharb I think I get where you coming from: those are expressions and not blocks [12:48:59.0000] because its conditional or smth idk [12:49:04.0000] right, it's "do expressions" not "do blocks" [12:49:10.0000] devsnek: lol well if you don't know then how is it a use case [12:49:11.0000] so maybe the bracked syntax is what's confusing me (and I expect it would confuse other folks as well) [12:49:22.0000] ljharb: i have specific code i would like to write [12:49:26.0000] but i don't think that's important [12:49:40.0000] and in this case try/catch and if/else shouldn't be allowed, right? since we're avoiding any kind of control flow [12:49:53.0000] what [12:50:04.0000] y'all seem to really be missing the point [12:50:07.0000] (not saying I'm agreeing with it) [12:50:16.0000] devsnek: without code, how can we avoid missing it [12:50:26.0000] mmarchini: nah, exceptions are fine [12:50:27.0000] the real goal of do exprs is the wish that we could have "everything is an expression" in JS [12:50:29.0000] mmarchini: expressions can still throw [12:50:37.0000] rkirsling: but, explicitly instead of implicitly [12:50:54.0000] rkirsling: i actively don't want implicit expressions everywhere, i *like* the statement/expression dichotomy, and wish functions aren't both [12:51:02.0000] ljharb: why do you not believe i would want to use return inside a block [12:51:02.0000] i [12:51:09.0000] i'm sure you've used return inside blocks before [12:51:14.0000] devsnek: i use return inside blocks all the time, that's not the issue [12:51:25.0000] devsnek: i'm not understanding why you'd do that *and* want to capture the value of the block [12:51:29.0000] ah okay. I would just as well not have statements in a language myself, but regardless, implicit would be quite a language revamp [12:51:31.0000] because both are useful [12:51:33.0000] orthagonally [12:51:39.0000] therefore `do { ... }` is explicit [12:51:48.0000] devsnek: i'm not disputing it, i'm asking for a single non-contrived concrete example of it being useful [12:52:04.0000] ljharb: expanding my macros in engine262 [12:52:12.0000] can you link me to an example? [12:52:30.0000] ljharb: because capturing the value of the block is the entire point [12:52:38.0000] https://github.com/engine262/engine262/blob/master/scripts/transform.js [12:53:15.0000] but I would think that that means that `do` just means putting a _scope_ around "everything is an expression" and not restricting what (would-be) statements are allowed in there [12:53:42.0000] like `do if () {}`? [12:53:44.0000] https://www.irccloud.com/pastebin/2hSLTTCi/do-expression-return.js [12:54:22.0000] You can't always devolve an the remaining part of a block into an else condition. [12:54:24.0000] devsnek: tbf `do if` is just somebody complaining about ternaries [12:54:53.0000] rkirsling: ternaries don't allow variable delcarations [12:55:03.0000] jridgewell: everything after an if+return is implicitly the else bock [12:55:04.0000] do with return gets really weird/new [12:55:04.0000] block [12:55:08.0000] Blocks are necessary to cleanly express a lot of code [12:55:31.0000] devsnek: You can't always devolve an the remaining part of a block into an else condition. [12:55:41.0000] i think its a good idea, but doubt we should use the `do` keyword due to how gross the `do...while` interactiom is [12:55:42.0000] why can't i refactor any `let x; ` to `let x = do { }` [12:56:02.0000] My code example is contrived, and is just meant to demonstrate early return [12:56:13.0000] jridgewell: ok so can you give me an example of when you *can't* devolve the rest of the block into an else? [12:56:24.0000] jridgewell: you want to early return to the end of the do block? [12:56:31.0000] jridgewell: i'm not saying "there are none", i'm saying "please give me one because nobody seems to be capable of doing that so far" [12:56:38.0000] i've never not been able to devolve into an if+else in rust [12:56:40.0000] At the beginning [12:56:41.0000] jridgewell: to be clear I meant `do if` as opposed to `do { if {} }` [12:56:59.0000] jridgewell: i've never encountered something that can't be [12:57:08.0000] const x = do { [12:57:29.0000] ? [12:58:08.0000] This can't be cleanly develoved into an if-else. https://www.irccloud.com/pastebin/bmg0madZ/do-expressions.js [12:58:25.0000] Again, contrived. [12:58:42.0000] But every set if conditions can't be cleanly devloved into an if-else. [12:58:48.0000] it can be [12:58:52.0000] But not** [12:58:58.0000] it would take a few minutes of thinking [12:59:02.0000] **cleanly** [12:59:06.0000] and i'd argue that's spaghetti with or without do expressions [12:59:12.0000] I don't want to repeat `doSomething()` [12:59:55.0000] It's a fallthrough, which is very valuable. [13:00:06.0000] jridgewell: sure it can `if (first) { if (second) { something; } else { doSomething(); } } else { doSomethingMore(); value; }` [13:00:30.0000] and then you return that entire thing wrapped in `do { }` [13:01:27.0000] Nit picking my example isn't really the point. [13:01:30.0000] i'm still seeing some very smart people struggling to come up with a single non-contrived concrete example of where it'd be useful to have return/break/continue inside a do expression, which doesn't bode well for the persuasiveness of the argument [13:01:35.0000] i think assigning to a var might be part of the issue with this basis, putting them inside awkward expression positions feels more concrete: `foo({x: existing ?? do { try { /*expensive*/ } catch { /* better message here */ } })` [13:01:37.0000] Do this with a for-loop, where you early return. [13:01:40.0000] jridgewell: i've literally only ever seen logic that contrived in my js lexer [13:02:02.0000] bradleymeck: that example is fine, there's no return/break/continue in it [13:02:25.0000] ljharb: i mean i can make a return based example in there [13:02:27.0000] y'all should really try using some languages with this behaviour [13:02:35.0000] such as things that fail silently [13:02:40.0000] bradleymeck: i'd love to see my first non-contrived one [13:02:57.0000] i don't think contrived is a valuable position [13:03:05.0000] we have a turing complete language, everything is contrived [13:03:56.0000] ljharb: it occurs to me you can have a no-return-in-do-expression eslint rule [13:04:01.0000] i'd lean on allowing usages rather than trying to pin the language down to only having 1 way to accomplish anything [13:04:44.0000] devsnek: sure, but why add burden for those that lint if there's not a compelling argument to allow it in the first place [13:04:52.0000] well we shouldn't have 20 ways to accomplish something, but you should be able to compose features into new ways of using them [13:05:00.0000] ljharb: i would use it [13:05:31.0000] i feel like 95% of my arguments turn into people saying my use cases aren't valid [13:05:34.0000] devsnek: and all i've been asking for is, to see some JS code where you'd use it :-/ [13:05:42.0000] ljharb: i linked you to an example [13:05:46.0000] i'm not saying your use cases aren't valid, i'm saying "please give me > 0 use cases" [13:05:47.0000] `for (...) { results.push(do { try { ... } catch { continue } }) }` [13:05:50.0000] devsnek: in JS? or in rust [13:05:52.0000] that transform code isn't even feature complete [13:05:58.0000] i linked you some js [13:06:38.0000] oh, let me take a look [13:06:39.0000] bradleymeck: more generally, wherever you'd normally want to express control flow, you might want to do so if that logic happens to occur inside a do expression [13:06:55.0000] devsnek: any lines in particular? [13:07:08.0000] ljharb: the entire thing is a system to restructure random expressions into using control flow [13:07:12.0000] devsnek: i mean thats the complaint with arr.forEach in general vs loops [13:07:48.0000] and like i said its not complete, there are certain ways you can't use macros in engine262 because i haven't figured out how to transform them correctly [13:07:52.0000] the only thing with do expressions is they can live in an expression position [13:09:09.0000] so, things that want to skip an effect while being in an expression position such as the .push example above are prime examples [13:09:16.0000] the argument i did find interesting was that someone would be confused about return inside a do expression and whether it returned the block or the enclosing function [13:09:39.0000] but i think that's more of a general language education problem [13:09:43.0000] you could refactor things into a lot of statements, or you could keep the bailout logic in the literal 🤷 [13:10:56.0000] for what it is worth, i think return/continue/break are scary, but have no clear reason to argue against them as you could refactor things to be done w/o do expressions anyway; that just makes it more verbose / may increase loss of locality [13:11:18.0000] labelled break/continue are super interesting here [13:11:27.0000] labels are illegal [13:11:43.0000] in the proposal? we have power to alter such things [13:11:56.0000] no i meant in general, it was a joke [13:12:06.0000] i use labels! [13:12:12.0000] i've only used labels once [13:12:21.0000] for lexing whitespace in js [13:12:33.0000] nested loop sadness [13:12:33.0000] i use em in bad places [13:12:38.0000] like_here: debugger; [13:12:49.0000] why do you label a debugger statement [13:13:00.0000] gives me my debugger operands proposal effectively /cackling [13:13:13.0000] wait i don't think that syntax is even valid [13:13:38.0000] LabelledStatement and DebuggerStatement are both productions of Statement directly [13:13:58.0000] browsers think it is [13:14:11.0000] wait a second [13:14:15.0000] LabelledItem is any statement [13:14:18.0000] this changes everything [13:14:23.0000] yes, they can even nest [13:14:27.0000] if i remember [13:15:16.0000] what does it change? [13:16:07.0000] devsnek: are you just gonna add a ton of labels? [13:16:20.0000] lol it doesn't actually change much [13:16:29.0000] i just never realized you could label things that aren't loops [13:16:49.0000] i thought you were about to do something weird like [13:17:04.0000] return_if_abrupt: foo(); [13:17:40.0000] you can break to a label without a loop as well, i think [13:17:56.0000] yea [13:18:37.0000] aw i was hoping this would work `x: { console.log('hi!'); while (true) { continue x; } }` [13:19:28.0000] nah, just break [13:19:50.0000] also TIL break is not constrained to loops [13:19:57.0000] what a wild world [13:20:15.0000] why would it be? [13:20:48.0000] what are you breaking if you aren't in a loop [13:21:12.0000] the quality of your code [13:21:15.0000] lol [13:21:18.0000] `x: { console.log('hi!'); break x; console.log('bye') }` [13:21:22.0000] so this doesn't log bye [13:22:37.0000] you could use that for early return in do expressions [13:28:24.0000] that isn't the same, the completion value would carry over rather than stop outer scope [13:30:29.0000] jridgewell's example https://gc.gy/53996426.png [13:31:19.0000] devsnek: fwiw i don't mind anything that breaks out of the do expression; but that you could put the label anywhere seems like it'd be bad [13:31:31.0000] wdym [13:31:34.0000] devsnek: so like, i'd be ok with a do-expression-level unlabelled break [13:31:49.0000] unlabelled break has to go to the enclosing loop [13:31:57.0000] not if it's inside a do expression [13:32:19.0000] (you can make a consistency argument that it must, sure, but i'm saying it could have different semantics there) [13:32:32.0000] why do things have to randomly be different inside the block of a do expression [13:33:34.0000] things are already that way, because of the completion value [13:33:38.0000] it's not a problem to use if/else in rust [13:33:40.0000] no other blocks are expresisons [13:34:06.0000] wait, was the statement about `break` just in the context of do exprs? [13:34:18.0000] rkirsling: which statement [13:34:30.0000] the idea that you could use it as goto in general [13:34:37.0000] no, you can already do that [13:34:42.0000] how? [13:34:49.0000] outside of a loop, you can't use an unlabelled break; but you can use a labelled break anywhere [13:35:04.0000] you can't use it as goto [13:35:17.0000] that's deeply horrifying but also I can't get that to happen in eshost whatsoever [13:35:39.0000] https://gc.gy/53996740.png [13:35:59.0000] oh hm, maybe it's only out of blocks [13:36:04.0000] you can't jump [13:36:23.0000] ahh if it's just "break out of block" I'm less horrified [13:36:27.0000] `(function () { x: console.log('a'); break x; }())` says "undefined label x" [13:36:30.0000] ok yeah same [13:36:44.0000] phew [13:37:01.0000] anyway [13:37:07.0000] people who are concerned about early exit from do expressions [13:37:14.0000] should try out languages which have blocks as expressions [13:37:31.0000] because its basically not a problem [13:37:46.0000] like every once in a while you have to refit something to be if/else but it's very trivial [13:38:44.0000] ECMAScript allows expressions in places like variable initializers [13:39:11.0000] it allows them in lots of places [13:39:15.0000] almost anywhere in fact [13:51:26.0000] more specifically, ECMAScript allows expressions in places where it _doesn't_ allow control statements [13:52:18.0000] it allows them in places where it doesn't allow statements [13:52:26.0000] control or otherwise [13:52:29.0000] a pathological example from an earlier meeting was something like `function foo(a = do { return }){}` [13:52:49.0000] ^ that is something that imo shouldn't be possible [13:53:26.0000] 🤷🏻 https://gc.gy/53997804.png [13:53:31.0000] seems well defined enough [13:53:59.0000] i'd expect a no-do-in-arg-init eslint rule regardless of whether they can contain control statements [13:54:38.0000] perhaps, but i wouldn't enable it [13:54:48.0000] why not [13:54:59.0000] why shouldn't it be possible [13:55:02.0000] is what i'm curious about [13:55:31.0000] rkirsling: i wouldn't enable it because i don't think there's a problem with using a do expression as a default argument - in place of the places that might currently invoke a function instead [13:55:41.0000] well actually i know why it shouldn't be possible [13:55:57.0000] devsnek: in general, i lean towards all things should be prohibited unless its good usage outweighs its bad usage [13:56:03.0000] now do `function foo(a = do { continue }){}` [13:56:08.0000] it shouldn't be possible because arg init shouldn't be +Return [13:56:11.0000] i already have some "do" via iife in default arge for throwing [13:56:42.0000] gibson042: arg init can't contain an outer loop [13:56:45.0000] it's at the function boundary [13:56:56.0000] that's always an unsyntactic continue [13:57:19.0000] gibson042: the key here is that function arg init shouldn't be +Return, regardless of whether do expressions exist or not [13:57:36.0000] agreed [14:01:33.0000] breaking non-loops is useful in almost exactly the set of cases when an early return is useful, it's just that usually you would refactor that code to use a function with an early return rather than keeping it inline. but that's not always something you want to do. [14:02:29.0000] yeah i pointed that out above with jridgewell's example [14:04:20.0000] most of the places i've ended up emitting a non-loop with a label are in generated code [14:04:37.0000] ljharb: re: grapheme clusters being locale-dependent, the example which always occurs to me is, there are some flags which correspond to entities whose status as "a state" (and therefore which qualify for a flag) is a matter not everyone agrees upon [14:04:48.0000] i've never even seen that in generated code [14:05:00.0000] would love to see some examples [14:05:12.0000] which means flag emoji +ZWJ+their country code may, or may not, be a single character [14:05:25.0000] devsnek: code I'm generating tends to be proprietary, alas [14:05:46.0000] oh this is code *you're** generating [14:06:22.0000] well, it is code which tools I wrote are generating, at any rate [14:06:37.0000] Bakkot: oh meaning like taiwan, or palestine, to name the most controversial examples i can think of? [14:06:39.0000] i'm curious what higher-level control flow mapps to that output [14:06:51.0000] ljharb I was extremely carefully in not naming examples :P [14:06:59.0000] but yes [14:07:45.0000] Bakkot: that makes sense, but it still seems like something that could be addressed in a generic way (but Intl/locales could decide) [14:08:11.0000] Bakkot: I thought all the regional flags used regional indicators, which are always grapheme clusters per the default rules [14:08:12.0000] devsnek the higher level control flow is usually functions which have early returns which I am inling [14:08:21.0000] i see [14:09:00.0000] gibson042 the regional indicators may or may not be joined into a single unit depending on whether the code you're running recognizes that falg [14:09:17.0000] default rules include "Do not break within emoji modifier sequences or emoji zwj sequences" and "do not break between regional indicator (RI) symbols if there is an odd number of RI characters before the break point" [14:10:01.0000] it's not breaking between the RI symbols, is whether you end up with just a colored flag (one grapheme), or a white flag + a regional indicator (two graphemes) [14:10:43.0000] now i kind of want to write a babel transform that does function inlining using labels [14:11:06.0000] that presentation detail is not relevant to grapheme cluster boundaries [14:11:43.0000] I suspect it is relevant to the thing ljharb wants, though [14:16:29.0000] i think i'd be content with the default 262 impl being the default rules, and 402 imposing the locale-dependent ones on top of it [14:16:54.0000] (assuming it would do the "right" thing in most cases) [14:21:23.0000] would be interested in hearing from engines that have no intention to implement 402 though [14:21:33.0000] if there were commitment to put it in ECMA-262, that would seem to be the best approach (specify default rules and let ECMA-402 override, similar to but better than how ECMA-262 specifies toLocale*) [14:22:03.0000] as of today, the default rules appear to require no information not already required of regex \p [14:22:22.0000] rkirsling: you can compile node to node include intl, and i don't think xs does [14:22:26.0000] *to not include [14:22:38.0000] rkirsling: node < 12 or 13 didn't include it by default, iirc [14:22:42.0000] yeah XS doesn't, is a key example [14:22:49.0000] gibson042: thanks, that sounds good [14:23:18.0000] my point is that engines that do implement 402 have ICU to use, even for a feature that might be 262-side [14:23:34.0000] but XS would have to reimplement and maintain this logic themselves [14:24:05.0000] right [14:31:34.0000] but I don't know if it makes sense or not... grapheme cluster segmentation seems to occupy a gray area between code unit/code point segmentation (trivial, deterministic, time-invariant) and word/sentence segmentation (difficult, locale-dependent, and time-dependent) [14:33:50.0000] yeah :-/ [14:34:21.0000] regex \p is a good point though, I wonder whether XS would opt out of that too [14:38:05.0000] (I mean, they are currently opting out, but the question is would they ever change that) [14:39:37.0000] in the fullness of time, they'd have to implement anything that wasn't normative optional, no? [14:41:00.0000] in theory, though I feel like that's kind of a new concept in 262 outside of Annex B? [14:41:36.0000] well, function toString returning source is normative optional via the host hook :-p [14:42:42.0000] I guess I just mean that that phrase occurs in 402 but not in 262 at present [14:43:46.0000] oh, sure [14:44:11.0000] but i doubt they'd be able to get away with not implementing regex `\p` and still be 262-compliant [14:46:37.0000] certainly, but they consciously ship with caveats: https://github.com/Moddable-OpenSource/moddable/blob/public/documentation/xs/XS%20Conformance.md#caveat [15:06:49.0000] ljharb: backing up a step, I feel like grapheme segmentation is a thing I am unlikely to care about on platforms which lack Intl; is there a specific reason you care about having it on non-Intl platforms? [15:11:50.0000] i don't feel like i can rely on Intl in any of my code, because i want my code to be as portable as possible. i don't have a concrete use case for this right now, it's not a proposal :-) just asking out loud [15:20:32.0000] it's a worthy discussion, but I'm not sure a portability argument holds water, if the places where it wouldn't work (in the long-term) are just memory-constrained places like microcontrollers [15:20:48.0000] I don't think other engines are opting out so much as deprioritizing it? [15:21:36.0000] (btw I'm removing JSC's ENABLE_INTL define as we speak 😉) [15:30:49.0000] removing it so it's always on? [15:31:05.0000] removing it so its always off [15:31:16.0000] sad trombone noises [15:31:29.0000] on! [15:31:36.0000] happy trumpet noises [15:31:38.0000] wherefore this disinformation [15:31:42.0000] lol [15:31:56.0000] now if we can just convince v8 to always ship intl [15:32:04.0000] gonna assume the Intl object exists and then we can just runtime-guard new classes [15:32:50.0000] (there was only one upstream platform flipping it off, is why this should be okay to simply do as maintenance) 2020-04-08 [18:12:54.0000] devsnek: has there been such a discussion? [18:19:27.0000] rkirsling: i don't think so [18:19:39.0000] oh hm [18:19:45.0000] but v8 has very strict binary size requirements [18:19:55.0000] interesting 🤔 [18:20:45.0000] I got a comment that there are nonzero people using JSC downstream for embedded systems that would prefer to leave it disabled, but [18:21:09.0000] we wouldn't have any bots to verify that everything continues to work without it anyway... [18:40:05.0000] binary size is very important for mobile, not just embedded [18:40:14.0000] v8 cares because android cares aiui [18:40:25.0000] that's fair [18:40:56.0000] iOS evidently doesn't share that concern [18:41:14.0000] i think i will refrain from commenting [18:44:08.0000] 😅 [01:26:21.0000] rkirsling, does jsc ship with its own icu on ios [02:18:30.0000] Cocoa platforms make use of system ICU [02:19:08.0000] so yeah, that would lessen the load [04:51:55.0000] Does the name "Dave Poole" ring a bell for anyone? [06:51:38.0000] ystartsev: vaguely but not of any particular memory [12:37:47.0000] there's an event "MF-Chair Group Meeting" on the TC39 calendar, but i don't recognize any of the names on it. is that possibly "messageformat"? 2020-04-09 [15:42:07.0000] rkirsling: mind rebasing https://github.com/tc39/ecma262/pull/1860 ? [15:45:32.0000] ljharb: sure [15:46:33.0000] thanks [15:46:44.0000] (implied is, please make sure any interim changes are updated) [15:47:08.0000] but of course :) [15:49:01.0000] <3 [16:26:21.0000] hmm so [16:26:29.0000] (sorry for delay) [16:26:56.0000] there's only one new instance of `` constructor but [16:27:29.0000] there are a couple of places with `` object, where I claimed in the PR description that that wasn't the case [16:28:27.0000] I wonder if I should deal with the third paragraph here as well? [16:28:28.0000] https://tc39.es/ecma262/#sec-ecmascript-overview [16:28:57.0000] otherwise the PR currently claims to just deal with "~ constructor" and "~ behavior" cases so I could leave it [16:29:09.0000] seems ok to leave it for now [16:29:41.0000] kk [16:31:28.0000] just gonna deal with one obvious case of "an `Error` object" [16:40:59.0000] ljharb: 'tis done [16:42:05.0000] great, thanks! 2020-04-10 [00:15:14.0000] umm I think however test262 report is running JSC needs to be updated, lol [00:15:15.0000] https://test262.report/?date=2020-04-07 [00:15:46.0000] I assure you our overall conformance did not drop to 45% lol [00:20:27.0000] (that V8 jumped from 89% to 96% in one day also seems quite dubious...the test count didn't even change on that day) [00:27:13.0000] (hmm, I mean it is possible that a bunch work to perfect the implementation of classes was landed all at once, I guess? but if so, damn, I tip my hat) [00:29:19.0000] anyway the JSC situation is almost certainly due to our ICU upgrade but I have no idea what test262 infra is doing wrong there [07:19:14.0000] https://test262.report/browse/language/module-code/namespace/internals/set.js [07:19:19.0000] everything is failing this test [07:20:52.0000] probably because it expects the assignments to throw [07:25:54.0000] oh wait its a module the assignments would throw [07:27:01.0000] weird it passes locally [07:38:35.0000] doesn't pass when using test262-harness https://gc.gy/54234503.png [07:42:02.0000] hah https://github.com/tc39/test262/pull/2574/files [08:50:57.0000] rkirsling, v8 shipped private methods/accessors last week [09:14:46.0000] rkirsling: all the strict tests are failing, must have something to do with how they're being concatenated or something [09:52:50.0000] gsathya: oho [10:55:23.0000] really, private methods and accessors is 7% of all test262? [10:57:47.0000] it's the main reason i'm in the 80s instead of the 90s in test262.report [10:58:42.0000] my guess is that a lot of those tests are generated, so there's more of them. test generation is relatively new to test262 so the generated tests tend to correspond to new features, which means new features have more tests. [10:58:53.0000] but that's just a guess. [10:58:55.0000] probably true [10:59:08.0000] it is a pervasive feature [10:59:18.0000] and yet 7% is such an enormous figure here [10:59:25.0000] I remain floored [15:28:46.0000] shu wrt test262 on private methods and accessors: too much for syntax variation and too many details to cover [15:30:34.0000] also, one thing that is distributed in many Test262 parts: destructuring assignment [15:30:45.0000] and binding [15:30:58.0000] you'll get a lot of that in any function form. [15:31:43.0000] leobalter: you saw about the test262.report infra choking on JSC though? [15:32:09.0000] not sure what ICU assumptions are being made but it must be related [15:33:03.0000] all the strict tests are failing [15:33:05.0000] rkirsling I have no more access to the test262.report repo [15:33:14.0000] oh ack [15:33:23.0000] I guess rwaldron then [15:33:32.0000] and I can't even say what's going on with the JSC tests. There are CI reports for each one [15:34:02.0000] yes, and I'm not sure if IRC would be the best way to reach out to Rick. [15:34:06.0000] I'd recommend the https://github.com/bocoup/test262-report-issue-tracker [15:34:12.0000] can do [15:34:20.0000] it would be cool if the error messages were made public [15:35:06.0000] rkirsling: https://github.com/tc39/test262/pull/2574#issuecomment-612248008 [15:35:36.0000] ohh wow [15:35:41.0000] it wasn't ICU after all [15:39:07.0000] so it's a bug in https://github.com/bterlson/test262-harness then? [15:42:30.0000] rkirsling it might be? let me update everything here [15:44:34.0000] wow, everything is wrong in my env, lol. [15:44:41.0000] 404 on installing JSC [15:46:36.0000] :oh_no: [15:47:39.0000] ok, I had a wrong version of jsvu and my PATH was messed up linking to it rather than the new version [15:47:56.0000] 404 webkit not found [15:52:41.0000] rkirsling confirmed, it's test262-harness [15:52:56.0000] probably eshost, but they are in the same family [15:53:32.0000] i looked at the test262-harness code, the error message implies it's something about a string receiver being turned into an object in sloppy mode, but the code path doesn't seem related at all [15:53:49.0000] "Expected no error, got TypeError: Attempted to assign to readonly property" [15:53:52.0000] node's `path.relative` is throwing saying it needs a string, but `argv._` should only ever contain strings [15:54:08.0000] (referring to the stack trace in the github comment linked earlier) [15:54:15.0000] it seems like the previous option for JSC's strict mode is now for some sort of Frozen Realms? [15:55:18.0000] what is "jsc's strict mode" and why would test262 be invoking it? [15:55:29.0000] eg node's strict mode, via v8, breaks tons of things and shouldn't ever be used [15:55:37.0000] (it's not "use strict", it's something wonky) [15:56:06.0000] it's use strict but literally everywhere [15:56:11.0000] i think there was some talk of removing it [15:56:39.0000] the patch was just enforcing strict mode in all classes: https://bugs.webkit.org/show_bug.cgi?id=205578 [15:56:46.0000] right but that breaks things [15:56:48.0000] sloppy code must be sloppy [15:57:19.0000] class bodies are always strictg [15:57:21.0000] strict [15:57:22.0000] true [15:57:56.0000] it is not meant to be breaking anything [15:58:15.0000] in particular, it did not cause any test262 failures [15:58:28.0000] ljharb on what's strict mode: most of engines have a strict mode by default from the cli as an argument [15:59:07.0000] leobalter: sure, but why on earth would we want to use a mode that breaks javascript, which is sloppy by default? [15:59:18.0000] like what's the value [15:59:34.0000] if your intention is to put use strict at the top of every script you run [15:59:40.0000] might as well save some labor and use a flag [15:59:42.0000] sloppy by default != sloppy by req [15:59:58.0000] lots of people tried to use it with node because they thought it'd be good to have everything be in `'use strict'` mode by default, but a) that's not actually what it does, and b) third party code relies on being in sloppy mode at time [16:00:01.0000] *times [16:00:06.0000] i don't like those flags [16:00:26.0000] it'd be reasonable if it meant "do what the strict pragma does by default" but that's not what v8's flag does. [16:00:36.0000] what's it do [16:00:37.0000] so i assume that's not what the strict flag does on other runtimes too [16:00:49.0000] it's been years, i'd have to check. it had subtly different semantics in various places [16:00:52.0000] ljharb back in 2015 (or close) we found syntax tests that were just passing but then we found many valid and useful errors for duplicating test execution both on sloppy and strict mode [16:01:06.0000] IIRC [16:01:38.0000] so then the test would be run again with a strict flag, though nowadays the better way to do that is to concat the struct pragma to the test source [16:01:41.0000] test262 tests everything in both modes unless it's explicitly said otherwise in the metadata [16:01:58.0000] right, what devsnek said. run the test once normally and once with "use strict" prepended [16:02:01.0000] devsnek if we do that, we duplicate literally all the tests [16:02:06.0000] you can do it on the fly [16:02:15.0000] test262-stream does it on the fly [16:02:25.0000] wait [16:02:27.0000] i think all implementer's test runners do it on the fly [16:02:34.0000] or most [16:02:50.0000] I'm confused. Test262-harness uses test262-stream, so it uses the pragma on the fly [16:02:55.0000] (tbh there's no point in keeping generated tests committed/on disk, if the test generation is fast enough) [16:03:03.0000] leobalter: ok then it wouldn't be using jsc's strict mode [16:03:03.0000] yes it does [16:03:25.0000] I worked more on other test262 runners than test262-harness (and family) [16:03:37.0000] so I'm confused rn on what each one does [16:03:55.0000] lol, I believe that WebKit's runner uses the cli [16:04:20.0000] I'm trying to remember. so if test262-stream is already doing it the correct way, I wonder what JSC is actually doing [16:04:45.0000] let me get a streamed file from test262 and run it with JSC directly [16:07:52.0000] oh wow i just found a major slow area in my test262 runner [16:08:22.0000] doubled me test speed with this one easy trick (CPUs hate me) [16:08:49.0000] https://gc.gy/54265119.png [16:10:06.0000] that's pretty neat, devsnek! are you reporting that in an issue? [16:10:13.0000] like, I can use it [16:10:19.0000] oh wait [16:10:21.0000] oh that's my personal runner [16:10:22.0000] that's your runner, right? [16:10:24.0000] oh [16:10:26.0000] not test262-harness [16:10:40.0000] I'd love to do some performance work on test262-harness [16:10:43.0000] did I just see a use case for logical assignment? :) [16:10:59.0000] yes [16:10:59.0000] I also wonder if I'll ever write a new runner for test262, lol [16:11:15.0000] i was thinking of going and rewriting all the agents in eshost at some point [16:11:46.0000] rkirsling: when i can do logical assignment in node i'll use it :P [16:12:06.0000] hehehe [16:12:34.0000] wao, `BigInt()` throws instead of defaulting to 0n, eh [16:12:52.0000] (not that I'd ever do that I'm just writing tests) [16:13:00.0000] devsnek: `realm.evaluateScript(includeCache[include] || fs.readFileSync(p, 'utf8'), { specifier: p });` [16:13:30.0000] leobalter: that doesn't fill the cache though [16:13:35.0000] oh I see [16:14:20.0000] It was my next question if you actually used that cache. This seems to save a big chunk of time due to io [16:14:59.0000] i run multiple tests inside the same process [16:15:05.0000] so yeah only loading the file once is good [16:15:14.0000] also gotta appreciate this https://gc.gy/54265476.png [16:16:34.0000] well, my child skipped his nap time and now my planned time for open source today is over. [16:23:29.0000] oh boy anonymous names were merged i can unskip so many tests 2020-04-11 [23:50:33.0000] rbuckton: why do ecmarkup and grammarkdown pass around cancel tokens? the only async things I can see that they'd be doing are file IO. [23:52:46.0000] i was confused by that too, why is cancellation needed [23:56:49.0000] I am going to maybe rip support for it out of them out of ecmarkup [23:59:06.0000] no one is using it, that I can see, and if you want things to be cancelable it's pretty trivial to accomplish that by passing in a `fetch` function which throws when cancelled or when called after it has been cancelled [23:59:53.0000] (where by "throws" I mean in the first place "causes the promise it has already returned to reject" and in the second place "returns a rejected promise", obviously, no zalgo here) 2020-04-13 [15:44:45.0000] is this a problem? https://github.com/tc39/ecma262/pull/1860#discussion_r407760589 [15:44:56.0000] at best it feels like a weird inconsistency [15:45:12.0000] the "Edit" comment, I mean 2020-04-14 [06:47:40.0000] heads up everyone, notes go up tomorrow [06:47:45.0000] please make sure you reviewed them [08:35:40.0000] akirose: bterlson: MylesBorins: do any of you know how i get write access to the TC39 calendar? [08:37:04.0000] I don [08:37:06.0000] 't [08:37:09.0000] but can ping chairs [08:50:52.0000] ty [09:30:29.0000] shu: i will give it to you [10:06:31.0000] ystartsev: littledan: MylesBorins: i'll try to write up a document laying out participation expectations of champion group, core stakeholders, and non-core stakeholders for these calls [10:06:46.0000] thanks [10:06:56.0000] for us to iterate on, that is [10:07:01.0000] good idea [10:07:07.0000] maybe in the how-we-work repo? [10:07:14.0000] +1 [10:07:17.0000] I think perhaps the problem with how I expressed it was more "lets prioritize based on blockers" not "if this isn't brought up y'all can't say anything later [10:08:04.0000] but I'm happy to augment my approach or thinking on these calls if that framing is not productive [10:10:29.0000] greeat [10:21:22.0000] great first meeting by the way. Some more concrete feedback from my side: This is just a brain dump of what i was thinking, you can decide if this is realistic or not. Some "structures" i could see making this really useful are the following "types": [10:21:22.0000] type 1: introduce major changes to the proposal or a new proposal for people to chew on (resource: readme / presentation with usecases and problems solved; expectation: clarifying questions, discussion points identified for new issues, follow on meeting expected), [10:21:22.0000] type 2: walk through a small set of issues for deep discussion (resources: the set of issues, max 3? max 1?; expectation: feedback per issue / questions and clarifications, follow on meeting expected), [10:21:23.0000] type 3: identify blockers (follow up meeting after a first meeting, resource: meeting notes + readme, expectation: deep discussion on identified blockers or issues, follow on meeting on this topic not expected), [10:21:24.0000] type 4: open "lets just talk about whatever comes to mind" (resource: the problem statement; expectation: whatever, no follow on expected). [10:21:25.0000] My preference would be to focus on one of these, and let stake holders know what is expected (read the explainer plus these issues) so that we don't rehash stuff. Also we should be careful about getting sidetracked -- for example the options bag discussion i think was something that could have been moved to a different forum. [10:22:58.0000] I feel like we really didn't do a good job of laying things out in a clear way. I regret the use of everyone's time. [10:23:13.0000] nah its fine, it was very similar to committee in a way [10:23:22.0000] plus this is a learning experience, i am really glad we are doing this [10:23:28.0000] I'd like to cycle through everyone else's topics before we get back to module attributes [10:23:33.0000] being the first is pretty hard [10:50:49.0000] ystartsev: very good feedback, i'll try to incorporate them in the document [10:56:34.0000] I do think the original format of doing multiple topics would be best. That's what I've found in outreach group calls [10:56:55.0000] Half an hour or 40 minutes could be spent on one "main" topic, with 10-20 minutes on some other topics [10:57:23.0000] so those topics where less time is spent may be more of "type 1" and the longer deep dive might be "type 2" for example [10:57:39.0000] the agenda can include links to supporting resources for people to prepare, as well as timeboxes [10:58:08.0000] I think module attributes needed something of "type 2", but our presentation style was sort of mixed between 1, 2 and 3 [11:02:52.0000] in general i want the guiding question to always be "would this discussion result in a more polished proposal for committee consideration at large?" [11:08:07.0000] hmm, in that case, maybe we should focus on earlier stage proposals [11:08:23.0000] module attributes is more in need of debating things out somehow than polishing [11:10:15.0000] people have several kinds of disagreements about what the goals shoudl be of things which involve module loading [11:12:31.0000] littledan: i wouldn't categorically exclude existential disagreements from incubator calls, especially if it's new [11:12:59.0000] but otherwise i agree, re-raising an existential disagreement is usually not going to be worked through in ~30-40 mins [11:13:01.0000] no, I definitely don't want to exclude any concerns people have [11:13:12.0000] I'm just thinking, what are the proposals which would benefit from this sort of polishing format [11:13:49.0000] ah [11:14:32.0000] thinking on it now, existential disagreements are great to surface, and i hope at the end of the call there is no misunderstanding on what the disagreement is [11:14:52.0000] i hope to better understand realms in exactly this way, for instance [11:20:50.0000] yes, I think it'll be a valuable discussion. At the same time, I've worked for a while with the Realms champions to polish Realms, and I doubt that "more polish" will come out of the discussion. [11:21:04.0000] and that's after they have spent years refining the proposal, of course [11:21:08.0000] i see what you mean, fair enough [11:21:33.0000] within the call, we might give guidance to some champion groups about what kinds of polish they should work on before presenting; that's just not the case with these groups [13:34:38.0000] Am I crazy or is there no apparent reason why iteratorClose checks that the iterator.return function returns an Object? [13:47:58.0000] you had me at "iteratorClose" [13:48:42.0000] but let me see [13:55:48.0000] keith_miller: https://github.com/tc39/notes/blob/master/meetings/2014-06/jun-5.md#closing-iterators and https://github.com/tc39/notes/blob/master/meetings/2014-06/closing-iterators.pdf [13:56:09.0000] keith_miller: dherman's slide deck suggests the object return type is mainly for symmetry with all other iterator methods [13:56:14.0000] and i suppose no one objected? [13:56:24.0000] weird [13:56:30.0000] ok, w/e [13:57:13.0000] Seems like that just adds a ergonomics overhead unnecessarily [14:00:51.0000] actually how do you even get out the final iteration result [14:03:13.0000] keith_miller: iterator return seems like an unnecessary overhead overall ¯\_(ツ)_/¯ [14:04:34.0000] ljharb: True, for-of is so complicated that it completely blows out all our inlining heuristics... [14:04:47.0000] So, we never inline anything that has a for-of loop [14:05:07.0000] dherman's slides also have the original motivation: async [14:05:18.0000] it concedes return for sync iterators seem not useful [14:05:41.0000] keith_miller: would it also be true to say you don't optimize them either? [14:06:11.0000] but now i'm just kind of confused how you even observe the returned object in iterator return [14:06:12.0000] no, they're optimized just they're too big to inline into another function so you'll always make a call to them [14:06:23.0000] keith_miller: ah k [14:06:27.0000] at least when called as part of an abrupt completion in a loop [14:06:43.0000] I guess you could say they're not optimized in that we won't infer things for the caller into the for-of loop but that's true for anything we don't inline [14:06:49.0000] gotcha [14:07:13.0000] shu: You don't other than to ensure it's an object lol [14:07:27.0000] that is a dumdum [14:07:37.0000] AFAICT, I could have missed something [14:07:51.0000] i implemented this too long ago now i don't really remember [14:08:10.0000] but i do remember being generally confused why it's there [14:08:16.0000] and how complicated it makes bytecode generation [14:08:45.0000] like, implicit try-finally around all iterator-protocol iterations, including destructuring [14:08:49.0000] kinda gross [14:16:06.0000] i really appreciate the existence of "closing-iterators.pdf" [14:17:35.0000] yes, especially after i recently found out that the link to one of my circa 2016 google sheets presentation is dead [14:17:54.0000] maybe i should export to pdf for the agenda/notes repos in the future [14:18:01.0000] that seems like a good idea in general [14:18:16.0000] we could probably build a bot to scrape all the slides links after every meeting [14:18:28.0000] it's possible that that sheets presentation was hosted on my old grandfathered, free gsuite instance [14:18:33.0000] and that's why it's gone [14:18:37.0000] speaking of bots [14:18:59.0000] i wanted to set up a thing that opens an issue in my engine262 repo every time someone pushes to ecma262 [14:19:17.0000] but that might require setting up a webhook in ecma262 [14:19:19.0000] which seems nasty [14:19:49.0000] it would, but that's not a huge deal [14:19:58.0000] for a known implementation [14:31:08.0000] or just having a script somewhere which checks the most recent commit every five minutes or whatever [14:31:42.0000] maybe [14:31:48.0000] polling works absent a webhook, true [14:31:48.0000] yeah the directionality seems wrong, feels weird to have the specs do the pushing [14:31:50.0000] i know gh actions can do cronjob syntax [14:32:04.0000] i'm not entirely sure where to store "latest commit processed" [14:32:05.0000] true, i use one to automatically keep forks up to date [14:32:15.0000] devsnek: make a git submodule, and use its sha as that marker [14:33:15.0000] hm maybe this https://help.github.com/en/actions/configuring-and-managing-workflows/persisting-workflow-data-using-artifacts [14:33:34.0000] i'll into this more after i finish rewriting the parser [14:34:13.0000] you can also just roll a gcp or aws instance. I have two or three scrapers running like this and they collectively cost me something like $5/yr, I think 2020-04-15 [17:33:26.0000] ljharb: I don't know how github templates work; if you do, want to fix the instructions in https://github.com/tc39/template-for-proposals#create-your-proposal-repo ? [17:56:56.0000] you just click this button https://gc.gy/54617214.png [17:58:47.0000] Bakkot: i'll fix the instructions in the template tho yes 2020-04-16 [17:58:39.0000] does anyone know off hand where we say that accessor properties are configurable:true? [18:00:26.0000] ah ha, last paragraph of here: https://tc39.es/ecma262/#sec-ecmascript-standard-built-in-objects [19:36:39.0000] "no fomo" as a goal [19:36:40.0000] lol [19:36:42.0000] love it 2020-04-20 [23:17:24.0000] Bakkot: wdyt about allowing `[\p{Seq}]`? the only remaining surprising cases are then negation (either through `[^...]` or `\P{...}`) [23:28:28.0000] mathiasbynens that feels... pretty weird at first glance? but it is possible that is just the novelty of it. [23:34:51.0000] mathiasbynens I guess that seems like it makes things worse, not better; my major problem with `\p{Seq}` in general is that a thing I am expecting to match one character is suddenly matching maybe more than one character and to figure out which it's going to do I need to go track down some table in unicode [23:35:22.0000] and expanding that so that `[]` now also maybe matches more than one character does not seem like an improvement [23:49:03.0000] Bakkot: yeah, I similarly hadn't seriously considered it before. I get it from the UTC perspective though: UTS18 has always allowed strings in character classes [23:50:02.0000] Bakkot: anyway, it's one of those things where if we throw now (like in the current proposal), we can always decide to loosen that up later [23:51:05.0000] OTOH, the discussion on whether character classes can match multiple code points influences the syntax discussion [23:53:11.0000] Bakkot: out of curiosity, why do you need to know if the thing that's matched is just one code point or more? [23:53:56.0000] with /u you already don't know if it's 1 UTF-16 code unit or 1 code point (which could be 2 such units), and that's a Good Thing(tm) [23:54:17.0000] this is the next step [23:59:19.0000] mathiasbynens the way I reason about regular expressions is by walking them over strings, one character at a time [23:59:45.0000] if we could redefine 'character' to 'glyph' everywhere then I could walk one glyph at a time [00:00:06.0000] but as long as `.` means one code point I am stuck with thinking about code points 2020-04-21 [18:19:55.0000] I can't be the only one jarred by the use of \mathbb{F} for floating point [18:20:12.0000] Bakkot and shu must feel it too [18:23:08.0000] is there a math definition of the domain of ieee floating point numbers [18:29:48.0000] are you saying the F should be in comic sans or something [18:30:00.0000] obviously yes [18:30:46.0000] hell yes [18:31:00.0000] I literally cannot think of a more appropriate use of comic sans [06:02:40.0000] I'd be fine with editorial revisions for this, I just don't want it to be \mathbb{R} [08:46:20.0000] F stands for Funny [11:48:46.0000] littledan: oh I was mostly joking 😅 it's true that \mathbb{F} is typically used for finite fields (https://mathworld.wolfram.com/FiniteField.html) but it's not like I have a better idea, and finite fields always have a constant subscript so it's technically not confusable either [11:49:14.0000] well, that's like F_5 or something, not 1_F, right? [11:49:38.0000] or you could also write it like <1_5> or something like that, right? [11:50:08.0000] yeah exactly [11:50:20.0000] yeah I should include finite fields when talking about applications of operator overloading [11:50:25.0000] it'd be a huge boon to something! [11:50:29.0000] :D [11:50:39.0000] or like rings in general really [11:51:43.0000] indeed [11:54:27.0000] littledan: unrelated, but did you have any thoughts about ICU version sensitivity in test262's 402 tests (commenting on your closed issue might not have been the optimal approach: https://github.com/tc39/test262/issues/1515#issuecomment-615998922) [11:57:35.0000] been working on Intl implementation stuff for the first time these past couple of weeks and it's often been time-consuming to determine where a specific locale data oddity is coming from [11:58:30.0000] responded to the comment [11:58:42.0000] can I suggest that you just try to target all the non-locale: tests at first? [11:59:41.0000] ultimately, it's going to be an issue for JSC if you can't use a relatively new ICU version eventually; some APIs will just be missing [12:00:53.0000] ah yeah, ignoring `locale:` would be one way to go [12:01:34.0000] missing APIs are one thing, we can #ifdef those cases [12:03:14.0000] unfortunately the ICU limitation can't go away due to not only Mac/iOS but also GTK and such [12:04:58.0000] I tried to move our minimum from (effectively) 55 to 62 (Mojave's system ICU version), but Ubuntu 18.04 LTS system ICU is 60.2, so that was a hard limit for Igalia 2020-04-22 [07:27:18.0000] rkirsling: Oh, hmm, I work with Igalians... I wonder if we could just #ifdef your feature out if the ICU version isn't high enough [07:27:27.0000] rkirsling: Who in Igalia gave you that limit? [07:27:59.0000] (or, what thread was this limit presented on?) [11:19:43.0000] littledan: we can always #ifdef out specific features, yeah. comment was here: https://bugs.webkit.org/show_bug.cgi?id=209694#c30 [11:22:07.0000] it's a pretty fair constraint, so long as system ICU for a given platform is involved... [11:35:31.0000] thanks for the reference; i'll talk with Carlos [11:36:48.0000] I'm not sure if Ubuntu needs to be the point of reference; at the end of the day, Epiphany could upgrade to a later version of ICU and package that, like Chrome and Firefox do [11:39:41.0000] just curious, are you thinking of using the new Intl APIs more in PlayStation? [11:45:10.0000] hoping to! [11:46:46.0000] it'd be super cool if app devs on our platforms didn't need to rely on moment.js or custom localized strings just for, e.g., relative time strings [11:48:46.0000] (meant to say "our platform", but I guess "platforms" isn't wrong since desktop/mobile is important for anybody) [11:49:06.0000] I guess the best I can do is make noise about "hey did you realize this is available? it's already there in the engine for you!" and have them push back against any "but do the strings produced actually meet our spec?" whining that arises [11:49:35.0000] yeah ultimately people could wrap it with something that gives other strings when they need it [11:49:41.0000] indeed [11:49:57.0000] anyway it's a great little endorsement if you think these things will be useful for your customers! [11:50:23.0000] and memory constraints are pretty important for us (since the hardware is for the games so our apps are supposed to be as lightweight as we can make 'em) so I think it could be a real win [11:50:57.0000] for sure! it's really neat stuff, I just didn't have time to jump into it before now [11:53:01.0000] rkirsling: Do you think it'd work out to develop features like Intl.RelativeTimeFormat in a way that the entire feature would just be omitted if a new enough ICU is not present? Would this be taxing from a maintenance perspective? [11:54:32.0000] we're OK if tests fail on older versions of ICU (either due to outdated data or APIs that are entirely missing), we just want WebKitGTK and WPE to be able to build using a variety of system libraries [11:55:19.0000] littledan: so my plan was originally to #ifdef formatToParts because I thought we needed ureldatefmt_formatToResult, but that turned out to be bug-ridden in ICU 64 anyway? so then I just implemented it in terms of NumberFormat's formatToParts, at which point I needed to go through which tests would succeed with which version, which was tedious, but ultimately I made it available to everyone, data bugs or not [11:56:33.0000] oh I see... yeah Chrome has historically shipped some workarounds like this too [11:57:20.0000] but it can get through somewhat more flexibly since it can make downstream ICU changes, since ICU is always bundled [11:57:28.0000] ah yeah [11:58:16.0000] I guess the WebKitGTK/WPE projects rely on the surrounding distro to maintain packages, which is why we have the more conservative policy. If it ever prevents you from making progress in Intl, let me know, but I guess you're unblocked anyway now. [11:58:28.0000] so I think the current plan is: if there's actually a "this doesn't exist before X version" then we'll #ifdef, otherwise I think we'll just let data bugs live? [11:58:44.0000] yeah, that plan sounds *100 emoji* to me [11:58:45.0000] oh yeah, I'm not viewing it as blockage [12:00:54.0000] good [14:01:26.0000] (yeah, seems like I was missing a lot of context on embedded toolchains; the situation is really complicated) [14:02:03.0000] yeah I'm not surprised :) 2020-04-24 [08:36:27.0000] at the last plenary someone mentioned something about a TC39 (or Ecma?) email list, which I'm definitely not a part of. should I be? how do I get added? [08:51:01.0000] mpcsh: Are you thinking of es-discuss? [08:51:25.0000] maybe? I really don't know. sounded like an administrative thing [08:51:50.0000] If it's admin, maybe the Reflector repo. [08:52:10.0000] (I wasn't at the last meeting, unfortunately.) [08:56:36.0000] mpcsh: there’s the delegates team on GitHub, and the old reflector list itself (which doesn’t really matter anymore), and es-discuss (which many people aren’t on), and es-discourse [08:56:57.0000] ah ok. as long as that's all there is I'm good [09:01:33.0000] yeah, maybe someone was talking about the old reflector [09:02:07.0000] Reflector is named Reflector because it used to be an email reflector [09:02:25.0000] which was infamously unreliable and would swallow messages iirc 2020-04-27 [07:48:42.0000] there still is a TC39 mailing list, but traffic is very low. However, it's still used sometimes, for example, the Ecma Secretariat decided to use it for the last editor election [07:49:00.0000] to update your enrollment in this list, contact the Ecma secretariat [07:49:11.0000] IMO we should basically never use these lists, because of their reliability issues [07:51:08.0000] the TC39 chair group uses an Ecma-managed list, and suffers reliability issues. We've raised these issues to the Ecma secretariat, but they always respond with excuses, suggestions to debug gmail itself, etc. [07:51:11.0000] I've been trying to convince the chair group to not use an Ecma list, and for us to avoid all use of Ecma infrastructure in any future election. However, there will probably always be some kind of Ecma-managed list, since Ecma will want some way to contact people that they control. [08:02:39.0000] is caridy and mark miller on here? [08:04:18.0000] Mark Miller is not [08:04:28.0000] unsure about Caridy [08:22:41.0000] Caridy comes in and out. (I pinged him on Twitter DM during the call but I don't think he saw it yet) [11:42:35.0000] that was fun :) [11:51:25.0000] Was a productive meeting getting us all to touch base. [12:54:57.0000] shu: fwiw, i have the tc39 calendar shown on my gcal display, and i didn't see the incubator call on it when i looked at my morning's schedule last night [12:55:51.0000] ljharb: i did not put one on for this call; i had some permissions issues when i first tried, and after i got that sorted out i forgot to add. mea culpa [12:55:56.0000] ahhh k [12:55:58.0000] np [12:56:22.0000] ljharb: not sure if you saw, but the final time also wasn't clear to the Realms champions, so with them being absent this call was cancelled anyhow [12:56:45.0000] i just saw that now, and was surprised/reminded that i was supposed to be on an incubator call this morning :-p [12:57:10.0000] indeed. i had only updated the reflector issue after the Doodle results, but realized in hindsight that wasn't enough publicity [12:57:19.0000] anyways, sorry again, will make calendar of truth going forward [12:57:27.0000] make calender source of truth* [12:57:51.0000] sgtm, ty 2020-04-30 [12:58:28.0000] could someone in the chair group give me admin permissions over https://github.com/tc39/proposal-pipeline-operator ?