| 16:52 | <mathiasbynens> | same meeting link as yesterday, right? |
| 16:53 | <rkirsling> | I don't think any of us have that link anymore though |
| 16:53 | <rkirsling> | it's going to need to be posted |
| 16:53 | <devsnek> | you can go through the form again |
| 16:53 | <rkirsling> | is that desired though? |
| 16:53 | <devsnek> | bterlson: ^ |
| 16:54 | <ljharb> | rkirsling: they said yesterday you can fill the form out twice |
| 16:54 | <rkirsling> | oh |
| 16:54 | <rkirsling> | alright |
| 16:54 | <bterlson> | it doesn't hurt anything we can dedupe as needed |
| 16:56 | <devsnek> | so much stage 4 this meeting |
| 16:56 | <devsnek> | very exciting |
| 16:57 | <jridgewell> | Could we just post the link in the Reflector issue? |
| 16:58 | <ljharb> | jridgewell: the goal was that nobody saw the link who hadn't filled out the attendance form |
| 16:58 | <ljharb> | (from what i understand) |
| 17:00 | <rickbutton> | I filled it out a second time, and then bookmarked the final link. |
| 17:00 | <ljharb> | the "thanks for filling out the form" page is bookmarkable, ftr |
| 17:01 | <ljharb> | or at least, refreshing it loads it fine |
| 17:01 | <rkirsling> | I wish the Teams client could remember your previous meeting link |
| 17:06 | <devsnek> | 🎉 |
| 17:06 | <rickbutton> | that was fast |
| 17:09 | <rkirsling> | wow |
| 17:10 | <rickbutton> | nice work devsnek |
| 17:10 | <devsnek> | hehe |
| 17:11 | <ystartsev> | that x++ one is really something |
| 17:20 | <mathiasbynens> | ljharb: woohoo, thanks for merging https://github.com/tc39/ecma262/pull/2040 \o/ |
| 17:20 | <rkirsling> | so fast |
| 17:21 | <ljharb> | ☚(ﾟヮﾟ☚) |
| 17:21 | <devsnek> | now i gotta remove the flag in engine262 |
| 17:31 | <devsnek> | ljharb: if i can't screenshare from linux can you share your screen, its just issue 1941 and pr 1948 |
| 17:31 | <rkirsling> | huh, I didn't know there was a `"unit"` type |
| 17:32 | <ljharb> | devsnek: i'm on an ipad (－‸ლ) but i can try |
| 17:32 | <devsnek> | oh no |
| 17:32 | <devsnek> | we'll make it work |
| 17:32 | <devsnek> | someone's tea is going |
| 17:32 | <rkirsling> | I was just gonna say that hahaha |
| 17:33 | <rickbutton> | better make your cup before the water's gone |
| 17:37 | <rkirsling> | yeah that water is totally gonna be gone |
| 17:39 | <devsnek> | ears gone |
| 18:04 | <michaelficarra> | shu: you said you prefer not to have "function get name() { … }", right? |
| 18:04 | <shu> | michaelficarra: ideally i prefer `get name() { ... }` |
| 18:07 | <ljharb> | +1 |
| 18:21 | <Bakkot> | littledan / ystartsev: can you point me to something which explains the motivation for the callback argument to cleanupSome? |
| 18:21 | <haxjs> | it's a little weird to have "function" before "get name" :-) |
| 18:21 | <devsnek> | https://github.com/tc39/ecma262/pull/1948/commits/e417f396a276953c8329ddb89d8e523cf9cbe642 |
| 18:21 | <devsnek> | shu: michaelficarra: Bakkot: ^ |
| 18:23 | <ystartsev> | Bakkot: do you mean the iterator or the per item callback? |
| 18:26 | <Bakkot> | ystartsev the per-item callback |
| 18:26 | <Bakkot> | that overrides the one the registry has |
| 18:26 | <Bakkot> | that bit is weird to me |
| 18:35 | <littledan> | Bakkot: These design discussions were mostly offline. I recommend you file an issue if you're skeptical of this design. |
| 18:35 | <littledan> | I think someone found it to be more natural when writing code samples using it |
| 18:35 | <Bakkot> | littledan mostly I just want to know what the motivation for it is |
| 18:36 | <Bakkot> | will file if I remember after taking notes |
| 18:36 | <littledan> | same motivation as using an iterator and returning a boolean |
| 18:36 | <Bakkot> | hmm |
| 18:37 | <Bakkot> | it's the "overriding the original callback" part which is the strangest to me |
| 18:37 | <devsnek> | "using an iterator and returning a boolean"? |
| 18:37 | <Bakkot> | the fact that the registry's original callback isn't used anymore |
| 18:37 | <ystartsev> | bakkot, we have some emails i can summarize |
| 18:38 | <Bakkot> | jridgewell I always appreciate your presentations |
| 18:38 | <Bakkot> | specifically I like the recaps |
| 18:39 | <michaelficarra> | recaps are important, everyone should take note |
| 18:40 | <jridgewell> | 😀, thanks! |
| 18:42 | <robpalme> | can anyone contact the numeric separator folk (Sam Goto, Rick, Leo) to see if they can go next? |
| 18:42 | <Bakkot> | leobalter ^ |
| 18:42 | <Bakkot> | rwaldron ^ |
| 18:45 | <devsnek> | tc39 wg 3 js for build tools |
| 18:46 | <devsnek> | honestly wouldn't even be the most awful idea |
| 18:46 | <Bakkot> | there's a tooling outreach call I think? |
| 18:46 | <Bakkot> | which I keep meaning to attend and failing to for reasons |
| 18:47 | <devsnek> | i mean like, have a formal specification of js features for build tools |
| 18:47 | <devsnek> | like 402 is for internationalization |
| 18:48 | <devsnek> | actually i guess the embedded devices group is a better example |
| 18:48 | <littledan> | devsnek: Decorators standardized in tools would still run into these constraints; we'd still have to decide which one(s) to violate |
| 18:49 | <devsnek> | littledan: well you don't have to polyfill it if its defined to be part of build tools |
| 18:50 | <littledan> | I don't know whether all polyfill authors would agree with that. Anyway, we also heard from tools authors that they would prefer if transforms were per-file, without requiring cross-file knowledge |
| 18:50 | <devsnek> | its time for build tools to be cognizant of cross-file information |
| 18:51 | <devsnek> | tell me if my exported function isn't used anywhere else in the codebase |
| 18:52 | <Bakkot> | p sure https://github.com/benmosher/eslint-plugin-import does that |
| 18:53 | <devsnek> | i have not observed it being able to do that |
| 18:53 | <devsnek> | might have it configured wrong though 🤷🏻 |
| 18:54 | <Bakkot> | "Report modules without exports, or exports without matching import in another module (no-unused-modules)" |
| 18:54 | <Bakkot> | claims to do that |
| 18:55 | <Bakkot> | "unusedExports: if true, exports without any static usage within other modules are reported (defaults to false)" |
| 18:55 | <Bakkot> | so you'd have to opt in |
| 18:55 | <ljharb> | if it doesn't do that, file me an issue |
| 18:57 | <haxjs> | It seems unusedExports is not well fit for library?? It's likely a library will not use all its exports? |
| 18:57 | <Bakkot> | yup |
| 18:57 | <Bakkot> | probably why it's off by default |
| 18:57 | <ljharb> | haxjs: which is why the rule allows you to explicitly configure your entry points |
| 18:58 | <ljharb> | for library usage, or for apps where the entry points are all bundler entry points |
| 18:58 | <ljharb> | (that are referenced in ERB templates, for example) |
| 18:58 | <haxjs> | Great, I will try it in my next project :) |
| 19:03 | <ljharb> | does anyone disagree with the claim that https://github.com/tc39/ecma262/pull/2106 already has consensus, based on yesterday's consensus on https://github.com/tc39/ecma262/pull/2057 ? |
| 19:04 | <Bakkot> | yes; import.meta does not seem liek the same kind of thing as the Math and Reflect namespaces |
| 19:04 | <ljharb> | ok |
| 19:04 | <littledan> | ljharb: I didn't realize we were talking about `import.meta` |
| 19:04 | <devsnek> | import.meta having a tostringtag seems wrong |
| 19:04 | <ljharb> | sounds good, i'll mark it as needs consensus |
| 19:05 | <ljharb> | littledan: https://github.com/tc39/ecma262/issues/1970#issuecomment-622248793 |
| 19:05 | <devsnek> | technically a host could do something weird |
| 19:06 | <devsnek> | like set import.meta.[[Prototype]] to something that already has a tostringtag |
| 19:06 | <ljharb> | littledan: i misconstrued your comment as agreement that import.meta should have it |
| 19:06 | <littledan> | which comment? |
| 19:07 | <ljharb> | littledan: the one that says "+1 on new namespaces going forward", right after the one where i asked about import.meta |
| 19:07 | <ljharb> | import.meta being a namespace, since its properties matter but it itself doesn't |
| 19:07 | <bradleymeck> | why would we add it to import.meta |
| 19:07 | <bradleymeck> | it isn't a namespace like the others |
| 19:07 | <littledan> | oh, sorry, I was responding to the original post |
| 19:07 | <bradleymeck> | it isn't something TC39 is going to populate |
| 19:07 | <ljharb> | bradleymeck: it might add something to it one day ¯\_(ツ)_/¯ |
| 19:08 | <ljharb> | but it's still a builtin object |
| 19:08 | <devsnek> | hallway track dead todya? |
| 19:08 | <bradleymeck> | ljharb: hosts can add any key |
| 19:08 | <bradleymeck> | ljharb: it isn't builtin, it is something a host supplies |
| 19:08 | <bradleymeck> | and there are many of them, so each having an own prop seems weird |
| 19:08 | <ljharb> | those are all reasonable concenrs |
| 19:08 | <ljharb> | *concerns |
| 19:09 | <bradleymeck> | hosts can supply their own toStringTag already it looks like (odd to allow setting symbols, but 🤷) |
| 19:09 | <ljharb> | if you could comment on the PR that'd be great; if it's not able to reach consensus we don't have to waste plenary time on it |
| 19:13 | <bradleymeck> | done |
| 19:14 | <ljharb> | thanks |
| 20:01 | <devsnek> | when is lunch over |
| 20:01 | <jridgewell> | Now |
| 20:02 | <devsnek> | someone made a good point in the rust server about allowing multiple underscores in a row for padding binary literals |
| 20:02 | <devsnek> | sad we didn't get that |
| 20:02 | <devsnek> | can always be added later though |
| 20:05 | <haxjs> | what padding bin literal mean? |
| 20:05 | <devsnek> | haxjs: right now you can only use one underscore at a time |
| 20:05 | <devsnek> | `1__0` is a syntax error |
| 20:05 | <Bakkot> | who is chewing |
| 20:06 | <haxjs> | I mean why 1__0 is useful? |
| 20:06 | <ljharb> | i have the same question |
| 20:07 | <haxjs> | though I don't think it's harmful :-) just don't get the use case. |
| 20:07 | <rkirsling> | woo slice |
| 20:07 | <devsnek> | `1111_1111_1111_1111_1111_1111_1111_1111` |
| 20:07 | <devsnek> | that's only 32 bits |
| 20:07 | <devsnek> | imagine 64 bits |
| 20:07 | <ljharb> | rwaldron: please assign https://github.com/tc39/ecma262/pull/2043 to me once you've made all the planned updates |
| 20:08 | <Bakkot> | devsnek that's only one _ at a time |
| 20:08 | <devsnek> | `1111_1111_1111_1111__1111_1111_1111_1111` |
| 20:08 | <devsnek> | two underscores helps |
| 20:08 | <Bakkot> | ahh |
| 20:08 | <rkirsling> | 1_________________________________________1 |
| 20:08 | <devsnek> | lol |
| 20:08 | <Bakkot> | yeah makes sense |
| 20:09 | <rwaldron> | ljharb sure will do. I think leobalter is actually going to tackle the fixes |
| 20:09 | <devsnek> | and at 64 you might have three in the middle |
| 20:09 | <devsnek> | two at each half way point |
| 20:09 | <devsnek> | one for each nibble |
| 20:09 | <devsnek> | not the end of the world obviously |
| 20:12 | <haxjs> | devsnek oh, sounds useful :) |
| 20:13 | <devsnek> | ljharb: strings do have @@slice |
| 20:13 | <devsnek> | in terms of this proposal |
| 20:13 | <ljharb> | devsnek: not according to the proposal's readme |
| 20:13 | <ljharb> | unless i missed it |
| 20:13 | <devsnek> | on twitter they did |
| 20:13 | <shu> | sathya explicitly said string is not included because it's unclear what slice means on strings |
| 20:14 | <ljharb> | devsnek: https://github.com/tc39/proposal-slice-notation#should-slice-notation-work-on-strings |
| 20:14 | <ljharb> | imo it's perfectly clear what it means on strings :-) |
| 20:14 | <devsnek> | oh that's unfortunate |
| 20:14 | <ljharb> | i'll get to that once the queue hits |
| 20:14 | <devsnek> | i'd rather argue about whether slicing strings should be utf16 or utf32 instead of whether strings should have slice |
| 20:15 | <ljharb> | strings already have slice, it's .slice. |
| 20:16 | <haxjs> | how we can make it slice on code point? |
| 20:16 | <ljharb> | make .slice work on code points |
| 20:16 | <michaelficarra> | ljharb: what |
| 20:16 | <ljharb> | i'm not saying that's possible nor proposing it |
| 20:17 | <haxjs> | that's an good idea, but it cause inconsitency between s[a:b] and s.slice(a,b)? |
| 20:17 | <ljharb> | but this is called "slice notation" so it should only do "what slice does" |
| 20:17 | <bterlson> | anyone regret making for-of a string iterate over code points? |
| 20:17 | <ljharb> | +1000 |
| 20:17 | <ljharb> | strings shouldn't be iterable, there should be a normal method for that |
| 20:17 | <michaelficarra> | nooo, it's by far the most useful choice |
| 20:17 | <devsnek> | bterlson: no |
| 20:17 | <ljharb> | like .keys/.values/.entries |
| 20:17 | <haxjs> | I think iterate over code points is good. |
| 20:17 | <ljharb> | code points isn't actually what people want, grapheme clusters is. |
| 20:17 | <bterlson> | speaking personally, I supported it but have since gotten zero value and have made mistakes |
| 20:17 | <shu> | keith_mi_: i think the first tack for that would be to see if we can replace more HTML collections with ObservableArray (which is what's motivating adding .item() to Arrays) |
| 20:17 | <Bakkot> | code points is what people want |
| 20:18 | <bterlson> | code points are pretty much useless |
| 20:18 | <bterlson> | lol |
| 20:18 | <ljharb> | also, iterable strings interfered with flat/flatMap |
| 20:18 | <shu> | keith_mi_: if that's possible, then they should get @@slice for free, if this becomes a thing |
| 20:18 | <ljharb> | Bakkot: they want 💩 but they also want 🏳️🌈 |
| 20:18 | <ljharb> | code points doesn't give you both |
| 20:18 | <keith_miller> | shu: is @@slice not the same as Array.prototype.slice? |
| 20:18 | <Bakkot> | but yeah doesn't TabAtkins have an essay about this? |
| 20:18 | <shu> | keith_miller: it is |
| 20:18 | <michaelficarra> | ljharb: people don't want locale-dependent string iteration |
| 20:18 | <keith_miller> | slice looks up .item? |
| 20:18 | <shu> | keith_miller: no no, i'm saying the tack to get HTML collections to have @@slice is to actually replace the bespoke HTML collections with ObservableArray, which inherits Array |
| 20:18 | <Bakkot> | https://www.xanthir.com/b4wJ1 |
| 20:18 | <ljharb> | michaelficarra: i agree, but they *definitely* don't want to have to piece together grapheme clusters |
| 20:19 | <keith_miller> | ohh, gotcha |
| 20:19 | <keith_miller> | sounds good to me |
| 20:19 | <ljharb> | it should have just been String.prototype.codePoints to return an iterator |
| 20:19 | <keith_miller> | shu: I like the ObservableArray thing anyway |
| 20:19 | <shu> | +1 |
| 20:19 | <keith_miller> | so sounds good to me |
| 20:19 | <michaelficarra> | ljharb: I agree there's no one-size-fits-all default, so no default would've been best |
| 20:19 | <michaelficarra> | but if we HAD to have a default… code points |
| 20:20 | <ljharb> | perhaps. but we definitely didn't have to have one |
| 20:20 | <ljharb> | obv the ship has long since sailed :-) |
| 20:20 | <bterlson> | if code points were used everywhere then yeah, obviously indexing by code points is better than utf-16 units |
| 20:21 | <bterlson> | but having both in hindsight feels like a wrong choice :/ |
| 20:21 | <devsnek> | new string type |
| 20:21 | <devsnek> | like new bigint type |
| 20:21 | <haxjs> | yeah at least it will not split string at surrogate |
| 20:22 | <bterlson> | hypothesis: most uses of for-of string are bugged and assume a correspondence between iteration steps and string indexes |
| 20:23 | <haxjs> | devsnek yeah , i really hope we can have utf8 string which eliminate the need of many encoding/decoding |
| 20:23 | <haxjs> | most uses of for-of string are bugged --- how ? u can't get index in for-of, so how to make bug? |
| 20:24 | <rkirsling> | this can't do more than slice, definitionally |
| 20:24 | <rkirsling> | not sure how to argue for it beyond "I would use the crap out of it" |
| 20:24 | <drousso> | ^ +1 |
| 20:25 | <haxjs> | original proposal have step, but seems removed now |
| 20:25 | <ljharb> | i would also use the crap out of it |
| 20:25 | <michaelficarra> | wait, are we assuming this will support negative indices? because if so, I don't think we can implement it as an iterator helper :( |
| 20:25 | <ljharb> | also, substr vs substring vs slice would all become this nice pretty syntax |
| 20:25 | <ljharb> | michaelficarra: yes, it supports negatives |
| 20:26 | <keith_miller> | ystartsev: FWIW here's a list of languages with syntax: https://en.wikipedia.org/wiki/Comparison_of_programming_languages_(array)#Slicing |
| 20:26 | <michaelficarra> | ljharb: that's unfortunate |
| 20:26 | <devsnek> | michaelficarra: it would throw i guess |
| 20:26 | <devsnek> | or yeah just not support it |
| 20:26 | <ljharb> | it has to, it's slice. |
| 20:26 | <keith_miller> | That's probably not exhaustive though |
| 20:26 | <ystartsev> | keith_miller: im not sure that "its in other languages" is the bar we want to use |
| 20:26 | <devsnek> | if its *all* of them though... |
| 20:26 | <ljharb> | definitely not a bar, but a strong indication that the syntax weight may be worth it |
| 20:27 | <drousso> | what other bar is there then? |
| 20:27 | <keith_miller> | I think it's a signal at least |
| 20:27 | <drousso> | how do you determine if something is useful without it existing |
| 20:27 | <devsnek> | does elang have slice syntax |
| 20:27 | <ljharb> | drousso: we don't need any other languages to decide what's useful for JS. it's just massively helpful as a guide. |
| 20:27 | <drousso> | oh sure i'm not saying "it's in other languages" should instantly mean "yes we should do it too" |
| 20:27 | <ystartsev> | introducing new syntax means two things: syntax is more difficult for beginners to learn than names and it is more difficult to search. secondly -- this takes up syntax space which might be used for other thins |
| 20:28 | <ystartsev> | in the cases of logical assignment, this aligned ??, ||, && with other binary operators |
| 20:28 | <rkirsling> | I'm not sure this conflicts with any other syntactic space though, given that it's strictly within [] |
| 20:28 | <ystartsev> | it made the language, in a way, more consistent |
| 20:28 | <drousso> | i would argue that using this syntax for something else is possibly worse than the complexity of learning that it means slice |
| 20:28 | <ljharb> | ystartsev: in the case of slice notation, what else could it do that wouldn't be confusing for users of "most every other language"? |
| 20:28 | <drousso> | ^ +1 |
| 20:29 | <ystartsev> | i don't see consistency in other languages |
| 20:29 | <ljharb> | it's definitely harder to google for syntax tho, i agree with that one for sure |
| 20:29 | <ystartsev> | they all have unique ways in which they slice |
| 20:29 | <ljharb> | ystartsev: sure but is there anything like this syntax in another language that doesn't slice in some form? |
| 20:29 | <ystartsev> | there is some organization aroudn `[a...b]` |
| 20:29 | <michaelficarra> | FYI PureScript strings don't have any default iterability; all String operations have code point and UTF-16 code unit variants |
| 20:30 | <rkirsling> | there's consistency in it being within [] though |
| 20:30 | <ystartsev> | which is used for slice |
| 20:30 | <robpalme> | is Philip Chimento in here? he's up to present next |
| 20:30 | <ystartsev> | i would be more open to this proposal, if it solved something |
| 20:30 | <shu> | i am confused by the random noises that start up, because presumably someone is manually unmuting |
| 20:30 | <shu> | but why, since there's a queue of speakers? |
| 20:31 | <devsnek> | can't jump the queue if you're muted |
| 20:31 | <rkirsling> | yeah the biggest concern around this proposal is conflict with .item(), I think |
| 20:31 | <ljharb> | it does solve *something* - it solves the lack of ergonomics around the slice methods, and the lack of anything beyond "magic word: slice" as a protocol for other objects to participate in |
| 20:31 | <rkirsling> | because negative indices are the selling point |
| 20:31 | <shu> | rkirsling: it doesn't conflict i don't think |
| 20:31 | <haxjs> | why it will conflict with item() ? |
| 20:31 | <rkirsling> | oh because element vs. range |
| 20:31 | <shu> | rkirsling: right |
| 20:31 | <ljharb> | if anything they're complementary |
| 20:31 | <rkirsling> | alright nevermind then |
| 20:32 | <jridgewell> | shu: It's Brian when he unmutes to moderate |
| 20:32 | <ystartsev> | ljharb: does `slice` have a lack of ergonomics? |
| 20:32 | <shu> | jridgewell: i see |
| 20:32 | <ystartsev> | because i think this is debatable |
| 20:32 | <ljharb> | ystartsev: it's very debatable, as is anything around ergonomics, and it's fine that we ascribe different weights to that :-) |
| 20:32 | <ystartsev> | i consider ergonomics to be quite important, but i am not convinced by the argument at the present moment |
| 20:33 | <rkirsling> | it would be good to identify how we could identify sufficient demand then |
| 20:33 | <rkirsling> | 'cause I don't think we'll be able to identify a "need" |
| 20:34 | <ljharb> | this seems like something where status quo is "fine" but this proposal would _feel_ a lot better |
| 20:35 | <ljharb> | so it's not solving a burning trash fire, but it's salving an irritant |
| 20:35 | <shu> | gsathya: part of my point is that the analogy to "other languages have slice notation" may be not as strong an argument as it sounds, because their slice notations weren't retrofitted, and thus are more symmetrical with their existing indexing notations |
| 20:35 | <rkirsling> | yeah. that ended in kind of a sad way |
| 20:35 | <ystartsev> | also echoing shu there, i think this is another argument |
| 20:36 | <shu> | that said i'm not anti this notation, i'm maybe weakly against but would be just fine with it being in the language |
| 20:36 | <gsathya> | shu, i'm not sure about that |
| 20:36 | <haxjs> | I agree with shu, a[-1] and a[-1:5] inconsistency is bad |
| 20:37 | <gsathya> | i'm sure a bunch of languages didn't ship their initial version with slicing syntax |
| 20:37 | <haxjs> | I remeber rbuckton suggest use ^1 instead of -1 :) |
| 20:37 | <shu> | fair enough, the high-order bit is whether there're points of inconsistencies and does it affect DX |
| 20:38 | <gsathya> | shu, how do i answer that? |
| 20:38 | <devsnek> | every second we don't have temporal is a second of pain |
| 20:38 | <leobalter> | devsnek: on which TimeZone? |
| 20:38 | <devsnek> | leobalter: mars time |
| 20:38 | <haxjs> | we need more feedback for temporal , it's now a really big proposal |
| 20:38 | <shu> | gsathya: hmm, i suspect the answer is "existing languages don't have this point of inconsistency". but maybe pick 3 popular languages that have slice syntax, and check if `n` in `[n:m]` is interpreted sorta-kinda the same as `[n]`? |
| 20:38 | <shu> | gsathya: python, rust, and something else? |
| 20:39 | <gsathya> | what does `n` in `[n:m]` is same as `[n]` mean? |
| 20:39 | <haxjs> | it mean a[-1] should work (but can't) |
| 20:40 | <rkirsling> | yeah that seems to be the concrete barrier here |
| 20:40 | <shu> | given the domain of `n`, are all values in the domain interpreted the same in both notations wrt things like negatives, coercion |
| 20:40 | <haxjs> | so the only way to overcome it is introduce syntax like ^1 |
| 20:41 | <gsathya> | yeah, I guess you could disallow negative indexing in slice notation but now its no longer consistent with array.prototype.slice |
| 20:41 | <ljharb> | imo without negative indexing it's not worth the syntax weight |
| 20:41 | <gsathya> | yeah |
| 20:41 | <rkirsling> | yeah that's kind of the key subfeature |
| 20:41 | <haxjs> | we could allow slice support ^1 if ^1 is sugar of new Index(1, {from:'end'}) |
| 20:42 | <leobalter> | `arr[-1]` may be counter intuitive in JS but I don't see it as a blocker for a richer feature such as `arr[-n:m]`. |
| 20:42 | <gsathya> | well, i would very much like it to be consistent with existing slice methods |
| 20:43 | <shu> | gsathya: i wanna be clear that i don't consider this inconsistency fatal, but an extra gotcha |
| 20:43 | <haxjs> | gsathya I think maybe we'd better first consider a[^1] ? |
| 20:44 | <ljharb> | that seems weird to me |
| 20:44 | <ljharb> | `[^1]` means "not 1" in git, and regex |
| 20:44 | <rkirsling> | yeah I don't think I could support that |
| 20:44 | <ljharb> | sorry, in git it means "1 commit back" |
| 20:45 | <littledan> | so, people were cool with the Temporal timeline? ystartsev and ljharb expressed concerns with that in the past; I think this timeline leaves plenty of time for review |
| 20:45 | <haxjs> | `^1` come from c# , but we could also consider other syntax |
| 20:45 | <ystartsev> | littledan: they have given a timeframe within the realm of what i requested, so i am fine with it |
| 20:46 | <haxjs> | ljharb so ^1 seems ok as git usage? |
| 20:47 | <ljharb> | littledan: sorry, maybe i missed it; what timeline? |
| 20:47 | <gsathya> | shu, gotcha |
| 20:47 | <ljharb> | i'm pretty sure i'm going to need to see finalized spec text that has minimal further churn, for more than 2 months, to be able to properly review it |
| 20:47 | <ystartsev> | iiuc we have till november? |
| 20:48 | <ljharb> | is the spec text settled? i feel like i've seen lots of changes still, recently |
| 20:48 | <rkirsling> | yeah, I'm excited but it's basically a new spec |
| 20:49 | <haxjs> | what the diff of `if` vs `with`? |
| 20:49 | <rkirsling> | (new spec as in "it's the size of 402", not as in "it's changed completely") |
| 20:49 | <michaelficarra> | haxjs: nothing, new term |
| 20:49 | <michaelficarra> | I prefer "if" over "assert" FWIW |
| 20:50 | <haxjs> | michaelficarra the example is ... if {type:json} with {...} |
| 20:50 | <ljharb> | `if` does kind of imply that if the condition isn't met, the import doesn't happen, when in fact it throws |
| 20:50 | <ljharb> | which is the semantics `assert` has already |
| 20:50 | <ljharb> | there's been some comments with that mistaken assumption on the repo already |
| 20:51 | <haxjs> | so `with` do not throw, only provide metadata? |
| 20:51 | <ljharb> | `with` isn't in the current proposal |
| 20:51 | <ystartsev> | yeah the `with` also threw me when i readd this |
| 20:51 | <ljharb> | previously the proposal also allowed the possibility of "evaluators", ie, things that change what module you import |
| 20:52 | <ljharb> | but since it was restricted to conditions/assertions, changing `with` to `if` made more sense |
| 20:55 | <haxjs> | oh, `if` is a little bit strange, `assert` is a little bit clear. |
| 20:56 | <haxjs> | maybe `must {type:'json'}` :P |
| 20:59 | <benjamn> | thinking out loud: what about returning a Record/Tuple/primitive for JSON imports? |
| 21:00 | <bradleymeck> | would reduce __proto__ errors |
| 21:01 | <haxjs> | not bad. I like this idea! |
| 21:01 | <benjamn> | ah I see Mark M is on the queue with that point :) |
| 21:01 | <haxjs> | but it means we must first land record/tuple |
| 21:02 | <benjamn> | yep, that seems like the main objection, but maybe there's something strategic we can do, like saying record/tuple will be used only if available? |
| 21:11 | <ystartsev> | is philip on irc? |
| 21:12 | <ystartsev> | or i guess i can ping sffc: wdyt of contacting hebrew / arab communities? do we have contacts there? |
| 21:12 | <ystartsev> | re: temporal |
| 21:13 | <sffc> | ystartsev: I know some arab expats who are software engineers |
| 21:21 | <akirose> | can someone give me an example of valid properties without quotes |
| 21:22 | <akirose> | i'm confused and i went through the slides again and did not feel any less confused |
| 21:22 | <gibson042> | akirose: { type: "json" } vs. { "type": "json" } |
| 21:24 | <akirose> | ohhhhhh lolol right |
| 21:24 | <bradleymeck> | assert { "\0": "YOLO" } |
| 21:28 | <ljharb> | can someone record the consensus in the notes for import conditions? |
| 21:29 | <ljharb> | littledan ^ |
| 21:35 | <ljharb> | rricard ^ |
| 21:38 | <ystartsev> | anyone looking to get a stream of explainations or ask questions can join #tc39-beginners |
| 21:39 | <rricard> | sorry about that ljharb, I will let dan properly record it |
| 21:40 | <littledan> | ljharb: Draft conclusion at https://docs.google.com/document/d/1IHoLaRSH41oU4an4HwfngP8aASTM51HYzlWgEhjGyI0/edit#bookmark=id.3zje6vza7bnl please review |
| 21:40 | <ljharb> | thanks, sgtm - please lmk when there's a repo URL for json modules |
| 21:41 | <littledan> | will do |
| 21:44 | <TabAtkins> | Whoever's running the meeting, could you approve me joining via phone? |
| 21:44 | <TabAtkins> | Probably an (832) number. |
| 21:45 | <rkirsling> | ooh `item` has appeared |
| 21:46 | <TabAtkins> | I take no credit nor blame for Shu's slides |
| 21:46 | <TabAtkins> | good lord |
| 21:47 | <TabAtkins> | Note: not inherit, a Proxy around Array. |
| 21:49 | <rkirsling> | mmm negative indices |
| 21:50 | <ljharb> | should i add a queue item asking if `.item` should go on strings </troll> |
| 21:50 | <benjamn> | is there a good way we can express support for proposals without unmuting and taking the floor etc.? |
| 21:51 | <rkirsling> | benjamn: I too wish for that |
| 21:52 | <ljharb> | benjamn: you can put a queue item that's like "+1 <EOM" maybe |
| 21:52 | <littledan> | part of what I have recorded in the conclusion of the import conditions topic is, "Split JSON modules into a separate Stage 2 proposal". Does this match everyone's understanding of the conclusion, or would we need another committee proposal for consensus to really make JSON modules at Stage 2? |
| 21:52 | <ljharb> | i'm sure we could come up with a convention for things where it's "read the queue item, move along" |
| 21:52 | <ljharb> | littledan: that matches my understanding |
| 21:54 | <benjamn> | ljharb: READONLY? |
| 21:54 | <ljharb> | sgtm |
| 21:55 | <ljharb> | i'll save my bikeshed energy for actual proposals, pick any word you like :-p |
| 21:55 | <benjamn> | haha sure, I hear that |
| 21:55 | <shu> | oops i clicked the wrong button |
| 21:55 | <shu> | hung up on the call |
| 21:55 | <shu> | ljharb: what was the question? |
| 21:55 | <devsnek> | node 14.6.0 is OUT |
| 21:55 | <devsnek> | WEAK REFS ARE LIVE |
| 21:56 | <rkirsling> | * might be live |
| 21:56 | <ljharb> | shu: "what stuff is still open for stage 3?" and tab said basically only the clamping question |
| 21:56 | <devsnek> | lmao |
| 21:56 | <shu> | ljharb: yeah that sounds right |
| 21:56 | <ljharb> | cool |
| 21:56 | <ljharb> | getify raised some good points about "providing numbers larger than the length" and i think it's worth serious consideration |
| 21:56 | <shu> | ljharb: oh? link? |
| 21:56 | <ljharb> | shu: it's an issue on the repo, one sec |
| 21:57 | <shu> | ah |
| 21:57 | <ljharb> | shu: https://github.com/tc39/proposal-array-last/issues/21 might be it |
| 21:58 | <ljharb> | oh no wait, wrong proposal |
| 21:58 | <ljharb> | shu: https://github.com/tabatkins/proposal-item-method/issues/6 |
| 21:59 | <ljharb> | shu: the discussions have wandered around a bunch |
| 21:59 | <TabAtkins> | Yeah I'm really confident in rejecting that, at least as an issue against this proposal. There is no way we can have the function throw or return a new truthy value for oob access. |
| 21:59 | <ljharb> | it seems reasonable to me for `.item` to accept any negatives but only to accept positives up to the length - 1 |
| 21:59 | <ljharb> | that's the open question i had |
| 21:59 | <TabAtkins> | Hm, can you expand on that? I don't see the cases being at all distinct. |
| 21:59 | <ljharb> | (i'm very -1 on a sentinel value ofc, and also throwing) |
| 21:59 | <ljharb> | TabAtkins: yeah maybe issue 6 wasn't relevant, my bad if so |
| 22:00 | <shu> | ljharb: yeah undefined being conflated with "empty" is a ship that has sailed |
| 22:00 | <shu> | bbl, mtg |
| 22:00 | <ljharb> | agreed |
| 22:00 | <shu> | it's like a big ship that has sailed too, like a carrier |
| 22:00 | <ljharb> | hm, let me look harder for where the overflow question came up |
| 22:00 | <ljharb> | it's particularly relevant for empty arrays tho, i think? |
| 22:01 | <ljharb> | altho `[].item(n)` would just return undefined for any n, i guess |
| 22:01 | <rkirsling> | that's what I would expect though |
| 22:03 | <littledan> | ljharb: ystartsev The timeline for Temporal that I was talking about is in https://pipobscure.dev/slides/temporal-2020-07/#5 . This is designed to give everyone enough time to review and iterate, based on the concerns expressed last meeting. Do you have any thoughts on it? |
| 22:05 | <ljharb> | littledan: "now til november" is plenty of time iff the spec is largely finalized. has that happened? because i feel like i'm still seeing discussions bandying about major changes |
| 22:06 | <littledan> | did you see the bullet point, "Finalize specification and pass to reviewers by September" ? |
| 22:06 | <ljharb> | ahhh ok, missed that, sorry |
| 22:06 | <ljharb> | september to november feels like a very tight window to me |
| 22:06 | <ljharb> | temporal feels like one of the largest proposals ever to land |
| 22:07 | <ljharb> | but i will certainly try |
| 22:07 | <littledan> | IMO two months is a lot of review time. We usually use two weeks to ten days as the standard |
| 22:07 | <littledan> | it's true that it's a big proposal, so I think it's justified to increase from 10 days to two months |
| 22:08 | <ljharb> | there's also a ton of context and concepts to page in |
| 22:08 | <littledan> | maybe we can also recruit more than two reviewers and figure out good ways to split things up |
| 22:08 | <littledan> | yes, that's true. I'm really happy about the proposal's documentation, so I hope that helps the review. |
| 22:08 | <devsnek> | how easily can the docs be dumped into mdn |
| 22:09 | <littledan> | devsnek: That was a sorta-kinda design goal for these docs, but we'll see |
| 22:09 | <devsnek> | exciting |
| 22:09 | <littledan> | devsnek: The WeakRefs docs got dumped into MDN and that seems to have worked out well |
| 22:09 | <devsnek> | nice |
| 22:41 | <ljharb> | benjamn: would you assume that even if https://github.com/facebook/regenerator/blob/master/packages/regenerator-runtime/runtime.js#L389 is fixed, it will remain present on the web for a very long time? (https://bugzilla.mozilla.org/show_bug.cgi?id=1644581 for context) |
| 22:48 | <benjamn> | ljharb: I'm actually somewhat optimistic that people update regenerator-runtime fairly often |
| 22:48 | <benjamn> | it would be a different story if it was transpiled code, but it's just a runtime library |
| 22:49 | <ljharb> | how quickly do you think that kind of fix could get in, to conditionally define toStringTag values? |
| 22:51 | <benjamn> | ljharb: in my mind this is a backwards-compatible change, so any new patch version I release will be compatible with https://github.com/babel/babel/blob/2bf38fb9149eb514a13bb608e5a9a0c06ad5cacd/packages/babel-runtime/package.json#L17 |
| 22:51 | <benjamn> | in other words, very quickly |
| 22:51 | <benjamn> | are you opposed to just using Object.defineProperty, to avoid the conditional? could do both obviously |
| 22:51 | <benjamn> | re: the last couple of comments in the bugzilla thread |
| 22:51 | <ljharb> | depends on your targets; if you use dP then it can't work in IE < 9, which might be a breaking change |
| 22:52 | <ljharb> | but also the define is unnecessary when there's already a toStringTag value |
| 22:52 | <ljharb> | so the conditional seemed simpler to me |
| 22:52 | <ljharb> | (the specific string isn't really important, just that there is one) |
| 22:52 | <benjamn> | ah yes, and Regenerator is increasingly only needed for older IE versions, so I guess that's still an essential audience |
| 22:53 | <ljharb> | realistically you could even do `if (!(toStringTag in whatever)) { whatever[toStringTag] = blah }` (don't have the code in front of me) |
| 22:53 | <ljharb> | that way it's only set where it's absent |
| 22:53 | <ljharb> | (probably tons of ways that could be worded ofc) |
| 22:55 | <benjamn> | ljharb: interestingly, when these toString tags were added, one of them was conditional and the other wasn't: https://github.com/facebook/regenerator/commit/28621286a46c95e2cde2970918b565545fcf5cdf |
| 22:55 | <ljharb> | 1 out of 3 ain't bad |
| 22:56 | <ljharb> | do you want a PR, or is it easier for you to do it? |
| 22:56 | <benjamn> | I'm imagining they should all be conditional? |
| 22:56 | <ljharb> | yes |
| 22:56 | <benjamn> | a quick PR would be great, so I don't have to self-review |
| 22:56 | <ljharb> | sure |
| 22:57 | <benjamn> | ljharb: although there already appears to be one? https://github.com/facebook/regenerator/pull/399 |
| 22:58 | <ljharb> | haha k, exe beat me to it |
| 22:58 | <ljharb> | i'll make the alternative |
| 22:58 | <ljharb> | that one uses defineProperty. |
| 22:59 | <benjamn> | ++ |
| 23:00 | <ljharb> | benjamn: https://github.com/facebook/regenerator/pull/400 |
| 23:00 | <ljharb> | i did it on the web ui, so lmk if i need to clone it and flesh anything out |
| 23:01 | <benjamn> | no worries, I'll make any tweaks necessary |
| 23:01 | <ljharb> | word, thanks |
| 23:02 | <devsnek> | tfw the polyfill breaks the actual feature |
| 23:02 | <ljharb> | not the first time this author's polyfill code has done that :-( |
| 23:02 | <benjamn> | yep, definitely a sad moment for any polyfill |
| 23:03 | <ljharb> | i don't *think* any of mine have had this problem yet, but i'm sure the second i post this, it's gonna happen |
| 23:04 | <devsnek> | this is why instead of writing polyfills you should just use a separate js engine |
| 23:05 | <devsnek> | ironically transpiling engine252 would involve regenerator |
| 23:06 | <shu> | does that have 10 fewer features than what's in JS |
| 23:06 | <benjamn> | fascinatingly (to me), the Rust Babel clone actually went to the trouble of converting Regenerator to Rust: https://github.com/swc-project/swc |
| 23:06 | <shu> | i'm going to start telling people it's called ecma262 because there are 262 features |
| 23:06 | <benjamn> | https://github.com/swc-project/swc/pull/554 |
| 23:07 | <devsnek> | I've never even heard of this |
| 23:07 | <devsnek> | I did at one point write my own regenerator though |
| 23:08 | <devsnek> | that might be when I first became interested in compilers |
| 23:12 | <devsnek> | wow this parser code is rough |
| 23:27 | <benjamn> | devsnek: yeah I can't vouch for swc from personal use, but it does seem to have users |
| 23:30 | <benjamn> | and it's ~fast~ |
| 23:36 | <benjamn> | ljharb: ok theoretically new installs of regenerator-runtime (or babel-runtime) will now have this fix! (regenerator-runtime⊙0 has been published to npm) |
| 23:53 | <ljharb> | awesome, thanks - hopefully the affected sites upgrade quickly |