| 01:01 | <shu> | i was writing a logical assignment test in C++ and tripped C++ trigraph warnings for ?? |
| 01:01 | <Bakkot> | nice |
| 01:02 | <shu> | if i had known at the time of proposing nullish, who knows what my opinion would've been |
| 01:09 | <drousso> | shu i actually ran into the same thing 🤣 |
| 01:12 | <shu> | drousso: beset by legacy features no matter where we work |
| 01:12 | <drousso> | 😭 |
| 01:42 | <devsnek> | we should add trigraphs to js |
| 01:43 | <devsnek> | by which I mean the c ones |
| 01:43 | <drousso> | shu i don't think the test262 tests for `AggregateError.prototype.errors` has been removed |
| 01:44 | <drousso> | oh wait i just found the PR |
| 01:44 | <drousso> | sorry 😅 |
| 01:44 | <devsnek> | oh what was the conclusion on that |
| 01:45 | <drousso> | it should be an own property instead of a prototype accessor |
| 01:45 | <drousso> | im trying to change this in JSC right now <https://webkit.org/b/212677>; |
| 01:45 | <devsnek> | nice |
| 01:47 | <rkirsling> | damn, Yusuke reviewed it before I even knew it existed |
| 01:47 | <rkirsling> | lol |
| 01:48 | <drousso> | rkirsling i asked him :P |
| 01:49 | <drousso> | rkirsling also, i think i have a fix for the `foo ??= function() {}` change :) |
| 01:49 | <rkirsling> | yeah I'm teasin', I know he reviewed the original (and gave lots of comments I wouldn't've been equipped to give) |
| 01:51 | <devsnek> | was it decided that it should get the name |
| 01:51 | <Bakkot> | yeah |
| 01:52 | <devsnek> | woo |
| 01:52 | <rkirsling> | I think by saying "woo" now you just expressed the most energetic sentiment there |
| 01:53 | <rkirsling> | people seemed to be pretty meh on the whole whether agreeing or disagreeing 😅 |
| 01:54 | <drousso> | i genuinely could go either way on this lol |
| 05:23 | <rkirsling> | yikes. guess it's good we switched away? https://twitter.com/NicoAGrant/status/1268020841054269440 |
| 05:38 | <ljharb> | personally i'd prefer name inference not exist, but i'm a -0 on adding it in new places |
| 05:39 | <ljharb> | rkirsling: i mean, that kind of presumes microsoft and google don't cooperate with law enforcement |
| 05:40 | <rkirsling> | perhaps |
| 05:40 | <rkirsling> | just seemed poorly put |
| 05:41 | <ljharb> | well sure, zoom is a garbage company. but their product is miles ahead of everyone else, and there's sadly not many companies that don't cooperate with law enforcement; we just don't hear about most of them. |
| 05:41 | <ljharb> | (also we'd be using a premium zoom account if we used it) |
| 05:42 | <rkirsling> | fair enough... |
| 15:11 | <michaelficarra> | I'm very excited about the extensibility of module attributes |
| 15:12 | <Bakkot> | has Chrome expressed a position on module attributes? |
| 15:12 | <Bakkot> | I feel like someone from the chrome team was opposed to them |
| 15:13 | <Bakkot> | domenic, maybe |
| 15:13 | <ljharb> | michaelficarra: the syntactic extensibility, or the host-carte-blanche extensibility? |
| 15:13 | <michaelficarra> | ljharb: syntactic |
| 15:13 | <ljharb> | gotcha, thanks |
| 15:13 | <michaelficarra> | I think littledan is missing the biggest reason why these must be in-band: import-site-specific metadata vs resource-specific metadata |
| 15:14 | <ljharb> | i'm confused; the queue item says "for stage 2" but the slide intro said "status update". is this proposal seeking advancement today? |
| 15:14 | <michaelficarra> | ljharb: I'm sure littledan will clarify that for us shortly |
| 15:14 | <ljharb> | kk |
| 15:14 | <michaelficarra> | oh I should stop mentioning his name while he's presenting, sorry Daniel! |
| 15:14 | <shu> | Bakkot: i am for the most part for them |
| 15:16 | <Bakkot> | shu neat, thanks |
| 15:17 | <shu> | Bakkot: this is a bottleneck for non-JS assets for web apps |
| 15:17 | <ljharb> | not for wasm tho? |
| 15:17 | <shu> | Bakkot: and given that i've been convinced that non-syntax alternatives are strictly technically worse, i'd prefer this get through |
| 15:17 | <shu> | yes, also for wasm? |
| 15:17 | <shu> | i mean, it affects wasm |
| 15:17 | <ljharb> | hm, can you help me understand that? |
| 15:17 | <shu> | i don't understand what your question is |
| 15:18 | <ljharb> | right but i mean, the motivating concerns don't apply to importing wasm, as i understand them |
| 15:18 | <ljharb> | only to non-code assets |
| 15:18 | <ljharb> | (json, css, html) |
| 15:18 | <shu> | that's not how i understand it |
| 15:19 | <ljharb> | what's your understanding? :-) |
| 15:19 | <shu> | the original motivating security concern from apple included both "noexecute" and "wrong parser" |
| 15:19 | <shu> | wasm falls in "wrong parser" |
| 15:21 | <shu> | the function does run differently depending on how you call it |
| 15:21 | <ljharb> | "wrong parser" can be solved without syntax tho on the web - it can use headers |
| 15:25 | <brad4d> | why did my question disappear from the queue? Was it inappropriate in some way? |
| 15:25 | <ljharb> | brad4d: hm, i never saw yours on there |
| 15:25 | <ljharb> | brad4d: reload the page? |
| 15:26 | <brad4d> | weird, refresh brings it back, thx |
| 15:26 | <jridgewell> | brad4d: sometimes the tcq is buggy |
| 15:26 | <ljharb> | ah lol yes i see it now that i refresh too |
| 15:26 | <jridgewell> | Or, sometimes 2 people click "delete" on the same row at the time time |
| 15:33 | <akirose> | i have done that before |
| 15:33 | <rkirsling> | do you mean both click delete on their own item at the same time? |
| 15:34 | <rkirsling> | 'cause I don't think anybody can delete anybody else's |
| 15:35 | <akirose> | i mean as a chair |
| 15:36 | <akirose> | or like someone clicks "i'm done speaking" at the exact same time as i click "next speaker" bc i think they forgot and they did forget _until that exact moment_ |
| 15:37 | <ljharb> | i did click "done speaking" on myself |
| 15:38 | <ljharb> | robpalme: i'm still on the queue (i had 2), and if you refresh you may see that i'm "speaking" right now :-) but i can go after bradley |
| 15:44 | <ljharb> | msaboff: you can't try/catch imports |
| 15:45 | <msaboff> | I know |
| 15:53 | <michaelficarra> | I have the same concerns about ignored vs rejected unknown attributes, but I also think it wouldn't kill this proposal either way; if it ends up being a problem, those attributes just unfortunately won't be added |
| 15:54 | <shu> | ljharb: to answer your question on here |
| 15:55 | <shu> | ljharb: i think the pressure to align isn't going to prevent aligning on a strictly worse solution, like a DSL inside module specifier |
| 15:56 | <keith_miller> | How would an envaluator work if you have two imports with different evaluators do you get different modules? |
| 15:57 | <keith_miller> | Because that would be wild |
| 15:57 | <michaelficarra> | I agree with Shu, they will just do something worse for the other attributes |
| 15:57 | <ljharb> | shu: out-of-band is also a viable option |
| 15:57 | <shu> | ljharb: i do not have the energy to be the middle man currently for this entire space |
| 15:58 | <ljharb> | ok |
| 15:58 | <akirose> | timebox, y'all. i'm about to start snapping like an impatient suburban mom |
| 15:58 | <shu> | akirose: this is an important proposal |
| 15:58 | <shu> | i believe extension is worth while |
| 15:58 | <akirose> | yes it is. and so are all the other things on the schedule. |
| 15:58 | <shu> | no, i believe this is more important than other things on the schedule |
| 15:58 | <ystartsev> | cool down period and come back to this topic? |
| 15:59 | <rbuckton> | ljharb: Limit the allowed keys of the `with { }` to just the one we care about for now? |
| 15:59 | <ystartsev> | @bterlson akirose robpalme MylesBorins ? |
| 15:59 | <ljharb> | rbuckton: which is just "type", yes, i'd be happy with that for now |
| 15:59 | <michaelficarra> | I agree with Shu, can we take a break and come back to this later or tomorrow? |
| 15:59 | <ystartsev> | ditto |
| 15:59 | <akirose> | that's fine |
| 16:00 | <michaelficarra> | littledan please include me in the offline module attributes discussion |
| 16:01 | <michaelficarra> | I also encourage people to choose less restrictive timeboxes for time sensitive proposals like this |
| 16:01 | <littledan> | sorry aboutthat |
| 16:02 | <littledan> | I guess we can start this offline discussion during lunch |
| 16:02 | <sffc> | Great example of something to do in the hallway track |
| 16:03 | <ljharb> | littledan: i'll need 10m to make lunch but will hop in after that |
| 16:03 | <littledan> | OK good |
| 16:03 | <sffc> | I'm in favor of shorter timeboxes to identify conflicts, followed by hallway track to resolve those conflicts out of band |
| 16:04 | <sffc> | Since we are over-subscribed this meeting and I'm still hoping we can get to Intl.Segmenter, which fell off the end |
| 16:09 | <michaelficarra> | sffc: if it's any consolation, overflow from previous meetings precede other proposal agenda items |
| 16:10 | <michaelficarra> | though I don't necessarily agree with that ordering |
| 16:10 | <devsnek> | what is the argument for BuiltInModule being preferable to just having globals |
| 16:10 | <Bakkot> | devsnek I am about to ask that question |
| 16:11 | <ljharb> | wsdferdksl: you run the shimming Script first, and then later Modules are affected by it |
| 16:11 | <devsnek> | hasModule = name in global, import = global[name], export = global[name] = v, freezeModules = Object.freeze(global)? |
| 16:12 | <jridgewell> | Or, `import 'shim.js'; import 'main.js'`, and `shim.js` will run before imports |
| 16:12 | <Bakkot> | Object.freeze(global) has a lot of other effects |
| 16:12 | <Bakkot> | which you really don't want |
| 16:13 | <devsnek> | Bakkot: some application of removing configurability and writability then |
| 16:13 | <jridgewell> | Oh, maybe linking in `main.js` happens before execution of `shim.js` |
| 16:14 | <rkirsling> | +1 to Thomas Levy's question (not sure IRC handle) |
| 16:14 | <jridgewell> | I'm not 100% sure, since this would be the first time you could muck with it |
| 16:14 | <ljharb> | jridgewell: yeah you'd need `import 'shim.js'; await import('main.js')` i think |
| 16:14 | <devsnek> | would be nice to hear from implementations on that last point |
| 16:14 | <ljharb> | rkirsling: just like now, where applications must always choose to freeze the env if that's what they want, they must choose to freeze builtin modules |
| 16:15 | <devsnek> | they already have pretty reasonable accessor apis for lazy object creation |
| 16:15 | <ljharb> | rkirsling: (is how i understand it) |
| 16:15 | <rkirsling> | more specifically I'm wondering if this becomes the new way to begin a JS file |
| 16:15 | <Bakkot> | devsnek msaboff is an implementation |
| 16:15 | <rkirsling> | er wait not file |
| 16:15 | <Bakkot> | ... implementor |
| 16:15 | <rkirsling> | app |
| 16:15 | <ljharb> | rkirsling: SES.lockdown() isn't the way to begin a JS file now :-) |
| 16:15 | <devsnek> | Bakkot: ah ok, the way he phrased that made it sound otherwise |
| 16:16 | <rkirsling> | ljharb: I mean I can take your word for that but I'm not familiar with SES envs |
| 16:16 | <rkirsling> | first-hand |
| 16:16 | <ljharb> | rkirsling: it's definitely the way to start any app that wants that kind of lockdown, sure |
| 16:17 | <rkirsling> | I mean I guess once-per-app is reasonable |
| 16:17 | <rkirsling> | I dunno why I thought once-per-file |
| 16:20 | <rkirsling> | oh... this is a new topic that jumped the queue |
| 16:20 | <rkirsling> | :-/ |
| 16:21 | <devsnek> | so the only reason this is better than adding new apis to the global is because engines can lazy load? |
| 16:21 | <bradleymeck> | rkirsling: you don't freeze in prod due to perf |
| 16:22 | <bradleymeck> | perf goes down in a non-trivial way for frozen stuff in engines |
| 16:22 | <robpalme> | v8 does not really have much of a penalty once frozen |
| 16:22 | <rkirsling> | but I think locking down was for security _in prod_ |
| 16:22 | <rkirsling> | *thought |
| 16:22 | <bradleymeck> | robpalme: has that been fixed? last i saw it still devolved into dict mode |
| 16:22 | <jridgewell> | robpalme: it did until about last year |
| 16:23 | <jridgewell> | bradleymeck: Yes, they fixed it very recently |
| 16:23 | <bradleymeck> | yay |
| 16:23 | <devsnek> | bradleymeck: it causes a deoptimization but everything can reoptimize again |
| 16:23 | <devsnek> | not locked to dict anymore |
| 16:23 | <bradleymeck> | so likely it is just a comms issue for that |
| 16:23 | <robpalme> | @bradleymeck we did a lot of benchmarking and could not find anything worth investing in fixing, so i's "good enough" |
| 16:23 | <rkirsling> | ohh I didn't realize we skipped ALL the replies |
| 16:23 | <rkirsling> | I too didn't recognize voices 😓 |
| 16:24 | <gibson042> | mea culpa |
| 16:24 | <jridgewell> | I believe this is the public doc: https://docs.google.com/document/d/1X6zO5F_Zojizn2dmo_ftaOWsY8NltPHUhudBbUzMxnc/edit |
| 16:25 | <jridgewell> | ^ "Fast frozen & sealed elements in V8" |
| 16:27 | <devsnek> | is freezeModules shallow? |
| 16:27 | <devsnek> | do you have to call freezeModules if your app is esm |
| 16:27 | <msaboff> | freezeModule doesn't freeze the module, just the module map. |
| 16:28 | <ljharb> | devsnek: i'm not sure how the BuiltinModules object would be made unavailable inside ESM |
| 16:28 | <ljharb> | devsnek: so i'd say yes |
| 16:28 | <devsnek> | well i wouldn't want anything to not be made available |
| 16:28 | <devsnek> | so if this is shallow, can't bad code still do bad things |
| 16:29 | <devsnek> | like i can't replace Temporal but i can replace Temporal.prototype.whatever |
| 16:29 | <shu> | i don't understand how shallow/deep applies to freezing the module map |
| 16:29 | <shu> | that doesn't do any freezing to things inside the module |
| 16:29 | <devsnek> | right so i'm asking |
| 16:29 | <devsnek> | what's the point of it |
| 16:29 | <jridgewell> | devsnek: I think that applies to global objects, too |
| 16:29 | <jridgewell> | This shouldn't be any different |
| 16:29 | <devsnek> | my understanding was freezeModules implies some sort of security |
| 16:30 | <shu> | no |
| 16:30 | <devsnek> | ok so what's it for |
| 16:31 | <ljharb> | it just means that the module namespace object can't be replaced any further |
| 16:31 | <ljharb> | replaced/modified |
| 16:31 | <devsnek> | right but why does someone want that |
| 16:31 | <devsnek> | what would be my motivation to call freezeModules() |
| 16:31 | <ljharb> | to have guarantees about the semantics of the rest of your application |
| 16:31 | <ljharb> | some of them |
| 16:31 | <devsnek> | what guarantees |
| 16:32 | <ljharb> | that `import * as ns from 'builtin module'` will always provide the `ns` you expect |
| 16:32 | <ljharb> | you certainly may also want to freeze the contents of that ns |
| 16:32 | <devsnek> | so its just like... a consistency thing |
| 16:32 | <ljharb> | you say "just" but i prioritize that pretty highly :-) |
| 16:33 | <devsnek> | i mean if we don't allow mutating the map in the first place |
| 16:33 | <devsnek> | sorry scratch that, if we don't have the distinction |
| 16:33 | <devsnek> | of application before freeze and application after freeze |
| 16:34 | <devsnek> | like with the global, you can apply whatever constraints you want |
| 16:34 | <devsnek> | at whatever point |
| 16:35 | <robpalme> | heads up on scheduling: the next topic (deep-path properties) is 25min (11:45-12:10 CST) so will eat into lunch. meaning lunch will be 50min instead of 60min. |
| 16:44 | <robpalme> | this font is not the greatest font in the world, it is just a tribute |
| 16:46 | <rkirsling> | robpalme: to tdz with ye |
| 16:46 | <robpalme> | @rkisling soory of course |
| 16:47 | <rkirsling> | (oh I'm not chastising so much as inviting lol) |
| 16:49 | <NilSet> | that nestd spread mess is used all over our codebase today, when we attempt to be immutable without a lib |
| 16:50 | <michaelficarra> | couldn't you theoretically do something like `newObj = (someFunction(immutableObj).deep.path.property = newValue)`? |
| 16:50 | <devsnek> | michaelficarra: i was thinking the same thing |
| 16:50 | <michaelficarra> | getters/setters solve the problem |
| 16:50 | <devsnek> | it would be unique for assignment to not return rhs though |
| 16:50 | <Bakkot> | no, that gives you newValue |
| 16:51 | <jridgewell> | Yah, that's the same as `newObj = … = newVal` |
| 16:51 | <devsnek> | Bakkot: it could not though |
| 16:51 | <jridgewell> | Whic his just `newVal` |
| 16:51 | <Bakkot> | devsnek yeah, I assumed the question was about using existing language features |
| 16:51 | <michaelficarra> | even when a setter is invoked, assignment returns the RHS? |
| 16:51 | <Bakkot> | yup |
| 16:51 | <michaelficarra> | aww |
| 16:51 | <devsnek> | like i said, unique |
| 16:52 | <jridgewell> | Yah, just like with `x = (uint8array[0] = 999)` |
| 16:52 | <jridgewell> | You get `999` |
| 16:52 | <jridgewell> | Even though `uint8array` will do a setter-like thing |
| 16:52 | <devsnek> | how about |
| 16:52 | <keith_miller> | shu: Do you or V8 have performance concerns with tuples generally? |
| 16:52 | <devsnek> | walrus operator |
| 16:52 | <keith_miller> | Since there's going to be a lot more object allocations |
| 16:52 | <devsnek> | `newRecord := oldRecord.x.y.z = 5` |
| 16:52 | <shu> | keith_miller: i haven't looked too deeply yet. i have vague anxiety, i guess |
| 16:53 | <ljharb> | lol walrus |
| 16:53 | <shu> | keith_miller: the default implementation technique means a lot more interning too |
| 16:53 | <keith_miller> | and it's hard to do escape analysis in JS, which is pretty important generally for other languages that have tuples. |
| 16:53 | <devsnek> | ljharb: i thought i was kidding but now i think i'm serious |
| 16:54 | <shu> | keith_miller: well yeah, and v8 at least wants things to be fast in the interpreter nowadays, we can't really lean escape analysis or scalar replacement and the like even if it were easy |
| 16:54 | <keith_miller> | so you can't do the normal just use the same cell |
| 16:54 | <jridgewell> | I want walrus operator just for the name. |
| 16:54 | <shu> | lean on* |
| 16:54 | <keith_miller> | right |
| 16:54 | <Bakkot> | python has tuples and is hard to escape-analyze |
| 16:54 | <jridgewell> | Eg, `||=` should forever be known as the mallet operator |
| 16:54 | <devsnek> | Bakkot: python is famously slow |
| 16:54 | <shu> | Bakkot: true, but python's performance demands is mostly offshored to C |
| 16:54 | <jridgewell> | https://github.com/tc39/proposal-logical-assignment/blame/master/README.md#L6 |
| 16:55 | <ljharb> | jridgewell: ||= doesn't look like a mallet tho unless it's `||=` :-/ |
| 16:55 | <shu> | in those FFI modules, is my understanding |
| 16:55 | <NilSet> | the turbofish operator <>:: is literally why i first looked at rust |
| 16:55 | <michaelficarra> | what does it mean for this proposal to advance to stage 1 when records/tuples is not stage 4? |
| 16:56 | <ljharb> | michaelficarra: stage 1 just means we're going to talk about it more |
| 16:56 | <michaelficarra> | because we agree there's a problem that needs to be solved |
| 16:56 | <michaelficarra> | how can there be a problem if there's no feature? |
| 16:56 | <gibson042> | stage(deepPathProperties) ≤ stage(recordsAndTuples) |
| 16:57 | <devsnek> | i feel like this should either be part of the more general object proposal |
| 16:57 | <Bakkot> | michaelficarra I think it's fine to say that we're advancing this to stage 1 with an eye towards a problem which does not yet exist but might in the future |
| 16:57 | <devsnek> | or the record/tuple proposal |
| 16:57 | <akirose> | wait isn't stage 1 acknowledging "there's a problem" and stage 2 "that we're interested in solving" |
| 16:57 | <jridgewell> | michaelficarra: See NilSet's comment |
| 16:57 | <jridgewell> | > that nestd spread mess is used all over our codebase today, when we attempt to be immutable without a lib |
| 16:58 | <jridgewell> | I think that means we have a larger issue than just record/tuple? |
| 16:58 | <Bakkot> | akirose stage 2 is "that we are interested in solving _with something like this solution_" |
| 16:58 | <Bakkot> | stage 2 implies a particular approach to solving the problem |
| 16:58 | <Bakkot> | (just with details omitted) |
| 16:58 | <michaelficarra> | ^ |
| 16:59 | <michaelficarra> | stage 1: we agree that there's a problem, stage 2: we've agreed on the important bits of our solution, stage 3: we've nailed down all the details of our solution |
| 16:59 | <rbuckton> | All of the mutations could be packed into a single result if the mutations within the same `{}` are tracked? |
| 17:01 | <michaelficarra> | nowObj = delete lens(oldObj).deep.property.name |
| 17:01 | <michaelficarra> | *newObj |
| 17:02 | <Bakkot> | michaelficarra fwiw we usually treat stage 1 as more like "we are not willing to declare that there is definitely not a problem" |
| 17:02 | <michaelficarra> | agreed, the bar for stage 1 is low |
| 17:02 | <michaelficarra> | and I think that's the right way to operate |
| 17:03 | <michaelficarra> | we should really add descriptions like these to the process document |
| 17:03 | <Bakkot> | request that we refrain from arguing about these details, given the timebox |
| 17:03 | <Bakkot> | the ones being discussed on the call, that is |
| 17:10 | <jridgewell> | Is "lenses" just codewords for proxy? |
| 17:11 | <michaelficarra> | jridgewell: all you could ever want to know about lenses: https://hackage.haskell.org/package/lens-tutorial-1.0.4/docs/Control-Lens-Tutorial.html |
| 17:12 | <rkirsling> | it's basically recreating property access in a pure FP setting |
| 17:12 | <rkirsling> | but I wasn't prepared to try to envision this in a JS setting |
| 17:13 | <TabAtkins> | OH wow, this was apparently not the morning for me to skip the pre-lunch parts of the meeting, if we're getting into lenses already |
| 17:13 | <jridgewell> | Can you translate into a normal language? |
| 17:13 | <jridgewell> | Lol. |
| 17:13 | <NilSet> | Question: What is a lens? |
| 17:13 | <NilSet> | Answer: A lens is a first class getter and setter |
| 17:13 | <rkirsling> | TabAtkins: lol. you missed it by a couple of minutes |
| 17:13 | <NilSet> | sounds to me like yes its codeword for proxy |
| 17:14 | <TabAtkins> | No, it's quite different from a proxy, but for ~mysterious reasons~ |
| 17:14 | <NilSet> | or rather you could implement a lens with a function that returns a proxy |
| 17:14 | <rkirsling> | oh like using a proxy as a view |
| 17:15 | <TabAtkins> | I'm busy this morning trying to untangle the HTML spec's use of GOTO in algorithms into nested loops |
| 17:15 | <TabAtkins> | for real wtf |
| 17:15 | <rickbutton> | oh no |
| 17:17 | <devsnek> | TabAtkins: link? |
| 17:18 | <TabAtkins> | the one i'm working on right now is https://html.spec.whatwg.org/multipage/parsing.html#reconstruct-the-active-formatting-elements |
| 17:18 | <devsnek> | i lost it at "rewind" |
| 17:20 | <rkirsling> | reverse reverse |
| 17:22 | <shu> | ljharb: are we talking about module attributes? |
| 17:26 | <gibson042> | michaelficarra: https://tools.ietf.org/html/rfc3986#section-3 |
| 17:27 | <jridgewell> | To answer the builtin modules discussion earlier: |
| 17:27 | <michaelficarra> | gibson042: huh? |
| 17:27 | <jridgewell> | https://gist.github.com/jridgewell/8428f797ef85346d3081c99518fa9fce |
| 17:27 | <ljharb> | shu: i'm here in the hallway track just now; littledan? |
| 17:27 | <jridgewell> | That will execute `shim.js` (which defines `js:foo`) before `main.js` links `js:foo` |
| 17:27 | <devsnek> | jridgewell: what if shim.mjs imports main.mjs |
| 17:27 | <shu> | ljharb: stepped away for a sec, omw |
| 17:27 | <jridgewell> | That would break it |
| 17:28 | <gibson042> | scheme = ALPHA *( ALPHA / DIGIT / "+" / "-" / "." ) |
| 17:28 | <gibson042> | sorry, that was for jridgewell |
| 17:44 | <bradleymeck> | jridgewell: in your gist the whole graph is lined prior to entry being ready to evaluate (and thus before shim) |
| 17:44 | <bradleymeck> | linked* |
| 17:44 | <bradleymeck> | so shim wouldn't execute prior to main linking |
| 17:45 | <jridgewell> | This behavior is msaboff's intention |
| 17:45 | <bradleymeck> | ah |
| 17:45 | <bradleymeck> | cycles would have to be isolated, that seems... hard |
| 17:47 | <msaboff> | If the shimming happens in a script loaded before a module that imports the shimed module, We propose that the shimmed module is the one that would be linked. |
| 17:48 | <bradleymeck> | <script> or Script (JS parse goal) |
| 17:48 | <bradleymeck> | ? |
| 17:48 | <msaboff> | Yes |
| 17:48 | <bradleymeck> | which? |
| 17:49 | <msaboff> | Script |
| 17:49 | <msaboff> | parse goal |
| 17:49 | <bradleymeck> | msaboff: would the ESM module graph from an import be rewired is the question |
| 17:49 | <bradleymeck> | to my understanding your Script/<script> would be outside of the ESM module graph it can instrument |
| 17:49 | <bradleymeck> | not like the linked gist |
| 17:50 | <msaboff> | I'd like to talk with you about how that would work. |
| 17:52 | <msaboff> | In the linked gist, it is my desire that shim.js would be processed first, before the second import, but we need to talk. |
| 17:58 | <shu> | sorry had to close spatial chat |
| 17:58 | <shu> | was making my gsuite laggy :/ |
| 17:58 | <robpalme> | two minutes warning! |
| 17:59 | <bradleymeck> | msaboff: that would be a change for sure to how ESM currently works |
| 17:59 | <robpalme> | we will be starting with Restrict subclassing support for built-inmethods |
| 17:59 | <bradleymeck> | linking is in early error domain currently |
| 17:59 | <msaboff> | Let's figure out a time to talk. |
| 17:59 | <rwaldron> | bterlson tomorrow do a 4 minute warning. https://www.youtube.com/watch?v=6eyUrpOl40k |
| 18:00 | <rkirsling> | ooh yes, been waiting for this topic |
| 18:02 | <leobalter> | littledan: for what I want, it's ok for -0 to be similar as in `0 === -0`, at the same time I want the flexibility of not breaking a deep comparison because of NaN |
| 18:03 | <ljharb> | leobalter: that's SameValueZero |
| 18:03 | <leobalter> | yes |
| 18:03 | <leobalter> | yes |
| 18:03 | <keith_miller> | rickbutton: littledan: Thinking about record/tuple more, have you considered just one type? so #["a"] is just sugar for #{ 0:"a" }? |
| 18:03 | <ljharb> | keith_miller: lists and structs should be conceptually distinct imo, that seems odd |
| 18:03 | <jridgewell> | Can we just throw if you insert a `NaN` inside a record? |
| 18:04 | <rickbutton> | keith_miller: it would need to sugar to #{ 0: "a", length: 1 } |
| 18:04 | <keith_miller> | ljharb: It's weird to me that those wouldn't be the same? |
| 18:04 | <keith_miller> | rickbutton: Sure |
| 18:04 | <ljharb> | keith_miller: a list has N items, a struct has N pairs |
| 18:04 | <ljharb> | also there's a ton of methods you want on Tuples that don't really make sense on Records |
| 18:05 | <littledan> | keith_miller: Tuples have Array-like methods on their prototype, whereas Records probably shouldn't have those |
| 18:05 | <littledan> | also Tuples have a .length, but I guess that could be part of the desugaring |
| 18:05 | <Bakkot> | jridgewell markm proposed that but a lot of people didn't like it |
| 18:05 | <Bakkot> | I also don't like it |
| 18:05 | <keith_miller> | I don't know how much it matters for the array methods to be on the prototype |
| 18:05 | <Bakkot> | though I don't hate it I guess |
| 18:06 | <keith_miller> | since it just wouldn't do anything |
| 18:06 | <rickbutton> | keith_miller I think it matters a lot, because we want people to be able to use tuples like they already use arrays, which use prototype methods |
| 18:06 | <rickbutton> | Array.prototype.slice doesn't mutate the array |
| 18:06 | <Bakkot> | jridgewell https://github.com/tc39/proposal-record-tuple/issues/65#issuecomment-635771624 |
| 18:06 | <keith_miller> | I just find it mildly confusing that a record could have exactly the same members as a tuple but not be == |
| 18:06 | <ljharb> | keith_miller: if they're own properties you can't polyfill Tuple methods. |
| 18:06 | <jridgewell> | `NaN` causes hairy equality issues, which is bad if records are motivated by equality. |
| 18:06 | <ljharb> | keith_miller: imo that's a feature. a list and a struct can't be the same |
| 18:07 | <jridgewell> | We already have runtime checks for disallowing mutable objects |
| 18:07 | <keith_miller> | ljharb: But that's not how objects in JS work |
| 18:07 | <keith_miller> | Objects in JS can have both indexed and non-index properties |
| 18:07 | <ljharb> | keith_miller: depends on what custom comparison logic you choose |
| 18:07 | <keith_miller> | so can arrays |
| 18:08 | <ljharb> | keith_miller: most comparison libraries (including the quite popular ones i maintain) consider arrays and objects to not be equalish |
| 18:08 | <ljharb> | also node's assert |
| 18:08 | <jridgewell> | Bakkot: I think Mark was also proposing `#[-0]` throws |
| 18:08 | <Bakkot> | jridgewell true |
| 18:08 | <Bakkot> | -0 also causes hairy equality issues, tbf |
| 18:08 | <keith_miller> | What do you mean by custom comparison logic? |
| 18:08 | <devsnek> | thinking of tuples in terms of arrays is surprising to me |
| 18:08 | <ljharb> | keith_miller: like, what's the implementation of your `isEqual(a, b)` function |
| 18:08 | <rickbutton> | I would be against #[-0] throwing, there are legitimate cases where -0 can appear, we don't want those to throw |
| 18:08 | <jridgewell> | I think `===` has good equality for `-0`. |
| 18:09 | <ljharb> | keith_miller: if it includes an Array.isArray check, as all the common ones do, then an array and an object would never be considered equal |
| 18:09 | <jridgewell> | It doesn't for `NaN` |
| 18:09 | <keith_miller> | But that's not part of the actual type system that's just what people implement when they do deep comparison |
| 18:10 | <keith_miller> | You could also do any amount of prototype chain checking |
| 18:10 | <shu> | keith_miller: after this item you got a min to talk through the deep property path escape analysis comment you had |
| 18:10 | <rickbutton> | it is a part of the type system, if you consider that object being an "array" exotic object is a part of the type itself |
| 18:10 | <keith_miller> | shu: Sure |
| 18:10 | <keith_miller> | shu: You mean the presentation or IRC? |
| 18:11 | <shu> | keith_miller: the presentation |
| 18:11 | <keith_miller> | 👍🏾 |
| 18:11 | <shu> | keith_miller: i just wanted to queue it up |
| 18:11 | <keith_miller> | 👍🏼 |
| 18:13 | <ljharb> | keith_miller: right but i'm saying that virtually the whole ecosystem does check the type when doing deep comparison at this point |
| 18:13 | <ljharb> | keith_miller: which means that many would find it confusing for JS not to do that |
| 18:14 | <keith_miller> | ljharb: The only way you'd see a distinction is if you create a record that looks exactly like a tuple |
| 18:15 | <keith_miller> | So, it's not even really a thing that's going to come up |
| 18:17 | <ljharb> | it comes up with arrays and objects. |
| 18:18 | <keith_miller> | So does equality not look at the prototype chain? |
| 18:18 | <rickbutton> | equality of what? |
| 18:18 | <ljharb> | keith_miller: normal JS equality does not, no |
| 18:18 | <keith_miller> | rickbutton: ljharb's isEqual function |
| 18:18 | <ljharb> | keith_miller: ecosystem deepEqual methods compare the [[Prototype]] |
| 18:19 | <ljharb> | iow `{ __proto__ A }` is not equal to `{ __proto__: B }` |
| 18:19 | <keith_miller> | Ok, so yeah, that makes sense because those are different types then. |
| 18:19 | <ljharb> | and so is `[]` and `{}` |
| 18:24 | <shu> | yikes |
| 18:24 | <shu> | robot |
| 18:25 | <ljharb> | jridgewell: you're a bit roboty |
| 18:25 | <bterlson> | droids |
| 18:25 | <ljharb> | jridgewell: ok you're better now |
| 18:25 | <leobalter> | daleks |
| 18:25 | <shu> | oh man that was jarring, the transition |
| 18:25 | <shu> | it was like watching the t-1000 heal |
| 18:25 | <robpalme> | sounded like a vocoder |
| 18:25 | <jorendorff> | `CustomArray.of` and `CustomArray.from` silently changing to not return a CustomArray seems almost mean |
| 18:25 | <bterlson> | any signals geeks know what happened there? |
| 18:26 | <ljharb> | jorendorff: only if there's a single person doing that tho, which i'm not sure is established :-p |
| 18:26 | <jorendorff> | true |
| 18:26 | <rickbutton> | bterlson: gremlins in the wires |
| 18:27 | <leobalter> | I want to take the opportunity of new types to fix a long time issue with === and NaN. I'd love for Records and Tuples to have a SameValueZero out of the box if I use === |
| 18:28 | <rkirsling> | <3 "stepping up to take out the trash" |
| 18:31 | <jorendorff> | +1 |
| 18:38 | <keith_miller> | rbuckton: Wait what were you saying? I zipped out for a second what's the problem with this.constructor? |
| 18:39 | <littledan> | I'm a very strong supporter of this proposal |
| 18:40 | <littledan> | (I think I added the species support in feross's buffer library...) |
| 18:40 | <keith_miller> | littledan: I heard you speaking about the this.constructor thing |
| 18:40 | <rbuckton> | This: |
| 18:40 | <rbuckton> | ``` |
| 18:40 | <rbuckton> | class MyArray extends Array { |
| 18:40 | <rbuckton> | constructor(options, items) { |
| 18:40 | <rbuckton> | super(...items); |
| 18:40 | <rbuckton> | this.options = options; |
| 18:40 | <rbuckton> | } |
| 18:40 | <rbuckton> | } |
| 18:40 | <rbuckton> | ``` |
| 18:40 | <rbuckton> | If we use `this.constructor` for `map`, calling `map` on a `MyArray` results in garbage. |
| 18:40 | <littledan> | https://github.com/feross/buffer/pull/97 |
| 18:40 | <littledan> | is this what people are referring to as the only correct usage of species? |
| 18:41 | <littledan> | yeah, that problem came up in the buffer library, and was actually a sort of web compat issue for ES6 |
| 18:41 | <bradleymeck> | littledan: it is the only one that doesn't do things like accidentally stop subclasses from working |
| 18:41 | <bradleymeck> | i'm sure there are *some* examples of using it properly elsewhere |
| 18:42 | <bradleymeck> | but not on sites i've crawled/code searches |
| 18:42 | <rbuckton> | With species I can do something like: |
| 18:42 | <rbuckton> | ``` |
| 18:42 | <rbuckton> | class MyArray extends Array { |
| 18:42 | <rbuckton> | ... |
| 18:42 | <rbuckton> | } |
| 18:42 | <rbuckton> | MyArray[Symbol.species] = function(...args) { return new MyArray({}, ...args); }; |
| 18:42 | <rbuckton> | ``` |
| 18:42 | <bradleymeck> | which makes me question if actually setting it is too complex |
| 18:42 | <rkirsling> | wait I thought 2-without-3 was on the table |
| 18:42 | <rbuckton> | If we use `this.constructor`, I have to override `map` hack around the use of `this.constructor`. |
| 18:42 | <bradleymeck> | rwaldron: if you have examples of cross realm apps/libs/sites/etc. I'd appreciate since writing cross context hooks is a bit involved |
| 18:42 | <rkirsling> | (er "remove 3 without removing 2") |
| 18:43 | <ljharb> | rbuckton: `constructor() { super(); this.constructor = custom; }`? |
| 18:43 | <michaelficarra> | yeah rkirsling that's not what the slides said |
| 18:44 | <shu> | rkirsling: oh, not via .constructor |
| 18:44 | <shu> | maybe there's a better way but i don't have any ideas |
| 18:44 | <shu> | i think there was indeed miscommunication here |
| 18:44 | <rkirsling> | oops |
| 18:48 | <rkirsling> | yay |
| 18:48 | <rwaldron> | bradleymeck It's not really something that's well advertised about apps |
| 18:48 | <rwaldron> | or libraries, or whatever |
| 18:48 | <ljharb> | mpcsh: on it |
| 18:49 | <bradleymeck> | yea, so not easy for me to find :-/ |
| 18:49 | <keith_miller> | Bakkot: RE the branch on pageload, there's so much other stuff that's in builtin functions that normal user code would never do already |
| 18:49 | <shu> | i think folks are overfocusing a bit on it being "an unnecessary branch" |
| 18:50 | <shu> | it propagates to a lot more complexity in V8 and SM than just a single branch, though that's what it is in the spec text |
| 18:50 | <keith_miller> | i.e. you'd get better perf by rewriting all the iterator methods anyway |
| 18:50 | <keith_miller> | err |
| 18:50 | <bradleymeck> | rwaldron: right now the crawler just replaces every method that calls [@@species] with a devtools debugger trap. in theory it should catch cross realm stuff, but idk if any of our listed sites do that |
| 18:50 | <devsnek> | i'm a big fan of async context |
| 18:50 | <keith_miller> | prototype |
| 18:50 | <rwaldron> | What is the current preferred way of adding things to the notes that we didn't get to? |
| 18:50 | <msaboff> | So is the "restrict subclassing support" the first stage 1 or greater proposal to remove normative behavior? |
| 18:51 | <rwaldron> | msaboff nope, I think I get that award: renaming Atomics.wake to Atomics.notify |
| 18:51 | <rwaldron> | That was in a published spec |
| 18:51 | <keith_miller> | shu: How do V8/SM do their fast path check? |
| 18:51 | <rwaldron> | ᕦ(ò_óˇ) |
| 18:52 | <rickbutton> | rwaldron: like additional queue items? |
| 18:52 | <rbuckton> | Yay, async call contexts. I've wanted this for awhile. Kind of like `Threading.AsyncLocal` in .NET. |
| 18:52 | <rickbutton> | (that didn't make it) |
| 18:52 | <jridgewell> | bradleymeck: Are you using `Object.defineProperty` for that? |
| 18:53 | <shu> | keith_miller: there're two ways: 1) manual fast/slow path dispatch in the built-in implementation |
| 18:53 | <jridgewell> | The `@@species` props are all no-set getters |
| 18:53 | <msaboff> | rwaldron =: Okay. But we knew that wasn't web breaking because the feature was turned off (and still is). |
| 18:53 | <bradleymeck> | jridgewell: no, just replacing the primordial method with a diff function |
| 18:53 | <shu> | keith_miller: 2) a monotonic "protector bit" that gets flipped if the page does something that results in a bad time, i think as you call it |
| 18:53 | <ystartsev> | do i get an award for having my first championed proposal be to remove normative behavior instead of add? |
| 18:53 | <bradleymeck> | jridgewell: basically we are trapping [].map not [][@@species] |
| 18:53 | <shu> | keith_miller: it's much worse for regexp than Array#map |
| 18:53 | <rickbutton> | you certainly should ystartsev |
| 18:54 | <shu> | keith_miller: okay, so to dequeue my question earlier |
| 18:54 | <rkirsling> | I removed early ref error 🤔 |
| 18:54 | <rkirsling> | but it was a normative PR lol |
| 18:54 | <rbuckton> | I think the Queue is still on a topic from the last agenda item? |
| 18:54 | <shu> | keith_miller: help me understand the escape analysis issue, more in detail? |
| 18:54 | <robpalme> | you should get 10x more tc39 points for deleting lines from the spec vs adding them |
| 18:54 | <shu> | keith_miller: what allocations would it elide if the optimization applies? |
| 18:54 | <bradleymeck> | jridgewell: slightly old but same idea in https://gist.github.com/bmeck/5f195c4ae08009db4f3eefdc8bb360c9 |
| 18:55 | <bradleymeck> | we have a lot more coreJS detection stuff now :-/ |
| 18:55 | <rwaldron> | rickbutton yeah, I was in the queue |
| 18:55 | <keith_miller> | shu: Yeah, I think we mostly use the our equivalent of bit method. |
| 18:55 | <rwaldron> | There's a pretty important point that I need to add to the notes |
| 18:55 | <keith_miller> | But I haven't looked in a while |
| 18:55 | <rickbutton> | rwaldron: we usually just append them to the end of the notes for the section |
| 18:55 | <rickbutton> | :%s/section/proposal section/g |
| 18:55 | <rwaldron> | I think it changes our understanding of what would be affected by @@species removal |
| 18:55 | <rwaldron> | Because it's not @@species being used directly |
| 18:56 | <rickbutton> | with like a header of "remaining queue items" or something |
| 18:56 | <rkirsling> | robpalme: we should add that to how-we-work |
| 18:56 | <shu> | rwaldron: what's the point? |
| 18:56 | <shu> | rwaldron: the proposed semantics is that the built-ins create an instance of the built-in in the current realm |
| 18:56 | <ljharb> | mpcsh: rickbutton tell me where to add my skipped queue item for that one btw |
| 18:56 | <rwaldron> | shu you shook something loose when you mentioned looking through old code (or something like that) |
| 18:57 | <shu> | what does that mean? :) |
| 18:57 | <rwaldron> | I'm getting to it |
| 18:57 | <keith_miller> | shu: So in most languages that have simple updates to immutable things they are either refcounted (so refCount == 1 means mutate in place) or they heavily rely on an escape analysis to prove that the tuple doesn't leave the function so you don't need to allocate it at all |
| 18:57 | <rwaldron> | I need to check something |
| 18:57 | <rwaldron> | No, I can do that later |
| 18:57 | <rickbutton> | ljharb just put it after the conclusion in the "restrict subclassing support" section |
| 18:57 | <rwaldron> | If we remove @@species, I believe we will break every site that ever used Zepto |
| 18:57 | <keith_miller> | actually you need the escape for the ref count thing anyway |
| 18:58 | <shu> | rwaldron: fascinating, would love to dig in |
| 18:58 | <keith_miller> | But you can't really do that optimization in JS without a lot of speculation due to getters |
| 18:58 | <rwaldron> | shu https://github.com/tc39/notes/blob/master/meetings/2014-11/nov-18.md#46-zepto-broken-by-new-thisconstruct-usage-in-some-arrayprototype-methods |
| 18:58 | <shu> | keith_miller: ah, that's a general concern about records/tuples, not a specific one about the deep path properties? |
| 18:59 | <keith_miller> | shu: Yeah, true but deep path properties make it much more ergonomic. |
| 18:59 | <ljharb> | rwaldron: that's if we remove species *and* use constructor? |
| 18:59 | <keith_miller> | And I don't think people realize that it's going to be very expensive |
| 19:00 | <shu> | keith_miller: ah, i see. kinda a moral hazard argument that they might think records and tuples are cheaper than object literals |
| 19:00 | <shu> | when they are in fact worse |
| 19:01 | <keith_miller> | shu: If deep path mutation is in a userland library they 1 need to find it and 2 probably have different expectations on its performance |
| 19:01 | <shu> | rwaldron: good find, though my read is of that is how @@species broke ES5-era behavior (the "old semantics" we're proposing), and removing @@species and constructor delegation altogether gets us back to ES5-era behavior, and would be compatible |
| 19:01 | <rickbutton> | keith_miller: these are valid arguments, can you list your performance considerations in the issue tracker? |
| 19:01 | <shu> | that's a big part of the intuition that this change IS compatible fwiw, because it was what it was in es5 and we broke it for a bit and worked around with @@species |
| 19:01 | <keith_miller> | rickbutton: sure |
| 19:01 | <rickbutton> | thank you :) |
| 19:02 | <shu> | keith_miller: and to make sure i understand some more... |
| 19:02 | <shu> | keith_miller: the worst case here for tuples is _as many allocations_ as mutable objects |
| 19:02 | <shu> | not somehow inherently worse than mutable objects? |
| 19:03 | <shu> | i guess this is also a question for wsdferdksl |
| 19:03 | <shu> | i still don't fully understand his concern |
| 19:03 | <keith_miller> | shu: I'm not sure I understand your concern |
| 19:03 | <shu> | i have no concern yet |
| 19:03 | <keith_miller> | err clarification |
| 19:03 | <shu> | keith_miller: like, suppose we definitely cannot do any smart optimizations |
| 19:04 | <keith_miller> | It's just that when I do `foo.bar.baz = 1` on an object it doesn't do an allocation people don't think about the fact that the immutable thing will do allocations |
| 19:04 | <shu> | what will be the performance characteristic of records be? wouldn't it be the same as using mutable objects as if they were immutable?? |
| 19:04 | <shu> | ah, i see, ok |
| 19:04 | <keith_miller> | Oh, I see what you're saying |
| 19:04 | <keith_miller> | yeah, it's the same |
| 19:04 | <shu> | didn't mean 2 question marks |
| 19:05 | <shu> | still working trigraphs out of my system |
| 19:05 | <keith_miller> | But it's just much harder to work with so people are unlikely to do it. |
| 19:05 | <shu> | right, i get your concern now |
| 19:05 | <keith_miller> | I'd just be sad if we add this feature then every linter in the world say "DON'T DO IT FOR PERF!!!!11!!" |
| 19:06 | <keith_miller> | it's gonna ruin your page load time |
| 19:06 | <keith_miller> | maybe that won't happen though... |
| 19:06 | <keith_miller> | It's more just something I'd like to consider |
| 19:07 | <jridgewell> | > `foo.bar.baz = 1` |
| 19:07 | <jridgewell> | Isn't it clear from `{ ...record, x: 1 }`'s syntax that it will be doing a clone? |
| 19:07 | <rickbutton> | I would also be sad if that is the case. I think it would be useful to find some examples of cases where this kind of thing is already happening, during the prez redux got mentioned, where deeply-nested "many allocations" with regular objects are common/expected. |
| 19:08 | <shu> | jridgewell: you'd think, but we were just talking yesterday about IIFEs being a suitable replacement for a do-block, despite the extra allocations |
| 19:18 | <rwaldron> | shu you may indeed be right, but I just want to make sure we don't miss any of the historic context |
| 19:22 | <shu> | rwaldron: +100 |
| 19:22 | <devsnek> | shu: fwiw people who use products like datadog and sentry tracing and stuff all opt into the perf hit and seem fine with it |
| 19:22 | <devsnek> | (i still think these should be disabled by default) |
| 19:22 | <shu> | devsnek: sure, the point is we want it to be opt in |
| 19:23 | <shu> | devsnek: but last time the feedback was we don't know how to make the performance characteristic to be opt in |
| 19:23 | <devsnek> | got it, understand you now |
| 19:23 | <rwaldron> | mmarchini I think you just gave me a flash back to Domains |
| 19:24 | <mmarchini> | lol |
| 19:24 | <mmarchini> | sorry |
| 19:24 | <devsnek> | "flash back" i wish domains were in my past |
| 19:24 | <rwaldron> | That was the Zones issue, IIRC |
| 19:24 | <rwaldron> | right? |
| 19:24 | <bradleymeck> | rwaldron: zones were a 21 line wrapper around domains |
| 19:24 | <rwaldron> | Yep ^^^ |
| 19:24 | bradleymeck | wiggles eyebrows |
| 19:24 | <rwaldron> | hahahahaha |
| 19:24 | <mmarchini> | LOL |
| 19:24 | <devsnek> | zones are a small wrapper around async hooks as well |
| 19:26 | <rwaldron> | This proposal makes me want to revive my "async blocks" syntax proposal |
| 19:27 | <rwaldron> | (I can't tell if I'm serious yet) |
| 19:27 | <jridgewell> | Async blocks? |
| 19:27 | <rwaldron> | yeah dog |
| 19:27 | <Bakkot> | rwaldron I mentioned `async do {}` in my do-exprs proposal |
| 19:27 | <rwaldron> | I knooooooowwwww |
| 19:27 | <shu> | i miss when people said dog |
| 19:27 | <rwaldron> | ;) |
| 19:28 | <rwaldron> | Bakkot I was *thrilled* |
| 19:28 | <devsnek> | tracking the causality of async tasks bro |
| 19:29 | <rwaldron> | Gus, don't you mean "tracking the causality of async tasks dog" |
| 19:30 | <rkirsling> | not dawg though? |
| 19:30 | <rwaldron> | That works as well |
| 19:30 | <rwaldron> | Interchangeable |
| 19:31 | <rwaldron> | Bakkot jridgewell my old timey proposal was basically something that I came up with when Luke Hoban first started working on async functions |
| 19:32 | <ystartsev> | akirose: regarding announcments, would tomorrow morning work? |
| 19:36 | <leobalter> | robpalme I have to pause for another meeting, I won't be able to catch the Intl Enumeration discussion. Please let me know if anything else will be discussed today, if you have time to do it, of course :) |
| 19:37 | <devsnek> | i'm so confused about the stage 1 block |
| 19:37 | <rwaldron> | devsnek I've been confused by Stage 1 since forever |
| 19:37 | <devsnek> | isn't people agreeing this is a problem the exact stage 1 |
| 19:37 | <devsnek> | requirement |
| 19:37 | <robpalme> | we have nothing else scheduled. this will take us to 6 minutes beyond the scheduled end. |
| 19:37 | <ljharb> | devsnek: stage 1 also means, we want to talk about it more in committee |
| 19:37 | <devsnek> | right |
| 19:38 | <ljharb> | devsnek: to me it sounds like the blocks mean "we are currently convinced there's nothing further to discuss" |
| 19:39 | <ryzokuken> | right, I always thought of a stage 1 block as "this is a non-starter. we don't even think this warrants attention." |
| 19:39 | <devsnek> | i don't think stage 1 requires exhaustively proving no solution will be found |
| 19:39 | <michaelficarra> | is there a reason we're skipping Intl.Segmenter for stage 3? |
| 19:39 | <michaelficarra> | we're not going to get to it today and it's not on the schedule for tomorrow |
| 19:39 | <ljharb> | devsnek: it generally requires convincing everyone that a solution *could* be found |
| 19:39 | <ljharb> | michaelficarra: it was added late, so it'd be done last |
| 19:40 | <michaelficarra> | since when? |
| 19:40 | <michaelficarra> | we do agenda items in order (modulo timing constraints) |
| 19:40 | <ljharb> | that's true |
| 19:40 | <ljharb> | i'm not really sure |
| 19:40 | <ljharb> | it came up on monday and the chairs suggested it going later |
| 19:40 | <michaelficarra> | being added late only changes whether we think it's justifiable to reject based on timing alone |
| 19:40 | <ljharb> | agreed |
| 19:41 | <michaelficarra> | oh it was added after we agreed to the agenda? |
| 19:41 | <rbuckton> | michaelficarra: are you looking at the draft schedule or TCQ? |
| 19:41 | <ljharb> | michaelficarra: no https://github.com/tc39/agendas/commit/ec18f27dce69959586ad5f205bfb00b690201d26#diff-3441294351e2ad1cc9682d5d1eafb082 |
| 19:41 | <rbuckton> | In the draft schedule Intl.Segmenter is listed as Overflow |
| 19:41 | <michaelficarra> | oh then we should definitely prioritise it ahead of stage 0 things |
| 19:42 | <ljharb> | but michaelficarra is right; being added late is not supposed to mean they get bumped to the end |
| 19:42 | <ljharb> | akirose et al? ^ |
| 19:42 | <rickbutton> | it's on the draft agenda twice, once under overflow, once under "items added after deadline" |
| 19:42 | <keith_miller> | I could see an argument for bumping it FWIW, not that I care that much one way or the other |
| 19:42 | <ystartsev> | michaelficarra: i think this was a response to how packed the agenda and there was a question asked to the room if things that missed the deadline should be deprioritized, and the answer was yes |
| 19:43 | <ystartsev> | since it was added late, this is grounds for not allowing it to move forward due to a technicality, and it might not be a good use of time |
| 19:45 | <michaelficarra> | we could ask if anyone feels it should be skipped for this reason before starting, but I don't think it's appropriate to assume that it would not be a good use of our time |
| 19:45 | <sffc> | I would like Intl.Segmenter to be prioritized if possible |
| 19:46 | <sffc> | Chrome is getting ready to ship it |
| 19:46 | <sffc> | But it would be awkward to ship a Stage 2 proposal |
| 19:46 | <sffc> | It's been ready for Stage 3 for a few months, but it just never got added to the agenda |
| 19:46 | <rickbutton> | will it truly take 30 minutes? could consider slipping it in as a smaller timeslot |
| 19:46 | <ystartsev> | could it be shorter? |
| 19:47 | <ystartsev> | it already got the ok from zibi so we are fine with it |
| 19:47 | <ystartsev> | the problem is it was added to the agenda after the deadline, so the team didn't review it |
| 19:47 | <ystartsev> | and i don't want that to become acceptable practice. |
| 19:47 | <sffc> | We could timebox it for 10-15 minutes, and attempt for Stage 2 |
| 19:47 | <ystartsev> | that deadline for advancement is really important |
| 19:48 | <sffc> | I agree about the deadline being important |
| 19:48 | <sffc> | attempt for *Stage 3* |
| 19:48 | <ystartsev> | chrome is preparing to ship it, that is a little strange for stage 2 no? |
| 19:49 | <sffc> | I mean, it's implemented, but I think Frank won't flip the bit until it gets to Stage 3 at TC39 |
| 19:50 | <ystartsev> | i have to say i am not comfortable with having something shoe horned in. we are lucky that zibi had been working on this so much so we are already invested |
| 19:50 | <ystartsev> | that isn't true for all delegates |
| 19:50 | <ystartsev> | just because something is ready for stage 3 for a long time doesn't necessarily mean people have checked it for review |
| 19:50 | <michaelficarra> | ystartsev: if that is the case, you are completely justified in rejecting advancement |
| 19:50 | <ystartsev> | that said, overall, we don't have an issue |
| 19:50 | <michaelficarra> | I don't want you to feel pressured |
| 19:51 | <rkirsling> | I agree the principle may be more important here, even if the thing is totally uncontroversial |
| 19:51 | <rkirsling> | (i.e. I'd actually like to see it advance now rather than later but I'd prioritize the principle) |
| 19:53 | <ljharb> | there's plenty of things we discuss that aren't up for advancement |
| 19:53 | <ystartsev> | yeah ... it was added on thursday last week which only gives 1 full day for review |
| 19:53 | <ljharb> | even if advancement is off the table due to not enough review time, discussing the item could still be valuable |
| 19:53 | <ystartsev> | we could discuss it, but would that be a good use of time if it doesn't advance? |
| 19:53 | <Bakkot> | fwiw I am totally on board with the chairs making that kind of call |
| 19:54 | <ystartsev> | same |
| 19:54 | <ljharb> | that's really up to the champions i'd think? as i said above, tons of things are worth the time even when they don't request advancement. |
| 19:54 | <ljharb> | if advancement is the main criteria, then we shouldn't have any items that aren't advancement requests |
| 19:54 | <ljharb> | i think it's appropriate to leave it up to the chairs when it means the difference between completing the agenda or not |
| 19:55 | <ljharb> | but the intention when adding that deadline was to not obstruct people's ability to add discussions even at the last minute |
| 19:55 | <Bakkot> | I'd support changing the agenda rules to say that anything added after the advancement deadline is deprioritized even if it isn't looking to advance, absent some particular reason it is time-sensitive |
| 19:55 | <ljharb> | iow, it's not to prevent the need for someone to block based on the deadline; it's to make that blocking low-cost |
| 19:55 | <Bakkot> | we also review the agenda after the deadline to make sure we know what we think about all of the topics on the agenda |
| 19:55 | <jridgewell> | wsdferdksl: https://github.com/bslassey/privacy-budget |
| 19:55 | <ljharb> | Bakkot: if we got consensus on that (like we did on the original deadline) then that seems fine to me too |
| 19:55 | <Bakkot> | and we don't have that for things added after the deadline |
| 19:56 | <ystartsev> | we do the same as bakkot |
| 19:56 | <ljharb> | understood, and while review's always helpful, and for some is critical to permit advancement, that doesn't mean that lack of review should block the discussion |
| 19:57 | <ljharb> | stage 1-seeking proposals don't even have to provide materials |
| 19:57 | <rkirsling> | but they should >_< |
| 19:57 | <Bakkot> | ljharb ehhhhhhhhh |
| 19:57 | <rkirsling> | did we not finish that discussion? |
| 19:57 | <Bakkot> | I think it should deprioritize the discussion |
| 19:57 | <ljharb> | sure. and "should", but not "must", was an explicitly chosen difference. |
| 19:57 | <ystartsev> | they do now? they require a proposal |
| 19:57 | <rkirsling> | there was a thread |
| 19:57 | <littledan> | I think browser TC39 representatives have been monitoring browser fingerprinting concerns; at least that's been the case in ECMA-402 |
| 19:57 | <rkirsling> | yeah I know we had a full PR... |
| 19:57 | <ljharb> | ystartsev: yes we changed it recently to "Such proposals must link to a proposal repository and they should link to supporting materials when possible." |
| 19:57 | <ljharb> | but i don't have to have anything in the repo |
| 19:58 | <rkirsling> | https://github.com/tc39/process-document/pull/26 |
| 19:58 | <ystartsev> | ok but we are getting into a digression |
| 19:58 | <michaelficarra> | Bakkot: I would prefer we continue to prioritise by stage, regardless of when the item was added or whether it is looking for advancement, so that we continue to make progress on reducing our in-progress work |
| 19:58 | <ljharb> | ah true, that requires the repo "capture the above requirements" |
| 19:58 | <ljharb> | sorry for the digression |
| 19:58 | <Bakkot> | michaelficarra except it is difficult to make progress on things when there isn't time for people to review htem |
| 19:59 | <ljharb> | sometimes difficult. and not impossible. |
| 19:59 | <ljharb> | and that seems like something the champions should be able to judge? |
| 19:59 | <michaelficarra> | maybe not as productive as they could have been, but I doubt the champion would bring it forward if they didn't think it could be useful |
| 20:21 | <bradleymeck> | hallway track definitely keeps cutting off audio, anyone else seeing that |
| 20:22 | <rickbutton> | not happening for me |
| 20:42 | <rkirsling> | oof, so much for 26 C; it's now 33 |
| 21:32 | <shu> | ljharb: i confirmed internally with some folks that the 'type' attribute should suffice for the web use cases currently |
| 21:32 | <ljharb> | shu: awesome, great to hear! |
| 21:32 | <shu> | ljharb: (of course, the formulation where it's up to the host to process the value) |
| 21:32 | <shu> | the value of the 'type' key |
| 21:32 | <ljharb> | yes, agreed |
| 21:35 | <shu> | while we disagree on the signals that ecma262 do or should send, i believe we understand each other, and i'm more than happy to move forward with the check-style only restriction |
| 21:41 | <bradleymeck> | i did realize i have one evaluator i want somewhat badly, `wrapToAvoidThenable=true` |
| 21:42 | <ljharb> | bradleymeck: that seems like it only applies to dynamic import, and would be the same Module object, it just would wrap it in a container. not just a "check" to be sure, but i'm not sure that qualifies as an evaluator either |
| 21:43 | <bradleymeck> | import.wrapped() would be fine to me |
| 21:53 | <shu> | big oof @ thenables |
| 21:54 | <gibson042> | ystartsev: the spec hasn't changed since team review from last time when the Mozilla objection was withdrawn |
| 21:55 | <gibson042> | but I realized that Intl.Segmenter stage 3 official review #2 is still pending and so advancement will/would be conditional upon that anyway. But there is an important issue to discuss that stretches beyond this specific proposal and should be discussed if there's time: https://docs.google.com/presentation/d/1Pe9eVhgK93cgB3KCufTQvzqCjIYj3RRxJaOeNIbWN_A/edit#slide=id.g87b4869bad_0_0 |
| 21:56 | <gibson042> | I'm willing to defer because I did miss the deadline, but fwiw the requirement is "must be added (and noted as such) *along with the necessary materials* prior to the deadline", and every meeting there are always tons of slides and spec text slipping in to an otherwise empty placeholder slot after the deadline |
| 23:51 | <rkirsling> | wow, it could've been called @@copyConstructor, huh |
| 23:52 | <rkirsling> | that would've been way less "I have zero idea what this word will be used to mean"-inducing than @@species :p |