2026-01-02 [08:16:12.0692] The March 2026 plenary meeting in New York is now [confirmed.](https://github.com/tc39/Reflector/issues/571#issuecomment-3705704390) šŸ—½ 2026-01-05 [00:53:48.0029] Happy 2026. šŸŽ‰ Clarification request: Is the 112 meeting scheduled from 2026ā€‘01-20 to 23 or 2026ā€‘01-20 to 22; 3 or 4 days? [00:53:51.0208] Thanks [04:23:19.0261] Pretty sure it's intentionally three days. [06:02:07.0705] Ok, thanks. [10:39:33.0126] given the current status of the agenda... it's likely only 1 [11:58:20.0988] The deadline for proposal advancement is in ~5 days and there is lots of room available on the agenda. Please add your topics! šŸ™ 2026-01-06 [13:19:26.0530] That was absolutely an AI response. The arguments also don't make sense, syntax is much easier to understand and detect than an imperative method. [13:21:06.0887] * That was absolutely an AI post. The arguments also don't make sense, syntax is much easier to understand and detect than an imperative method. 2026-01-07 [03:01:35.0751] For those who are attending FOSDEM 2026 in Brussels, please also consider to register and attend Toasting TC54 Drinks and light bites. [03:02:55.0885] Thanks 2026-01-08 [01:56:45.0759] Should the following intl proposal repos be archived? - https://github.com/tc39/proposal-intl-segmenter - https://github.com/tc39/proposal-intl-numberformat-v3 - https://github.com/tc39/proposal-intl-unit-format The first two have reached Stage 4, while the last was effectively superseded by NumberFormat v3. [08:25:42.0924] def the stage 4 ones [10:01:36.0001] the stage 1 one should be formally withdrawn if it's been superseded [10:05:36.0392] Is the formal withdrawal something that needs to be proposed by the champion, or any delegate? [10:27:05.0346] šŸ¤·ā€ā™‚ļø dunno, but probably anybody can do it [12:49:54.0009] if itā€™s uncontroversial you can just update the proposals repo, and mention it next plenary, i think [12:55:46.0016] Zibi (the proposal's champion) was on today's TG2 call, and I gather that the request to withdraw it will be included in the TG2 update at plenary. [12:55:55.0635] > Is the formal withdrawal something that needs to be proposed by the champion, or any delegate? mostly depends if the champion(s) are active and/or reachable but anyone can technically propose it. it should be formally on the meeting agenda to withdraw it [12:56:37.0779] given that Zibi just made a commit to the repo saying it's deprecated in favor of Unified Intl.NumberFormat, seems safe for anyone to put it on the agenda for the upcoming meeting [12:57:31.0565] (I'll miss the next plenary, so not available to submit an agenda item for the withdrawal.) [12:58:09.0623] you can put my name down on it if you don't mind creating the PR [12:58:38.0694] Sure, will do. [13:04:52.0432] Done. Adding the item increases the total timeboxed time by over 4%, from 70 to 73 minutes. 2026-01-10 [06:50:30.0284] The agenda now has a whole day of content! 2026-01-11 [18:17:46.0313] so I guess I wasn't the only one who took all of December off 2026-01-15 [01:47:27.0819] Could somebody archive https://github.com/tc39/proposal-json-modules ? [10:13:05.0189] šŸ“¢ Due to sparse agenda, next week's plenary meeting is reduced to two days (Tuesday and Wednesday). [10:13:33.0070] draft schedule is now available. link is in the reflector issue: https://github.com/tc39/Reflector/issues/572 [13:23:54.0955] For the New York meeting, we don't yet have a community event. Does anyone have contacts with JS meetup groups there? 2026-01-16 [03:58:01.0276] The invite for the March TC39 meeting in New York is now [posted on the reflector.](https://github.com/tc39/Reflector/issues/573) Please note the Community Event and TG5 workshop have not yet been arranged, so potentially the Monday or Friday should factor into your travel plans. 2026-01-19 [08:47:54.0003] FYI (Aki ?) ecma-international.org has a cert error (which I figured out after searching ECMA 404 and clicking first link [08:47:56.0630] * FYI (Aki ?) ecma-international.org has a cert error (which I figured out after searching ECMA 404 and clicking first link) [08:48:48.0170] how did the cert _suddenly_ expire in April of last year?! [08:49:40.0128] anyway, thank you mgaudet , I let the secretariat know [08:50:19.0274] Firefox error says "https://ecma-international.org/publications-and-standards/standards/ecma-404/ Unable to communicate securely with peer: requested domain name does not match the serverā€™s certificate." but also that roughly is the end of my TLS knowledge [09:53:41.0958] I'll cast the net wider. Who knows sociable JS people in NY who might have contacts with meetup groups there? [13:57:26.0010] [Carl Vitullo](https://bsky.app/profile/vcarl.com) -community lead at Reactiflux, generally well-connected- likely is a good lead. I can connect you if you'd like. Also, looking at the local meetup scene, they've got a couple upcoming ones I bet would love to hear from anybody in TC39: * [Brooklyn Web Workers](https://bsky.app/profile/brooklynwebworkers.com) * [NY Web Performance](https://bsky.app/profile/nywebperf.com) 2026-01-20 [19:03:17.0812] Apologies, I added a late-breaking constraint in https://github.com/tc39/agendas/blob/9f358facee2c51c8d2a17bae4edcb8b4837d70aa/2026/01.md but must have misclicked in the mobile web ui as it committed directly rather than creating a PR. [06:52:47.0572] The sign-in form is now posted on the Reflector. Plenary begins in 13 mins! [06:53:06.0713] * The sign-in form is now posted on the Reflector. Plenary begins in 6 mins! [07:14:59.0886] šŸ‘‹šŸ» attendees: volunteering as a note-taker is relatively low effort, please do take a "shift" (as long or as little as you're comfortable). All that is required is to keep an eye on the transcription and make edits/fixes if errors come up. [07:15:32.0253] also report back to #temporaldeadzone:matrix.org any funny homophones or otherwise amusing typos [07:22:40.0999] reference material: ArkTS (is on the agenda for a link to the slides) [07:23:39.0453] https://github.com/tc39/agendas/blob/main/2026/Basic%20ArkTS%201117%20-%20ext%20-%20simplified.pdf [07:29:20.0438] my train arrives in Zurich at 17:41, so I will drop off, and join again after the lunch break. [07:29:38.0651] was my audio OK? [07:29:57.0477] downright impressive for train wifi [07:30:48.0787] Congratulations bakkot ! (?) [07:32:04.0437] thanks, looking forward to having time off for a while [07:32:28.0712] honestly kind of expecting to do more not less committee work, but we'll see what happens [07:43:20.0057] I changed the notes template to be Conclusion/Summary/Title rather than Title/Conclusion/Summary, since that's most of the times what we need to copy&paste [07:43:23.0491] Please don't revert it! [07:51:03.0062] I'm pretty shocked that GraalJS has a Temporal implementation already [07:51:24.0724] while their implementation is generally very *good*, they often lag behind modern features by a year or more [07:51:58.0806] maybe in this case it's more that the browsers have been slow to implement than that Graal has been fast [07:52:00.0623] people are hungry for temporal [07:52:25.0399] Everybody is just asking for more time [08:42:08.0636] (ļ¾‰ā—•ćƒ®ā—•)ļ¾‰*:惻ļ¾Ÿāœ§ https://tc39.es/ecma404/ [08:44:56.0512] glorious [08:47:47.0010] I will mourn this proposal. It was a good proposal. I sometimes have a need for it myself. But I will not champion this proposal. [08:48:07.0320] same [08:48:28.0835] though I've been kind of trying to imagine a way to do it without new syntax [08:48:41.0787] I feel like it should be doable with a Generator.prototype method [08:48:48.0537] but haven't thought hard about it yet [08:51:15.0883] hax (HE Shi-Jun): any objection to withdrawing function.sent? if we're keeping it active, it'd be great to see it at the next plenary [08:52:57.0098] Regarding the option 3 on deferred re-exports, I'm worried by this behavior of throwing for optional re-exports when they are accessed if the module was not evaluated by other path. There are a couple of things I'm worried here: 1. The first point is that it will throw a runtime error only when namespace is accessed, and this can be caused by changes from library side, which will make adoption quite unsafe. I can see production code breaking because of this. 2. Second is the behavior of not throwing if it was loaded by other path, because it will insert some complexity to understand why some imports throws and others don't. This will require some analysis from dependency graph and make it hard to debug. [09:03:38.0355] It will end up creating race conditions. [09:21:08.0133] ljharb: I recall mentioning my plans regarding function.sent in the previous Stage 2 proposals review, but for some reason, I can't find the record in tc39 notes repo now. However, the idea at the time was to explore whether decorators could serve as a alternative solution in this problem space once decorators land and the function decorator proposal advances. Given the current status of the decorator-related proposals, I have no immediate plans to update function.sent. [09:21:40.0426] ah ok gotcha, i'd missed that update. are you ok with withdrawing it for now, and it can be restored in the future if decorators doesn't work out? [09:39:43.0780] ljharb: I found the record: https://github.com/tc39/notes/blob/59c6f56131851169e62051b7f292453e73cd0e92/meetings/2024-06/june-11.md?plain=1#L1037 . And I dont like to withdraw it, but perhaps downgrading to Stage 1 would be appropriate, as the specific form of the solution might no longer be a meta property, but rather another syntactic form or a decorator-based API. [10:03:38.0512] is there a link to the import sync slides? [10:06:10.0419] ljharb: I checked the notes and saw that the topic of withdrawal has already been discussed. Unfortunately, I wasn't present because my home network has been very unstable this week, and Matrix has been intermittently disconnected as well. Iā€™m afraid I wonā€™t be able to join the video conference for this afternoonā€™s meeting eitherā€”Iā€™ll only be able to follow via the notes. However, if itā€™s convenient, please help clarify during the meeting that this proposal was actually updated in 2022 (though the last presented time wasnā€™t updated on the tc39/proposals page), and it was also presented during the 2024 proposal review, so it isnā€™t a case of ā€œno activity in over a decade.ā€ šŸ˜‚ [10:13:42.0670] `import.sync` feels a lot like the "synchronously unwrap a promise" proposals which occasionally come up and which many people strongly object to, just specialized to a specific kind of promise (i.e., those which are returned by dynamic import) [10:13:58.0411] it is not totally clear to me what rule justifies allowing one but not the other [10:17:05.0624] does `import.meta` work in scripts? [10:17:16.0364] no, they weren't imported [10:17:28.0853] what's it do? [10:17:33.0497] syntax error iirc [10:18:06.0094] my position isn't some arbitrary "all import.foo must work in Scripts" tbc, it's "we should bend over backwards to avoid adding something to the language that doesn't work in all supported parse goals" [10:18:22.0644] ah, you're right [10:18:58.0818] bakkot: is not unwrapping a promise, it's synchronously executing a module that has its source text synchronously available for whatever reason [10:19:18.0516] import defer detects deadlocks and throws, this could reuse the same infrastructure [10:30:26.0364] The example I mentioned: ```js import { didRunPromiseQueue } from "./async-check.js"; import { x } from "./tla.js"; console.log(x, didRunPromiseQueue); ``` ```js // async-check.js let didRunPromiseQueue = false; Promise.resolve().then(() => didRunPromiseQueue = true); ``` ```js // tla.js await null; export const x = 1; ``` If `tla.js` was already evaluated, it will synchronously log `x` synchronously right after running `async-check.js`, without introducing an artificial await. [10:31:04.0658] While if `tla.js` still needs to be evaluated, it will only log asynchronously (after `didRunPromiseQueue` becomes true) [10:40:54.0025] Would import.sync cause regular import * from to also become sync? If import.sync was to bevome an equivalent of require(esm) in node.js it would be the current behavior [10:42:03.0805] I'd appreciate it if someone could tag me out as a notetaker after this item [10:42:04.0351] What does it mean for `import * from` to be sync? [10:43:03.0058] I'm not sure. Let's consider that part of the question [10:47:52.0996] nit: we clearly wouldn't want to ToIntegerOrInfinity the limit because that converts non-numbers using ToNumber, which goes against our normative convention [10:48:22.0161] also that's a completely unnecessary level of detail for a proposal going for stage 1 (and even 2) [10:52:01.0247] I recommend explicitly keeping defining what stack frames are outside of the proposal scope [10:52:18.0297] But what exact validation we do on the number yes no need to worry about that now [10:54:29.0445] Hermes (the engine behind React Native) is also emulating a subset of the non-standard Error stack mechanics from V8 [10:56:28.0691] I don't understand MM's comment. This proposal is going for Stage 1 before the next proposal is presented. If the comments apply to both, shouldn't we hear them now? [10:59:15.0232] Maybe the limit of 0 should not be allowed [10:59:23.0377] So you always have some idea of where to start looking [11:17:25.0478] another related proposal: https://github.com/tc39/proposal-function-implementation-hiding [11:24:23.0461] TIL that DOMException lacks a cause [11:24:33.0261] that should be merged [11:26:23.0290] * that should really be merged [11:26:25.0478] https://github.com/whatwg/webidl/pull/1179 was blocked due to difference on the property on the error prototype or an error instance [11:26:34.0132] ljharb: it does not inherit from Error eitherā€¦ https://webidl.spec.whatwg.org/#idl-DOMException [11:26:49.0583] oof, i guess it has the slot but doesn't inherit from it [11:27:06.0065] The entire existence of DOMException is a wart in the platform :( [11:27:11.0217] its prototype is Error.prototype: https://webidl.spec.whatwg.org/#js-exceptions [11:27:16.0254] it just can't be represented in WebIDL [11:28:03.0005] `new DOMException() instanceof Error` checks out [11:28:16.0207] Andreu Botella: not in the browser implementation at leastā€¦ `Object.getPrototypeOf(DOMException) === Function.prototype`ā€¦ [11:28:37.0270] that's still ES5-style inheritance tho, just not `class`-style [11:28:44.0788] (sounds like web idl is a wart too, if it can't represent the web's programming language properly) [11:28:54.0617] * Andreu Botella: not in the browser implementation at leastā€¦ `Object.getPrototypeOf(DOMException) === Function.prototype`ā€¦ (edit: same in Node) [11:29:01.0069] so i guess DOMExceptions inherit from Error.prototype, but the DOMException constructor doesn't inherit from Error [11:29:13.0998] would it break anything to make it do so? [11:30:05.0687] Oooh, that's true, `Object.getPrototypeOf(DOMException.prototype) === Error.prototype`. How weird. [11:31:15.0937] The question is not just whether it would actually break anything, but also whether people can be convinced to checkā€¦ [11:33:29.0192] Turns out there is an issue already: https://github.com/whatwg/webidl/issues/1107 [11:36:51.0436] wait so `Error.captureStackTrace(x)` exists so you don't have to `x.stack = new Error().stack`? [11:36:53.0578] * wait so `Error.captureStackTrace(x)` only exists so you don't have to `x.stack = new Error().stack`? [11:38:12.0808] * wait so `Error.captureStackTrace(x)` only exists so users didn't have to do `x.stack = new Error().stack`? [11:40:13.0823] Yeah that is pretty ...weird [11:40:58.0736] ljharb: Here's the background: https://github.com/tc39/proposal-error-capturestacktrace [11:48:27.0933] ljharb: Specifically what needs to be updated w.r.t. GitHub teams? [11:49:01.0371] look over the list of members, and make sure everyone on the list is still employed at your company and still wants to participate; and that nobody who wants to participate is missing [11:51:13.0585] Are you talking about https://github.com/orgs/tc39/people or https://github.com/tc39/notes/blob/main/delegates.txt or something else? [11:51:49.0038] https://github.com/orgs/tc39/teams/delegates/teams i think [11:52:31.0222] Gotcha, thanks! [12:08:26.0880] sorry yes, the link andreu provided :-) thank you! [12:43:49.0996] who was helping with notes during the second session aside from PFC ? [13:02:21.0718] i helped at various times, but not continuously [13:14:13.0839] i'm confused, when did import.sync get stage 2? [13:14:20.0923] did i zone out and miss consensus on it? [13:17:15.0173] * did i zone out and miss consensus on it? i'd made it pretty clear i had a potentially blocking concern; did that get resolved? [13:26:50.0229] Ben Allen, and Caio Lima took over from me when I rotated out [14:25:56.0242] Thank you, everyone, for your summaries and conclusions so far. Right now, I am still looking for the following: - bakkot just a very brief summary of the 262 update - chipmorningstar I wrote a one-sentence summary, please review and edit if needed - Chris de Almeida summary and/or conclusion for Withdrawing Intl.UnitFormat - guybedford Import Sync for Stage 2 slides were not linked in the agenda, also need summary of presentation/conversation and to record any decisions or conclusions - Ruben Error option limit & Error option framesAbove are both missing slides, summaries, and conclusions 2026-01-21 [07:16:57.0366] my takeaway from this poll is not "we need a bunch more syntax for accessors" [07:18:22.0839] Oh damn I missed the beginning of plenary, thank you for writing a message here [07:20:29.0232] Is there a link to the slides? [07:20:41.0677] reminder to note-takers that if the captioner is inserting newlines, they don't have to worry about those. I'll take care of them at conversion time. [07:22:06.0196] proposal repo, it's html [07:22:12.0635] https://github.com/LeaVerou/proposal-composable-accessors [07:22:34.0826] `slides` dir [07:22:45.0466] Thank you [07:25:23.0818] I am confused about what this "internal property" is that is not the existing `accessor` property [07:27:22.0979] Maybe this proposal is pointing to a need to split off accessor from the decorators proposal so that it's not blocked on them? [07:28:12.0374] `accessor` is sort of split off. It was originally introduced in Grouped and Auto-Accessors and brought over to decorators to meet implementor requirements [07:31:01.0501] I think I would prefer for these things to be reified as accessors and not directly visible in descriptors, to avoid making descriptors being more complicated [07:31:10.0167] * I think I would prefer for these things to be reified as accessors and not directly visible in descriptors, to avoid making descriptors being more complex [07:54:48.0632] What's the time box? I noticed we are almost at the hour, and my reply is low priority so I can drop it if needed [07:54:58.0577] 1 hour [07:59:33.0001] nicolo-ribaudo: Which syntax were you talking about the one on the slide now with the decorator? [07:59:59.0691] The one with the validate keyword [08:00:04.0604] Or the `class Foo { accessor x = 2; }` syntax? [08:00:54.0501] I meant that `class Foo { validate x(val) { ... } }` looks a lot like `class Foo { set x(val) { ... } }`, so I'd expect similar performance [08:01:16.0684] I'd also expect similar perf with the decorator example, since I'm literally seeing a function attached to the property [08:01:35.0226] I would have less of that expectaton for a plain `accessor x = 2`, but I guess most times you'd want to decorate that anyway [08:02:06.0910] I wonder if `accessor x = 2` is more optimizable though, since there is no user code running there even if it's a get/set pair [08:02:26.0091] The motivation for this, as I understand it anyway, is to use it everywhere [08:02:48.0023] * The motivation for this, as I understand it anyway, is to use it everywhere for reflection/metaprogramming [08:03:55.0464] Which is the reason I mentioned hiding the cost of the call. Not sure about others [08:04:09.0575] Ok I think I was mostly focusing on the second use case, I'm not sure I agree with the first one [08:04:13.0584] only for the use cases where the instance shape is needed from outside [08:04:44.0527] For this could we have a bult-in `@public` decorator, with the decorators metadata proposal? [08:04:50.0800] That marks it as "public" in the metadata [08:06:02.0097] true - and a class decorator could do it all in one [08:06:04.0881] Are people realistically going to add the mental overhead of figuring that out though? My assumption would be that codebases that don't particularly care about performance would just apply it everywhere [08:07:00.0599] sure but if they donā€™t care about performance then it doesnā€™t matter there, right? [08:07:49.0468] _we_ care about performance even if they don't [08:08:02.0400] "people are not thinking about what things make their code slow" and "people want their code to be fast" unfortunately have a large intersection [08:08:20.0693] we should design the language such that even people who don't care about performance end up on the happy (= reasonably performant) path [08:09:08.0765] fair [08:20:21.0576] New features aren't necessarily free, especially when we implement whole new capabilities to the language. [08:27:02.0675] I'm looking at my accessors usage, and they are (numbers are not measured): - 75% "property forwarding" - 15% lazy initial computation - 10% validation - 5% other [08:27:27.0951] The % symbol obviously means " / 105" [08:27:40.0950] For point 1 in the problem statement, would we ever consider adding something like `Function.getInstanceFieldNames(ctor)`? [08:28:14.0899] Some feedback that was shared at last plenary is that class fields should behave similarly to properties defined in the constructor [08:28:28.0122] You could add a proxy trap for it like `apply`/`construct` [08:29:17.0816] I don't necessarily agree with that position, though I do agree you shouldn't be able to just grab them via `getOwnPropertyDescriptors`. [08:30:01.0231] A `getInstanceFieldNames` would be simpler than a `@Public` decorator that uses `Symbol.metadata` to do the same thing [08:34:39.0583] Test message; please ignore [08:36:45.0985] (Matrix seems to have glitched and kicked me out for a while) [08:44:52.0447] If Decorators were at stage 4, the composable accessors piece would easily be a public API proposal a.la iterator helpers or similar, which would likely be easier to discuss and advance [08:45:04.0595] * If Decorators were at stage 4, the composable accessors piece would easily be a public API proposal a la iterator helpers or similar, which would likely be easier to discuss and advance [08:48:45.0381] That said, most of the composition pieces presented or in the explainer could be implemented in userland decorators first before standardizing [08:49:50.0974] The built-in decorators that can't be implemented in userland that I'm mostly interested in are not these composable decorators, unfortunately. [08:49:59.0700] * The built-in decorators that can't be implemented in userland that I'm mostly interested in are not these composable decorators, however. [08:57:29.0408] Let's continue with this please, to keep context [09:02:17.0053] overall the transcription was pretty good but there was a writer switchover at 11:00 while @rbuckton:matrix.org was speaking and that paragraph got completely mangled [09:02:30.0008] you'll know it when you see it [09:02:50.0281] @rbuckton:matrix.org do your best to fix it up [09:05:33.0903] Yeah I have similar usage, and I think lazy init is especially hard to expresss even with current decorator proposal. [09:16:56.0688] But if u consider validate/sideeffect use cases, it actually don't require to be use accessor but only some observer ability. Force it to become accessor have performance result (To be clear, I don't care much about perf issue, but I always hear some delegates attack some proposals use this reason). [09:18:49.0024] I think lea already suggest similar proposal in last meeting and be refused? Or maybe I misunderstand it? [09:20:42.0177] Oooh yes, lazy init is another big one. [09:21:47.0389] While most things can be done with decorators, I suspect alias accessors likely would need _some_ syntax if we want to support private members. And property chains would be a lot elegant as an actual language construct (like in `delete`) as opposed to e.g. an array of property names. [09:21:48.0529] To be honest, my question is, whether decorator could really go to stage 4, considering the position of browser vendors? (If there was any news on that, pls tell me...) [09:23:00.0018] Another advantage of the decorators direction is that it's a lower-cost way to prototype and test the waters. E.g. if this ends up being used tremendously much, we could introduce a syntax-level solution *down the line*. For this alone, I'm actually now myself in favor of the decorators direction [09:23:31.0201] * While most things can be done with decorators, I suspect alias accessors likely would need _some_ syntax if we want to support private members. And property chains would be a lot more elegant as an actual language construct (like in `delete`) as opposed to e.g. an array of property names. [09:23:40.0720] `@lazy accessor x = lazy.of(() => init)` // example provided by Jack Works Full of syntax noise šŸ™ƒ [09:25:00.0630] Which paragraph? [09:25:06.0935] hax (HE Shi-Jun): it doesn't need to, it could be `let { lazy } = SomeObject` and then just `@lazy(init) accessor x` . I'm less worried about O(1) DX issues, it's the O(N) (per property) DX issues that are the main problem [09:28:28.0271] I'm afraid @lazy(init) does not work if u want to access something on the instance in initializer? [09:31:24.0922] `@lazy accessor x = () => init`? [09:36:12.0976] I think u can't make it type safe in ts. Though it maybe the fault of TS šŸ˜† [09:38:07.0655] Anyway, I really feel lazy init is too common and should have better DX. If u check other morden langauge, in Kotlin u write `var x by lazy { ... }`, in swift u write `lazy var x = { ... }()`, in cala u write `lazy val x = { ... }`. It's shame that we can't provide js programmers a [09:38:20.0230] > <@rbuckton:matrix.org> A `getInstanceFieldNames` would be simpler than a `@Public` decorator that uses `Symbol.metadata` to do the same thing it is critically important that it be opt in and not available by default. [09:38:25.0869] * Anyway, I really feel lazy init is too common and should have better DX. If u check other morden langauge, in Kotlin u write `var x by lazy { ... }`, in swift u write `lazy var x = { ... }()`, in Scala u write `lazy val x = { ... }`. It's shame that we can't provide js programmers a good solution [09:39:17.0015] hax (HE Shi-Jun): A way I often implement lazy accessors myself is to set a symbol property in the getter and just return that if set. I believe that can totally be done with decorators, right? [09:39:38.0922] That's my point about well-known builtin decorators - TypeScript could learn the type calculus behind them. [09:44:26.0249] Obviously 10 js developers can have 10 different way to do it. If u ask GPT it may teach u write `class C { get val() { Object.defineProperty(this, 'val', { value: expensive(), writable: false }); return this.val; } }` [09:45:26.0994] Yes, but if it's a built-in decorator that's not an issue [09:46:32.0683] I'm very curious how engine vendors see such re-defining prop descriptor which LLM like to encourage but they refused in decorator proposal. [09:52:55.0054] Is there any specific reason that it should be opt in? And what opt-in mechnism will u like to see? [10:00:40.0377] > <@haxjs:matrix.org> `@lazy accessor x = lazy.of(() => init)` // example provided by Jack Works > Full of syntax noise šŸ™ƒ (my version is to let TypeScript happy, otherwise it can be @lazy accessor x = () => init [10:01:00.0349] It's certainly feasible for TS to implement. It's on the backlog and I planned to work on it at some point. [10:01:31.0028] * It's certainly feasible for TS to implement. It's on the backlog and I had planned to work on it at some point. [10:02:31.0279] Put those that didn't help yet during this meeting on random.org and pick two! [10:03:13.0663] * Put those that didn't help yet during this meeting on random.org/lists and pick two! [10:03:14.0316] yoooo it's Julie captioning [10:03:16.0789] she's really good [10:05:40.0321] we should do this every time ā€“ maybe excluding first-timers [10:06:00.0632] because anything that's introspectable is part of the public API and a breaking change if altered. i don't care what the mechanism is, it just has to be solely up to the class author. [10:06:43.0520] * because anything that's introspectable is part of the public API and a breaking change if altered. i don't care what the mechanism is, it just has to be solely up to the class author. separately, public class fields are sugar for statements in the constructor, and statements inside function bodies are *never* introspectable in the language, nor should they be. [10:06:58.0439] the only reason the chairs haven't done that in the past (at https://takingnotes.rocks) is that there are some people who can't for personal reasons and it's not fair to put them on the spot [10:07:28.0181] Isn't that why we have private fields? public fields are introspectable on an instance, just not from a constructor. IMO, you shouldn't need to construct an instance for that introspection. [10:07:50.0041] I mean the chairs could do the extraction privately, and those people can privately ask them in advance to be excluded [10:08:12.0087] nope, they're not. public _properties_ on the resulting instance are, certainly. but the existence of a field does not guarantee it will end up as a property, nor will the list of fields be exhaustive. [10:08:23.0732] * nope, they're not. public _properties_ on the resulting instance are, certainly. but the existence of a field does not guarantee it will end up as a property, nor will the list of fields be exhaustive (meaning there could eventually be properties not in that list). [10:10:26.0432] * nope, they're not. public _properties_ on the resulting instance are, certainly. but the existence of a field does not guarantee it will end up as a property, nor will the list of fields be exhaustive (meaning there could eventually be properties not in that list). (remember any subclass can arbitrarily delete a property that a field created, for example) [10:10:46.0763] A field declaration will definitely guarantee its presence as a data property. They are always installed on an instance (barring use of `delete`, which is rarely a good idea). [10:11:06.0913] ok but the existence of that caveat means that it's not a guarantee. [10:11:07.0207] But u already can use Object.getOwnPropertyNames() or other api or syntax to get the own properties... I don't see any difference here (except u can only get them via object not class). [10:11:17.0909] *of the instance*. you can't do that from a constructor alone. [10:11:37.0677] nor should you be able to, without the permission of the class author. [10:11:49.0869] You can `delete` methods and accessors as well [10:11:55.0265] indeed you can [10:12:04.0035] but that you can introspect on the class. [10:12:23.0254] overall, implicit reflection/introspection is a horrifically bad language "feature" and we should go out of our way to not introduce any additional cases of it. [10:12:46.0550] explicit/opt-in reflection is great though! i fully support an author's freedom to expose what they want. but it must be a choice. [10:13:01.0554] I strongly disagree with that sentiment. [10:13:03.0019] * explicit/opt-in reflection is great though! i fully support an author's freedom to expose what they want. but it must be a choice. (ideally it's an easy one, just explicit) [10:13:11.0060] that is unsurprising :-) [10:13:57.0496] but suffice to say there's no consensus to add any new implicit/default introspection mechanisms, though. [10:14:18.0669] IMO, it's a terrible idea to use `delete` on any member of a class. [10:14:22.0823] oh i agree [10:14:42.0761] lots of things in any language are a terrible idea. but they still exist. [10:14:54.0364] And you certainly won't be able to `delete` fields from `struct` instances. [10:15:04.0833] which is great [10:15:15.0991] ljharb: " public class fields are sugar for statements in the constructor, and ..." --- No they are not sugar. No one write "Object.defineOwnProperty(this, "name", ...) in constructor. šŸ˜‚ [10:15:26.0941] that nobody writes it is *why* it's sugar [10:15:39.0399] and prior to the [[Define]] decision it was sugar for the thing *everyone* writes, which is `this.foo = 'bar'` [10:17:27.0074] Ok. I mean, no one want to [[Define]] before this feature, so it's really weird to me to see it as sugar. I always see sugar should not introduce uncommon semantic. [10:18:24.0456] Oh well I can't speak sorry. It's for Trusted Types, it is being implemented [10:19:16.0106] It's not ready for stage 4 yet though, according to my colleague working on it [10:21:16.0738] ljharb: On the other side, why it should be opt-in but not opt-out?? For example, in TS you use `private x` which seems match the case you want (by default it's public api, but private means it's not public) [10:26:03.0443] Can uhh, I convince one of the chairs to add the 3.md agenda so I can add Atomics.pause to stage 4 before I forget... :) [10:26:50.0102] ljharb: To be clear, I think opt-in is ok, I even like everything is not public by default, but JS class already make methods public, it's really weird that only fields need to opt-in for public. [10:29:38.0205] TS's `private` is bad for a ton of reasons so i don't think it should be used as an argument [10:30:02.0629] because a "field" isn't a first-class thing. a field is just instructions to set up a property - which is indeed public by default. [10:30:07.0988] * because a "field" isn't a first-class thing. a field is just instructions to set up a property - which is indeed public by default. iow, it's sugar. [10:30:54.0100] yes, i will do that now [10:34:45.0459] I might be interested in co-championing ljharb: but will need a comprehensive intro [10:39:36.0464] I am not sure what "first-class" means. In my opinion, the whole point of fields proposal is to make it declarative and get the "first-class" support in the language. [10:43:25.0108] @erights Mark Miller (Agoric) MM: I have a counter for last match, left context and right context. It is surprisingly not that small: https://chromestatus.com/metrics/feature/timeline/popularity/5641#V8RegExpStaticPropertiesWithLastMatch [10:44:17.0257] We would also have counters for the rest (and most probably more common) of the static properties, but it seems there is a feature id collision so that counter is broken... [10:45:20.0779] it means "a thing you can pass around". variables are not first-class; objects are, for example. [10:45:38.0880] things that aren't first-class aren't reified "things" [10:45:59.0465] k, now done [10:47:08.0413] * We would also have counters for the rest (and most probably more common) of the static regexp properties, but it seems there is a feature id collision so that counter is broken... [10:48:12.0272] So why some class members (methods and accessors) are first-class, others (fields) are not? very inconsistent. [10:48:49.0990] Interesting, I can see usage of `.lastMatch`/leftContext/rightContext on the xiaomi website but not in the other two of the top 3 [10:49:34.0960] that's not a consistency that i'd expect anyone to expect, but sure, it's inconsistent. the "why" doesn't change that it's the way it is. [10:50:05.0356] * that's not a consistency that i'd expect anyone to expect, but sure, it's inconsistent. the "why" doesn't change that it's the way it is. classes are declarative - they're instructions. that some pieces of them turn into first-class things and some don't is just based on the semantic of the instructions. [10:51:10.0078] * that's not a consistency that i'd expect anyone to expect, but sure, it's inconsistent. the "why" doesn't change that it's the way it is. classes are declarative - they're instructions. that some pieces of them turn into first-class things and some don't is just based on the semantic of the instructions. static blocks aren't first-class either, and neither are private fields. [10:51:45.0316] And the fourth one is coming from a twitter sdk (https://github.com/twitter/twitter-text) [10:52:52.0845] * And the fourth one is coming from a twitter sdk (https://github.com/twitter/twitter-text): https://github.com/twitter/twitter-text/blob/30e2430d90cff3b46393ea54caf511441983c260/js/src/extractUrlsWithIndices.js#L70 [10:54:37.0596] Which is unmaintained but has 50k downloads/week [10:58:22.0396] I'm back, sorry for the interruption [11:00:27.0427] I found that the combined counter is probably correctly working: https://webstatus.dev/features/regexp-static-properties?q=RegExp . 7% :(( [11:01:05.0507] Unfortunately not only that library has no recent activity, but every single person that worked on it seems to not be working at that company anymore [11:02:40.0594] Built-in decorators (+ function decorators) would allow something like C#'s `StackTraceHiddenAttribute` https://learn.microsoft.com/en-us/dotnet/api/system.diagnostics.stacktracehiddenattribute?view=net-10.0 [11:05:12.0661] Yeah, but I think the fact that the other static properties are used even more is worse. Unless we split the proposal to only remove the little used ones. [11:05:49.0226] I have to drop, tty all next time [11:06:31.0460] Looking at that file, we can work on a proposal to remove `RegExp.$6`! šŸ˜› [11:09:41.0787] Have no idea why xiaomi website use such legacy feature, I will try to find and ask the guys in xiaomi šŸ¤Ø [11:09:59.0254] thank you for hosting this session Peter! [11:10:44.0713] I'm a Matrix n00b, is there a place where these different spaces are listed? [11:11:23.0728] if only there were...some kind of guide... like a matrix guide.. with information on matrix [11:11:38.0849] https://github.com/tc39/how-we-work/blob/main/matrix-guide.md [11:11:59.0946] https://matrix.to/#/#tc39-space:matrix.org [11:12:15.0113] ā˜ļø TC39 space [11:22:54.0435] what was this in response to? isTemplateObject? [11:26:28.0237] my pleasure! [11:26:55.0932] For simple field wrapping to support public read/private write, I'd argue for this feature in grouped accessors: ```js class C { accessor x { get; #set; } // paired public getter/private setter m() { this.x; // ok this.#x = 1; // ok } } const c = new C(); c.x; // ok // can't use c.#x ``` For more complex cases, `alias` is maybe interesting? [11:27:24.0891] * For simple field wrapping to support public read/private write, I'd argue for this feature proposed in grouped accessors: ```js class C { accessor x { get; #set; } // paired public getter/private setter m() { this.x; // ok this.#x = 1; // ok } } const c = new C(); c.x; // ok // can't use c.#x ``` For more complex cases, `alias` is maybe interesting? [11:27:49.0096] * For simple field wrapping to support public read/private write, I'd argue for this feature proposed in grouped accessors: ```js class C { accessor x { get; #set; } // paired public getter/private setter m() { this.x; // ok this.#x = 1; // ok } } const c = new C(); c.x; // ok // can't use c.#x ``` For more complex cases (like subproperty access), `alias` is maybe interesting? [11:35:00.0953] I *have* been tempted to propose something like C#'s "expression bodied methods", which use `=>`, i.e.: ```csharp // C# class C { int _x = 0; public x => _x; // public getter with shorthand expression body public y { get => _x; set => _x = value; } } ``` Which could could cut down on boilerplate for the `alias` case: ```js class C { #x; get x => this.#x.value; accessor y { get => this.#x.value; set => this.#x.value = value; } } // vs. class C { #x; get x() { return this.#x.value; accessor y { get () { return this.#x.value; } set (value) { this.#x.value = value; } } } ``` [11:35:14.0738] nicolo-ribaudo: How many lines of code did your numbers come from BTW? [11:35:24.0510] * I _have_ been tempted to propose something like C#'s "expression bodied methods", which use `=>`, i.e.: ```csharp // C# class C { int _x = 0; public int x => _x; // public getter with shorthand expression body public int y { get => _x; set => _x = value; } } ``` Which could could cut down on boilerplate for the `alias` case: ```js class C { #x; get x => this.#x.value; accessor y { get => this.#x.value; set => this.#x.value = value; } } // vs. class C { #x; get x() { return this.#x.value; accessor y { get () { return this.#x.value; } set (value) { this.#x.value = value; } } } ``` [11:38:20.0796] Yes [11:38:31.0046] Around 200k in a few repos, but I didn't _measure_ as I said above. I scrolled to search results and eyeballed it. [11:38:55.0444] All property forwarding was about getters btw, setters are much rarer [11:39:27.0081] One codebase uses typescript, the others do not. Validation is higher in the one that does not use TS [11:39:35.0307] * One codebase uses typescript, the others do not. Validation is higher in the ones that do not use TS [11:40:07.0671] * Around 200k in a few repos, but I didn't _measure_ as I said above. I scrolled through search results and eyeballed it. [11:41:00.0469] I have some appreciation for the feature and have been looking at ASTs of tagged templates recently [11:44:44.0649] This seems like a good use case for expression-bodied getters, IMO. [11:46:00.0524] * I _have_ been tempted to propose something like C#'s "expression bodied methods", which use `=>`, i.e.: ```csharp // C# class C { int _x = 0; public int x => _x; // public getter with shorthand expression body public int y { get => _x; set => _x = value; } } ``` Which could could cut down on boilerplate for the `alias` case: ```js class C { #x = { value: 0 }; // for something more complex get x => this.#x.value; accessor y { get => this.#x.value; set => this.#x.value = value; } } // vs. class C { #x; get x() { return this.#x.value; accessor y { get () { return this.#x.value; } set (value) { this.#x.value = value; } } } ``` [11:46:34.0266] * This seems like a good use case for expression-bodied getters, IMO. i.e., `get x => this.#x` [11:46:58.0460] is there a proposal for this? [11:47:31.0381] * is there a proposal for this? (edit: nvm, just saw the earlier messages!) [11:48:11.0343] Couldn't aliases/forwarding be done with a decorated accessor? It would be a little wasteful of the unused underlying accessor, but there's any number of ways you could write ``` @alias({get: () => this.foo.bar, set: (x) => this.foo.bar = x}) accessor bar; ``` or ``` @alias({owner: this.#foo, prop: 'bar'}) // obviously order matters here, could be lazy () => this.#foo ``` And if you wanted to define a bunch of them, you could compose your own decorator that saved some boilerplate ``` @myalias('foo') accessor foo; @myalias('bar') accessor bar; ``` where `@myalias` could effectively "close over" any `this.#owner`. [11:48:21.0626] Not yet. I'd considered it when I proposed grouped/auto-accessors but since that proposal was blocked from Stage 2 until decorators hit Stage 4, I held off. [11:49:00.0423] Separating the object from the prop like that seems even more awkward than the status quo [11:49:18.0252] though this makes me wonder if instead of alias accessors we need a syntax-level feature for referencing property chains [11:49:26.0688] that certainly isn't very concise, imo. [11:49:29.0165] then regular decorators could do it [11:49:37.0945] plus, lots of other use cases outside accessors [11:50:45.0765] C# has `Expression` that's used in LINQ, but that requires reifying a subset of the AST [11:50:46.0807] E.g. filtering, various helpers (e.g. lodash's get/set) [11:51:58.0341] Well, not quite the same. `Expression` is used by an expression rewriter to turn C# expression syntax into other languages like SQL to convert a LINQ pattern into a database query. [11:52:14.0343] basically a type of literal that returns some kind of `PropertyReference` object [11:53:00.0397] which could have methods to get/set/etc the property chain for a given object, perhaps. (Just brainstorming out loud here [11:53:02.0968] I have a proposal for reified references that I have yet to bring to committee (https://github.com/rbuckton/proposal-refs) that would do that. [11:53:05.0317] * which could have methods to get/set/etc the property chain for a given object, perhaps (Just brainstorming out loud here) [11:54:35.0976] I'll need to look at this more closely later, I tried skimming but it needs more time than that [11:54:53.0037] * Thanks! I'll need to look at this more closely later, I tried skimming but it needs more time than that [11:55:39.0635] It could be useful to include examples of property chains and privates (if it covers them too) [11:57:19.0390] It does. [11:58:01.0396] Though "property chain" isn't the right term. It captures the Reference resulting from the property chain. [11:58:27.0193] FWIW (probably not much), my Closure Compile-addled brain tends to go to something along the lines of `{foo: {bar: true}}` to represent a property chain... but that's more due to limitations with how our optimizer handles property rewriting. I don't know if `{#foo: {bar: true}}` could work (assuming privates in object literals landed), but it's certainly neither pretty nor performant and probably a non-starter. [11:59:25.0746] * FWIW (probably not much), my Closure Compile-addled brain tends to go to something along the lines of `{foo: {bar: true}}` to represent a property chain... but that's more due to limitations with how our optimizer handles property renaming. I don't know if `{#foo: {bar: true}}` could work (assuming privates in object literals landed), but it's certainly neither pretty nor performant and probably a non-starter. [12:02:03.0918] But at the end of the day, what we're talking about is a pair of functions: {get: (T) => V, set: (T, V) => void}, so I think the question is whether there could be a reasonably ergonomic way to write that object. [12:05:52.0903] The idea with `ref` is that a `ref`-expression captures a _Reference_ to an expression and reifies it: ```js let x = 0; let rx = ref x; // ref expression rx.value; // 0 rx.value = 1; x; // 1 ``` While a `ref`-declaration _dereferences_ that reference as if it were the roughly the same binding: ```js let x = 0; let rx = ref x; // ref expression takes reference let ref y = rx; // ref declaration dereferences y; // 0 y = 1; x; // 1 ``` [12:07:20.0239] There's no concept of a `ref` declaration for a field or accessor however, so while you could _take_ a ref to a property, you can't necessarily install the ref as a property (at least, not yet) [12:13:03.0353] There is a suggestion for `ref` properties, though (https://github.com/rbuckton/proposal-refs/issues/12) [12:13:36.0502] I really should just present this and at least get stage 1, since one way or another it's worth discussing. [12:18:29.0913] That seems to be the desirable behavior? Are there any cases where that would break expectation? [12:19:51.0882] Oof, that's quite a problem. Do you think it's fixable? [12:19:53.0508] Yes, I'm just saying "property chain" is the wrong terminology. to me, "property chain" implies that if some part of the chain is replaced, re-evaluating would produce a different result. [12:20:08.0623] See https://github.com/rbuckton/proposal-refs/issues/12 [12:21:23.0972] For that to work for the intended use cases, it basically needs to re-evaluate the chain itself, kind of like a very very limited eval almost. Which seems like the case here? (aside from the issue above) [12:25:05.0252] For the intended use case, only the Reference at the end matters. Consider: ```js let x = { y: { z: 0 } }; let rz = ref x.y.z; ``` `rz.value` will always point to the Reference for `y.z` at the time the `ref` was taken even if you change `x.y` to something else. This is no different from ``` let y = x.y; let rz = ref y.z; ``` the intermediates don't matter, only the trailing Reference [12:25:45.0661] Yeah, Iā€™ve always liked the refs proposal. Just one thing Iā€™m a bit concerned about is the syntax `ref x` ā€” for example, the syntactic ambiguity of `ref (x)`, and also that `ref a.b.c` could easily be misunderstood as re-evaluating the entire chain every time. Maybe a syntax like `x.&` could be an alternative ā€” it has better ergonomics (in my opinion) and can express capabilities more clearly (for example, `x.&r` could mean only expose read capability). Anyway, syntax is just bikeshed issue. [12:26:31.0709] `ref` is a placeholder. It could easily be `&`. I just was veering away from C-like addresses and pointers. [12:27:11.0128] However, `ref x.y.z` works with a Reference the same way `delete x.y.z` does and is consistent with JS on the whole. [12:27:32.0175] `x.&r` looks highly confusing to me [12:28:11.0845] `ref` (as expression and as declaration) also has prior art in C# [12:28:24.0095] ah, I forgot `delete x.y.z`, I suppose no one use `delete` in most morden JS/TS šŸ˜‚ [12:29:03.0630] I would not want `&` or `ref` to come in the middle of a property access. It could get lost in a deeply nested chain. [12:29:05.0145] For alias accessors, the entire chain matters. E.g. suppose I have ```js class C { alias foo = #foo.value } ``` If I replace `#foo`, I don't want `this.foo` to still be pointing to the old value (and it's the same for deeply nested objects) [12:29:29.0623] Also, there are use cases that need access to the intermediate properties (e.g. lodash's get/set that I mentioned earlier) [12:29:55.0421] If that's the case, then `ref` is not what you want. But I also wouldn't use `=` as that implies an immediate assignment [12:30:19.0567] Yes, that exact issue was an open question in the explainer (that `=` is probably not appropriate) [12:30:33.0155] You could just as easily use `as` or `for` or `->`, etc. [12:30:56.0245] But also, after this discussion I'm starting to think that this should _also_ be done with decorators, and we should instead introduce a syntax primitive to make it nice (even if it's not `ref`) [12:31:26.0571] There was another proposal in the previous meeting that also needed a way to reference property chains, I forget which one, and there was no good story [12:31:30.0520] It's a interesting question, let me check other language, eg. Kotlin code `var x by a::b::c` Not sure which behavior it adopt. [12:32:26.0316] * There was another proposal in the previous meeting that also needed a way to reference property chains, I forget which one, and there was no good story (perhaps the deep diffing one?) [12:34:20.0258] The main challenge I see is not syntax of the literal, it's how to handle privates. For it cover forwarding use cases, privates are MVP, but we have no way to represent them in a ComputedPropertyName [12:34:27.0847] * The main challenge I see is not syntax of the literal, it's how to handle privates. For it to cover forwarding use cases, privates are MVP, but we have no way to represent them in a ComputedPropertyName [12:37:00.0626] Perhaps it could end up behaving like an array of objects to represent the chain, then privates could have e.g. `private: true`, and if you try to construct a literal with a private property that doesn't exist in your current context the construction itself would throw. [12:37:38.0026] * Perhaps it could end up behaving like an array of objects (once created) to represent the chain, then privates could have e.g. `private: true`, and if you try to construct a literal with a private property that doesn't exist in your current context the construction itself would throw. [12:38:18.0525] Shouldn't that be a earlyerror? [12:38:50.0480] Yes, that's what I'm saying [12:39:48.0220] You could potentially do this with a decorator and `ref`: ```js class C { #x = { y: { z: 0 } }; @alias(_ => ref _.#x.y.z) accessor x; } ``` Where the get/set are replaced with an invocation of the callback that returns a `ref` you can read from or assign to [12:40:04.0256] e.g. ```js let foo = .a.#b.c.d; /* property chain literal */ ``` which could throw if your current context doesn't include `#b` (if it does but `a` doesn't have it that _could_ throw later) [12:42:58.0235] * e.g. ```js let foo = .a.#b.c.d; /* property chain literal */ ``` which could throw if your current context doesn't include `#b` (if it does but `a` doesn't have it that _could_ throw later) Especially since in a lot of these use cases, the "root" of the property is not fixed but the chain can be applied to a variety of root objects [12:43:14.0615] I think arrows and `ref` might be sufficient. `_ => _.a.#b.c.d` would generally work find as a deferred way to read a value, you just can't write to it. `_ => ref _.a.#b.c.d` would let you do both: ```js let foo = x => ref x.a.#b.c.d; let obj1 = ...; let obj2 = ...; foo(obj1).value; // read foo(obj1).value = ...; // write foo(obj2).value; // read foo(obj2).value = ...; // write ``` [12:43:19.0873] * e.g. ```js let foo = .a.#b.c.d; /* property chain literal */ ``` which could throw if your current context doesn't include `#b` (if it does but `a` doesn't have it that _could_ throw later) Especially since in a lot of these use cases, the "root" of the property is not fixed but the chain can be applied to a variety of root objects (e.g. in alias accessors there is an implicit `this`) [12:43:53.0934] Yes, that would work. I do find it awkward though. [12:44:37.0379] Also, there are use cases where you may want to *break* the chain [12:44:53.0794] E.g. "return the last non-null/undefined object" [12:46:38.0201] nicolo-ribaudo: I don't see PKA in this channel, but I was reachout out to Krzysztof Kotowicz about https://github.com/tc39/proposal-dynamic-import-host-adjustment and I think there was a transcription error somewhere since he's not actually mentioned _anywhere_ in that repo. It looks like it's entirely Mike Samuel (who _used_ to be at Google, but is no longer). [12:46:54.0771] * nicolo-ribaudo: I don't see PKA in this channel, but I was reaching out to Krzysztof Kotowicz about https://github.com/tc39/proposal-dynamic-import-host-adjustment and I think there was a transcription error somewhere since he's not actually mentioned _anywhere_ in that repo. It looks like it's entirely Mike Samuel (who _used_ to be at Google, but is no longer). [12:53:31.0075] Ok, kotlin behave same like ref proposal, the syntax is `var x by a.b::c` which is much clear the last part is the reference (a::b::c is invalid) [12:56:31.0767] I'd still rather not mix `&` or similar inside a property access. We already have `.` and `?.`, and have had proposals for other property-access-likes in the past. IMO that's too noisy. [12:59:25.0226] C, C++, Go, C#, and Rust (among others) use a prefix operand [13:13:07.0256] rbuckton: What about a leading `.` ? I have a hunch it would be ambiguous or break existing stuff in some cases, but I can't think of any offhand. It seems like it could be quite elegant if it worked [13:14:44.0103] * rbuckton: What about a leading `.` ? I have a hunch it would be ambiguous or break existing stuff in some cases, but I can't think of any offhand. It seems like it could be quite elegant if it worked. E.g. ```js class C { @alias (.#foo.value) accessor value; } ``` [13:56:48.0823] Maybe? At first glance it doesn't seem ambiguous, but I'm not 100% sure that's what I would use a leading `.` syntax for, if we had one. There's a lot of complexity being stuffed into that syntax. IMO, the upside of using `x => ref x.#foo.value` is that it depends on arrows, which are well known at this point, and `ref` has a lot more use cases outside of this narrow case, plus it clearly indicates what you have is a Reference. `.#foo.value` seems almost like partial application, except even that proposal doesn't magically handle References