| 00:03 | <robpalme> | bakkot: access granted |
| 00:13 | <Bakkot> | robpalme thanks! |
| 00:30 | <Bakkot> | > do do 42; while (false) while (false) |
| 00:30 | <Bakkot> | this is legal |
| 00:30 | <Bakkot> | good times |
| 00:31 | <Bakkot> | (as in, already legal) |
| 00:36 | <ljharb> | Bakkot: with your proposal tho, if you added curly braces it wouldn't be suddenly legal tho, right? |
| 00:37 | <ljharb> | like, it's legal right now as a statement, but it'd be a syntax error as a do expression |
| 00:38 | <Bakkot> | ljharb uuhhhh can you be more concrete? |
| 00:38 | <Bakkot> | i.e. write out what you're asking about |
| 00:39 | <ljharb> | `do { do { 42 } while (false) } while (false)` wouldn't be legal |
| 00:40 | <Bakkot> | that is currently legal |
| 00:40 | <Bakkot> | and would remain so |
| 00:41 | <ljharb> | sorry, i mean, in expression position |
| 00:41 | <ljharb> | `(do { do { 42 } while (false) } while (false))` or `(do do 42; while (false) while (false))` |
| 00:41 | <Bakkot> | ah: yeah, those are both illegal |
| 00:42 | <ljharb> | so there's not a refactoring hazard |
| 00:42 | <Bakkot> | first is illegal twice: it has a do-expr ending in a loop, and also it has `while` in a context it can't appear |
| 00:42 | <Bakkot> | second is illegal because `do`-exprs need braces |
| 00:43 | <Bakkot> | (though... I guess we could revisit that...) |
| 00:43 | <Bakkot> | (but maybe at a later point.) |
| 00:46 | <rkirsling> | needing braces feels weird if you're thinking of `do` as a control flow keyword but it doesn't feel weird if it's effectively a sigil on the braces |
| 00:46 | <rkirsling> | more and more I feel like `class {}` is a helpful comparison |
| 00:48 | <rkirsling> | (because I think braces should be required but that requires a conception that it's a "block marked by `do`" and not "`do` taking a block as an argument") |
| 00:49 | <Bakkot> | fwiw a `catch` block requires braces and there's no obvious "it's a block marked by `catch`" analogy there |
| 00:50 | <rkirsling> | hrmmmm |
| 00:50 | <Bakkot> | (I don't actually have any idea why we allow `if`/`else` without braces but not `try`/`catch`.) |
| 00:50 | <rkirsling> | tbh try/catch could easily drop the braces requirement |
| 00:50 | <rkirsling> | I just expect somebody to object |
| 00:51 | <rkirsling> | on a "you get a new footgun but you're not really solving a problem" basis |
| 00:51 | <Bakkot> | I guess maybe you end up with the dangling-else problem? |
| 00:51 | <rkirsling> | hmm, I haven't thought that through |
| 00:52 | <Bakkot> | `try try foo(); catch bar(); finally baz();` -> with which `try` do associate the `finally`? |
| 00:52 | <Bakkot> | *do you associate |
| 00:54 | <Bakkot> | aaaaaanyway I don't really want to do it for `catch` but it's marginally more appealing for `do` |
| 00:54 | <rkirsling> | surely the second but yeah, I'd expect that to raise an objection from somebody |
| 00:54 | <Bakkot> | surely the second? I'd say surely the first |
| 00:54 | <rkirsling> | wait really |
| 00:54 | <rkirsling> | how come |
| 00:54 | <Bakkot> | `else` binds to the closest `if`; why wouldn't `finally`? |
| 00:55 | <rkirsling> | that was my rationale for saying the second but I might have confused myself |
| 00:56 | <Bakkot> | if you put it on the second you end up (in that particular example) with something which would be legal, whereas you do not if you put it on the frst |
| 00:56 | <Bakkot> | but, you don't know if there's another `finally` coming |
| 00:57 | <Bakkot> | and it would be odd to say you have to wait until you parse the next thing to decide which `try` to associate the `finally` with |
| 01:01 | <rkirsling> | I'm actually not sure how you'd describe the logic to have it interpreted as `try { try foo(); } catch bar(); finally baz();` though, if that's what you mean |
| 01:03 | <Bakkot> | no |
| 01:04 | <Bakkot> | the natural interpretation is `try { try foo(); catch { bar(); } finally { baz(); }` |
| 01:04 | <Bakkot> | which would be as syntax error because the other `try` has neither `catch` nor `finally` |
| 01:04 | <Bakkot> | er, sorry, that should be `try { try { foo(); } catch { bar(); } finally { baz(); }` |
| 01:04 | <rkirsling> | yeah that was what I meant by "second" |
| 01:05 | <rkirsling> | second lexically |
| 01:05 | <Bakkot> | ahh |
| 01:05 | <Bakkot> | ok yes that was the confusion |
| 01:05 | <rkirsling> | whoops :) |
| 01:06 | <Bakkot> | that's on me probably; you're right that the token that comes first is "first" |
| 01:07 | <Bakkot> | ljharb I found this comment from 2018: https://github.com/tc39/proposal-do-expressions/issues/30#issuecomment-417389134 |
| 01:07 | <Bakkot> | (not holding you to that opinion, obviously, just was amused) |
| 01:28 | <devsnek> | did relative indexing make stage 4 |
| 01:29 | <Bakkot> | no, wasn't going for it because of the web compat issue |
| 01:29 | <Bakkot> | but they're gonna try outreach and re-shipping |
| 01:29 | <devsnek> | compat with "item" or "at"? |
| 01:33 | <Bakkot> | `at` |
| 01:33 | <Bakkot> | https://github.com/tc39/proposal-relative-indexing-method/issues/41 |
| 01:33 | <devsnek> | ah, unfortunate |
| 03:17 | <ljharb> | Bakkot: lol yeah, altho essentially i've been convinced that 2 is confusing, leaving 3 |
| 09:26 | <ystartsev> | shu: right, no problem. I was wondering if you wanted to order how we did the "intent to prototype" emails because that might give you something to point at, where developers from different communities might comment. We have the same situation with mozilla standards positions, where we sometimes have developers commenting on specific features. |
| 09:26 | <ystartsev> | But i think what you came up with will be closer to your goal so, we don't have to discuss it further |
| 17:58 | <ystartsev> | are we really only 10 people? |
| 17:59 | <michaelficarra> | 4 days is rough |
| 18:00 | <Bakkot> | up to 18 now |
| 18:00 | <Bakkot> | people were just waiting for 10am |
| 18:01 | <michaelficarra> | everybody out chatting in the hallway over breakfast? |
| 18:06 | <michaelficarra> | remember that this is for stage 1, so this example syntax is not set in stone |
| 18:06 | <michaelficarra> | the syntax shown on the previous slide would not have been backwards compatible, for example |
| 18:07 | <TabAtkins> | Does this proposal end up meaning that infinite numbers of nested square brackets are valid? like `[0-9]` and `[[[[[0-9]]]]]` are the same thing |
| 18:08 | <devsnek> | pretty soon we're gonna need multiline regex |
| 18:08 | <michaelficarra> | it appears that way TabAtkins |
| 18:09 | <TabAtkins> | not a problem, was just wondering. ^_^ |
| 18:09 | <ljharb> | enter, comments via "number of square brackets" |
| 18:09 | <TabAtkins> | devsnek: already got them via RegExp() with backtick strings |
| 18:09 | <devsnek> | awkward escaping though |
| 18:10 | <devsnek> | i guess new RegExp(String.raw``) would work? |
| 18:12 | <Bakkot> | bot seems to be working better today |
| 18:12 | <michaelficarra> | I don't think we should adopt that character class operand restriction |
| 18:12 | <rkirsling> | I know it's not either-or but actual Set operations seem much higher priority than this, hmm |
| 18:12 | <Bakkot> | I tweaked it a bit to maybe have fewer doubled words, which seems to have woorked, or else the speakers are just speaking more clearly |
| 18:12 | <rbuckton> | devsnek: I'm working up multiple RegExp proposals at https://gist.github.com/rbuckton/2f262b5298d4b2031cb7e0d5a1a62e19. One feature would allow for multi-line regexp. I'm also putting together a broad comparison of regexp engines (I showed some of that on day one with the flag comparisons at https://gist.github.com/rbuckton/cb0ea57949a8dfe0b4998301b6f46552). |
| 18:18 | <jridgewell> | mathiasbynens: Does regexpu already support set notation? |
| 18:18 | <jridgewell> | Or will Babel need to parse syntax to do it? |
| 18:18 | <mathiasbynens> | jridgewell: it does not. I've been using `regenerate` to do this kind of stuff by hand |
| 18:19 | <haxjs> | it seems the schedule changed? |
| 18:20 | <littledan> | haxjs: Is there a change you're concerned about? |
| 18:20 | <haxjs> | Isn't that my turn to present? |
| 18:20 | <jridgewell> | I think he was expecting to present now? |
| 18:20 | <littledan> | oh, I see |
| 18:20 | <haxjs> | what's the latest schedule? |
| 18:21 | <jridgewell> | Don't link it here |
| 18:21 | <jridgewell> | It's the hack.md link in the Reflector issue |
| 18:21 | <jridgewell> | https://github.com/tc39/Reflector/issues/340 |
| 18:21 | <jridgewell> | Sorry, the "Draft Schedule" link |
| 18:22 | <littledan> | well, that doc has haxjs going now |
| 18:22 | <littledan> | bterlson: akirose ^ |
| 18:22 | <devsnek> | haxjs: tcq says you're next |
| 18:23 | <rbuckton> | There was discussion about the schedule at the beginning of the day, based on what's in TCQ. |
| 18:23 | <haxjs> | ok, so i will be next? |
| 18:23 | <haxjs> | thank u |
| 18:23 | <ljharb> | https://github.com/benjamingr/RegExp.tag |
| 18:27 | <rbuckton> | A Regexp.escape that aggressively escapes (i.e., one that replaces characters or escapes with different meanings in and outside of character classes with `\u` sequences)? Or maybe a `u`-flag specific escape sequence like `/Escape{any content except unescaped curly brace }`. |
| 18:29 | <ljharb> | brad4d: such a repo already exists: https://github.com/benjamingr/RegExp.escape |
| 18:31 | <jorendorff> | ``RegExp.build`${thing}?` `` will mean something different from ``new RegExp(`${RegExp.escape(thing)}?`)`` |
| 18:31 | <jorendorff> | wow |
| 18:31 | <jorendorff> | RegExp.build`${thing}?` would mean something different from new RegExp(`${RegExp.escape(thing)}?`) |
| 18:31 | <gibson042> | background: the "even-odd problem" https://github.com/benjamingr/RegExp.escape/issues/37 |
| 18:33 | <jorendorff> | if we're going to be motivated by fear of what vendors might do, I'd like to know which vendors |
| 18:33 | <ljharb> | jorendorff: https://github.com/benjamingr/RegExp.escape/issues/43#issuecomment-738950494 implies that HTML monkeypatching it onto RegExp is a viable path |
| 18:34 | <ljharb> | jorendorff: and similar comments in that thread are about node's willingness to ship it as a utility module. |
| 18:36 | <wsdferdksl> | Is there a way to turn off the embedly previews? |
| 18:36 | <michaelficarra> | wsdferdksl: what is embedly and where are you seeing this? |
| 18:36 | <wsdferdksl> | webchat.freenode.net |
| 18:37 | <ljharb> | irccloud has no previews of github links for me. it seems client-specific |
| 18:38 | <ljharb> | wsdferdksl: it doesn't appear that kiwiirc (the webchat client) allows disabling of that feature |
| 18:38 | <rbuckton> | I wrote a tag-based solution as an npm package, but in user-land it suffers from the same requirements as `RegExp.escape` would. |
| 18:39 | <rbuckton> | I just aggressively escape any character that could have a meaning either in or out of a character class. |
| 18:39 | <wsdferdksl> | I get huge images of ljharb together with a snippet of the title and "Read the article on github.com" |
| 18:40 | <wsdferdksl> | This thing tries really hard to turn github pages into facebook profiles |
| 18:40 | <wsdferdksl> | Which is just silly for github issues |
| 18:40 | <ljharb> | agreed |
| 18:40 | <michaelficarra> | I am using a desktop IRC client and I do not get these things |
| 18:42 | <rbuckton> | The funny part is that a tag-template approach needs to be able to differentiate between safe an unsafe values, so you can do |
| 18:42 | <rbuckton> | ``` |
| 18:42 | <rbuckton> | R`unescaped${escaped}${R`unescaped`}` |
| 18:42 | <rbuckton> | ``` |
| 18:42 | <jorendorff> | ljharb: this is in the context of a node developer explicitly asking what would be appropriate and constructive to the standards process |
| 18:43 | <msaboff> | Why can't RegExp.escape() return a string wrapped with '(?:' ... ')' |
| 18:43 | <jorendorff> | is that right? |
| 18:44 | <msaboff> | RegExp.escape("foo [123]!") => "(?:foo \[123\]\!)" |
| 18:44 | <msaboff> | Seems like that should reduce / eliminate injection concerns. |
| 18:45 | <gibson042> | it reduces them, but does not eliminate them |
| 18:46 | <rbuckton> | Aggresively escape `RegExp.escape = (value) => value.replace(/./, _ => convertToUnicodeEscape(_))` where convertToUnicodeEscape just makes everything into its `\u{...}` form. No code injection, though slight differences with surrogate pairs in character classes... |
| 18:46 | <rbuckton> | msaboff: then it can't be used in a character class |
| 18:46 | <msaboff> | rbuckton Precisely! |
| 18:46 | <rbuckton> | well, it can be, but your character class would include `(:)` as characters |
| 18:47 | <rbuckton> | `(?:)` rather |
| 18:48 | <msaboff> | Do you think it is a common use case to escape a string and then put that in a character class? |
| 18:48 | <rbuckton> | msaboff no, but its not outside the realm of possibility. |
| 18:49 | <msaboff> | If not, let's come up with wrapping that would cause a syntax error if the returned string is put directly in a character class. |
| 18:49 | <ljharb> | msaboff: ooh, i like that |
| 18:49 | <devsnek> | i'd rather try to allow returning references from functions than have the ^ syntax |
| 18:50 | <littledan> | (or, have a setAt method...) |
| 18:50 | <rbuckton> | msaboff: possible for `u`-flag, may be impossible without |
| 18:50 | <rbuckton> | I actually brought up `^` in the slice notation syntax repo. |
| 18:50 | <msaboff> | It would also make sense to add {1} at the end of the returned string so that other immediately trailing quantifiers cause a syntax error. |
| 18:50 | <gibson042> | https://esdiscuss.org/topic/regexp-escape#content-55 |
| 18:51 | <rbuckton> | msaboff: Not sure about that. I might want to have a quantifier, in fact many of my use cases *do* use a quantifier. |
| 18:52 | <msaboff> | rbuckton So then you'd want the result as a non-captured group. |
| 18:52 | <rbuckton> | Though I suppose the workaround is `` new RegExp(`(?:${Regexp.escape(input)})?`) `` |
| 18:53 | <rbuckton> | well, irclcoud doesn't really understand markdown code sample syntax. |
| 18:53 | <devsnek> | ljharb: its solving setting |
| 18:53 | <devsnek> | you can't do `a.at(-1) = 5` |
| 18:53 | <ljharb> | rbuckton: surround it in ``` |
| 18:53 | <rbuckton> | ljharb: yeah |
| 18:53 | <ljharb> | that's normal markdown syntax for that |
| 18:54 | <ljharb> | ``` new RegExp(`(?:${Regexp.escape(input)})?`) ``` |
| 18:54 | <rbuckton> | ljharb: commonmark specifies you can use a balanced set of n-backticks for a code sample |
| 18:54 | <ljharb> | at this point GFM is "normal markdown" :-) |
| 18:54 | <rbuckton> | ``` |
| 18:54 | <rbuckton> | `` ` `` |
| 18:54 | <rbuckton> | ``` |
| 18:54 | <leobalter_> | ljharb: setting elements |
| 18:54 | <leobalter_> | wrt your queue item |
| 18:54 | <rbuckton> | That's GFM too (GFM is commonmark++) |
| 18:54 | <leobalter_> | arr[ˆ1] = x |
| 18:54 | <ljharb> | leobalter_: ah, thanks. i'll see if that's what's claimed |
| 18:55 | <ljharb> | rbuckton: ah ok, i've never found that to work reliably - slack, at least, works just like irccloud here, so maybe i've just assumed npm/github works the same |
| 18:55 | <ljharb> | jridgewell: can you mute |
| 18:56 | <ljharb> | ty |
| 18:56 | <shu> | wait, how does s[^n] for a string have any different behavior than code units? |
| 18:56 | <rbuckton> | The important bit is you have to have a space between the leading backticks/trailing backticks and if the sample starts or ends with a backtick. Leading/trailing spaces are removed (source: wrote a 100% compliant commonmark/gfm parser) |
| 18:57 | <devsnek> | i would not intuit that `x[^a]` is relative to x's length |
| 18:57 | <leobalter_> | I have a very positive support for this proposal but I don't like this take of discussing it in some exclusive way for this proposal vs .at |
| 18:58 | <rbuckton> | devsnek: https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/ranges |
| 18:59 | <devsnek> | rbuckton: i don't consider c# to be the best language either :P |
| 18:59 | <shu> | GME level volume on the queue |
| 18:59 | <jridgewell> | WHY DOES TEAMS ALLOW ME TO JOIN WITH AN UNMUTED MIC?! |
| 18:59 | <devsnek> | keeps you on your toes |
| 19:00 | <wsdferdksl> | This is the longest queue I've seen in a long time |
| 19:00 | <rbuckton> | jridgewell: didn't it ask you if you wanted your mic on or video broadcasting as part of the join process? |
| 19:00 | <devsnek> | i think a lot of it is not stage 1 concerns |
| 19:00 | <jridgewell> | I hit "rejoin" on my app |
| 19:00 | <devsnek> | due to how scoped this presentation is |
| 19:00 | <jridgewell> | Didn't change anything |
| 19:00 | <ljharb> | shu: +1 to your point |
| 19:00 | <jridgewell> | I was muted on the way out, I expect to be muted on the way in. |
| 19:01 | <rkirsling> | this feels wildly inappropriate, to suddenly propose a Stage 1 proposal that attacks what could have been a Stage 4 proposal in the same meeting |
| 19:01 | <rbuckton> | jridgewell: Odd. I'll take a note to send to the teams dev team |
| 19:02 | <jridgewell> | (This is the 2nd time it's happened, too. Yulia muted me yesterday after rejoining) |
| 19:02 | <rbuckton> | jridgewell: can you /msg me teams version/system specs in case its a version/os specific issue? |
| 19:07 | <devsnek> | i had a demo of some functionality a while back where you could do like `Array.prototype.at = function(n) { return &this[n < 0 ? this.length + n : n] }` |
| 19:07 | <devsnek> | and then `x.at(-1) = 5` |
| 19:08 | <shu> | we _could_ introduce pointers to JS |
| 19:08 | <devsnek> | well its narrowly scoped to return/functions |
| 19:08 | <shu> | but why? (: |
| 19:08 | <devsnek> | 🤷🏻 |
| 19:08 | <rbuckton> | shu: Pointers bad, memory-managed referenced maybe |
| 19:08 | <devsnek> | i'd be down to reify References |
| 19:08 | <devsnek> | as long as we use * and & |
| 19:09 | <devsnek> | :P |
| 19:09 | <shu> | and `->`? |
| 19:09 | <Bakkot> | wow what a strong oppose to this proposed negative 0 behavior |
| 19:09 | <Bakkot> | er |
| 19:09 | <Bakkot> | *I strongly oppose, that is |
| 19:09 | <rbuckton> | devsnek: https://github.com/rbuckton/proposal-refs |
| 19:09 | <shu> | i strongly oppose treating -0 differently |
| 19:09 | <shu> | that is quite out there |
| 19:09 | <devsnek> | does ^n have the same meaning as at(n) |
| 19:09 | <TabAtkins> | I've never once run into a -0 problem in Python, I dont' understand what th eissue is |
| 19:10 | <devsnek> | or is it a different thing |
| 19:10 | <shu> | devsnek: no, because ^0 means .length - 0 |
| 19:10 | <TabAtkins> | devsnek: No, ^n is equal to at(-n-1), as proposed |
| 19:10 | <shu> | (i.e. one beyond the end) |
| 19:10 | <devsnek> | ah |
| 19:10 | <devsnek> | that seems worse |
| 19:10 | <TabAtkins> | oh shoot yeah, sorry, not the -1 |
| 19:11 | <devsnek> | i think the at behavior is much more intuitive and composable |
| 19:11 | <shu> | i can see the scope of this proposal expanding to work with the slice proposal champions |
| 19:11 | <shu> | as it stands now it's kinda narrow |
| 19:11 | <shu> | for new syntax, that is |
| 19:12 | <TabAtkins> | Yeah def, if we're going to add syntax to indexing this should *absolutely* be done in concert with slices, that'd be great |
| 19:12 | <rickbutton> | if a[^1] works I would expect that a[(^1)] works |
| 19:12 | <devsnek> | i kind of want to do a poll on how people feel about refs |
| 19:12 | <TabAtkins> | I wouldn't necessarily - I'm reading the ^ as part of the [] syntax, so it's like the [^] operator |
| 19:13 | <ljharb> | ^ same |
| 19:13 | <rbuckton> | C# uses `^` for negative index values, and `..` for ranges |
| 19:13 | <devsnek> | ljharb: same to me or rick? |
| 19:13 | <ljharb> | to tab |
| 19:13 | <ljharb> | if `a[(^1)]` works than `^1` has to be a first-class thing, which doesn't make sense |
| 19:13 | <rickbutton> | or tab :) |
| 19:13 | <ljharb> | because then you have a third kind of property key |
| 19:13 | <michaelficarra> | ljharb: how does RegExp.escape escape properly for capture group names? |
| 19:13 | <devsnek> | ^ is never a valid unop, so we *could* make it valid |
| 19:14 | <ljharb> | michaelficarra: haven't tried it - it probably doesn't, since that's a newish feature |
| 19:14 | <ljharb> | devsnek: right but then what would it make |
| 19:14 | <rbuckton> | For now I'd be happy with |
| 19:14 | <rbuckton> | ``` |
| 19:14 | <rbuckton> | MemberExpression `[^` PrimaryExpression `]` |
| 19:14 | <rbuckton> | ``` |
| 19:14 | <devsnek> | rbuckton: `[^` or `[` `^` |
| 19:15 | <devsnek> | ljharb: only valid inside indexing, of course |
| 19:15 | <rbuckton> | devsnek: either. |
| 19:15 | <ljharb> | devsnek: right but then it's not a unary operator :-) |
| 19:15 | <rbuckton> | If we ever introduced `^` on its own, the above would give us room to expand |
| 19:15 | <michaelficarra> | ljharb: that context is particularly problematic, as supporting it would force us to \uXXXX escape everything non-identifiery |
| 19:16 | <devsnek> | ljharb: oh "it" is `a[(^x)]`, not making `^` a unary operator |
| 19:17 | <ljharb> | michaelficarra: can you file an issue? that seems like an important thing to look into |
| 19:18 | <ljharb> | devsnek: ah ok |
| 19:18 | <michaelficarra> | ljharb: already did |
| 19:18 | <ljharb> | ty |
| 19:18 | <rbuckton> | In the slice proposal, I mentioned a possible future of `@@seti`, `@@geti`, and reified `Index` and `Range` types so that `^x` and `x:y` could stand on their own. |
| 19:18 | <ljharb> | devsnek: but the parens working there suggest to me that it *is* a unary operator. |
| 19:18 | <devsnek> | ljharb: yeah i agree it would be confusing |
| 19:18 | <TabAtkins> | with slicing, I wouldn't think `a[(1:2)]` would work either, honestly |
| 19:19 | <rbuckton> | I brought up `^` in the slice proposal here: https://github.com/tc39/proposal-slice-notation/issues/30 |
| 19:20 | <rbuckton> | I also brought up slice extensibility (including reified values for `^x` and `x:y`) here: https://github.com/tc39/proposal-slice-notation/issues/19 |
| 19:20 | <TabAtkins> | I guess reifying them is useful; being able to store indexes somewhere else and later use them to lookup into an array is good, and being able to do that simply, rather than tracking the syntax out-of-band, would be good |
| 19:23 | <TabAtkins> | Tho reifying doesn't require the syntax to be invokable outside of the [] - it could just be a new object type for keys you can manually construct, but which is automatically done by the [] syntax |
| 19:23 | <Bakkot> | TabAtkins "lastIndexOf" is the most relevant precedent |
| 19:23 | <Bakkot> | not strings |
| 19:23 | <rbuckton> | The drawback to reification is that it could slow down implementations. Indexed access wouldn't just be coercion to string or symbol, instead it would have to check if the index expression is an object value with a `@@geti` (or `@@seti`) for indirection first |
| 19:23 | <rickbutton> | reified `x:y` would allow for `for (let x in 1:10) {}` which is fun |
| 19:23 | <TabAtkins> | Right, but that's talking about the last instance. The *direction* (in findFromX) is called "end" |
| 19:24 | <TabAtkins> | rickbutton: But we're already trying to handle that in the `range()` proposal too. |
| 19:25 | <rickbutton> | ah yeah forgot about the range proposal |
| 19:25 | <TabAtkins> | findLast() is fine. findFromLast() is not. |
| 19:25 | <rbuckton> | Strings don't have `find` or `findIndex` anyways |
| 19:25 | <devsnek> | *yet* |
| 19:26 | <jorendorff> | yay last |
| 19:26 | <rbuckton> | TabAtkins: no reason we couldn't have `range(x,y)` and `x:y`. We already have `Array(1, 2, 3)` and `[1, 2, 3]` :) |
| 19:27 | <TabAtkins> | Technically true, but I just wouldn't want to block `arr[1:2]` if a naked `1:2` is problematic. ^_^ |
| 19:27 | <rickbutton> | ^ agree |
| 19:27 | <rbuckton> | Plus `^x` and `x:y` would be unforgeable (at least, in the same way as `[]` and `{}` are) |
| 19:29 | <rbuckton> | TabAtkins: I think its a matter of framing the syntax for slice/negative index so that there's room to expand later (i.e., not `[^ Expression ]`, since changing `^` to infix later would break code) |
| 19:31 | <wsdferdksl> | rbuckton: What's "unforgeable"? |
| 19:32 | <rbuckton> | `Array` can be replaced globally, so `new Array()` could create something different than `[]`, which always creates an array per spec text. |
| 19:32 | <ljharb> | not that anyone should be using `new Array` in any code ever :-) |
| 19:32 | <wsdferdksl> | And what would ^x and x:y create? |
| 19:32 | <wsdferdksl> | New kinds of range objects? |
| 19:32 | <rbuckton> | Same for `new RegExp("foo")` vs `/foo/`. |
| 19:33 | <TabAtkins> | wsdferdksl: Yes, a reified Offset/Range object |
| 19:33 | <wsdferdksl> | OK |
| 19:33 | <rbuckton> | wsdferdksl: that's that I was just discussing, yes. Reified values for `^x` and `x:y` |
| 19:33 | <rbuckton> | that's not part of the proposal, but something I've discussed on the issue tracker for slice notation. |
| 19:34 | <wsdferdksl> | I can imagine lots of mistakes where folks wrote [a:b] when they meant (a:b), and it works but uses gobs of unnecessary memory. |
| 19:34 | <wsdferdksl> | Iterating over [a:b] instead of (a:b) |
| 19:36 | <haxjs> | I think the motivation of slice notation is ergonomics, so reification of `^i` and `a:b` should be a separate proposal. |
| 19:36 | <michaelficarra> | other than WithStatements, is there ever a case where reading from an in-scope identifier could have effects? |
| 19:36 | <TabAtkins> | wsdferdksl: Can you elaborate? I'm not sure what sort of potential mistake you're referring to |
| 19:36 | <wsdferdksl> | Reification of ^i cannot be a separate proposal because a[^b] would preclude it. |
| 19:36 | <devsnek> | this proposal seems unworkable due to TLA |
| 19:37 | <ljharb> | michaelficarra: a global getter? |
| 19:37 | <ljharb> | michaelficarra: otherwise i don't think so |
| 19:37 | <michaelficarra> | yeah I don't consider a global getter as in-scope |
| 19:37 | <wsdferdksl> | If we're doing them at all, we need to do them together |
| 19:39 | <wsdferdksl> | devsnek: TLA = Three Letter Acronym? |
| 19:39 | <gibson042> | "top-level await" |
| 19:39 | <devsnek> | wsdferdksl: top level await 😄 |
| 19:39 | <haxjs> | @TabAtkins the -0 problem in Python is like, you want a[1:-n] express drop n elements in the end, but if `n` could be 0, u have to write code like n == 0 ? a[1:] : a[1:-n] |
| 19:40 | <TabAtkins> | hm, ok. I've never run into that situation, but i get it |
| 19:41 | <wsdferdksl> | haxjs: The same problem occurs with all of the array methods that take negative indexes. How do you plan on fixing all of those? |
| 19:41 | <haxjs> | only slice/splice use neg index. |
| 19:41 | <haxjs> | Are there any other? |
| 19:43 | <wsdferdksl> | haxjs: That's incorrect |
| 19:43 | <TabAtkins> | If we have ranges *and* you can compose : and ^, then the syntax would fix it - `arr[1:^n]` |
| 19:43 | <haxjs> | @TabAtkins Yes, that what I want :-) |
| 19:44 | <michaelficarra> | imported names are not globals... |
| 19:44 | <haxjs> | @wsdferdksl Is there any other methods use neg index? |
| 19:44 | <wsdferdksl> | Yes |
| 19:44 | <haxjs> | which one? |
| 19:45 | <michaelficarra> | haxjs: Array.prototype.splice |
| 19:46 | <michaelficarra> | oops you mentioned splice |
| 19:46 | <michaelficarra> | TypedArray copyWithin |
| 19:46 | <ljharb> | copyWithin is what i was going to mention yeah |
| 19:46 | <ljharb> | regular arrays have it too |
| 19:47 | <michaelficarra> | oh wow didn't notice |
| 19:47 | <ljharb> | it's a really annoying one to shim |
| 19:47 | <michaelficarra> | also fill on Arrays and TypedArray |
| 19:47 | <ljharb> | to implement, rather |
| 19:47 | <wsdferdksl> | haxjs: There are lots of them. I'm surprised that you're unfamiliar with them when promoting a proposal to replace negative indexes. |
| 19:47 | <haxjs> | oh thank u , so we have three methods: slice/splice/copyWithin |
| 19:47 | <ljharb> | ahh yes, fill's `start` and `end` arguments |
| 19:47 | <michaelficarra> | also subarray on TypedArray |
| 19:47 | <michaelficarra> | haxjs: at least 5 |
| 19:48 | <ljharb> | also anything that takes fromIndex, like includes, indexOf, lastIndexOf, etc |
| 19:48 | <ljharb> | ok so i think that's it - 7 on array and 8 on typedarray |
| 19:48 | <michaelficarra> | tl;dr it's pretty common |
| 19:49 | <TabAtkins> | Anyway, a reified ^ could be passed to all of those, I suppose. ^_^ |
| 19:49 | <michaelficarra> | ljharb: also arraybuffer and sharedarraybuffer |
| 19:49 | <devsnek> | this is some cursed code |
| 19:49 | <ljharb> | which only has slice, yeah |
| 19:49 | <shu> | no no no no no |
| 19:49 | <shu> | nooooooo |
| 19:49 | <rbuckton> | devsnek: throwing a promise isn't new. See: React |
| 19:49 | <haxjs> | Ok. so at least we can have a better slice :) |
| 19:49 | <robpalme> | this is beautiful |
| 19:49 | <ljharb> | rbuckton: and it's cursed that react does it too |
| 19:50 | <shu> | what have we wrought |
| 19:50 | <devsnek> | rbuckton: oh i know, it just makes me sad |
| 19:50 | <ljharb> | rbuckton: and react's Suspense/Lazy model is still not really "finished" or fully fleshed out. |
| 19:50 | <wsdferdksl> | devsnek: yup! |
| 19:50 | <ljharb> | the ability to reject with a promise is absurd and i continue to think it's a mistake |
| 19:50 | <ljharb> | (to have a promise rejected with a `reason` that is itself a Promise, i mean) |
| 19:51 | <rbuckton> | ljharb: having had to use `Suspense` I can't say I disagree, its highly confusing |
| 19:51 | <shu> | i think i missed the connection between React's cursed code and how lazyInit would replace that use case |
| 19:52 | <rbuckton> | shu: more discussing the code example that showed throwing a Promise |
| 19:52 | <shu> | rbuckton: right, it's doing an iloop to simulate blocking and using thrown promises for control flow, or am i missing something? |
| 19:52 | <ljharb> | shu: the way you "suspend" a component in react is by throwing a promise. i believe that's also possibly how some react hooks work |
| 19:52 | <shu> | and how would lazyInit help? |
| 19:54 | <shu> | i thought those things were a sub-ESM boundary |
| 19:54 | <rricard> | it covers the lazy-component loading use case from suspense |
| 19:54 | <rricard> | not the full thing |
| 19:54 | <rricard> | (as I understand it) |
| 19:54 | <leobalter_> | My brain is still on Test262: https://gist.github.com/leobalter/f9ba9cc3fde91567212150ad2883eb77 |
| 19:58 | <littledan> | this is the Chrome investigation Shu is talking about https://docs.google.com/document/d/1o3qgHBx5_T0cV6kFU3HzSp8-bBOJFEtlRJKh59-ljgc/edit |
| 19:58 | <leobalter_> | seems like `a` is certain to end early on main.js, but it's a bit odd for "b" |
| 19:59 | <littledan> | here's my take on what we might do in HTML to make that reality https://github.com/whatwg/html/issues/4400#issuecomment-738737956 |
| 19:59 | <littledan> | note that this laziness has been prototyped https://github.com/whatwg/html/issues/4400#issuecomment-739049763 and doesn't *yet* help, though maybe it could if other changes are made |
| 19:59 | <littledan> | (changes inside the browser, not spec changes) |
| 20:00 | <Bakkot> | purity annotations!!!! |
| 20:00 | <Bakkot> | I mean they're a bad idea but I am still excited they're being brought up, even as a bad idea |
| 20:00 | <shu> | i regret bringing it up |
| 20:01 | <Bakkot> | it's fine I think we all know they're bad |
| 20:01 | <Bakkot> | even if I want them in my soul |
| 20:01 | <shu> | ystartsev: i worked on PJS too! |
| 20:01 | <shu> | big failure |
| 20:02 | <devsnek> | ljharb: let me introduce you to getters on the global object 😄 |
| 20:02 | <michaelficarra> | I second ljharb's horror |
| 20:02 | <shu> | yes, i mean we have getters |
| 20:02 | <shu> | we have that horror |
| 20:03 | <ljharb> | devsnek: i am aware of the existing horrors that i have no wish to repeat |
| 20:03 | <littledan> | JoelMarcey is trying to enroll as a delegate. Are there any Facebook colleagues who could help? |
| 20:03 | <devsnek> | i remember someone made a thing with exceptions and global getters to have `__LINE__` in js |
| 20:03 | <shu> | ljharb: i think the point is that there's nothing to repeat |
| 20:03 | <bradleymeck> | i keep touching something on my keyboard and it is unmuting me in teams |
| 20:03 | <shu> | ljharb: we're not adding a new thing that repeats the horror, but variable references now are already a horror |
| 20:03 | <ljharb> | shu: right, fair |
| 20:03 | <bradleymeck> | devsnek, I did __LINE |
| 20:03 | <ljharb> | shu: i don't want to expand the cases where the horror is reified |
| 20:03 | bradleymeck | :chef's kiss: |
| 20:04 | <bradleymeck> | oh god why did my client do that |
| 20:04 | <michaelficarra> | that reminds me, someone from Microsoft should help Wenlu Wang get added to delegates.txt |
| 20:04 | <jridgewell> | I love `__LINE__` actually |
| 20:04 | <shu> | ljharb: that may be contentious too, you can take the position that i think yulia is taking, which is that it _is_ a getter |
| 20:04 | <michaelficarra> | (rbuckton bterlson) see above |
| 20:04 | <ljharb> | shu: right but it's not a global one |
| 20:04 | <bradleymeck> | jridgewell: it gets really weird though once you start dealing with code wrappers |
| 20:04 | <ljharb> | shu: it's a module-level getter, which is not a thing that exists yet. |
| 20:04 | <shu> | ljharb: what's the global distinction? |
| 20:04 | <shu> | ah |
| 20:05 | <shu> | hmm, need to think on that |
| 20:05 | <ljharb> | shu: iow, either 100% or 0% of my code has this horror available. adding it at module level means i need to worry about it per-module instead of per-app |
| 20:05 | <ljharb> | so the cognitive load is much, much higher. |
| 20:05 | <shu> | ljharb: but module toplevels can reference things on the global scope, which may have getters |
| 20:06 | <ljharb> | also global getters are a bad thing and basically nobody does them; the point of this new feature is to encourage people to do it |
| 20:06 | <devsnek> | *technically* all imports are getters rn |
| 20:06 | <shu> | ljharb: and in general, when you look at an isolated variable use, you have no idea what it is |
| 20:06 | <ljharb> | shu: eval exists but we wouldn't want new features that encourage use of eval |
| 20:06 | <michaelficarra> | shu: you know when a variable is in scope or not |
| 20:06 | <devsnek> | do you? |
| 20:06 | <michaelficarra> | as in, would resolve before the global object |
| 20:06 | <ystartsev> | for what its worth, making the import binding a getter is basically how we do this in fx |
| 20:06 | <ljharb> | devsnek: sure but a guaranteed side-effect-free getter |
| 20:06 | <shu> | michaelficarra: that is ... mostly true |
| 20:07 | <shu> | michaelficarra: but only false for an arcane terrible reason |
| 20:07 | <shu> | which is that the global lexical scope is shared among script tags |
| 20:07 | <michaelficarra> | with statement? |
| 20:07 | <devsnek> | honestly i'd be more interested in a variant of dynamic import which has to take a string literal |
| 20:07 | <shu> | well, with too |
| 20:07 | <devsnek> | so the engine can eagerly load it |
| 20:07 | <ljharb> | devsnek: that would be great |
| 20:07 | <devsnek> | it still introduces async though |
| 20:07 | <shu> | michaelficarra: but yeah, good point |
| 20:07 | <devsnek> | which is blocking i think |
| 20:07 | <ljharb> | devsnek: altho that's an optimization they could already apply with a literal, right? |
| 20:08 | <shu> | michaelficarra: i can better relate to the qualitative difference of why this is added horror |
| 20:08 | <devsnek> | yes, but i think the point is that they don't want to refactor their code to have a dynamic import somewhere in it |
| 20:08 | <ystartsev> | not only that, but dynamic import has significant implications for a codebase |
| 20:08 | <ystartsev> | as shown by react's use case |
| 20:09 | <ystartsev> | because we have investigated just using a script to rewrite everything that use our lazy getter to use dynamic import |
| 20:09 | <shu> | ystartsev: to make sure i understand the async-should-be-eager point |
| 20:09 | <shu> | the problem is just that you can't kick off a sync fetch on variable access |
| 20:10 | <shu> | because... the programmer intention was async? |
| 20:10 | <ystartsev> | no because it would break run to completion |
| 20:10 | <shu> | oh right |
| 20:10 | <shu> | of course, thanks |
| 20:10 | <shu> | it changes the timing completely |
| 20:11 | <ystartsev> | so, one way to deal with side-effectful code, that i looked at, was the same approach as top level await |
| 20:11 | <ystartsev> | but it requires analysis and definition of what is side effectful |
| 20:11 | <ystartsev> | in practice, it might end up delazifying everything and only allows modules that are basically just lists of functions to be lazy |
| 20:11 | <ystartsev> | I didn't bring that up really clearly, but that was my worry there |
| 20:12 | <ystartsev> | if there is a way to do this, i would be interested because it would resolve this issue |
| 20:36 | <shu> | ystartsev: that's a good worry |
| 20:36 | <shu> | ystartsev: really looking forward to having an incubator call and bringing the chrome module streaming folks to the table |
| 20:36 | <ystartsev> | yeah, very excited to talk further about it |
| 20:56 | <robpalme> | we are restarting in 4 mins |
| 21:17 | <michaelficarra> | I appreciate the phrasing of "exploring the space of language negotiation" sffc |
| 21:19 | <shu> | +1 |
| 21:28 | <michaelficarra> | we have logs now! |
| 21:29 | <rkirsling> | I still don't know what a bouncer is, concretely lol |
| 21:29 | <shu> | we COULD ask ecma to get an irccloud paid team account for delegates |
| 21:29 | <rkirsling> | not interested in figuring that out |
| 21:29 | <rkirsling> | shu: true |
| 21:29 | <ljharb> | i think we should |
| 21:29 | <michaelficarra> | shu: sounds like we could just go down the Slack route at that point |
| 21:29 | <devsnek> | anything but slack |
| 21:29 | <shu> | slack has additional complications, no? |
| 21:30 | <shu> | michaelficarra: it'll also be as-needed |
| 21:30 | <michaelficarra> | it has custom emojis, so… trade-offs |
| 21:30 | <devsnek> | slack doesn't allow user to user moderation (like blocking, etc) |
| 21:30 | <rkirsling> | #webkit is dead so Sony doesn't actually have a reason to keep paying for my team's accounts (though I can still be an exception, I just have to go out of my way) |
| 21:36 | <rbuckton> | I'm unfamiliar with Matrix. While I'd been hoping for a response from Discord, the fact that I can't switch between personal and a "work" Discord account makes me interested in trying out Matrix. |
| 21:36 | <TabAtkins> | Anything but Slack, yes. |
| 21:38 | <ljharb> | slack's great but i'm in camp "anything but discord" |
| 21:38 | <rkirsling> | I will round out the group by saying that I like Slack and Discord and am sad to add yet another platform to the mix |
| 21:40 | <jridgewell> | Can I be in "anything but IRC" camp? |
| 21:41 | <ryzokuken> | ljharb: count me in that camp as well |
| 21:41 | <ljharb> | jridgewell: #tc39-inclusion tends to include those folks |
| 21:41 | <jridgewell> | Replacing IRCCloud with X is net negative for me, but I'll get to forget IRC exists which is net positive. |
| 21:41 | <ryzokuken> | not the former |
| 21:41 | <jridgewell> | net neutral** |
| 21:41 | <jridgewell> | Ugh, correction isn't clear. |
| 21:42 | <jridgewell> | Replacing IRCCloud with X is net neutral** for me, but I'll get to forget IRC exists which is net positive. |
| 21:43 | <rkirsling> | I like IRCCloud but I have no other reason to use it, so at least I'm not actually adding to the number of active chat apps on my computer |
| 21:43 | <rkirsling> | by swapping it out with something else |
| 21:44 | <akirose> | ljharb: pls repost question after i advance q |
| 21:44 | <ryzokuken> | jridgewell: do you wish you wrote this on a platform that allows editing? :D |
| 21:44 | <ljharb> | akirose: ahh not enough time to copy paste, will try to retype |
| 21:44 | <akirose> | i got u |
| 21:44 | <ljharb> | ooh ty |
| 21:45 | <rkirsling> | ryzokuken: that is another big point toward "anything but IRC", yeah |
| 21:45 | <rkirsling> | I edit _constantly_ when that feature exists |
| 21:45 | <ryzokuken> | I think editing is awesome |
| 21:45 | <devsnek> | ljharb: you think multi-method protocols are inherently bad? |
| 21:46 | <ljharb> | devsnek: besides RegExp, do you have an example of one you think isn't bad? |
| 21:46 | <rickbutton> | Set? |
| 21:47 | <rickbutton> | add/delete |
| 21:47 | <devsnek> | the collection types more or less |
| 21:47 | <ljharb> | indeed, and we've already as a committee ran into that as a problem |
| 21:47 | <rkirsling> | if we ever do reify protocols, I sincerely hope that we stop calling them protocols |
| 21:47 | <devsnek> | rkirsling: traits |
| 21:47 | <rkirsling> | because no one has any idea what that word means |
| 21:47 | <ljharb> | that the Set constructor observably calls "add" is why Set methods haven't advanced. |
| 21:47 | <rkirsling> | yeah that'd be fine |
| 21:47 | <bradleymeck> | i had happily forgot the pain caused by Set and add() |
| 21:48 | <rkirsling> | I couldn't remember what Set methods were blocked by yeah |
| 21:51 | <ljharb> | akirose: my clarifying question isn't a question so i could just say it as part of my topic |
| 21:51 | <bradleymeck> | base class calling subclass is just a rats nest |
| 21:51 | <ljharb> | akirose: arguably i should have edited my topic to add that, but i can't edit :-) |
| 21:51 | <ljharb> | bradleymeck: yes |
| 21:56 | <Bakkot> | ljharb that is not why |
| 21:56 | <ljharb> | k, please correct me :-) |
| 21:58 | <jorendorff> | dictionaries are recognized as a special thing in webidl |
| 21:58 | <jorendorff> | aren't they? |
| 22:00 | <bradleymeck> | jorendorff: https://heycam.github.io/webidl/#idl-dictionaries |
| 22:00 | <Bakkot> | ljharb the main question was about reading internal slots when querying and how that would interact with subclassing |
| 22:00 | <Bakkot> | the fact that the set ctor calls "add" wasn't super relevant |
| 22:00 | <ljharb> | k |
| 22:01 | <Bakkot> | ljharb you don't validate "is this a calendar" |
| 22:01 | <ljharb> | i do if i want my API to give useful error messages when my users give me the wrong thing |
| 22:01 | <Bakkot> | how do you validate "is this a valid set of options to pass to babel" |
| 22:01 | <Bakkot> | you don't |
| 22:02 | <Bakkot> | it's just a grab bag of options |
| 22:02 | <Bakkot> | that's how JS works |
| 22:02 | <ljharb> | there's no class for "BabelOptions" |
| 22:02 | <Bakkot> | yup |
| 22:02 | <Bakkot> | that's good |
| 22:02 | <ljharb> | thus yes, it's just a grab bag |
| 22:02 | <ljharb> | the existence of a Calendar and TimeZone class mean it's not that. |
| 22:02 | <devsnek> | its different |
| 22:02 | <ljharb> | than a typical grab bag of options? yes, i think it is different. |
| 22:02 | <Bakkot> | if someone made such a class to let people more conveniently set them up, that would change the situation |
| 22:02 | <Bakkot> | *that would _not_ change the situation |
| 22:02 | <devsnek> | there is both a nominal and a structural definition |
| 22:02 | <devsnek> | that's the point of the protocol |
| 22:03 | <devsnek> | the nominal one is like the default impl in stdlib |
| 22:03 | <ljharb> | a calendar is not just a set of options tho |
| 22:03 | <Bakkot> | is too |
| 22:03 | <ljharb> | options are often separable. |
| 22:03 | <ljharb> | no part of the calendar is conceptually separable, all of the methods have to work in concert |
| 22:03 | <devsnek> | you could say "a calendar is an object with these methods and these properties" |
| 22:04 | <Bakkot> | options are not necessarily separable, that's just a thing which sometimes happens to be true |
| 22:04 | <ljharb> | true |
| 22:04 | <ljharb> | devsnek: right, so, how do i validate that an object someone gave me has the right methods and properties |
| 22:04 | <devsnek> | you could do it manually |
| 22:04 | <devsnek> | there's a proposal somewhere for `x implements Y` |
| 22:05 | <Bakkot> | could and should, since being an instance of the class does not imply it has those methods |
| 22:05 | <ljharb> | Bakkot: i'm fine assuming that a subclass is well-formed, that's not the same as assuming that any random object is. |
| 22:05 | <ljharb> | for a thenable i can `typeof x.then === 'function'` and assume the rest |
| 22:06 | <devsnek> | that's a manual check |
| 22:06 | <ljharb> | sure |
| 22:06 | <ljharb> | of a single method. |
| 22:06 | <devsnek> | because that's what a thenable is |
| 22:06 | <Bakkot> | iterator results objects have both a `value` and a `done` |
| 22:06 | <ljharb> | it's not difficult to distinguish objects conforming to a single-method protocol. |
| 22:06 | <ljharb> | Bakkot: those aren't methods. iterator results objects are just data. |
| 22:07 | <ljharb> | i'm not pretending there's a short list of simple rules here. |
| 22:07 | <ljharb> | but these things are not all the same. |
| 22:07 | <Bakkot> | timezone objects are also just data, they're just implemented as code |
| 22:07 | <jorendorff> | self-sends |
| 22:08 | <shu> | okay thanks |
| 22:08 | <Bakkot> | ljharb the reason to provide a class is to provide a convenient way to get a set of default behavior, if you want that |
| 22:08 | <shu> | sends as in sending messages |
| 22:08 | <ljharb> | Bakkot: a function serves that purpose |
| 22:08 | <Bakkot> | so does a class |
| 22:08 | <ljharb> | sure. but a function doesn't encourage subclassing. |
| 22:08 | <jorendorff> | the Set constructor does self-sends: https://tc39.es/ecma262/#sec-set-iterable |
| 22:09 | <jorendorff> | it's not required |
| 22:09 | <Bakkot> | it allows subclassing |
| 22:09 | <gibson042> | the proposal is that a time zone is an object with methods such as "getNextTransition" |
| 22:11 | <shu> | jorendorff: so self-sends means where the default implementation of a method calls out to another virtual method that also has a default implementation |
| 22:11 | <shu> | on the same receiver |
| 22:12 | <Bakkot> | ljharb I just do not agree with the claim that being a class encourages subclassing |
| 22:12 | <jorendorff> | That's my understanding, yes. |
| 22:12 | <shu> | jorendorff: cool thanks |
| 22:12 | <michaelficarra> | shu: correct |
| 22:12 | <ljharb> | Bakkot: i have heard many people ask me "if i'm not supposed to subclass Promise why can i `extends Promise`" |
| 22:12 | <Bakkot> | you can `extends Function` too |
| 22:12 | <Bakkot> | so what |
| 22:12 | <ljharb> | Bakkot: obv anecdotal but that's my experience |
| 22:13 | <shu> | what's the difference between that and "if i'm not supposed to never terminate my function why can i write for(;;)"? |
| 22:13 | <ljharb> | Bakkot: yes, and someone asked me *12 hours ago* how to make that work without violating CSP |
| 22:13 | <devsnek> | ljharb: you can extends any random function (arrows aside) |
| 22:13 | <ljharb> | Bakkot: because their opinion was, Function is a class, i should be able to subclass it |
| 22:13 | <michaelficarra> | we should not involve Promise in this discussion, every decision made for Promise was the wrong decision |
| 22:13 | <gibson042> | lol, perfect |
| 22:13 | <ljharb> | because "being a class" does, for some, imply it's subclassable. |
| 22:13 | <shu> | michaelficarra: the name was pretty good |
| 22:13 | <devsnek> | ljharb: i can even subclass your functions |
| 22:13 | <shu> | ljharb: i think that is a dangerous position to accept |
| 22:14 | <ljharb> | devsnek: sure, if i don't make them arrows or concise methods |
| 22:14 | <Bakkot> | ljharb I don't think the existence of people with that opinion is a very strong argument, on its own, that we should avoid having class for encapsulating a set of methods |
| 22:14 | <ljharb> | shu: dangerous how? |
| 22:14 | <ljharb> | devsnek: or async functions or generators |
| 22:14 | <shu> | ljharb: possibility is a far cry from "supposed to" |
| 22:14 | <Bakkot> | also like |
| 22:14 | <Bakkot> | it is fine to subclass these things |
| 22:14 | <devsnek> | agree with mark |
| 22:15 | <ljharb> | shu: that is true that it being possible is not the same as saying people should do it. |
| 22:15 | <Bakkot> | if these things brand check their arguments, that implies you're supposed to subclass |
| 22:15 | <ljharb> | shu: but it does mean the *easiest* way to override one method is to subclass it, so that's what people are likely to do |
| 22:15 | <ljharb> | Bakkot: that i agree with |
| 22:15 | <Bakkot> | but if they take options bags, there is no such implication |
| 22:16 | <ljharb> | i think the current design also means that every time a stored calendar object has a method invoked, it's observably Get-ed off the object - the Proxy handler pattern, basically. is that what we want? |
| 22:16 | <ljharb> | meaning, should it cache the methods rather than the object? |
| 22:17 | <Bakkot> | sure, having temporal cache sgtm |
| 22:17 | <Bakkot> | no strong feelings though |
| 22:17 | <ljharb> | i would say if it extracts functions off of the object and caches them, then *that* would be treating it like an object bag, and the object's identity/characteristics becomes irrelevant |
| 22:18 | <Bakkot> | eh, i think the majority of consumers of options bag consume the arguments as-needed, rather than pulling them off up front |
| 22:18 | <Bakkot> | or at least this was true before destructuring made it easier to pull them off |
| 22:19 | <gibson042> | I think that would hinder ergonomics, at least in Temporal |
| 22:19 | <ljharb> | gibson042: what sort of ergonomics |
| 22:20 | <gibson042> | Temporal.TimeZone.from("America/New_York").getNextTransition === Temporal.TimeZone.from("Europe/Paris").getNextTransition, but we definitely don't want the same output for the same input |
| 22:21 | <michaelficarra> | FYI first-class protocols proposal includes an easy way to check for conformance to a protocol |
| 22:21 | <gibson042> | there's state held in the object |
| 22:21 | <jorendorff> | geez how are we having this discussion |
| 22:22 | <jorendorff> | JS is not that language, let's move on |
| 22:22 | <ljharb> | michaelficarra: yes that would be a perfect answer to this queue item, to be fair. |
| 22:22 | <ljharb> | michaelficarra: +1 for first-class protocols |
| 22:22 | <Bakkot> | protocols aren't a good fit for this, since this isn't a protocol |
| 22:23 | <michaelficarra> | Bakkot: first-class protocols proposal can represent string-based "duck typing"/"protocols" in the same way it represents symbol-based protocols |
| 22:24 | <michaelficarra> | we don't want to provide the same convenience for *installing* string-based protocols, since they're not meant to be shared |
| 22:24 | <michaelficarra> | but for confirming them, it's fine |
| 22:24 | <Bakkot> | eh, sure, ok |
| 22:24 | <Bakkot> | ljharb if you only care about wildly wrong things, just pick some particular method and look for that one |
| 22:24 | <michaelficarra> | I've thought about this stuff *a lot* |
| 22:24 | <Bakkot> | does it have a `day` method? it's probably a calendar. does it not? throw an error |
| 22:27 | <ljharb> | littledan: i'm not sure why storing a Record holding all the functions wouldn't work the same |
| 22:29 | <shu> | i remain woefully ignorant of temporal |
| 22:29 | <shu> | is the current behavior subclassing or not subclassing? |
| 22:29 | <devsnek> | yes |
| 22:29 | <Bakkot> | shu there's a class, but you don't have to use it |
| 22:29 | <Bakkot> | you can just give a grab bag |
| 22:29 | <shu> | Bakkot: but to hook behavior, is it to subclass? |
| 22:29 | <shu> | okay, so it is not to subclass |
| 22:29 | <shu> | great |
| 22:29 | <gibson042> | ljharb: it would work if it held the functions *and* the object, with observable differences in the two approaches being whether or not code like `Temporal.TimeZone.prototype.getNextTransition = …` has any effect on already-used time zones |
| 22:29 | <littledan> | ljharb: Since the instances have an internal slot that the methods need to access |
| 22:30 | <mathiasbynens> | can someone help to move https://github.com/tc39-transfer/proposal-regexp-set-notation to the proper tc39 org? thanks! cc bterlson |
| 22:30 | <Bakkot> | shu subclassing works if you want that, I understand |
| 22:30 | <shu> | o |
| 22:30 | <ljharb> | littledan: that means it'd need to store the object too, to use as the receiver, sure - but not that it'd need to also do an observable Get every time. |
| 22:30 | <shu> | so Temporal does self-sends |
| 22:30 | <littledan> | yes |
| 22:30 | <shu> | ok |
| 22:30 | <ljharb> | gibson042: that is true, but to be that'd be less surprising - it'd mean breaking things only breaks *later* calendar/timezone usage instead of already-constructed, allegedly immutable instances. |
| 22:31 | <littledan> | ljharb: Yes, that is a different possible observable semantics |
| 22:31 | <ljharb> | gibson042: iow "immutable" seems like it a claim that would *want* the behavior i'm describibng. |
| 22:31 | <gibson042> | yes, I can see value in this position |
| 22:31 | <ljharb> | ie, Temporal objects as specified are not immutable at all - they're mutable by mutating a calendar method. |
| 22:31 | <ljharb> | *replacing |
| 22:33 | <gibson042> | but it's now a much narrower difference, just "Get(…) every time" vs. "Get(…) on ingest only" |
| 22:34 | <Bakkot> | fwiw it actually looks like Ecma 402 usually does ingestion relatively eagerly |
| 22:34 | <Bakkot> | e.g. https://tc39.es/ecma402/#sec-initializedatetimeformat |
| 22:37 | <ljharb> | gibson042: it'd be "Get once, plus Call every time" rather than "Get + Call every time" |
| 22:37 | <gibson042> | yep |
| 22:37 | <ljharb> | gibson042: which was the same change, with a perf motivation,. to look up `this.resolve` in all the Promise methods |
| 22:37 | <ljharb> | *combinators |
| 22:37 | <gibson042> | also in Map/Set/etc. constructors IIRC |
| 22:38 | <gibson042> | there was/is an exception in 402 that I'm looking for now |
| 22:38 | <gibson042> | but it was clearly unintentional, and a mess |
| 22:38 | <Bakkot> | gibson042 yes for map/set/etc ctors, though that was internal to a single method rather than caching for laters |
| 22:39 | <ystartsev> | wsdferdksl: i noticed people sometimes talk over you but it doesn't seem intentional, is it a delay issue? i don't know if others have noticed it |
| 22:39 | <ystartsev> | also, a bunch of people just left |
| 22:39 | <Bakkot> | it's only happened in the last hour or two that I noticed, and I think it's a network issue yeah |
| 22:40 | <ljharb> | i can't see tab's video |
| 22:40 | <ljharb> | (because teams doesn't let me browse through everybody while seeing their video) |
| 22:42 | <TabAtkins> | It's all right, it's just me in my jammies and housecoat, and pretty scruffily unshaved |
| 22:44 | <gibson042> | https://github.com/tc39/ecma402/issues/132 is definitely relevant |
| 22:47 | <gibson042> | https://github.com/tc39/ecma402/pull/493#discussion_r465537106 is what I was thinking of, which is related but distinct |
| 22:51 | <ljharb> | gibson042: thanks for finding that |
| 22:59 | <jridgewell> | We should do JSConf Hawaii again in the aftertimes. |
| 23:00 | <TabAtkins> | yes absolutely |
| 23:01 | <Bakkot> | I am most excited to actually have the tokyo meeting |
| 23:01 | <michaelficarra> | was Hawaii a sufficient compromise timezone-wise for Asian delegate inclusion, or would Tokyo be better? |
| 23:01 | <Bakkot> | I keep making plans to go to Japan or HK and having them not work out |
| 23:01 | <Bakkot> | (and HK is probably not an option any more...) |
| 23:01 | <ljharb> | sooooo sad about tokyo and looking forward to that meeting |
| 23:02 | <ljharb> | michaelficarra: tough to tell; none attended, but it was also covid time for them |
| 23:02 | <jridgewell> | I don't believe any Asian delegates were in HI |
| 23:02 | <jridgewell> | So, probably not good enough? |
| 23:02 | <ljharb> | also i think that particular week was a holiday in china? |
| 23:02 | <TabAtkins> | i had an *amazing* alaska/japan cruise planned last year, that obviously had to get canceled. as did my mediterranean cruise that was supposed to happen this summer, too :( |
| 23:03 | <michaelficarra> | TabAtkins: I bet you are a fun cruise partner |
| 23:03 | <TabAtkins> | I do board game cruises (BGG At Sea) and yeah, I hope so |
| 23:03 | <TabAtkins> | my wife enjoys it at least |
| 23:08 | <Bakkot> | also a reminder to please fill out the do-exprs survey if you haven't yet: https://docs.google.com/forms/d/e/1FAIpQLScyNcGNfjoJXMTmfBkLRMREKCP2TihiFGqc26HhjL4710qdiA/viewform?usp=sf_link |
| 23:09 | <jridgewell> | I bought a heated floor mat for my feet, and it's the 💣 |
| 23:09 | <jridgewell> | Now I feel like a cat. |
| 23:09 | <Bakkot> | i bought slippers |
| 23:09 | <jridgewell> | I have slippers, and they weren't doing the job well enough. |