| 00:27 | <ljharb> | https://github.com/tc39/proposal-pattern-matching/issues/155 |
| 00:30 | <rkirsling> | I mean I could be interested in co-championing |
| 00:30 | <rkirsling> | I've never done it and I do feel excited about the feature |
| 00:30 | <rkirsling> | I'm worried about needing to bikeshed about it with the entirety of the internet |
| 00:31 | <rkirsling> | but that's really my only worry |
| 00:31 | <littledan> | 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. |
| 00:32 | <ljharb> | rkirsling: that is very much likely to be the job |
| 00:32 | <ljharb> | rkirsling: including, managing opinions on github |
| 00:32 | <ljharb> | rkirsling: happy to move you to the top list tho if you like :-) |
| 00:33 | <rkirsling> | 😭 |
| 00:33 | <ljharb> | lmk |
| 00:33 | <rkirsling> | I'll sleep on it and get back to you |
| 00:33 | <ljharb> | kk, no rush |
| 00:47 | <TabAtkins> | 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. |
| 00:47 | <rkirsling> | doesn't have to be mutually exclusive, right? 😅 |
| 00:47 | <rkirsling> | I could probably learn from you folks on that |
| 00:52 | <rkirsling> | (basically the notion of a "champion group" is what's heartening me into wanting to do this :p) |
| 01:18 | <rkirsling> | also is the whole group being replaced? |
| 01:18 | <rkirsling> | including Brian and Sebastian? |
| 02:14 | <ljharb> | neither has been involved in the proposal for a long while; if either is interested in resuming they’ll be welcome |
| 02:28 | <rkirsling> | fair enough |
| 03:59 | <mpcsh> | 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. |
| 04:00 | <ljharb> | sgtm |
| 05:54 | <Bakkot> | sffc mathiasbynens gibson042: I have slides for tomorrow: https://docs.google.com/presentation/d/1COuuP_0fxK_s8-H8AScDMjMzKSEiAlAnOi4snP-OiHY/edit?usp=sharing |
| 05:54 | <Bakkot> | the summary of which is, I would like both kinds of escape to work in both kinds of regex |
| 05:56 | <Bakkot> | 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 |
| 05:57 | <Bakkot> | 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 |
| 05:57 | <Bakkot> | if you have thoughts on this I'd be happy to discuss more before it comes up again in plenary |
| 05:58 | <Bakkot> | (or, of course, once it has come up again in plenary, just, it would be ideal to resolve this in advance) |
| 06:03 | <rkirsling> | (I love the subtitle, hehe) |
| 06:08 | <mathiasbynens> | Bakkot: I appreciate the heads-up, will take a look today |
| 06:09 | <Bakkot> | mathiasbynens also we agreed to revisit for half an hour tomorrow |
| 06:10 | <Bakkot> | hoping we can get things to a point where we don't need the full time |
| 06:10 | <Bakkot> | _really_ hoping we get to a point where we don't need more than that, because that will force an absolutely excruciating process discussion |
| 06:19 | <mathiasbynens> | 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 |
| 06:19 | <mathiasbynens> | need to tokenize/parse |
| 06:19 | <Bakkot> | mathiasbynens ok, thanks for feedback |
| 06:20 | <Bakkot> | 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 |
| 06:21 | <Bakkot> | (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) |
| 06:25 | <mathiasbynens> | 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?) |
| 06:28 | <Bakkot> | 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. |
| 06:28 | <Bakkot> | I feel like these are pretty good reasons to regard it as not being open |
| 06:28 | <mathiasbynens> | Bakkot: littledan explicitly said he didn't think the IESH case through here: https://github.com/tc39/ecma262/issues/1861#issuecomment-604120402 |
| 06:29 | <Bakkot> | yeah, but we often get consensus on things which not everyone has thought through, and that doesn't automatically mean they're open |
| 06:29 | <Bakkot> | even if it turns out there's a genuine point of unclarity nearby |
| 06:31 | <Bakkot> | 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 |
| 06:31 | <mathiasbynens> | 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 |
| 06:32 | <Bakkot> | 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 |
| 06:32 | <Bakkot> | it _is_ obvious how to interpret SV of `\uLead \uTrail`, and engines implemented that behavior |
| 06:33 | <mathiasbynens> | Bakkot: I see how your current patch is the smallest possible change to fix the spec, I'm not debating that |
| 06:35 | <mathiasbynens> | 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 |
| 06:36 | <Bakkot> | Yeah, I get the history and the original intent |
| 06:36 | <Bakkot> | but we have shipping implementations which match the intent one would read in the spec text |
| 06:37 | <Bakkot> | 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 |
| 06:37 | <Bakkot> | for this reason I think it makes sense to consider the question not to be open _for the purposes of this bugfix PR_ |
| 06:38 | <Bakkot> | 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_ |
| 06:39 | <Bakkot> | *"rather than what it is currently being read to mean", not "to me" |
| 06:39 | <mathiasbynens> | Bakkot: i'm confused, don't shipping impls have to change anyway if your proposal goes through? |
| 06:39 | <Bakkot> | shipping impls have to make some new things legal, not make any currently legal things illegal |
| 06:40 | <mathiasbynens> | i don't think that's much of an argument in this case |
| 06:41 | <Bakkot> | the cases where they would be changing are specifically the ones where there is no single natural interpretation of the current spec text |
| 07:04 | <mathiasbynens> | i disagree that “making tooling as simple as possible” is a goal |
| 07:04 | <Bakkot> | you disagree that it is _a_ goal? |
| 07:04 | <Bakkot> | you think it ought to get literally no weight? |
| 07:05 | <mathiasbynens> | it can get some weight, but we’re overvaluing it here imho |
| 07:05 | <mathiasbynens> | if an asciifier gets the program `foo.𐊧` what does it produce? |
| 07:05 | <Bakkot> | foo['\uwhatever'], presumably |
| 07:05 | <mathiasbynens> | something like `foo['\uD800\uDEA7']` right |
| 07:06 | <Bakkot> | but anyway if we are overvaluing it what are we overvaluing it relative to? |
| 07:06 | <mathiasbynens> | yeah so the simple asciifier that doesn't need to parse anything doesn't exist |
| 07:06 | <Bakkot> | yes, asciifiers have to at least tokenize |
| 07:06 | <Bakkot> | but, like, they do |
| 07:06 | <Bakkot> | I have seen them |
| 07:06 | <Bakkot> | in production |
| 07:06 | <mathiasbynens> | i think it's fair for tooling that operating on source code to be able to tokenize that source code |
| 07:06 | <Bakkot> | bespoke asciifiers |
| 07:06 | <Bakkot> | _at banks_ |
| 07:06 | <Bakkot> | yes but they don't also have to parse regexes |
| 07:07 | <Bakkot> | they also, emperically, don't parse regexes |
| 07:07 | <Bakkot> | very few parsers parsed regexes until quite recently |
| 07:07 | <mathiasbynens> | can you point to a few of these asciifiers btw? just curious |
| 07:07 | <Bakkot> | no, they are customers |
| 07:07 | <mathiasbynens> | do you know of any opensource ones? |
| 07:08 | <Bakkot> | I end up seeing a lot of enterprise JS toolchains |
| 07:08 | <mathiasbynens> | that take JS source text as input |
| 07:08 | <Bakkot> | not off the top of my head; you could probably find some if you google |
| 07:08 | <mathiasbynens> | google? what's that |
| 07:10 | <Bakkot> | uglifyjs2 takes an `ascii_only` option |
| 07:10 | <mathiasbynens> | 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 |
| 07:11 | <Bakkot> | https://github.com/mishoo/UglifyJS2/blob/0d820e4c0a7a1b1eeee25fb632b9496a9780b28a/lib/output.js#L109-L119 |
| 07:11 | <Bakkot> | mathiasbynens but... that will work in all cases, no one says that shouldn't work |
| 07:11 | <Bakkot> | so I am confused why it is relevant |
| 07:11 | <Bakkot> | that symmetry will always be present |
| 07:12 | <mathiasbynens> | Bakkot: by symmetry I mean that whatever I put there instead of `𝒜𝒜𝒜`, it should work |
| 07:12 | <mathiasbynens> | Bakkot: your proposal breaks that |
| 07:12 | <Bakkot> | no human will put surrogate pairs there, so no human will be exposed to that asymmetry, so why does that matter? |
| 07:12 | <mathiasbynens> | Bakkot: heh, uglifyjs2’s ascii_only apparently breaks the simple `foo.𐊧` case (it outputs `foo.\ud800\udea7`) |
| 07:12 | <mathiasbynens> | so it sounds they have bigger problems than this |
| 07:13 | <Bakkot> | yeah but we don't need to make their tools more broken |
| 07:13 | <mathiasbynens> | does no human debug the bundle that is deployed to production ever? |
| 07:14 | <Bakkot> | occasionally, but not by editting the source |
| 07:15 | <Bakkot> | and the group name allows multiple representations anyway and no one says it shouldn't |
| 07:15 | <Bakkot> | so there is no possible new confusion here |
| 07:16 | <mathiasbynens> | by allowing \uLead\uTrail we’re introducing yet another representation though |
| 07:16 | <mathiasbynens> | one that breaks the symmetry |
| 07:16 | <mathiasbynens> | we could choose not to do that |
| 07:17 | <Bakkot> | how will the user be exposed to the fact that it breaks the symmetry? |
| 07:17 | <Bakkot> | they would have to write `match.groups.\uLead\uTrail` and find that it fails. but they are not going to write that. |
| 07:17 | <Bakkot> | so they will not be exposed to the fact that it breaks the symmetry. |
| 07:17 | <Bakkot> | so, why doe that matter? |
| 07:20 | <mathiasbynens> | they would if they happen upon source code of the form `/(?<\uLead\uTrail>.)/u` which you want to make valid |
| 07:20 | <mathiasbynens> | sure that code probably wasn't written by a human |
| 07:20 | <mathiasbynens> | it's not unreasonable to want to copy-paste the group name and place it `match.groups.<HERE>` |
| 07:21 | <mathiasbynens> | that’s how people use NCG |
| 07:21 | <ljharb> | if it has a backslash in it, i think it is |
| 07:21 | <ljharb> | that identifiers can have escapes is arcane nonsense that no normal human ever thinks of |
| 07:22 | <Bakkot> | 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 |
| 07:22 | <Bakkot> | because both forms of `\u` are legal and do the right thing in string literals |
| 07:22 | <mathiasbynens> | that’s what i’m saying. currently this confusion doesn't exist in this case. copy-pasting just works |
| 07:22 | <Bakkot> | it works but no one would try it |
| 07:22 | <ljharb> | right, nobody would try it |
| 07:22 | <Bakkot> | because no one thinks you can have backslashes in identifiers |
| 07:23 | <ljharb> | 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 |
| 07:23 | <mathiasbynens> | ok so let’s look at the current situation |
| 07:24 | <Bakkot> | 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. |
| 07:24 | <mathiasbynens> | the only way there'd be a backslash in the name currently would be if it used \u{…}, right? |
| 07:24 | <ljharb> | `var π` is reasonable, `var \u03c0` should never have been permitted |
| 07:24 | <Bakkot> | mathiasbynens depending on what you mean by "currently" |
| 07:24 | <mathiasbynens> | ljharb: but asciifiers!!1 |
| 07:24 | <Bakkot> | in shipping implementations, no, that's false, they can have the individually escaped surrogate pairs |
| 07:25 | <Bakkot> | in non-u regexes |
| 07:25 | <mathiasbynens> | we’re discussing the spec change |
| 07:26 | <Bakkot> | you are asking about "the current situation"; I'm asking which definition of current are you using |
| 07:26 | <mathiasbynens> | the current spec |
| 07:27 | <Bakkot> | 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 |
| 07:27 | <ljharb> | Bakkot: and that scenario should never imo have come to pass :-) obv the ship has long since sailed |
| 07:27 | <Bakkot> | ljharb yeah, like, in the shift-JIS days |
| 07:27 | <Bakkot> | _long_ sailed |
| 07:27 | <mathiasbynens> | if the current spec doesn't even allow \u{…}, then the symmetry holds |
| 07:27 | <mathiasbynens> | if the spec were to allow \u{…}, the symmetry would still hold |
| 07:28 | <Bakkot> | mathiasbynens the current spec is incoherent for non-u regexes, so it can't be said to allow or disallow either |
| 07:28 | <Bakkot> | ok I guess it actually can be said to disallow `\u{}` |
| 07:28 | <Bakkot> | for non-u |
| 07:28 | <Bakkot> | but I am willing to go along with this for the sake of argument |
| 07:29 | <mathiasbynens> | Bakkot: but that would make asciification impossible for that case, right? so a no-go |
| 07:29 | <mathiasbynens> | only if the spec allows \uLead\uTrail, the symmetry is broken |
| 07:30 | <Bakkot> | yes, I agree with this |
| 07:30 | <Bakkot> | 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 |
| 07:30 | <mathiasbynens> | ljharb: you’re saying escape sequences in identifiers are weird. also i think surrogates are weird. this is the combination of those two |
| 07:31 | <Bakkot> | I understand that the symmetry is nice |
| 07:31 | <Bakkot> | I was a mathematician, once upon a time |
| 07:31 | <Bakkot> | (I miss those days sometimes) |
| 07:31 | <ljharb> | mathiasbynens: surrogates are very weird, but people run into 💩 problems a LOT more often than they'd ever run into escapes in identifiers |
| 07:31 | <ljharb> | like, "not infrequently" compared to "basically never" |
| 07:31 | <ljharb> | emojis are super on trend |
| 07:34 | <ljharb> | mathiasbynens: anyways obv both are weird, but so are regexes in general because of the same allowing-escapes bs |
| 07:34 | <ljharb> | imo the non-weird thing would have been, no escapes at all, but it's also far too late for that |
| 07:35 | <mathiasbynens> | 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 `/(?<FOO>.)/u` & `match.groups.FOO` as “the same thing” |
| 07:35 | <Bakkot> | when there's no escape sequences involved, granted. |
| 07:36 | <Bakkot> | I dispute that anyone's mental model extends to cases where there are escape sequences. |
| 07:36 | <mathiasbynens> | Bakkot: no, in general |
| 07:36 | <mathiasbynens> | i'm talking generally |
| 07:36 | <mathiasbynens> | and here you’re adding a gotcha to that |
| 07:36 | <Bakkot> | then no, disputed. |
| 07:36 | <Bakkot> | but, like, ok, if we grant that for the sake of argument, then what? |
| 07:37 | <Bakkot> | they will never, ever be exposed to the fact that this absurd edge case breaks that symmetry very slightly |
| 07:37 | <mathiasbynens> | how is this disputable? it’s true in today’s spec, and you’re wanting to add an exception to this |
| 07:37 | <Bakkot> | so _why does it matter_ |
| 07:37 | <Bakkot> | mathiasbynens your claim was about what how people think |
| 07:37 | <Bakkot> | the spec is not especially relevant to that question |
| 07:37 | <ljharb> | how people think is definitely not related to what the spec says |
| 07:37 | <ljharb> | not tightly coupled, anyways |
| 07:38 | <ljharb> | i'd claim that no muggle has escape sequences in their mental model |
| 07:38 | <mathiasbynens> | you brought up escape sequences, which is arguably a spec thing |
| 07:38 | <Bakkot> | yes, and you brought up people's mental models, and the intersection of those two things is approximately empty |
| 07:38 | <ljharb> | this entire discussion is about something that simply doesn't exist in normal people's mental model |
| 07:39 | <mathiasbynens> | I agree! which is why I don't get the “when there’s no escape sequences involved” counterargument |
| 07:40 | <mathiasbynens> | most people wouldn’t think of that |
| 07:40 | <Bakkot> | most people would not realize that is a possible thing |
| 07:40 | <Bakkot> | so their mental model would not cover that case |
| 07:40 | <mathiasbynens> | well it isn’t currently |
| 07:40 | <mathiasbynens> | that’s my point |
| 07:41 | <Bakkot> | sorry, I don't see it |
| 07:41 | <mathiasbynens> | let’s keep the mental model simple |
| 07:41 | <Bakkot> | the mental model remains simple |
| 07:41 | <Bakkot> | because zero people will run into this edge case |
| 07:41 | <Bakkot> | zero |
| 07:41 | <ljharb> | even by accident. nobody looks at code that's output by tooling. |
| 07:42 | <Bakkot> | (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) |
| 07:42 | <mathiasbynens> | as someone who works on DevTools I cannot disagree more strongly |
| 07:43 | <Bakkot> | I do not agree with jordan's claim |
| 07:44 | <Bakkot> | but reading code output by tooling is not sufficient to run into this edge case |
| 07:44 | <Bakkot> | that is, to notice the asymmetry |
| 07:44 | <Bakkot> | you have to actually then go and try to write an escape sequence in identifier position |
| 07:44 | <rkirsling> | would uglify users typically end up with `match.groups.\u...` in prod code? |
| 07:44 | <Bakkot> | which is not going to be a thing very many people try |
| 07:45 | <Bakkot> | I feel confident in this claim |
| 07:45 | <mathiasbynens> | rkirsling: after setting ascii_only to true on https://skalman.github.io/UglifyJS-online/, enter `foo.𐊧` |
| 07:46 | <mathiasbynens> | rkirsling: it produces `foo.\ud800\udea7;` which is invalid |
| 07:46 | <mathiasbynens> | should be `foo['…']` |
| 07:46 | <rkirsling> | hmmm |
| 07:47 | <ljharb> | hm, that's for v3 |
| 07:47 | <ljharb> | v2 has the same problem? |
| 07:47 | <rkirsling> | 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 |
| 07:47 | <Bakkot> | 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 |
| 07:47 | <ljharb> | https://github.com/mishoo/UglifyJS2 is the one everyone seems to be using in my experience |
| 07:47 | <Bakkot> | except if we disallow `\u\u` in regexes |
| 07:47 | <Bakkot> | in which case the fix is also then "parse regexes" |
| 07:48 | <Bakkot> | which, like |
| 07:48 | <Bakkot> | that is a hell of a lot more work |
| 07:48 | <Bakkot> | (parsing to the point where you can identify a capture group name is substantially less work, but not totally trivial) |
| 07:49 | <Bakkot> | I feel like this, alone, out to outweight the <12 people who will ever notice the asymmetry you are concerned about |
| 07:49 | <mathiasbynens> | 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] |
| 07:50 | <Bakkot> | I just do not understand why you care about this symmetry so much |
| 07:50 | <Bakkot> | 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? |
| 07:50 | <mathiasbynens> | seems like i care more about the language and people reading code |
| 07:50 | <mathiasbynens> | whereas you prioritize making things easy for tooling |
| 07:50 | <Bakkot> | I care about _users_, first and foremost |
| 07:50 | <ljharb> | i'm a little confused about why you're focusing on dot access specifically |
| 07:50 | <Bakkot> | which means _not breaking tooling_, yes |
| 07:51 | <Bakkot> | because then websites break and people cannot get into their pharmacy |
| 07:51 | <Bakkot> | mathiasbynens but also, I reject your dichotomy |
| 07:51 | <Bakkot> | I care about the language and people reading code a great deal |
| 07:51 | <Bakkot> | however |
| 07:52 | <Bakkot> | I don't think this will affect basically any readers of code, and very very few writers of it |
| 07:52 | <mathiasbynens> | i didn't say that you don't care about these things (i know you do!) |
| 07:52 | <Bakkot> | 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. |
| 07:53 | <rkirsling> | tbf the fact that we do bring these very different perspectives to the discussion is really important |
| 07:54 | <rkirsling> | the pressure to rush the decision in today's session was very strange to me |
| 07:54 | <rkirsling> | (like, at the end of the day in particular) |
| 07:54 | <Bakkot> | rkirsling it comes from ecma basically |
| 07:54 | <Bakkot> | rkirsling we want to cut the spec, because ecma wants that and no one wants to fight them |
| 07:54 | <mathiasbynens> | ack. I understand your point, we just disagree about this. I think we’re overindexing on “tooling simplicity” here. |
| 07:55 | <Bakkot> | rkirsling and waldemar doesn't want to cut without resolving this. |
| 07:55 | <Bakkot> | 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? |
| 07:55 | <rkirsling> | Bakkot: yeah it's the last bit there that seemed more subjective |
| 07:56 | <Bakkot> | 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. |
| 07:57 | <mathiasbynens> | yeah, I understand that, and I agree we don’t want to break websites |
| 08:00 | <rkirsling> | (don't forget to rest up for another full day, folks 😁) |
| 08:00 | <rkirsling> | (g'night) |
| 08:01 | <Bakkot> | mathiasbynens ok, so... |
| 08:04 | <Bakkot> | 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 `/(?<FOO>.)/u` and `match.groups.FOO` |
| 08:04 | <Bakkot> | my position is, the latter number of users is very, very small |
| 08:05 | <Bakkot> | 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 |
| 08:05 | <Bakkot> | (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) |
| 08:06 | <Bakkot> | anyway yeah I've got to sleep; I'll read any overnight messages in this channel in the morning |
| 08:19 | <mathiasbynens> | 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) |
| 08:20 | <mathiasbynens> | 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{...}` |
| 10:12 | <mathiasbynens> | 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 |
| 10:12 | <mathiasbynens> | proposal 3* |
| 12:11 | <mathiasbynens> | moved it here: https://github.com/tc39/ecma262/pull/1869#issuecomment-607207764 |
| 13:29 | <gibson042> | Bakkot: the last slide claims that a code point interpretation for `/(?<\u{1d49c}>.)/` benefits tooling... how do you figure that? |
| 13:33 | <bradleymeck> | why can't we allow surrogate pairs to be moved to Identifier grammar outside RegExp as a 4th approach |
| 13:34 | <bradleymeck> | it would increase symmetry it seems to the same level as other ideas *and* allow surrogate pairs in named capture group ids |
| 14:38 | <mathiasbynens> | bradleymeck: agreed, that's an option too. personally i don't think exposing surrogates in more places is desirable |
| 14:40 | <bradleymeck> | mathiasbynens: undesirable or unacceptable? |
| 14:41 | <bradleymeck> | 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 |
| 14:42 | <bradleymeck> | another way to put it: if it is possible in *some* situations, but not in *all* situations. is there good reason to keep inconsistency |
| 14:44 | <mathiasbynens> | bradleymeck: several ES2015 features worked to remove the need for surrogates |
| 14:44 | <bradleymeck> | mathiasbynens: the need, not the capability to use |
| 14:44 | <mathiasbynens> | bradleymeck: sure, because of back-compat. we would if we could |
| 14:46 | <bradleymeck> | 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 |
| 14:46 | <mathiasbynens> | bradleymeck: this is like proposing to make some newer ES2020 APIs return `NaN` instead of throwing exceptions |
| 14:46 | <bradleymeck> | mathiasbynens: no, it is not. NaN has actively harmful / bug introducing effects historically |
| 14:46 | <mathiasbynens> | bradleymeck: and surrogates do not? |
| 14:46 | <bradleymeck> | how is allowing surrogates introducing bugs |
| 14:47 | <bradleymeck> | aesthetics are bad, I'd agree |
| 14:47 | <mathiasbynens> | surrogates are a common source of security issues |
| 14:47 | <mathiasbynens> | i'm talking about surrogates in general, not specifically this allow-escaped-surrogates-in-identifiers thing |
| 14:48 | <bradleymeck> | then give that angle as a reason for wanting inconsistency |
| 14:48 | <bradleymeck> | right now it hasn't been brought up as a reason to want inconsistency |
| 14:48 | <bradleymeck> | that seems a good reason |
| 14:49 | <bradleymeck> | just as ascii source text is a good reason to allow things |
| 14:49 | <mathiasbynens> | to be fair, I wasn't expecting this to be controversial and was assuming it to be widely known |
| 14:49 | <mathiasbynens> | surrogates are an objectively bad thing |
| 14:49 | <mathiasbynens> | i get that we're stuck with them in JS |
| 14:49 | <bradleymeck> | mathiasbynens: I've personally not had this issue come across my work |
| 14:49 | <bradleymeck> | so, thats probably similar for others |
| 14:50 | <bradleymeck> | we don't manually write the pairs though generally at work |
| 14:50 | <mathiasbynens> | 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 |
| 14:51 | <bradleymeck> | sure, but thats a different vector i'd think |
| 14:51 | <mathiasbynens> | lone surrogates are invalid characters, and cannot be represented in UTF-8 (that's why WTF-8 is a thing) |
| 14:51 | <bradleymeck> | to my knowledge, the id in the capture group could not be a lone surrogate |
| 14:52 | <bradleymeck> | and even with \u{ you could send a lone surrogate on a truncated packet to socket.io |
| 14:52 | <mathiasbynens> | it cannot. i'm explaining why surrogates are a Bad Thing we should avoid whenever we can in general |
| 14:52 | <bradleymeck> | (if you do something like send the JSON of a groups obj) |
| 14:52 | <mathiasbynens> | oh, i'm just talking about surrogates in general |
| 14:52 | <bradleymeck> | mathiasbynens: if the grammar does not allow the problem you describe of lone surrogates, is it applicable here |
| 14:53 | <mathiasbynens> | bradleymeck: there's nothing about \uXXXX\uXXXX that is somehow worse than what's already there in the language |
| 14:53 | <mathiasbynens> | i'm just saying... this is a known bad thing. ES2015 worked hard to hide it as much as possible from users. |
| 14:53 | <bradleymeck> | any split character would be problematic from my understanding of the socket.io problem (which I have encoutered!) |
| 14:54 | <mathiasbynens> | bradleymeck: yes, split/truncation is a common way to hit this indeed |
| 14:54 | <bradleymeck> | we still prevent split characters in the grammar |
| 14:54 | <mathiasbynens> | yes, i get that |
| 14:54 | <bradleymeck> | so, I'm unclear on how any ban actually removes a problem |
| 14:54 | <mathiasbynens> | again i'm not talking about this particular change |
| 14:54 | <bradleymeck> | the problem doesn't exist |
| 14:54 | <mathiasbynens> | i'm not claiming it removes a problem, i'm claiming it's a better solution than the alternatives |
| 14:55 | <mathiasbynens> | because we can get there without exposing surrogates (a Bad Thing!) in more places |
| 14:55 | <bradleymeck> | we are still introducing the split character problem in that location in your solution |
| 14:55 | <bradleymeck> | i don't see how your solution is any better at a glance given your concern of security |
| 14:55 | <mathiasbynens> | how? |
| 14:55 | <bradleymeck> | \u{ can still produce characters that split when serialized and are sent over the wire |
| 14:56 | <bradleymeck> | that is the concern of socket.io above |
| 14:56 | <mathiasbynens> | no, nothing about this change involves security. surrogates in general are tricky security-wise. there's nothing special about this one new change |
| 14:56 | <bradleymeck> | so, if you allow \u{ you have the same issue as \u\u |
| 14:57 | <bradleymeck> | so, if they have the same issue, why are you against \u\u in this context |
| 14:57 | <mathiasbynens> | we have a choice here. one option exposes the idea of surrogates to the user in syntax, the other doesn't. |
| 14:58 | <bradleymeck> | yes, but people are claiming that inconsistency with existing features is problematic |
| 14:58 | <mathiasbynens> | how is my proposal 3 inconsistent with any existing feature? |
| 14:59 | <mathiasbynens> | it's consistent with the ES2015 `u` flag, and the \u{...} it enables |
| 14:59 | <bradleymeck> | mathiasbynens: per waldemar's view the (?<id>.) id is a string->identifier, this leads to thinking that (?<id>.)id should function the same for some `id` |
| 15:00 | <bradleymeck> | having id do things in 2 different parts is the crux of the complaint of inconsistency |
| 15:00 | <bradleymeck> | while it is arguable we do want inconsitency |
| 15:00 | <bradleymeck> | i have not seen why in this context |
| 15:01 | <mathiasbynens> | not sure i understood that correctly, but let me try |
| 15:01 | <mathiasbynens> | in ES2015, the `u` flag by design enables `\u{...}` syntax. in non-`u`, `\u` just means `u`, and so `\u{` means `u{` etc. |
| 15:02 | <mathiasbynens> | following that logic, it seems reasonable to restrict the use of \u{...} within a capture group names to `u` regexps as well |
| 15:03 | <mathiasbynens> | the mental model then remains what is has been since ES2015: the `u` flag enables `\u{...}` syntax throughout the pattern |
| 15:04 | <bradleymeck> | however, the counterpoint is that for non-`u` regular expressions you could make any given source text of a regexp into ASCII previously |
| 15:04 | <mathiasbynens> | 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 |
| 15:05 | <mathiasbynens> | bradleymeck: you can still do that with proposal 3 |
| 15:05 | <bradleymeck> | 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 |
| 15:05 | <bradleymeck> | mathiasbynens: you can, but not under the constraints that keep being requested |
| 15:06 | <bradleymeck> | we need to identify which constraints we want to keep; we do not need to assert that there is one obvious solution |
| 15:06 | <mathiasbynens> | bradleymeck: i don't see why not? |
| 15:06 | <mathiasbynens> | astral identifier symbols do not work in group names within non-`u` regexps, whether used directly or through escape sequences |
| 15:07 | <mathiasbynens> | if setting the `u` flag enables their use, that again fits nicely with the ES2015 `u` flag |
| 15:07 | <mathiasbynens> | because it enables astral support in various regexp pattern contexts |
| 15:08 | <bradleymeck> | mathiasbynens: /(?<astral>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 |
| 15:08 | <bradleymeck> | mathiasbynens: this is not about stating that `u` enables things |
| 15:08 | <bradleymeck> | that doesn't relate to the goals |
| 15:08 | <mathiasbynens> | bradleymeck: where does this constraint come from? |
| 15:09 | <mathiasbynens> | why would you expect astral symbols within a non-u regexp to work? they don't work in any other context? |
| 15:09 | <bradleymeck> | mathiasbynens: waldemar's desire to have an asciifier that is context free within a regexp source text |
| 15:09 | <mathiasbynens> | i included asciified output for proposal 3 |
| 15:09 | <bradleymeck> | mathiasbynens: they work if they aren't escaped |
| 15:10 | <bradleymeck> | mathiasbynens: but it breaks the same behavior desire |
| 15:10 | <bradleymeck> | there isn't a desire for all things to behave the same, but for there to be some way that does behave the same |
| 15:11 | <mathiasbynens> | bradleymeck: what makes you say "they work if they aren't escaped"? the current spec? implementation reality? |
| 15:12 | <mathiasbynens> | as i said in the proposal, engines don't support `/(?<𐊧>.)/` (although adding `u` makes it work, as you'd expect) |
| 15:13 | <mathiasbynens> | so asciifiers don't even have to worry about this case. the transform I described takes care of it and preserves the early syntaxerror |
| 15:15 | <bradleymeck> | mathiasbynens: the concern is /\ud835\udc9c/.test('𝒜') does produce an astral character |
| 15:15 | <bradleymeck> | so inside the capture group id it doesn't behave the same |
| 15:16 | <bradleymeck> | 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) |
| 15:16 | <bradleymeck> | so, enabling pairs means pairs are always reliable |
| 15:16 | <bradleymeck> | we cannot make \u{ always reliable due to history |
| 15:17 | <bradleymeck> | 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 |
| 15:19 | <bradleymeck> | stating that we don't want to allow astral character in non-`u` seems an odd stance |
| 15:20 | <bradleymeck> | so if we do want to allow them, the desire for what we support is the question |
| 15:20 | <mathiasbynens> | bradleymeck: why? that's literally how non-`u` regexps behave w.r.t. astral symbols |
| 15:20 | <bradleymeck> | we can support only \u{ which means an inconsistency, we could only support \u\u which is legacy, or we could support both |
| 15:21 | <mathiasbynens> | there is no expectation that astral symbols, anywhere in a pattern, behave intuitively in non-`u` regexps |
| 15:21 | <mathiasbynens> | that's part of the reason the `u` flag was added, so we could fix those things |
| 15:21 | <bradleymeck> | mathiasbynens: that is not the opinion of all people involved |
| 15:22 | <bradleymeck> | so it isn't something we can assert |
| 15:22 | <mathiasbynens> | this is fact :/ |
| 15:22 | <mathiasbynens> | this is ECMAScript history |
| 15:22 | <mathiasbynens> | this is ES2015 |
| 15:22 | <bradleymeck> | 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 |
| 15:23 | <bradleymeck> | we can actively debate the history here which is an issue in itself |
| 15:23 | <bradleymeck> | i'm less interested in the history debate |
| 15:23 | <mathiasbynens> | i didn't expect it to be a debate tbh |
| 15:24 | <mathiasbynens> | bradleymeck: thanks for helping me understand this! |
| 15:24 | <bradleymeck> | mathiasbynens: either way, add a spec note about your intent in a separate PR and it might help us in the future |
| 15:26 | <mathiasbynens> | 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 |
| 15:27 | <mathiasbynens> | astral symbol support is known to be missing in non-`u` |
| 15:28 | <mathiasbynens> | expecting them to work within non-`u` named groups does not match this |
| 15:52 | <mathiasbynens> | bradleymeck: tried to clarify by posting https://github.com/tc39/ecma262/pull/1869#issuecomment-607332117 |
| 16:04 | <mathiasbynens> | Bakkot: what do you mean by "another"? I don't understand which other requirements are not met |
| 16:04 | <mathiasbynens> | https://github.com/tc39/ecma262/pull/1869#issuecomment-607335146 |
| 16:06 | <Bakkot> | mathiasbynens "another" meaning "I think we should not make life harder for chinese-language users" |
| 16:06 | <Bakkot> | this, I admit, was not a previously raised requirement |
| 16:06 | <Bakkot> | I just think it ought to be important |
| 16:07 | <Bakkot> | 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 |
| 16:08 | <mathiasbynens> | things are already broken in non-`u` though, that's why `u` was introduced. we cannot fix non-`u` behavior |
| 16:08 | <Bakkot> | and I see very little cost to allowing it |
| 16:08 | <Bakkot> | 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. |
| 16:09 | <Bakkot> | which are more about what the language allows you to write than about how it works. |
| 16:10 | <mathiasbynens> | it's already this broken in reality |
| 16:10 | <Bakkot> | 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 |
| 16:10 | <Bakkot> | yes, I agree it is already this broken in reality, I just think we ought to regard that as unacceptable |
| 16:12 | <mathiasbynens> | non-`u` is unacceptable tbqh |
| 16:12 | <Bakkot> | meh |
| 16:12 | <Bakkot> | people will continue using it forever |
| 16:12 | <Bakkot> | even me |
| 16:12 | <Bakkot> | I use regexes to process non-textual data stored as a sequence of 16-bit values |
| 16:12 | <Bakkot> | I realize this makes me a bad person but you can't stop me, nyah nyah |
| 16:13 | <mathiasbynens> | what's up with "regexen" btw? been meaning to ask since i saw the slides |
| 16:13 | <Bakkot> | old habit |
| 16:13 | <Bakkot> | one ox, two oxen; one regex, two regexen |
| 16:13 | <mathiasbynens> | ooh TIL |
| 16:14 | <Bakkot> | (ox -> oxen is one of english's many atypical pluralizations and does not actually generalize to this case, I just think it's funny) |
| 16:33 | <Bakkot> | 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? |
| 16:50 | <Bakkot> | 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? |
| 16:51 | <gibson042> | that doesn't save anything because the tool would _already_ need that "different way" for astral characters in the rest of the regex |
| 16:53 | <Bakkot> | 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 |
| 16:56 | <gibson042> | what's gained by asciifying `/(?<𝒜>𝒜)/` to `/(?<\u{1d49c}>\ud835\udc9c)/` rather than `/(?<\ud835\udc9c>\ud835\udc9c)/`? |
| 16:58 | <Bakkot> | 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. |
| 16:58 | <mathiasbynens> | Bakkot: wait when did this achieve consensus? |
| 16:59 | <Bakkot> | mathiasbynens when we accepted the current spec text. |
| 16:59 | <Bakkot> | mathiasbynens I realize you don't regard that as having achieved consensus, but other people do. |
| 16:59 | <devsnek> | is that regex valid or not defined |
| 16:59 | <devsnek> | the one without the escapes |
| 16:59 | <Bakkot> | devsnek WHO KNOWS |
| 16:59 | <Bakkot> | I would say valid |
| 16:59 | <devsnek> | in the spec |
| 16:59 | <Bakkot> | mathiasbynens would say not, and that it should not be |
| 16:59 | <Bakkot> | depends who you ask |
| 16:59 | <mathiasbynens> | Bakkot: I don't mind \uLEAD\uTRAIL within named groups as much tbh, I do think we should not add this in more places |
| 17:00 | <mathiasbynens> | like in generic identifiers |
| 17:00 | <Bakkot> | I would say definitely valid despite a slight underspecification |
| 17:00 | <mathiasbynens> | Bakkot: and as you know, i'd prefer if we didn't have it, for symmetry |
| 17:01 | <devsnek> | what's happens if I run the spec through a magic program that generates a js implementation |
| 17:01 | <mathiasbynens> | devsnek: engine262 |
| 17:01 | <devsnek> | lol |
| 17:01 | <mathiasbynens> | pretty sure _you_'re the compiler |
| 17:01 | <Bakkot> | devsnek: that program fails because the spec makes reference to an operation which is not defined |
| 17:01 | <devsnek> | fun |
| 17:02 | <devsnek> | so the question is what would it do if it were defined |
| 17:02 | <Bakkot> | yeah |
| 17:02 | <devsnek> | in that case i'd ask |
| 17:02 | <devsnek> | why we would want /(?<𝒜>𝒜)/ to be valid |
| 17:03 | <Bakkot> | `let 𝒜` is valid |
| 17:03 | <mathiasbynens> | 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 |
| 17:03 | <Bakkot> | but the main reason is that we actually want `let 𨭎` to be valid |
| 17:03 | <Bakkot> | mathiasbynens that would mean allowing \uLEAD\uTRAIL in u-mode regexes |
| 17:04 | <Bakkot> | devsnek: or rather, I want `/(?<𨭎>.)/ to be valid, though mathiasbynens does not |
| 17:04 | <devsnek> | 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 |
| 17:05 | <mathiasbynens> | Bakkot: "that would mean allowing \uLEAD\uTRAIL in u-mode regexes" yeah, see my answer above |
| 17:05 | <gibson042> | "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 |
| 17:05 | <Bakkot> | devsnek you're coming into this after, like, twelve hours of argument |
| 17:05 | <gibson042> | which is not required in the other case |
| 17:05 | <devsnek> | yeah i know |
| 17:05 | <Bakkot> | gibson042 right, but maybe it does; some tools do |
| 17:05 | <Bakkot> | tools which don't can continue not doing so |
| 17:05 | <Bakkot> | because \uLEAD\uTRAIL is legal |
| 17:05 | <Bakkot> | in my proposal |
| 17:06 | <gibson042> | in what sense is it a benefit to not use functionality that must necessarily be present? |
| 17:07 | <Bakkot> | 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. |
| 17:08 | <Bakkot> | even though those tools might already have both strategies _implemented_, they still have to realize they need to use one or the other. |
| 17:08 | <Bakkot> | 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. |
| 17:08 | <gibson042> | it's dangerous to use \u{ because that won't work throughout the regex |
| 17:09 | <gibson042> | any tool that uses that for group names seems more likely to use it for match characters, where it will cause bugs |
| 17:09 | <Bakkot> | 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. |
| 17:09 | <gibson042> | but I think I get you now, thank you |
| 17:12 | <mathiasbynens> | Bakkot: \uLEAD\uTRAIL does not need to be legal to get the tooling property you desire, right? |
| 17:12 | <mathiasbynens> | well with "proposal 3" at least |
| 17:12 | <Bakkot> | mathiasbynens there is another tooling property I desire, which is that tools which do _not_ parse regexes are _also_ less likely to have bugs |
| 17:13 | <Bakkot> | with proposal 3, yes |
| 17:13 | <mathiasbynens> | Bakkot: yes, without parsing/tokenizing |
| 17:13 | <mathiasbynens> | Within any regular expression literal with the u flag, escape any astral symbol as \u{…} regardless of the context. |
| 17:13 | <mathiasbynens> | Within any regular expression literal without the u flag, escape any astral symbol as \uXXXX regardless of the context. |
| 17:14 | <mathiasbynens> | it sounds like proposal 3 is _really_ close to what you want |
| 17:14 | <Bakkot> | yes; my objection to proposal 3 is that extending weird limitations to on chinese users who are not even using escapes is bad |
| 17:14 | <Bakkot> | I hold that preference more strongly than any other I have expressed |
| 17:14 | <mathiasbynens> | oh right the new goalpost |
| 17:14 | <Bakkot> | yup, sorry |
| 17:14 | <mathiasbynens> | weird that it didn't come up before then |
| 17:14 | <Bakkot> | didn't realize this was a point there was any disagreement on |
| 17:14 | <Bakkot> | no one had previously proposed something which would violate it |
| 17:14 | <jridgewell> | Can we move this to #tc39? |
| 17:15 | <Bakkot> | I did not imagine anyone else would fail to hold this preference |
| 17:15 | <jridgewell> | I imagibe there will be talk of Records and Tuples |
| 17:15 | <Bakkot> | sure |
| 17:15 | <jridgewell> | Thanks! |
| 17:15 | <mathiasbynens> | I wish Norbert Lindenberg was here |
| 17:16 | <rkirsling> | does one RefCollection suffice across the board? |
| 17:16 | <rkirsling> | I mean I guess it would have to, never mind |
| 17:17 | <michaelficarra> | ooohhh lenses/prisms? :-) |
| 17:18 | <gibson042> | seems like epicycles to me... |
| 17:19 | <michaelficarra> | oh, this is not what I was expecting |
| 17:20 | <littledan> | let's take questions on the queue |
| 17:20 | <jridgewell> | `{ …record, fieldToDelete: undefined`? |
| 17:20 | <jridgewell> | `{ …record, fieldToDelete: undefined }`? |
| 17:21 | <ljharb> | i'm confused, is this "update" also introducing 2 new stage 0 proposals? |
| 17:21 | <littledan> | 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? |
| 17:22 | <ljharb> | littledan: by convention, stage 0 proposals get presented to the committee |
| 17:22 | <gibson042> | 🙃 |
| 17:22 | <ljharb> | these weren't linked from the agenda, and the title implied nothing but an "update", which doesn't require review in advance |
| 17:22 | <littledan> | we could consider them pre-Stage 0 then; I was unaware of that convention |
| 17:22 | <devsnek> | ljharb: i have a list of reasons that refcollection shouldn't exist here so it might not be a problem |
| 17:22 | <ljharb> | 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 |
| 17:23 | <ljharb> | totally unrelated to stage entry requirements |
| 17:23 | <ljharb> | and both of these seem large enough to warrant their own discussion and timebox |
| 17:23 | <jridgewell> | I dont' think they're really introducing them now |
| 17:23 | <ljharb> | alluding to them is doing that |
| 17:23 | <jridgewell> | They're just pairing down the initial proposal |
| 17:23 | <littledan> | is it OK to call for feedback on something asynchronously and present it at another meeting for further discussion? |
| 17:23 | <jridgewell> | "We removed this part to simplify" |
| 17:24 | <ljharb> | … maybe i'm also confused, are either of these two capabilities something that was actually part of "records and tuples" in the first place? |
| 17:24 | <ljharb> | they seem like new things since the last time it was presented |
| 17:24 | <littledan> | these haven't been part of any version of the proposal that was presented to the committee |
| 17:24 | <ljharb> | obv if it's just factoring things out, then my concern doesn't apply |
| 17:24 | <ljharb> | ok |
| 17:24 | <ljharb> | so they're new things |
| 17:24 | <ljharb> | not paring down records and tuples |
| 17:24 | <jridgewell> | Spread was in the Oct meeting |
| 17:25 | <jridgewell> | `RefCollection` is new |
| 17:25 | <littledan> | do you mean `with`? |
| 17:25 | <ljharb> | basic spread sure, but not that lens things |
| 17:25 | <jridgewell> | Ahh, that's what it was. |
| 17:25 | <littledan> | in this case, I was mistaken |
| 17:25 | <jridgewell> | The "how do I mutate a record" was part of the Oct meeting |
| 17:25 | <littledan> | right, sorry |
| 17:26 | <littledan> | btw you can put a new topic if you're not replying to a thing we're currently discussing due to a TCQ item |
| 17:26 | <rbuckton> | how to mutate a record. Maybe `record = #{ ...record, foo: record.foo + 1 }`? |
| 17:26 | <littledan> | rbuckton: Yes, that's possible with this proposal |
| 17:26 | <littledan> | (without any of the follow-ons |
| 17:27 | <ljharb> | (imo it wouldn't make any sense if that wasn't possible in this proposal directly) |
| 17:27 | <littledan> | presumably Mark is referring to destructuring |
| 17:27 | <littledan> | ? |
| 17:28 | <ljharb> | mark is talking about destructuring, i believe |
| 17:28 | <shu> | should clarify |
| 17:28 | <ljharb> | ie `const { a, …rest } = #{ a: 1, b: 2 }` produces a `rest` non-record object |
| 17:29 | <jridgewell> | With pattern matching, something like `when (#{ a, …rest}) -> rest` might be able to return a record. |
| 17:29 | <jridgewell> | I think that's Mark's point. |
| 17:29 | <ljharb> | imo that would only be possible if `const #{ a, …rest } = #{ a: 1, b: 2 }` worked |
| 17:29 | <jackworks25> | maybe add it in that another stage 0 proposal `#{...rec, delete x.y.z}` |
| 17:29 | <ljharb> | s/would/should |
| 17:30 | <benjamn> | shu: RefCollection does seem to be polyfillable, yes |
| 17:30 | <benjamn> | to your userland question |
| 17:31 | <littledan> | no, RefCollection is not polyfillable |
| 17:31 | <benjamn> | littledan: is it not essentially a WeakMap<object, Symbol>? |
| 17:31 | <littledan> | a core part of it is that it's possible to "garbage collect" unreachable symbols |
| 17:31 | <benjamn> | with some additional methods? |
| 17:31 | <littledan> | it cannot be expressed by a WeakMap, since WeakMaps cannot have symbol keys |
| 17:31 | <ljharb> | benjamn: WeakMap strongly holds its values |
| 17:31 | <rbuckton> | 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. |
| 17:31 | <littledan> | but, the keys need to be symbols, not objects, so that they can be contained in a Record or Tuple |
| 17:31 | <benjamn> | but it would only need _object_ keys |
| 17:32 | <littledan> | ljharb: That's not relevant, since what we're looking for here is symbol keys |
| 17:32 | <benjamn> | symbols would be the value |
| 17:32 | <devsnek> | symbols don't have well defined gc semantics |
| 17:32 | <devsnek> | this issue came up with symbols as weakmap keys |
| 17:32 | <littledan> | I don't see how to do that. I think we need a mapping from symbols. |
| 17:32 | <littledan> | we need a bidirectional weak mapping, really |
| 17:32 | <benjamn> | littledan: that's only true because of the deref method, right? |
| 17:33 | <benjamn> | if the mapping was not reversible, we wouldn't need symbol keys? |
| 17:33 | <jackworks25> | 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 |
| 17:33 | <littledan> | 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" |
| 17:33 | <howdoi> | rbuckton: is there a draft, I was working on a proposal on similar lines :) |
| 17:33 | <shu> | littledan: i'm confused |
| 17:34 | <shu> | littledan: the example i saw was mapping function to a symbol |
| 17:34 | <benjamn> | if you want to associate a unique unforgeable symbol with any object reference, you can use a WeakMap |
| 17:34 | <howdoi> | Michał Wadas or Sathya Gunasekaran in here? |
| 17:34 | <littledan> | shu: You need to be able to dereference the symbol and get the function again |
| 17:34 | <benjamn> | > You need to be able to dereference the symbol and get the function again |
| 17:34 | <benjamn> | that's something we could debate |
| 17:35 | <rbuckton> | howdoi: I presented it a few years back: https://github.com/rbuckton/proposal-shorthand-improvements, but it wasn't taken for stage 1. |
| 17:35 | <benjamn> | 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 |
| 17:35 | <littledan> | 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 |
| 17:35 | <benjamn> | let's listen to devsnek on this (talking now0 |
| 17:35 | <littledan> | I don't understand that argument... the mutable stuff is all contained in the RefCollection |
| 17:35 | <howdoi> | rbuckton: oh yeah! I recall seeing this. |
| 17:36 | <howdoi> | What was the reason it wasn't taken for stage-1? |
| 17:36 | <caridy> | RefCollection will not work very well when passing throughout a membrane it seems! |
| 17:36 | <rbuckton> | howdoi: IIRC, some concerns about the value of the feature and some issues with runtime semantics. |
| 17:36 | <caridy> | I believe that should be implemented in user-land |
| 17:37 | <littledan> | caridy: I think it should work well with membranes--the membrane can wrap the RefCollection itself, mediating any dereferencing of symbols |
| 17:37 | <howdoi> | oh, okies... |
| 17:37 | <rbuckton> | howdoi: I based it off of C#'s similar feature `new { a, x.y.z }`. |
| 17:37 | <littledan> | we cannot implement RefCollection in userland, unfortunately |
| 17:38 | <howdoi> | rbuckton: hoping that we will get more consensus sooner. |
| 17:38 | <caridy> | @littledan, can you provide more details on how the membrane will handle a r/t with a refCollection on it? |
| 17:38 | <rbuckton> | 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`? |
| 17:39 | <gibson042> | how would the membrane get the RefCollection? |
| 17:39 | <gibson042> | seems like it would only see output from it in most cases |
| 17:39 | <littledan> | well, how would the other side of the membrane get the RefCollection? |
| 17:39 | <littledan> | presumably that access would be mediated by the membrane |
| 17:40 | <ljharb> | rbuckton: compositeKey |
| 17:40 | <rbuckton> | That's the one. |
| 17:40 | <devsnek> | the foremost problem is that the idea of collecting symbols is not something that all implementations inherently have |
| 17:40 | <jridgewell> | Do any? |
| 17:40 | <devsnek> | most do |
| 17:40 | <devsnek> | because they're just heap objects |
| 17:40 | <devsnek> | but you can also implement them as immediate values |
| 17:41 | <devsnek> | you can go look at the symbols as weakmap keys issue for more info |
| 17:41 | <devsnek> | under this limitation, refcollections are a permanent leak |
| 17:41 | <littledan> | well, implementations are allowed to leak everything, sure |
| 17:41 | <devsnek> | that's not a very good language design though |
| 17:42 | <littledan> | the unique thing about symbols is that they give identity while being a primitive |
| 17:42 | <devsnek> | "sucks if your implementation isn't how v8 does it" |
| 17:42 | <shu> | does someone have the link to refcollection? |
| 17:42 | <rbuckton> | `record.with({ x: { y: { z: 1 } } })`? |
| 17:42 | <ljharb> | shu: https://github.com/rricard/proposal-refcollection |
| 17:42 | <jridgewell> | RefCollection is just a `Map`, though |
| 17:42 | <littledan> | https://github.com/rricard/proposal-refcollection |
| 17:42 | <jridgewell> | Why couldn't the entire thing be reclaimed at once? |
| 17:42 | <littledan> | note, this readme is relatively early, still iterating on elaborating the explanations |
| 17:43 | <gibson042> | it seems like RefCollection is a WeakMap that allows Symbol keys |
| 17:43 | <gibson042> | and maybe also other primitives |
| 17:44 | <jridgewell> | It's just a `Map<symbol, *>` |
| 17:45 | <jackworks25> | and a not removable Map |
| 17:46 | <jackworks25> | ReadonlyWeakMap<*, >? |
| 17:46 | <jridgewell> | What do you mean by removable map? |
| 17:46 | <jridgewell> | Ohh |
| 17:46 | <jridgewell> | A ReadOnly Map, yes. |
| 17:46 | <jackworks25> | Also not changeable |
| 17:47 | <jridgewell> | drousso: That was answered earlier in the presentation |
| 17:47 | <drousso> | oh? |
| 17:47 | <drousso> | i came in late 😅 |
| 17:47 | <jridgewell> | Since ReadOnly Collections don't propose a array or object, they don't overlap |
| 17:48 | <jridgewell> | It seems like RefCollection could build on a ReadOnlyMap, per above |
| 17:48 | <drousso> | the readonly collections proposal states "all EcmaScript enumerable collections" |
| 17:48 | <drousso> | which I read as including tuples for sure, and possibly records |
| 17:49 | <jridgewell> | Neither is a collection |
| 17:49 | <jridgewell> | Though I understand the confusion |
| 17:49 | <michaelficarra> | benjamn makes a good point |
| 17:50 | <jridgewell> | Don't we already have significant runtime experience already? |
| 17:50 | <jridgewell> | Immer and Immutable.js, etc |
| 17:53 | <rkirsling> | the idea of both of those proposals existing separately doesn't seem good to me either |
| 17:53 | <rkirsling> | (readonly collections, I mean) |
| 17:53 | <rkirsling> | but separate development and syncing later might be good? |
| 17:54 | <rkirsling> | unless I'm confused about goals somehow. it was sort of stated as if obvious |
| 17:55 | <drousso> | it's odd to me that a `Map` can create a readonly snapshot, but that an `Object` can't |
| 17:55 | <drousso> | err, well it could if the proposal is approved 😅 |
| 17:56 | <gibson042> | isn't that Object.freeze? |
| 17:56 | <ljharb> | ^ |
| 17:56 | <drousso> | doesn't that modify the object itself though? |
| 17:56 | <drousso> | not create a readonly view? |
| 17:56 | <drousso> | err, not "modify" but "freeze" |
| 17:57 | <ljharb> | drousso: wait, how can you make a read only map? |
| 17:57 | <ljharb> | all Maps and Sets are unstoppably mutable |
| 17:57 | <rkirsling> | (oh never mind, this readonly collections proposal is way different than the title suggested) |
| 17:57 | <drousso> | https://github.com/tc39/proposal-readonly-collections |
| 17:57 | <ljharb> | ah in the proposal |
| 17:57 | <ljharb> | yes |
| 17:57 | <ljharb> | kk |
| 17:58 | <ljharb> | drousso: `Object.freeze(Object.create(Object.getOwnPropertyDescriptors(obj), Object.getPrototypeOf(obj)))` |
| 17:58 | <ljharb> | that's just as much a read only snapshot of an object as FixedMap eg would give |
| 18:00 | <mpcsh> | rickbutton: you should change your abbreviation from RBU to BTN ;) |
| 18:00 | <rickbutton> | that is such a good idea |
| 18:00 | <rickbutton> | totally gonna do that |
| 18:02 | <bradleymeck> | thats a readonly snapshot not but doesn't readonly proposal do a view? |
| 18:05 | <rbuckton> | 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. |
| 18:05 | <ljharb> | bradleymeck: ah maybe it also has a view, sure |
| 18:05 | <littledan> | someone is echoing and should mute |
| 18:05 | <ljharb> | jack is echoing |
| 18:06 | <littledan> | the meeting host should be able to mute if needed |
| 18:08 | <robpalme> | https://github.com/Jack-Works/proposal-Number.range/issues/17 |
| 18:08 | <ljharb> | mpcsh: does it not already mean [0, 10) ? |
| 18:09 | <mpcsh> | ljharb: last entry on the slide |
| 18:09 | <ljharb> | mpcsh: ah ty |
| 18:11 | <ljharb> | for reuse, you can also prepend `() =>` |
| 18:11 | <devsnek> | ^ |
| 18:11 | <ljharb> | ie `() => Number.range(x, y)` is infinitely reusable |
| 18:22 | <mpcsh> | 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 |
| 18:26 | <ljharb> | haxjs can you add a link for these slides to the agenda please? |
| 18:34 | <ljharb> | ystartsev: this proposal does have a repo, it just wasn't linked |
| 18:34 | <ystartsev> | ljharb: fair |
| 18:34 | <ystartsev> | i looked for it but didn't find it |
| 18:34 | <ljharb> | in general, objecting based on a lack of materials is a stage 2+ thing |
| 18:35 | <ljharb> | because stage 1 is about exploring a problem, and historically we haven't felt advance materials were required to illustrate a problem |
| 18:35 | <ystartsev> | 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 |
| 18:36 | <ystartsev> | also if i remember correctly there were issues with this last time and it didn't reach stage 1? |
| 18:36 | <ljharb> | i agree with that for sure |
| 18:36 | <rickbutton> | ystartsev: correct |
| 18:37 | <rkirsling> | was this the proposal that got rejected? |
| 18:37 | <ljharb> | 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 |
| 18:37 | <rkirsling> | there were two very similar ones IIRC |
| 18:37 | <jridgewell> | Yah, the requirement to patch every platform feature to add the check makes this difficult to accept for me. |
| 18:37 | <ljharb> | rkirsling: not rejected, but no consensus for stage 1 |
| 18:37 | <rbuckton> | 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"`? |
| 18:37 | <rkirsling> | I thought the "explicit `this` param" got rejected |
| 18:37 | <ljharb> | rkirsling: that's a different one |
| 18:37 | <rkirsling> | err yeah sorry, rejected is the wrong word |
| 18:37 | <rkirsling> | yeah I know |
| 18:38 | <ystartsev> | i guess we could set a flag for every function? |
| 18:38 | <ljharb> | 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." |
| 18:39 | <ljharb> | ystartsev: the proposal last meeting was an own data property, initially populated by the presence of `this` in a non-arrow function body |
| 18:39 | <rkirsling> | ljharb: thanks |
| 18:41 | <ystartsev> | it isn't clear to me -- will this throw if a function called from a function has a this requirement? |
| 18:41 | <jackworks92> | can think an explicit `this` to be a syntax sugar to `if (this === undefined) throw TypeError()` 🤔 |
| 18:41 | <jridgewell> | shu: consider `function foo() { return () => this; }` |
| 18:42 | <ystartsev> | for example `function foo() { bar()}` `function bar() { this + 1)` |
| 18:42 | <ljharb> | ystartsev: i believe it'd be, code could decide to throw if given the wrong "this-accepting" kind of function |
| 18:42 | <ystartsev> | and we are only checking foo? |
| 18:42 | <jridgewell> | `foo` has a `ThisRequired`, but the arrow it returns does not. |
| 18:42 | <bterlson> | 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? |
| 18:42 | <devsnek> | very important to note is that nothing about foo implies it is supposed to be given a this value |
| 18:42 | <devsnek> | it could be called `getFunctionThatReturnsUndefined` |
| 18:42 | <ljharb> | exactly what bterlson said, i think |
| 18:42 | <akirose> | remaining questions https://snaps.akibraun.com/6qaoe.jpg |
| 18:43 | <devsnek> | js is a dynamic language, validation of arguments is dynamic |
| 18:43 | <devsnek> | if you expect a this value you should validate it, not make someone else do it |
| 18:43 | <shu> | bterlson: that is a question about programmer intent, not syntactic presence of something that gives you the receiver |
| 18:43 | <devsnek> | for example if you do Map.prototype.set.call(5) |
| 18:43 | <shu> | like if your code has an if (rareCondition) { doSomething(this) }, now it's an error? |
| 18:43 | <devsnek> | ^ |
| 18:44 | <bterlson> | the proposla isn't that we do any error throwing |
| 18:44 | <bterlson> | in the language |
| 18:44 | <bterlson> | as far as I understand it |
| 18:44 | <devsnek> | the proposal exposes something that you can't make any decision from |
| 18:44 | <ystartsev> | i think the user has to throw themselves |
| 18:44 | <drousso> | functions can optionally use `this` tho |
| 18:44 | <shu> | right, but the only motivating use i saw was to check it and throw |
| 18:44 | <devsnek> | given the information "this function syntactically contains this" |
| 18:44 | <devsnek> | i can make no decision |
| 18:44 | <devsnek> | about whether the function should be given this |
| 18:44 | <shu> | and i don't think that is a useful reflection to make a decision on, right |
| 18:44 | <drousso> | ^ +1 |
| 18:45 | <devsnek> | the function could be using `this` to throw if this is not undefined |
| 18:45 | <devsnek> | which brings me back to "the function itself should validate its this value" |
| 18:45 | <bterlson> | 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 |
| 18:45 | <ystartsev> | yeah i would also agree with that... it seems like something that should be done by the author |
| 18:45 | <jridgewell> | The issue is that by the time the function is invoked, we've lost the location of where the function was passed. |
| 18:45 | <bterlson> | FWIW I am not arguing in favor of this proposal, merely explaining my understanding |
| 18:45 | <jridgewell> | `addEventLister` being the prime example |
| 18:46 | <robpalme> | https://github.com/tc39/proposal-hashbang/issues/18 |
| 18:46 | <jridgewell> | 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. |
| 18:46 | <ljharb> | rwaldron: to be fair, i have one on the agenda for today :-p |
| 18:46 | <shu> | 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 |
| 18:47 | <ljharb> | rwaldron: also, private methods was on top of private fields |
| 18:47 | <shu> | jridgewell: if it's about forgetting to bind for native methods, how would you adopt this? monkeypatch all the native methods? |
| 18:47 | <drousso> | i feel like a better solution would be to add a property that states whether a `this` was bound |
| 18:47 | <jridgewell> | Yes, which I think is the biggest downside to this proposal. |
| 18:47 | <rkirsling> | bradleymeck: hashbang is shipping everywhere, I think (whether that actually matters or not) |
| 18:47 | <bterlson> | shu: it is up to the framework? Frameworks query function arguments whether they create `this` references |
| 18:47 | <bterlson> | and decide what to do with that info |
| 18:47 | <drousso> | that way, when the function is passed in, it can be checked |
| 18:47 | <bradleymeck> | rkirsling: not safari stable |
| 18:47 | <bterlson> | Hax's idea is, they throw |
| 18:47 | <jridgewell> | Having to monkeypatch `addEventListener` (and every plaform API) is a huge burden |
| 18:48 | <shu> | jridgewell: i think that's just a dealbreaker |
| 18:48 | <bterlson> | sorry, they CAN throw |
| 18:48 | <jridgewell> | I agree |
| 18:48 | <drousso> | jridgewell why does `addEventListener` _have_ to have a `this` though? |
| 18:48 | <drousso> | i add event listeners all the time where I don't want a `this` |
| 18:48 | <drousso> | s/want/care about |
| 18:48 | <jridgewell> | `class Foo { method() { this.doSomething(); } }; addEventLisener('click', foo.method)` |
| 18:48 | <rwaldron> | ljharb the class private split was a strategic and intentional move because it was otherwise very large surface... this isn't that. |
| 18:49 | <rwaldron> | But I see what you're saying. |
| 18:49 | <rkirsling> | bradleymeck: even in 13.1 from last week? |
| 18:49 | <drousso> | jridgewell yes, that's a valid case, but I would argue that that's the programmers error |
| 18:49 | <jridgewell> | > i add event listeners all the time where I don't want a `this` |
| 18:49 | <jridgewell> | If you have a `this` in your function's code, I think it's reasonable to assume that you want a `this`. |
| 18:49 | <ljharb> | rwaldron: agreed, as somewhat was the "in" feature being removed from the main class fields proposal |
| 18:49 | <bradleymeck> | rkirsling: at least in REPL it isn't |
| 18:50 | <drousso> | i could just as validly have `addEventListener("click", function refresh() { /* do static things */ })` |
| 18:50 | <jridgewell> | If you don't have a `this`, then the proposal wouldn't have returned `true` and the API wouldn't have thrown |
| 18:50 | <jridgewell> | Yes, and your case is handled. |
| 18:50 | <drousso> | ah i see what you mean |
| 18:50 | <jridgewell> | `if (thisIsNeeded(cb)) { throw error }` |
| 18:50 | <rkirsling> | bradleymeck: yeah I wouldn't expect that to work unless web inspector wants it to; lemme make a test page and check |
| 18:50 | <jridgewell> | You `cb` doesn't need a `this`, so it doesn't throw. |
| 18:51 | <bradleymeck> | rkirsling: does it not execute as a Script? |
| 18:51 | <rwaldron> | ljharb I just went to write almost the same topic question |
| 18:51 | <rkirsling> | oh right I can eval |
| 18:51 | <jridgewell> | To be clear, I don't support the proposal (due to the burden of monkey patching everyting), I just understand the desire. |
| 18:51 | <drousso> | jridgewell how do you know for a fact that my callback _needs_ `this`? |
| 18:51 | <jackworks92> | what if, make # a valid comment starter if it appears at the line start? |
| 18:51 | <ljharb> | jackworks92: that's what the second half of this proposal is |
| 18:51 | <michaelficarra> | oh no, please not that |
| 18:51 | <rkirsling> | bradleymeck: eval works |
| 18:52 | <devsnek> | hashbang should only be allowed at byte 0 of a source text |
| 18:52 | <rkirsling> | ^ |
| 18:52 | <jridgewell> | `#` being a comment start creates a huge ASI for private fields |
| 18:52 | <ljharb> | jridgewell: queue that? |
| 18:52 | <rickbutton> | what about UTF BOM devsnek |
| 18:52 | <rkirsling> | I'm actually startled that devtools allows it |
| 18:52 | <rickbutton> | jk |
| 18:52 | <msaboff> | The <script> case is not a TC-39 issue in my opinion |
| 18:52 | <devsnek> | rickbutton: that's not a hashbang |
| 18:53 | <ljharb> | msaboff: my first queue item addresses that, fwiw |
| 18:53 | <devsnek> | rickbutton: utf8 bom should be stripped before processing it as a source text |
| 18:53 | <bradleymeck> | erlang and java are interesting, they are languages without # based comments and hashbangs |
| 18:53 | <drousso> | jridgewell understood, sorry for arguing with you 😅 |
| 18:53 | <devsnek> | rickbutton: ut8 bom is transport level |
| 18:53 | <jridgewell> | Did hax propose making `#` a comment start? |
| 18:53 | <rickbutton> | good point |
| 18:53 | <michaelficarra> | bradleymeck: and do they allow preceding whitespace? |
| 18:53 | <ljharb> | jridgewell: wait a slide or two |
| 18:53 | <bradleymeck> | michaelficarra: no, but there are not clear discussion archives on their design either |
| 18:53 | <bradleymeck> | the JEP is incredibly terse |
| 18:54 | <jackworks92> | or maybe just drop the whole hashbang syntax 🤔 |
| 18:54 | <devsnek> | we already went through all this in node (including how it behaves with BOM) |
| 18:54 | <devsnek> | sad times |
| 18:55 | <devsnek> | i think in some old node versions #!...{BOM} was allowed at some point due to how we stripped them out |
| 18:56 | <rpamely> | @devsnek The iterator helpers proposal that was mentioned earlier, are you the champion? |
| 18:56 | <ljharb> | shu: keith_miller lol my second queue item covers this one |
| 18:56 | <devsnek> | rpamely: no, i'm the author (i wasn't a delegate at the time) |
| 18:56 | <Bakkot> | rickbutton we actually did explicitly discuss BOM in the hashbang proposal and explicitly decide that BOM in your source text precludes hashbang |
| 18:56 | <rpamely> | Ah ok. Is there an active champion? |
| 18:56 | <rickbutton> | gotcha, makes sense |
| 18:57 | <devsnek> | rpamely: i can answer questions and make decisions, just on an official level i'm not the champion |
| 18:57 | <ljharb> | akirose: please save the queue |
| 18:58 | <keith_miller> | ljharb: Ah, I was just trying to understand how they work today |
| 18:58 | <shu> | ljharb: what does your queue item mean? that code opts into being inlined or appended or whatever? |
| 18:58 | <ljharb> | keith_miller: tldr they don't |
| 18:58 | <keith_miller> | because it seems like they don't |
| 18:58 | <keith_miller> | ok |
| 18:58 | <keith_miller> | yeah |
| 18:58 | <shu> | and it's up to it to know its whole world? i see |
| 18:58 | <ljharb> | shu: like you can't write "test.js" to be included somewhere without knowing exactly where that's going to be |
| 18:58 | <ljharb> | shu: in terms of parse goal as well as scoping |
| 18:58 | <michaelficarra> | akirose: we can move it to the overflow at the end of the meeting, right? |
| 18:58 | <shu> | right, so the answer is "they don't" |
| 18:58 | <devsnek> | oh is this lunch now |
| 18:58 | <ljharb> | i have concrete examples from history |
| 18:59 | <ljharb> | shu: yes |
| 18:59 | <shu> | ljharb: that further reinforces my opinion this should not happen |
| 18:59 | <shu> | and also other folks' i guess |
| 18:59 | <devsnek> | weakrefs are very fun |
| 19:01 | <michaelficarra> | people already have to watch out for </script> when they convert from external to inlined scripts |
| 19:01 | <michaelficarra> | fun fact: it's not even possible to inline arbitrary JS into HTML without changing its semantics |
| 19:02 | <michaelficarra> | because tagged templates and </script> |
| 19:02 | <mathiasbynens> | also Function#toString |
| 19:02 | <michaelficarra> | sure but let's please pretend that doesn't exist |
| 19:03 | <akirose> | michaelficarra: tentatively yes, if haxjs is interested. bear in mind that's like 5am his time. |
| 19:03 | <devsnek> | 'delete Function.prototype.toString' |
| 19:03 | <haxjs> | It seem very hard for me to explain the problem in english :( |
| 19:04 | <jackworks92> | (actually it's 3am) |
| 19:04 | <benjamn> | confession: I have used /\bthis\b/.test(Function.prototype.toString(func)) before |
| 19:05 | <ljharb> | 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? |
| 19:05 | <benjamn> | sorry, Function.prototype.toString.call(func) |
| 19:05 | <benjamn> | obviously has false positives, and doesn't work for native functions |
| 19:06 | <jackworks92> | i believe hax is in the same timezone as me, sunrise at around 6am so it's 3hrs to morning |
| 19:06 | <ljharb> | gotcha |
| 19:08 | <jackworks92> | 🙈+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 |
| 19:14 | <rbuckton> | 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. |
| 19:16 | <jackworks92> | `struct` as value types? what different with the record proposal? |
| 19:17 | <devsnek> | i really want enums |
| 19:17 | <devsnek> | oh i guess i could propose that now |
| 19:17 | <rbuckton> | devsnek: I'm working on that too... |
| 19:17 | <devsnek> | or you could |
| 19:17 | <devsnek> | i want like.... rust enums though |
| 19:17 | <rbuckton> | devsnek: I have one already, planned to present it a year ago but held off due to some discussions with others on the committee. |
| 19:17 | <bradleymeck> | devsnek: there be dragons on `enum` TS already took that space and it would be hard to convince people to reuse it |
| 19:17 | <devsnek> | i don't care what TS did |
| 19:18 | <bradleymeck> | others do |
| 19:18 | <jackworks92> | +1 I like the rust style enum |
| 19:18 | <devsnek> | 🤷🏻 it's a separate language |
| 19:18 | <shu> | rbuckton: i'm interested in something like `struct`s for shared memory and layout guarantees, was thinking of resurrecting typed objects |
| 19:18 | <devsnek> | they can keep using their enum until the end of time |
| 19:18 | <rbuckton> | devsnek: not really a separate language |
| 19:18 | <benjamn> | devsnek: have you seen how Scala handles object-oriented pattern matching? |
| 19:18 | <bradleymeck> | devsnek: doesn't matter, if it influences people it influences people. |
| 19:18 | <shu> | rbuckton: what did you have in mind? |
| 19:18 | <bradleymeck> | rbuckton: I'd claim it is increasingly divergent |
| 19:18 | <devsnek> | i've never used scala |
| 19:18 | <devsnek> | if ts wants to keep adding things that aren't types |
| 19:18 | <devsnek> | i don't think we should feel constrained by it |
| 19:18 | <rbuckton> | 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`. |
| 19:19 | <jackworks92> | typescript style enum is some kind of too weak, they doesn't have rust style tagged union that can contain data in it |
| 19:19 | <bradleymeck> | devsnek: that isn't the consensus though, some people do feel like accommodating TS is important. |
| 19:19 | <devsnek> | yeah if we just do c style enums |
| 19:19 | <devsnek> | that would be a loss |
| 19:19 | <benjamn> | oh, you're not talking about Rust enums and pattern matching |
| 19:19 | <benjamn> | or are you? |
| 19:19 | <keith_miller> | jackworks92: I think what you are descirbing is the pattern matching proposal? |
| 19:19 | <keith_miller> | the algebraic data type style enum? |
| 19:20 | <devsnek> | pattern matching is a good thing to use with that kind of enum |
| 19:20 | <benjamn> | keith_miller: yes |
| 19:20 | <devsnek> | but you don't need pattern matching to enjoy that kind of enum |
| 19:20 | <devsnek> | though its slightly harder |
| 19:20 | <jackworks92> | keith_miller: yes |
| 19:20 | <devsnek> | bradleymeck: isn't that basically making ts normative without the tc39 process |
| 19:20 | <bradleymeck> | devsnek: nope, just saying the design space is occupied |
| 19:21 | <benjamn> | 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 |
| 19:21 | <devsnek> | by what, i don't use ts |
| 19:21 | <Bakkot> | unapply is neat |
| 19:21 | <keith_miller> | jackworks92: https://github.com/tc39/proposal-pattern-matching |
| 19:21 | <rbuckton> | 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 |
| 19:21 | <bradleymeck> | devsnek: others do, so it remains occupied |
| 19:21 | <Bakkot> | but scala makes for very poor precedent |
| 19:21 | <Bakkot> | for anything |
| 19:21 | <Bakkot> | ever |
| 19:21 | <devsnek> | like if i said we shouldn't do something because clojurescript has it |
| 19:21 | <devsnek> | people would probably kill me |
| 19:22 | <rkirsling> | now now, we'd just ignore you |
| 19:22 | <bradleymeck> | devsnek: you could do that, we can just find a new design |
| 19:22 | <Bakkot> | 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? |
| 19:22 | <shu> | rbuckton: let's talk. for sharing them we probably need something more performant than wrappers around SABs |
| 19:22 | <rbuckton> | 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. |
| 19:22 | <keith_miller> | I mean I disagree that TS should not stop us from taking a different design |
| 19:23 | <keith_miller> | err I disagree => I think |
| 19:23 | <jackworks92> | 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 |
| 19:23 | <jackworks92> | violates ts design principle |
| 19:23 | <devsnek> | 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 |
| 19:23 | <shu> | 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 |
| 19:23 | <Bakkot> | devsnek: "not in good faith" is an extremely serious accusation |
| 19:23 | <rbuckton> | 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. |
| 19:24 | <bradleymeck> | devsnek: you can make a different enum, just not overlap the design |
| 19:24 | <benjamn> | rbuckton: did you see that ljharb is taking over championing pattern matching? |
| 19:24 | <rbuckton> | 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`. |
| 19:24 | <rbuckton> | benjamn: yes. |
| 19:24 | <devsnek> | Bakkot: i can't see how the argument creates productive discourse so... |
| 19:25 | <shu> | 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 |
| 19:25 | <devsnek> | interop sure, but if you go through a compiler |
| 19:25 | <shu> | think about the constituencies |
| 19:26 | <devsnek> | like if you can just block tc39 movement because you can create something similar somewhere else |
| 19:26 | <devsnek> | like how people were doing Array.prototype.smoosh to stop tc39 from using it |
| 19:26 | <rbuckton> | shu: Another part of the current `struct` draft is support for syntactic operator overloading. I'm talking with littledan about it as well. |
| 19:26 | <shu> | it's not something existing that blocks it, it's ecosystem pervasiveness |
| 19:26 | <devsnek> | if a delegate blocks because of it |
| 19:26 | <shu> | that's a pecularity of TC39 |
| 19:26 | <devsnek> | which is what was brought up above |
| 19:27 | <ljharb> | it is extremely not a good precedent if "TS did it therefore JS can't" becomes a thing |
| 19:27 | <shu> | but i don't think it's ever that black and white |
| 19:27 | <benjamn> | rbuckton made a really great point above about TS enums being able to evolve to something more like Rust enums |
| 19:27 | <devsnek> | i was responding to the above point that js couldn't deviate from ts enum semantics |
| 19:27 | <ljharb> | the first time that came up, we explicitly noted it as a one-off |
| 19:27 | <jackworks92> | 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) |
| 19:27 | <ljharb> | and then it came up a second time |
| 19:27 | <devsnek> | jackworks92: it doesn't break them |
| 19:27 | <benjamn> | with the current TS syntax continuing to work |
| 19:27 | <devsnek> | you have to run ts code through a compiler to get js |
| 19:28 | <devsnek> | its not breaking |
| 19:28 | <devsnek> | it's definitely not ideal for them |
| 19:28 | <jackworks92> | 🙈 |
| 19:28 | <ljharb> | TS users are sometimes part of the JS ecosystem, and TS build output is. but TS itself is a different language. |
| 19:28 | <devsnek> | i'm willing to say they're part of the js ecosystem in more than their compiler output |
| 19:29 | <ljharb> | (not a superset of JS, but if anyone wants to debate that let's go to another channel) |
| 19:29 | <devsnek> | but if they add things that aren't types |
| 19:29 | <devsnek> | they should be prepared to clash with js |
| 19:29 | <shu> | i don't see how this discussion is any more productive |
| 19:29 | <devsnek> | shu: i was concerned about someone saying that people would likely not accept semantics that deviate from ts |
| 19:30 | <devsnek> | which seemed problematic in a larger sense to tc39 |
| 19:30 | <jackworks92> | devsnek: will you start a rust style enum proposal? I'm happy to see that |
| 19:30 | <ljharb> | certainly nobody thinks TS compat should have no weight |
| 19:30 | <ljharb> | jackworks92: there's already 2 enum proposals, i'd love to see "not a third" :-p |
| 19:30 | <devsnek> | 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 |
| 19:30 | <Bakkot> | 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 |
| 19:30 | <jackworks92> | oh i didnt see them in the proposals list |
| 19:31 | <rbuckton> | 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? |
| 19:31 | <devsnek> | Bakkot: you don't think "the same as ts or not at all" isn't a regressive pattern? |
| 19:31 | <Bakkot> | I don't know what "a regressive pattern" means |
| 19:31 | <devsnek> | like |
| 19:31 | <devsnek> | harmful to tc39 process |
| 19:31 | <ljharb> | jackworks92: rbuckton's, and https://github.com/rwaldron/proposal-enum-definitions |
| 19:32 | <Bakkot> | 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. |
| 19:32 | <rbuckton> | ljharb, jackworks92: rwaldron and I discussed our proposals and my current proposal is designed to mostly incorporate his (with a few exceptions). |
| 19:32 | <Bakkot> | also no one stated that as a fully general ultimatum. |
| 19:33 | <shu> | devsnek: i feel like you're mostly arguing against a strawman |
| 19:33 | <ljharb> | rbuckton: that's great, i'd love to see rick's archived with a note to that effect then :-) |
| 19:33 | <devsnek> | shu: i suggested something about enums and was warned that people would be unlikely to choose it because ts does something else |
| 19:33 | <shu> | even web compat issues, given compelling reason we want to do something, warrant investigation into how bad the breakage is |
| 19:33 | <shu> | i've heard TS concerns brought up but never in the context of the TS way or not at all |
| 19:33 | <rbuckton> | ljharb: Mine hasn't officially subsumed his, though I believe we were moving in that direction. |
| 19:34 | <devsnek> | shu: that's what i'm responding to |
| 19:34 | <devsnek> | also as i keep saying, it's not breakage because ts is a different language, it has a compiler |
| 19:34 | <bterlson> | 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? |
| 19:34 | <rwaldron> | rbuckton jackworks92 confirm. |
| 19:34 | <Bakkot> | 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 |
| 19:34 | <ljharb> | rbuckton: gotcha |
| 19:34 | <Bakkot> | s/people/some people/ |
| 19:35 | <devsnek> | Bakkot: but there isn't breakage |
| 19:35 | <Bakkot> | devsnek call it whatever you like |
| 19:35 | <Bakkot> | the choice of noun here is not important |
| 19:35 | <devsnek> | ts can keep using its enums |
| 19:35 | <jackworks92> | oh afterall, ts can make a breaking change or add a compiler options to switch to ES semantics |
| 19:35 | <devsnek> | and its not like they don't already have a bunch of flags for switching things to es semantics |
| 19:35 | <Bakkot> | devsnek yes, but with other costs |
| 19:35 | <shu> | 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 |
| 19:36 | <Bakkot> | mostly to users, who know have to know about two kinds of enum |
| 19:36 | <Bakkot> | this is a real cost. |
| 19:36 | <Bakkot> | bringing up this cost is not bad faith. |
| 19:36 | <shu> | right, that is the primary charge for a standards body |
| 19:36 | <devsnek> | maybe ts should not have added enums then lol |
| 19:36 | <Bakkot> | but they did, that is the world we live in now |
| 19:36 | <devsnek> | why do we have to back ourselves into this corner is my point |
| 19:36 | <rbuckton> | 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). |
| 19:36 | <jackworks92> | there is `namespace`, `import x = expr` in ts already so it's already "3 kinds of module" need to know for ts users |
| 19:37 | <Bakkot> | 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. |
| 19:37 | <bterlson> | browsers should not have done stupid function-in-block semantics, let's break people depending on that behavior because browsers did a bad thing |
| 19:37 | <jackworks92> | so 2 kinds of enum is okay to me |
| 19:37 | <ljharb> | bterlson: browsers are very different from everyone else tho |
| 19:38 | <shu> | Bakkot: i think we actually do have to :P |
| 19:38 | <devsnek> | Bakkot: i don't think we should care about ts more than ts cares about js |
| 19:38 | <Bakkot> | shu it's not a requirement of our process document, is mostly what we mean to say |
| 19:38 | <shu> | Bakkot: indeed that i agree with |
| 19:38 | <Bakkot> | 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). |
| 19:39 | <rbuckton> | jackworks92: I'd like to avoid two kinds of enum if we can find a way to support both in a single design. |
| 19:39 | <jackworks92> | ts will follow the es semantics so there isn't too much things to worry about |
| 19:39 | <bterlson> | 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 |
| 19:39 | <ljharb> | bterlson: that is fair |
| 19:39 | <shu> | bterlson: well, as a capitalist, i should hope the TS team will also pays the price eventually in losing users and getting defunded |
| 19:39 | <devsnek> | and us apparently |
| 19:39 | <keith_miller> | bterlson: Doesn't that cut both ways though? |
| 19:40 | <jackworks92> | rbuckton: yeah, maybe a ts (syntax level) compatible and enhanced enum is great |
| 19:40 | <ljharb> | bterlson: but JS users also thus pay the price for decisions the TS team makes |
| 19:40 | <devsnek> | ^ |
| 19:40 | <shu> | why do you think the venn diagram of JS users and TS users is not mostly a circle |
| 19:40 | <ljharb> | 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 |
| 19:40 | <ljharb> | shu: it very much is not, in my experience |
| 19:40 | <Bakkot> | shu most people continue not using TS, I can tell you from experience talking to a lot of developers at, like, banks |
| 19:40 | <bterlson> | 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. |
| 19:41 | <ljharb> | fair |
| 19:41 | <ljharb> | but proposals aren't often blocked because lodash did it differently |
| 19:41 | <shu> | Bakkot: oh really? what's the overlap in your experience? |
| 19:41 | <devsnek> | 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 |
| 19:41 | <jackworks92> | (the runtime semantics of TS enum (two-way binding for int enum) is not good for me) |
| 19:41 | <rbuckton> | 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. |
| 19:41 | <devsnek> | i'm not angry at typescript itself |
| 19:41 | <ljharb> | shu: outside of large companies, i think it's much closer to "minimal overlap" than a circle. |
| 19:41 | <Bakkot> | shu maybe 20% of JS developers at non-software enterprises are using typescript, among those I have talked to as part of my job |
| 19:42 | <shu> | ah, i see |
| 19:42 | <Bakkot> | 75% confidence interval is like 5%-40% |
| 19:42 | <shu> | big range |
| 19:42 | <Bakkot> | confidence intervals should be large, people are bad at guessing |
| 19:42 | <devsnek> | make a virus that infects js software and detects if the code is similar to ts output |
| 19:43 | <devsnek> | oops wrong channel |
| 20:00 | <devsnek> | are people able to load drive.google.com |
| 20:00 | <michaelficarra> | reminder that Zoom resets your display name if you left and came back |
| 20:00 | <michaelficarra> | devsnek: yes |
| 20:01 | <devsnek> | weird |
| 20:02 | <devsnek> | also implemented in engine262! |
| 20:11 | <wsdferdksl> | Is there a way to keep freenode from kicking me out every couple hours or so? It randomly disconnects and "reconnect" just hangs it. |
| 20:11 | <michaelficarra> | wsdferdksl: are you using the web client? |
| 20:11 | <wsdferdksl> | Yes |
| 20:12 | <michaelficarra> | yeah I had the same issue when I was using it last meeting, it's just broken |
| 20:12 | <michaelficarra> | there's a bunch of free IRC clients |
| 20:12 | <michaelficarra> | I recommend using one of them |
| 20:15 | <jridgewell> | I think Mark is saying: |
| 20:16 | <jridgewell> | ``` |
| 20:16 | <jridgewell> | promise.then(() => console.log(1)); |
| 20:16 | <jridgewell> | / a cleanup cannot be scheduled here |
| 20:16 | <jridgewell> | promise.then(() => console.log(2)); |
| 20:16 | <jridgewell> | ``` |
| 20:16 | <shu> | yep, that's true today |
| 20:16 | <shu> | and will remain true |
| 20:17 | <jridgewell> | But is he also saying that the first and second console logs must be scheduled first and second, and cleanup after both? |
| 20:18 | <shu> | i don't think he was saying that |
| 20:18 | <shu> | i only understood interleaving as synchronous interruption |
| 20:18 | <jridgewell> | Ok. |
| 20:18 | <jridgewell> | Then, yah, that would be very surprising semantics |
| 20:18 | <jridgewell> | But I don't think the spec does that. |
| 20:19 | <jridgewell> | So we should be good. |
| 20:19 | <shu> | there is nothing in the ecma262 side that guarantees both console logs be both scheduled before cleanup |
| 20:19 | <shu> | that's up to the host |
| 20:19 | <shu> | html happens to do this because cleanup is a task, not a microtask (what dan was saying about priorities) |
| 20:19 | <jridgewell> | 👍 |
| 20:25 | <devsnek> | keith_miller: node also has workers |
| 20:25 | <keith_miller> | devsnek: sure |
| 20:27 | <devsnek> | shu: were you going to suggest that cleanupSome checks [[CanBlock]] |
| 20:28 | <shu> | no |
| 20:31 | <jridgewell> | What are the usecases for `cleanupSome`? |
| 20:32 | <devsnek> | jridgewell: something that doesn't yield to host safepoints |
| 20:32 | <devsnek> | like a tight loop in a worker |
| 20:33 | <jridgewell> | Is there an example? |
| 20:33 | <jridgewell> | Like, why is it critical to clean it up _now_? |
| 20:33 | <devsnek> | because it can never happen otherwise |
| 20:33 | <devsnek> | like if your worker is while (true) { ... } |
| 20:33 | <devsnek> | as long as you're in that loop the host can never perform cleanup callbacks |
| 20:34 | <jridgewell> | Why is that an issue? |
| 20:34 | <jridgewell> | If you're in a `while (true) {}`, you can never use Promises, etc. |
| 20:34 | <rwaldron> | shu https://github.com/tc39/test262/pull/2531 review this now? |
| 20:34 | <jridgewell> | Like, the whole JS ecosystem is broken with that. |
| 20:34 | <devsnek> | jridgewell: because if you're using weak stuff you expect your things to be cleaned |
| 20:34 | <shu> | rwaldron: yep, yes please |
| 20:34 | <devsnek> | and interactions with wasm, etc have this problem |
| 20:34 | <devsnek> | therefore we try to support it |
| 20:35 | <devsnek> | we could theoretically not have it |
| 20:35 | <devsnek> | but it would be kind of unfortunate |
| 20:36 | <rkirsling> | wow this is giving me fomo |
| 20:36 | <rkirsling> | oughtta dive into that Temporal repo more properly |
| 20:38 | <devsnek> | temporal is awesome |
| 20:39 | <keith_miller> | I don't see why wasm has any less constraint to return to the run loop |
| 20:39 | <keith_miller> | If your wasm source language doesn't return to the event loop you'll still be screwed |
| 20:39 | <devsnek> | someone needs to enable redirect to https on tc39's gh-pages |
| 20:39 | <keith_miller> | because you can't get any events |
| 20:39 | <devsnek> | you don't need events |
| 20:39 | <devsnek> | you could be working with atomic shared buffers |
| 20:40 | <devsnek> | which is something that people actually do |
| 20:40 | <littledan> | 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 |
| 20:40 | <littledan> | but you know we love this and would probably be doing it in our free time anyway... |
| 20:40 | <littledan> | (e.g., Ujjwal concretely did start on this in his free time before starting at Igalia) |
| 20:40 | <devsnek> | breaking: igalia and bloomberg conspiring to add usable datetime to js |
| 20:40 | <keith_miller> | littledan: I think it was in the slides |
| 20:40 | <keith_miller> | could be wrong |
| 20:41 | <littledan> | oh good |
| 20:41 | <ljharb> | devsnek: the box is checked |
| 20:41 | <devsnek> | ljharb: i was able to visit tc39.es/proposal-temporal/docs with no https |
| 20:41 | <ljharb> | devsnek: and http redirects to https to me |
| 20:41 | <ljharb> | devsnek: ah, that's just for that one repo |
| 20:41 | <ljharb> | devsnek: every repo has to check it separately |
| 20:41 | <devsnek> | oh |
| 20:41 | <devsnek> | that's not great |
| 20:42 | <devsnek> | we should ask github to do something about that |
| 20:42 | <michaelficarra> | wait I thought we didn't want a new way to probe system time |
| 20:42 | <shu> | 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? |
| 20:43 | <ljharb> | 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 |
| 20:43 | <keith_miller> | shu: I think the difference is between doing it at a different time or not at all |
| 20:43 | <keith_miller> | both are allowed by the spec but one is clearly not the intended behavior |
| 20:44 | <keith_miller> | 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 |
| 20:44 | <keith_miller> | Since we can't throw we can only silently ignore it |
| 20:45 | <shu> | keith_miller: i'm not convinced the interop risk is different |
| 20:45 | <littledan> | this sounds eerily similar to WebAssembly synchronous module compilation not working on the main thread in Chrome... |
| 20:45 | <keith_miller> | littledan: But that throws right? |
| 20:45 | <littledan> | yeah |
| 20:46 | <littledan> | but there's no part of the spec that specifically allows for throwing, there |
| 20:46 | <littledan> | anyway, the interop situation there is not great. I'd prefer to avoid if it possible! |
| 20:46 | <devsnek> | i'm still angry that chrome doesn't allow sync compilation |
| 20:46 | <shu> | this interop risk is also a risk for a single browser |
| 20:47 | <keith_miller> | I thought it was a size thing? |
| 20:47 | <keith_miller> | maybe I'm wrong though |
| 20:47 | <devsnek> | its a size but only enforced for the sync api |
| 20:47 | <devsnek> | the size is also small enough that only toy demos will be under the limit |
| 20:47 | <keith_miller> | I think it's mostly for snippets not for whole apps |
| 20:48 | <keith_miller> | or at least that was my understanding of why it's there |
| 20:48 | <shu> | i thought we (browsers) all signed up for educating devs in such a way that cleanupSome can be a nop at any time |
| 20:48 | <keith_miller> | not arguing for or against it |
| 20:48 | <keith_miller> | lol |
| 20:48 | <devsnek> | the logic for sorucemapping is too big for sync loading in chrome |
| 20:48 | <devsnek> | sourcemapping* |
| 20:48 | <devsnek> | and that's not a lot of logic |
| 20:49 | <keith_miller> | 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 |
| 20:50 | <keith_miller> | like we could educate devs that they nest constructurs in functions but that doesn't mean everyone doesn't do that |
| 20:50 | <keith_miller> | that they shouldn't nest constructors in functions |
| 20:50 | <shu> | keith_miller: that's qualitatively different than an inherently nondeterministic function |
| 20:50 | <shu> | err, feature |
| 20:50 | <shu> | keith_miller: let me separate the questions |
| 20:51 | <shu> | keith_miller: do you *also* object to the worker use case |
| 20:51 | <keith_miller> | I don't particularly like it but personally I'll swallow it. |
| 20:52 | <keith_miller> | I can't speak to the managers of WebKit though |
| 20:52 | <michaelficarra> | I'm surprised the era name is returned as "reiwa" instead of "㋿" |
| 20:53 | <rkirsling> | hmm yeah I didn't think `reiwa` was a thing from Unicode's perspective |
| 20:54 | <devsnek> | when in doubt blame icu4c |
| 20:56 | <michaelficarra> | rkirsling: you mean the square era names in general? |
| 20:56 | <shu> | 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 |
| 20:58 | <devsnek> | i know some people who would be very very sad if cleanupSome isn't available |
| 20:59 | <keith_miller> | I mean I know people that will be very very sad if cleanupSome is available :P |
| 20:59 | <devsnek> | what's the argument against it |
| 21:00 | <devsnek> | that it can be used on the main thread? |
| 21:01 | <howdoi> | Where do we signup for temporal weekly meetings? |
| 21:01 | <rkirsling> | michaelficarra: I mean specifically the romanized string like you said |
| 21:02 | <michaelficarra> | oh it shouldn't be |
| 21:02 | <michaelficarra> | I don't know where that came from |
| 21:02 | <shu> | keith_miller: okay, here's my proposal |
| 21:02 | <michaelficarra> | as devnsek says, probably blame ICU |
| 21:02 | <keith_miller> | 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. |
| 21:02 | <devsnek> | i mean that's partially the motivation of web workers |
| 21:02 | <keith_miller> | That's in addition to increasing the compatibility surface area of the proposal |
| 21:02 | <shu> | keith_miller: cleanupSome has valid use cases for both web workers and node workers, less so for main thread |
| 21:02 | <devsnek> | and no one was against web workers |
| 21:02 | <devsnek> | at least that i know of |
| 21:02 | <shu> | keith_miller: the spec currently already has allowance for cleanupSome to always be a no-op |
| 21:03 | <shu> | keith_miller: chrome and v8 will ship with cleanupSome being nop on the main thread |
| 21:03 | <shu> | keith_miller: we add this requirement in the HTML spec |
| 21:03 | <devsnek> | shu: chrome will or v8 will |
| 21:03 | <shu> | both? |
| 21:03 | <keith_miller> | why not allow throwing if the host doesn't allow it? |
| 21:03 | <devsnek> | shu: we would not want to disallow it in node |
| 21:03 | <devsnek> | i don't think |
| 21:04 | <mmarchini> | I second what devsnek said |
| 21:04 | <shu> | by main thread i mean align with [[CanBlock]] |
| 21:04 | <devsnek> | oh ok |
| 21:04 | <mmarchini> | otherwise we would need to spawn up a worker every time we want weakrefs with computational-heavy scripts |
| 21:04 | <shu> | does node have any agents where [[CanBlock]] is false? |
| 21:04 | <devsnek> | i thought you meant by default 😅 |
| 21:04 | <shu> | no, i mean on main thread |
| 21:04 | <devsnek> | uh i don't think we expose that |
| 21:04 | <shu> | Atomics.wait exposes it |
| 21:04 | <shu> | Atomics.wait throws where [[CanBlock]] is false |
| 21:04 | <devsnek> | no i mean the ability to disable it |
| 21:05 | <shu> | ah |
| 21:05 | <bradleymeck> | shu: no, it is allowed |
| 21:05 | <bradleymeck> | we should absolutely not disable it in node |
| 21:05 | <devsnek> | an embedder could create an agent and do whatever it wants with it |
| 21:05 | <shu> | keith_miller: i can live with throwing when [[CanBlock]] is false in cleanupSome |
| 21:05 | <keith_miller> | shu: Ok, let me get back to you tomorrow |
| 21:05 | <shu> | keith_miller: if apple agrees to that and we can settle this before the end of the meeting |
| 21:05 | <shu> | keith_miller: great, thanks |
| 21:05 | <keith_miller> | or w/e people get back to me |
| 21:06 | <shu> | well... |
| 21:06 | <shu> | i don't have plans to wait another 2 months for resolution on this |
| 21:07 | <devsnek> | where do i send the cake asking apple to please not block cleanupSome |
| 21:07 | <mhofman> | 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 |
| 21:08 | <devsnek> | if it doesn't yield the user can't click anything |
| 21:08 | <shu> | 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 |
| 21:08 | <devsnek> | regardless of click handlers |
| 21:08 | <devsnek> | the page just freezes |
| 21:08 | <shu> | 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 |
| 21:09 | <devsnek> | like the reschedule problem with iterators |
| 21:09 | <shu> | my initial response is basically "that's what you bought into by using finalizers to begin with" |
| 21:09 | <devsnek> | i agree with shu there |
| 21:09 | <shu> | i appreciate the practical difference between "never/always" and different likelihood |
| 21:10 | <mhofman> | 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? |
| 21:10 | <shu> | it does do that yes |
| 21:10 | <shu> | minor GCs especially |
| 21:10 | <keith_miller> | shu: Sorry I meant that as if people get back to me before tomorrow |
| 21:10 | <shu> | ah +1 |
| 21:10 | <keith_miller> | I'll reply then |
| 21:10 | <keith_miller> | lol |
| 21:11 | <Bakkot> | MylesBorins condolences |
| 21:11 | <shu> | 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 |
| 21:11 | <shu> | 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 |
| 21:12 | <Bakkot> | HTML could also spec it |
| 21:12 | <shu> | that's what i suggested above |
| 21:12 | <shu> | we leave cleanupSome as is, maybe add a host hook |
| 21:12 | <shu> | and HTML can decide to nop or throw on main thread |
| 21:13 | <mhofman> | either option will make testing interesting. Require to spun a worker to test `cleanupSome` |
| 21:13 | <devsnek> | testing this is pretty impossible |
| 21:13 | <shu> | shrug, we bought into that world already on the web |
| 21:14 | <shu> | where main thread and worker threads have distinctly different capabilities along sync/async boundaries |
| 21:14 | <devsnek> | speaking of which engine262 is reporting really low coverage levels for weakref stuff |
| 21:14 | <devsnek> | and i'm not sure why |
| 21:14 | <devsnek> | should investigate at some point |
| 21:15 | <mhofman> | half of the spec is impossible to test, especially after some of the more recent changes |
| 21:16 | <devsnek> | could make special cases for engine262 since it has deterministic collection |
| 21:16 | <devsnek> | hm i guess that's what the implementation contributed tests are |
| 21:17 | <mhofman> | 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 |
| 21:19 | <Bakkot> | 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" |
| 21:21 | <devsnek> | that's sort of what we have isn't it |
| 21:21 | <devsnek> | $262.gc |
| 21:24 | <keith_miller> | 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? |
| 21:24 | <devsnek> | keith_miller: as currently written that is required |
| 21:24 | <keith_miller> | ok wew |
| 21:24 | <mhofman> | right, we'd need the following hooks: |
| 21:24 | <mhofman> | - obj has been collected |
| 21:24 | <mhofman> | - all cells have been emptied |
| 21:24 | <mhofman> | - all finalizers have been called (aka no more empty cells in registries) |
| 21:24 | <mhofman> | - a kept objects list has been emptied |
| 21:25 | <devsnek> | https://tc39.es/proposal-weakrefs/#sec-weakref-execution |
| 21:25 | <devsnek> | for a given set of objects S |
| 21:25 | <devsnek> | clear everything related to those objects |
| 21:26 | <mhofman> | 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 |
| 21:26 | <keith_miller> | Don't you just need clear kept objects promise? |
| 21:26 | <keith_miller> | why do you need to know whether an object is collected or not? |
| 21:27 | <michaelficarra> | how is the agenda item spelled wrong on TCQ? I thought it was pulled in automatically |
| 21:27 | <keith_miller> | I guess I don't see why that's useful for testing (at least in the spec tests) |
| 21:27 | <rkirsling> | michaelficarra: not sure but we also had Surrogate Paris yesterday |
| 21:27 | <mhofman> | 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 |
| 21:27 | <keith_miller> | for an engine specifically I could see why you'd want to know if it so you don't have practical bugs |
| 21:28 | <keith_miller> | if it has been collected* |
| 21:28 | <devsnek> | that's my sadness regarding the tests |
| 21:28 | <devsnek> | they're so loose they might miss bugs in the implementations |
| 21:28 | <mhofman> | ^ |
| 21:28 | <keith_miller> | That's fair |
| 21:29 | <keith_miller> | You could have non-normative tests that are much stronger but I don't think those can be part of test262 |
| 21:29 | <devsnek> | they can be in implementation-contributed |
| 21:29 | <keith_miller> | I mean I just copied v8's tests and refactored them to work with JSC |
| 21:30 | <shu> | oh so |
| 21:30 | <keith_miller> | well except for the ones that required precise GC |
| 21:30 | <shu> | if i made a cleanupSome test that always collects something... |
| 21:30 | <jridgewell> | I really dislike the `#foo` = `this.#foo` shorthand. |
| 21:30 | <jridgewell> | So, happy with this. |
| 21:30 | <shu> | keith_miller: bro what if cleanupSome in fact always triggered a major gc |
| 21:30 | <keith_miller> | Lol |
| 21:30 | <keith_miller> | shu: Only if it's Sync |
| 21:31 | <devsnek> | 🎉 |
| 21:31 | <shu> | yes the only implementation allowed is naive stop-the-world mark and sweep |
| 21:31 | <shu> | none of fil's snooty stuff here |
| 21:31 | <devsnek> | the only allowed implementation is engine262's where you sweep after every job |
| 21:31 | <keith_miller> | better be precise too |
| 21:32 | <devsnek> | honestly y'all might enjoy this https://github.com/engine262/engine262/blob/1493ad798f84b74d5c2cb0a249d7222320fa67f4/src/api.mjs#L47-L144 |
| 21:33 | <devsnek> | shu: is it on purpose that the host hook is called for each cell in the registry instead of each registry |
| 21:33 | <shu> | what host hook? |
| 21:33 | <devsnek> | HostCleanupFinalizationRegistry |
| 21:34 | <devsnek> | if seven cells are empty in a registry that hook is called seven times |
| 21:34 | <devsnek> | instead of once |
| 21:34 | <shu> | where does it say that? |
| 21:34 | <shu> | oh, in Execution |
| 21:34 | <devsnek> | yeah |
| 21:34 | <shu> | not really, other than easier to spec |
| 21:34 | <shu> | this is non-observable |
| 21:34 | <devsnek> | right |
| 21:45 | <michaelficarra> | I am so excited for Compartments! |
| 21:45 | <rickbutton> | bradleymeck can you link your slide deck when you are finished |
| 21:45 | <devsnek> | compartments ftw |
| 21:46 | <rickbutton> | oh nvm no slides |
| 21:47 | <robpalme> | I only see two cursors in the Note Takers area. Do we need more help? |
| 21:48 | <rickbutton> | i think we are ok |
| 21:48 | <michaelficarra> | the fact that people are already doing this in so many ad hoc ways is HUGELY comepelling |
| 21:48 | <robpalme> | k |
| 21:48 | <devsnek> | michaelficarra: +1 |
| 21:57 | <shu> | ystartsev: keith_miller: https://github.com/tc39/proposal-weakrefs/issues/197 |
| 21:57 | <shu> | dan had the good suggestion on making the method normative optional delegated to the host, like what we just did with the SAB constructor |
| 22:00 | <keith_miller> | shu: What would be the process for requiring it? HTML would spec it? |
| 22:00 | <shu> | keith_miller: requiring what? |
| 22:01 | <keith_miller> | requiring cleanupSome. |
| 22:01 | <keith_miller> | Or are you saying that Safari could just not implement it? |
| 22:01 | <shu> | on worker threads? |
| 22:01 | <shu> | HTML would spec it |
| 22:01 | <shu> | HTML would say, main thread doesn't have cleanupSome, web workers do |
| 22:04 | <ljharb> | https://twitter.com/ljharb/status/1245472022697627649 asking for feedback on `#field in obj` |
| 22:04 | <shu> | there is a 3rd proposal, i guess, of cleanupSome being completely normative optional, but i am against that |
| 22:06 | <michaelficarra> | this proposal is really worked, and we're talking about way-beyond-stage-1 concerns right now |
| 22:17 | <michaelficarra> | are we planning on revisiting WeakRefs this meeting or should I check it off on the agenda? |
| 22:19 | <michaelficarra> | shu? |
| 22:19 | <shu> | i have asked MylesBorins to revisit, i consider it very high priority to get consensus from other browsers on what we will ship |
| 22:20 | <MylesBorins> | ok I think I missed that ask |
| 22:20 | <MylesBorins> | let me look at schedule |
| 22:20 | <shu> | akirose: bterlson: ^ just in case i'd like 15-20 mins to revisit weakrefs before end of meeting |
| 22:20 | <MylesBorins> | today's meeting? |
| 22:20 | <MylesBorins> | or the plenary |
| 22:20 | <shu> | no, today or tomorrow |
| 22:20 | <shu> | plenary |
| 22:21 | <shu> | err, not today, tomorrow |
| 22:21 | <MylesBorins> | copy that |
| 22:21 | <MylesBorins> | does littledan need to be present? |
| 22:22 | <littledan> | shu and I have sync'd about this and I'm good to defer to him |
| 22:22 | <littledan> | (if needed) |
| 22:22 | <MylesBorins> | ok cool |
| 22:22 | <MylesBorins> | I've added it to tomorrow |
| 22:22 | <littledan> | I'm signing off in 20 minutes |
| 22:22 | <shu> | tyty |
| 22:22 | <MylesBorins> | after the vote before stomics |
| 22:22 | <littledan> | (tomorrow I'll be here) |
| 22:22 | <shu> | yeah the atomics thing is bumpable |
| 22:23 | <MylesBorins> | ok |
| 22:23 | <MylesBorins> | it is on the agenda |
| 22:24 | <MylesBorins> | update in tcq + hackmd |
| 22:24 | <michaelficarra> | well glad I asked |
| 22:28 | <michaelficarra> | sffc's presentations are always SO easy to follow, I love it |
| 22:30 | <rickbutton> | ^ |
| 22:33 | <sffc> | Thanks :) |
| 22:41 | <robpalme> | import.meta queue from yesterday: |
| 22:41 | <robpalme> | New Topic: Do we need to worry about this prior to Compartments actually exposing hooks? Jordan Harband |
| 22:41 | <robpalme> | New Topic: I would prefer a stronger argument to preclude hosts from doing things because we can happen to enumerate use cases today |
| 22:43 | <shu> | that was me |
| 22:49 | <jridgewell> | Merge now |
| 22:51 | <Bakkot> | mathiasbynens sffc gibson042 wsdferdksl : ready to talk some more about escape sequences? |
| 22:52 | <sffc> | Gotta do it, next on the agenda seems like a good time |
| 22:52 | <wsdferdksl> | Let's go for it |
| 22:54 | <keith_miller> | 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? |
| 22:54 | <gibson042> | I guess so |
| 22:55 | <shu> | keith_miller: i have proposed no restrictions on what proposals should be in the incubator calls |
| 22:55 | <shu> | keith_miller: except that they be "amenable to being iterated on in smaller groups" |
| 22:55 | <keith_miller> | shu: Uhh, fair enough. I guess in a way this is independent of the calls |
| 22:56 | <shu> | keith_miller: the scope was widened to anything that's amenable to being discussed in smaller groups, not just stdlib |
| 22:56 | <shu> | since stdlib was hard to nail down and that seemed counterproductive to the point of the calls |
| 22:56 | <keith_miller> | 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 |
| 22:56 | <keith_miller> | shu: fair enough |
| 22:57 | <shu> | 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 |
| 22:57 | <MylesBorins> | If anyone has strong feelings (or any feelings) re: including import.meta in 2020, or just general process around that pleasel mk |
| 22:57 | <MylesBorins> | lmk |
| 22:58 | <shu> | is daniel rosenwasser on here? |
| 22:58 | <ljharb> | 404 |
| 22:59 | <keith_miller> | shu: Yeah, true. |
| 22:59 | <keith_miller> | 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. |
| 22:59 | <rkirsling> | shu: I don't think he ever has been :( I don't know why |
| 22:59 | <keith_miller> | Not that it has to be the same way JSC does it but just as an example |
| 22:59 | <shu> | keith_miller: there are counterpoints to that in V8, which has moved away from self-hosting |
| 22:59 | <keith_miller> | I thought that was for perf? |
| 22:59 | <michaelficarra> | nooo this was good until this slide |
| 23:00 | <rkirsling> | this slide must've changed just recently |
| 23:00 | <shu> | keith_miller: it's the same argument, right? part of the perf argument is the semantics that actual JS allows you to observe |
| 23:00 | <robpalme> | in case you hear anything, NYC is screaming again for the health workers |
| 23:01 | <shu> | keith_miller: though i don't know how JSC does it, if by that you mean a restricted subset... |
| 23:01 | <keith_miller> | Oh, I thought it was perf because you had to parse it at runtime? |
| 23:01 | <shu> | i wasn't there for the entire discussion obviously, but i think it's just for finer control |
| 23:01 | <rkirsling> | we do use a restricted subset, but we don't have a linter so it's tribal knowledge lol |
| 23:01 | <devsnek> | if i had to choose between torque and js self hosting i'd choose torque |
| 23:01 | <keith_miller> | I mean it's somewhat restricted but only in that you can't use global variables |
| 23:02 | <rkirsling> | keith_miller: yeah but we avoid let/const, e.g. |
| 23:02 | <devsnek> | v8 had so many perf cliffs from self hosting too |
| 23:02 | <devsnek> | remember when people avoided promises because they had to allocate those js arrays |
| 23:02 | <shu> | 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 |
| 23:02 | <keith_miller> | rkirsling: That's just because our parser is slower at parsing let/const |
| 23:02 | <shu> | see: LAPIs |
| 23:02 | <shu> | and the deeply problematic getOriginals |
| 23:03 | <devsnek> | es4 was based on a reference implementation |
| 23:03 | <devsnek> | written in ocaml |
| 23:03 | <rkirsling> | 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 |
| 23:03 | <devsnek> | or something |
| 23:03 | <devsnek> | one of the MLs |
| 23:03 | <shu> | there could be a more expressive, less verbose JS-for-specs, but i wouldn't want it to be actual JS |
| 23:03 | <keith_miller> | yeah, we just haven't done it |
| 23:03 | <rkirsling> | k |
| 23:03 | <devsnek> | i had an idea |
| 23:03 | <devsnek> | of having a meta language that spec steps are written in |
| 23:04 | <devsnek> | which renders to proseish |
| 23:04 | <keith_miller> | I also think it would be much easier for a webdev to read and understand |
| 23:04 | <keith_miller> | if it were JS-like |
| 23:04 | <devsnek> | could point to engine262 sources |
| 23:04 | <keith_miller> | but I don't think it has to be 100% JS tbf |
| 23:04 | <shu> | keith_miller: JS-like, sure, but not JS |
| 23:05 | <devsnek> | tc1337: specifying the language used to specify ecmascript |
| 23:05 | <shu> | 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 |
| 23:05 | <devsnek> | we could reify internal slots as private symbols if we had private symbols :P |
| 23:05 | <shu> | i don't want a 3rd thing |
| 23:05 | <shu> | we have a thing right now with records |
| 23:06 | <ljharb> | keith_miller: using https://npmjs.com/es-abstract, you can already do that :-p |
| 23:06 | <ljharb> | (and theoretically, trivially transform that code into spec text) |
| 23:06 | <keith_miller> | Yeah, but the point is somewhat that's not what's actually in the spec |
| 23:07 | <keith_miller> | which leads to things like my promise issue |
| 23:08 | <shu> | what is your promise issue? |
| 23:08 | <keith_miller> | shu: https://github.com/tc39/ecma262/pull/1912 (I forgot to add it to the agenda...) |
| 23:08 | <ljharb> | keith_miller: es-abstract's abstract op names are what's actually in the spec |
| 23:09 | <ljharb> | keith_miller: altho for IfAbruptRejectPromise and whatnot yeah, that's not easily done |
| 23:09 | <keith_miller> | but the JS code that produces the spec code isn't and isn't used for updates |
| 23:10 | <ljharb> | like ecmarkup? |
| 23:10 | <Bakkot> | mpcsh I would like to ask people to not argue about symmetry at all |
| 23:10 | <Bakkot> | unless it's really important |
| 23:10 | keith_miller | ljharb: looks |
| 23:10 | <mpcsh> | Bakkot: yep, I was too busy notetaking to remove it from the queue. gone now |
| 23:10 | <Bakkot> | thanks! |
| 23:11 | <keith_miller> | ljharb: yeah |
| 23:11 | <keith_miller> | ljharb: Maybe I'm misunderstanding how es-abstract works though... |
| 23:12 | <ljharb> | keith_miller: it's just JS implementations of abstract operations |
| 23:12 | <ljharb> | keith_miller: but if you write a spec polyfill with it, the spec text is remarkably 1:1 to the polyfill code |
| 23:12 | <ljharb> | keith_miller: except for a few caveat cases, which include any macros like IfAbruptRejectPromise :-/ |
| 23:13 | <devsnek> | engine262 only has a build step because of macros :( |
| 23:13 | <gibson042> | 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. |
| 23:13 | <keith_miller> | ljharb: Right, I'd like to see the polyfill be closer to the source JS |
| 23:13 | <keith_miller> | err |
| 23:13 | <rkirsling> | gibson042: +1 |
| 23:13 | <keith_miller> | spec be closer to the polyfill |
| 23:13 | <ljharb> | keith_miller: eg https://github.com/es-shims/Promise.prototype.finally/blob/master/implementation.js |
| 23:13 | <ljharb> | keith_miller: with this approach, i've found spec bugs in proposals |
| 23:14 | <keith_miller> | ljharb: In which direction? |
| 23:14 | <keith_miller> | like you've found bugs in the current spec text when translating to JS? |
| 23:14 | <keith_miller> | or the other way around? |
| 23:14 | <ljharb> | keith_miller: yes, the former |
| 23:15 | <keith_miller> | ljharb: I've found the same thing |
| 23:15 | <devsnek> | there are a lot of bugs in the spec |
| 23:15 | <ljharb> | devsnek's approach is much more extreme, writing an entire engine in JS :-p |
| 23:15 | <devsnek> | lol |
| 23:16 | <keith_miller> | oh 100% I just think its easier to think about the JS source over the spec text itself |
| 23:16 | <keith_miller> | with our current spec language |
| 23:16 | <keith_miller> | so I wouldn't be opposed to allowing something a bit nicer for us and (hopefully) readers |
| 23:19 | <shu> | i'm supportive of a higher-level spec language but the observability questions need to be very clearly answered |
| 23:19 | <keith_miller> | Yeah, I think it'd totally need to be a restricted set of JS |
| 23:20 | <devsnek> | how about c |
| 23:20 | <keith_miller> | shu: but that's in some ways much easier to verify since we don't have to be complete in our analysis. |
| 23:20 | <michaelficarra> | YAY everything is legal! |
| 23:20 | <rkirsling> | ^ tc39 out of context |
| 23:21 | <shu> | 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 |
| 23:21 | <shu> | i don't want us to shift the tradeoff to be that it's now easy to get the second kind of thing wrong |
| 23:21 | <gibson042> | https://www.imdb.com/title/tt6110648/ |
| 23:21 | <keith_miller> | shu: In JSC we have parsing assertions for things like that. |
| 23:22 | <keith_miller> | If you don't have a variable named "Object" in the function you'll crash in the parser |
| 23:22 | <keith_miller> | although we don't have something to stop you from doing %Object%.prototype |
| 23:22 | <shu> | keith_miller: i'm not convinced you can do all of this with parsing linting |
| 23:22 | <keith_miller> | But you could probably assert for that too |
| 23:23 | <shu> | anyways, easier to comment on a concrete thing |
| 23:23 | <keith_miller> | true |
| 23:23 | <mpcsh> | 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? |
| 23:23 | <michaelficarra> | there's also metajs: http://int3.github.io/metajs/ |
| 23:23 | <Bakkot> | mpcsh yes |
| 23:29 | <rkirsling> | nice use of logical assignment 😎 |
| 23:33 | <MylesBorins> | 🧙🏼♂️ |
| 23:39 | <michaelficarra> | I kinda wish this part was recorded so I could watch again if I wanted to implement one of my proposals in engine262 |
| 23:40 | <ystartsev> | michaelficarra: ditto |
| 23:40 | <bradleymeck> | jridgewell: I'm trying to fix up a stepper |
| 23:40 | <bradleymeck> | the readme also has a naive stepper impl for the debugger hook |
| 23:40 | <robpalme> | new requirement: stage 4 presentations must include live-coding the second implementation |
| 23:41 | <bradleymeck> | jridgewell: onDebugger() { debugger; } is enough |
| 23:41 | <bradleymeck> | but it isn't good at stepping (which is important) |
| 23:42 | <jridgewell> | Where do I put onDebugger? |
| 23:42 | <bradleymeck> | jridgewell: https://github.com/engine262/engine262/blob/c5285227f26ef661fc6f3723df3b44489a12a42d/test/supplemental.js#L23-L26 |
| 23:42 | <bradleymeck> | but make your own agent XD |
| 23:43 | <rbuckton> | If I add regexp match indices to engine262, would that meet the requirement for the proposal to advance to Stage 4? |
| 23:43 | <jridgewell> | Can we add it to the website? |
| 23:43 | <ljharb> | rbuckton: the actual answer is "maybe" |
| 23:43 | <rbuckton> | (since I have one impl right now, waiting on a 2nd...) |
| 23:43 | <bradleymeck> | a real stepper deals with the onNode hook, but i found i needed to also implement an exit hook not enter |
| 23:44 | <bradleymeck> | not just* |
| 23:44 | <shu> | rbuckton: what impl do you have? |
| 23:44 | <rbuckton> | It's implemented in V8 behind a flag and has been for several months. |
| 23:45 | <shu> | V8 does not have an implementation we're satisfied with shipping |
| 23:45 | <shu> | i would not want that used to fulfill stage 4 advancement until we think it's in a shippable state |
| 23:46 | <rkirsling> | jridgewell: noice |
| 23:46 | <jridgewell> | Self hosted spec language |
| 23:47 | <jridgewell> | That's real bootstrapping |
| 23:47 | <shu> | 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 |
| 23:48 | <shu> | (i know you've already called for more engines to implement) |
| 23:48 | <rbuckton> | maybe its the TypeScripter in me, but it feels like Engine262 at least needs JSDoc-style comments to indicate types. |
| 23:48 | <ljharb> | it probably is |
| 23:58 | <rkirsling> | well done devsnek 👏 |
| 23:59 | <devsnek> | thank you |
