| 03:30 | <ljharb> | rickbutton: is the records and Tuple monthly call still happening in 15.5 hours? |
| 03:34 | <devsnek> | rough if true |
| 08:54 | <robpalme> | can anyone contact Frank Tang - we want to see if Intl.Enum can be brought forwards to today |
| 09:01 | <wsdferdksl> | It's a good day when the notes document starts with "Yes, sir. Take it off." |
| 09:01 | <wsdferdksl> | (brought to you by autotranscribe) |
| 09:04 | <leobalter> | robpalme: the best person to contact Frank would be sffc, IMO |
| 09:06 | <michaelficarra> | typically, I would avoid normative changes with strictly editorial motivation, but I think this ends up with a nicer semantics |
| 09:08 | <michaelficarra> | oh I guess it was originally motivated by non-editorial reasons, which makes sense |
| 09:09 | <michaelficarra> | ystartsev: I also don't understand how iterator helpers are impacted |
| 09:10 | <ljharb> | littledan: it kind of sounds like your active mic is on your phone in your pocket |
| 09:11 | <ystartsev> | michaelficarra: the comment I got from the people involved was "this simplification looks good, we had to jump through similar hoops when implementing iterator helpers" |
| 09:11 | <littledan> | This is a very positive simplification |
| 09:11 | <littledan> | I want to note that we did discuss this path in the past |
| 09:11 | <littledan> | It created extra load for implentations and no one had a particular use for it |
| 09:11 | <ystartsev> | michaelficarra: i wasn't directly involve in the implementation but i can get further details |
| 09:11 | <littledan> | We decided to leave it in because engines thought it might be more intuitive for developers |
| 09:12 | <michaelficarra> | ystartsev: it's not a big deal, but I am curious |
| 09:12 | <littledan> | I don't think this is a very strong intuition though. I like the change. |
| 09:22 | <devsnek> | is this supposed to say who voted for what |
| 09:22 | <devsnek> | ystartsev: ^ |
| 09:22 | <ystartsev> | devsnek: as in, the list of names? |
| 09:22 | <devsnek> | yea |
| 09:22 | <ystartsev> | yes, that was requested in the reflector |
| 09:22 | <devsnek> | cool |
| 09:23 | <ljharb> | is daniel R on irc? |
| 09:23 | <ystartsev> | this appears to be contentious though, it would be good to have a direct conversation about it. i have no strong opinion |
| 09:23 | <devsnek> | i don't mind that much either |
| 09:23 | <devsnek> | just surprised me |
| 09:24 | <ljharb> | i'd be interested to hear an argument for anonymity on a non-binding temperature check; i like the names being shown tho |
| 09:24 | <ystartsev> | the argument is that people may not feel safe voting as they really feel, due to social pressure and their name being present |
| 09:25 | <ystartsev> | "voting" used here in a loose sense, "expressing their emotions through hieroglyphs" |
| 09:25 | <ljharb> | ah |
| 09:25 | <haxjs> | Again, I strongly feel we should roll back the stage ,because the plan of early stage said that if there is web comp issue, it will be withdrawn. |
| 09:27 | <akirose> | ljharb: he says "idk how to use IRC" |
| 09:29 | <ljharb> | akirose: happy to walk him through it during our local tuesday if he's interested :-p |
| 09:31 | <michaelficarra> | haxjs: I agree, that's a fair point |
| 09:32 | <ljharb> | why is it important that that was the original plan, if it's not the plan now? |
| 09:32 | <ljharb> | haxjs: do you mean you think this isn't useful at all if it can't help ObservableArray compat? |
| 09:32 | <haxjs> | if we don't rollback the stage, it means the communtiy do not have the chance to invole about the name or other things. |
| 09:33 | <ljharb> | what other things? |
| 09:33 | <ystartsev> | damn, that would have been such an improvement |
| 09:33 | <haxjs> | for example, new syntax or new method. |
| 09:34 | <ljharb> | shu: isn't "indifferent" the same as "abstain"? |
| 09:34 | <haxjs> | I feel new syntax could be a better choice in current situation. |
| 09:34 | <ljharb> | haxjs: as shu already commented, new syntax for this isn't something a number of us feel are warranted |
| 09:34 | <ystartsev> | haxjs: the benefit here would have been the unification of the html datastructures |
| 09:34 | <michaelficarra> | ljharb: lack of support is similar to opposition in this committee |
| 09:34 | <ystartsev> | its a huge pain point for devs |
| 09:34 | <ljharb> | michaelficarra: fair enough |
| 09:35 | <devsnek> | itemAt makes me wince |
| 09:35 | <ystartsev> | adding new syntax to html won't help, because historical code still exists |
| 09:35 | <ystartsev> | so it doesn't achieve the goal of unification |
| 09:35 | <ystartsev> | real shame |
| 09:35 | <haxjs> | if we want to solve dev pain point, pls roll back the stage so devs can say their ideas. |
| 09:36 | <ystartsev> | haxjs: the outcome here is that this specific goal is impossible |
| 09:36 | <ystartsev> | we can certainly roll back the stage, but its irrelevant with regards to unification |
| 09:37 | <haxjs> | We at least should give a chance that community could revisit the proposal in current situation. Becuase normally naming issue is solved in stage 2 not stage 3. |
| 09:37 | <ystartsev> | haxjs: sure, but that is a different topic |
| 09:38 | <haxjs> | What's different? Are we discussing naming issue now? |
| 09:38 | <ystartsev> | no... |
| 09:44 | <ljharb> | ystartsev: not sure if you already got the feature req but it'd be really cool if presenters could self-request a temp check and provide a question, so that chairs both can "approve" it, and then also the question is displayed near the emojis |
| 09:44 | <ystartsev> | ljharb: ill add it -- looks like we need labels for temp checks and multiple temp checks |
| 09:44 | <ljharb> | +1 |
| 09:44 | <leobalter> | I'm strongly positive about .at in Arrays and TypedArrays, but really indifferent about it in Strings |
| 09:46 | <michaelficarra> | we're running dangerously close to turning this temperature check into a voting system |
| 09:46 | <leobalter> | shu for the records, my indifference means I'm totally neutral about this feature in Strings |
| 09:47 | <devsnek> | +1 michaelficarra |
| 09:48 | <ljharb> | we should probably make heart and thumbs up be mutually exclusive, at least |
| 09:49 | <akirose> | idk i mean rn shu is soliciting how the room feels about a thing, not whether or not we are permitting forward momentum |
| 09:49 | <ystartsev> | my internet is bad |
| 09:50 | <akirose> | it's like exit polling, totally unproblematic |
| 09:50 | <akirose> | erm |
| 09:50 | <ryzokuken> | TC39 now has "no confidence" votes :D |
| 09:51 | <leobalter> | for the records: I'm opposed to explore syntax before the proposed built-in API for this feature |
| 09:53 | <littledan> | I explicitly endorse staying at Stage 3 with these changes we discussed |
| 09:53 | <ljharb> | +1 |
| 09:54 | <michaelficarra> | was the syntax proposal actually serious? |
| 09:54 | <ljharb> | sounds like yes |
| 09:54 | <michaelficarra> | I am floored |
| 09:55 | <devsnek> | same |
| 09:56 | <littledan> | I am not really sure if this syntax suggestion is in good faith. It seems like solving for "what will block this proposal from affirming Stage 3" rather than a serious proposal. |
| 09:57 | <littledan> | it's clear, given everyone's comments, that it will not get consensus in committee |
| 09:58 | <littledan> | I feel like we're getting off-topic from the proposal topic and instead considering changing what Stage 3 means. I do not agree to this change. |
| 10:01 | <haxjs> | The situation is significantly changed and the break the original motivation and the requirements in stage 1. So I don't understand how the proposal have the quality of stage 3 should have. |
| 10:02 | <michaelficarra> | brad4d: please mute |
| 10:02 | <michaelficarra> | I think we could use an extra hand with the notes |
| 10:03 | <rricard> | sorry had to take a quick break |
| 10:04 | <ljharb> | haxjs: the motivation from the committee when it achieved stage 1 included its ergonomics/usefulness separate from ObservableArray: https://github.com/tc39/notes/blob/840c700dc7fa7b9f6d0a3c208bd66b333e304717/meetings/2020-06/june-4.md#item-for-stage-1 |
| 10:05 | <ljharb> | haxjs: so despite the only motivation prior to being presented being ObservableArray compat, since stage 1 it's had more motivations than that |
| 10:05 | <haxjs> | What i mean is, if the motivation is only ergonomics, it's possible to not advance to stage 1 in that time, or may have other solution in stage 2. |
| 10:06 | <littledan> | I don't really understand the motivation for the `debugger.` proposal. It feels like overkill. |
| 10:06 | <haxjs> | ljharb: this is why i think it should be at least rollback to stage 2. |
| 10:07 | <ljharb> | haxjs: i'm not sure i'd ever put ergonomics after "only" |
| 10:07 | <ljharb> | haxjs: what other solution tho? as has been discussed, syntax for this is a nonstarter for some on the committee |
| 10:07 | <ljharb> | haxjs: (at least until after a method exists) |
| 10:09 | <littledan> | in our process, we require consensus to change stages, not to maintain them |
| 10:09 | <haxjs> | I don't others, but if it did not have the benefit of unifying dom .item(), i will not agree it's worth to add new method for that. And yes, if there is a method ,then syntax may be not have enough benefit. |
| 10:09 | <haxjs> | littledan: this is the process issue we need to figure out |
| 10:10 | <ljharb> | haxjs: can you elaborate on why you don't think it's worth adding a new method without the unification goal? |
| 10:10 | <littledan> | haxjs: Sure, if you have a process change you want to propose, feel free to ask the committee for consensus. I'm describing how we work today. |
| 10:11 | <littledan> | +1 to Waldemar's comment about how it's good to specify intent |
| 10:11 | <haxjs> | littledan: sorry i can't because my english level can't discuss such complex thing. |
| 10:13 | <haxjs> | ljharb: just feel not worth enough. especially the possible syntax solution could have better ergonomics . So if the only motivation is ergonomics, we should first consider syntax solution. |
| 10:14 | <ljharb> | haxjs: why would you find syntax more ergonomic than a method? is that just in this case, or in general? |
| 10:15 | <haxjs> | in this case i think it's better because it match `a[idx]`, and the syntax could also apply to slice notation proposal. |
| 10:16 | <ljharb> | slice notation is viable because a slice method exists |
| 10:17 | <drousso_> | shu i had similar "concerns"/unease |
| 10:18 | <leobalter> | haxjs: I sympathize with the fact ESL makes it harder. The same happens to me. Although, it's hard for me to understand your objection about adding the method as not worth being added. When you say "just feel not worth enough" it seems to me also as not convincing to reject it, as the room is generally positive about the feature. |
| 10:19 | <leobalter> | haxjs: as ljharb has mentioned, the syntax version is a nonstarter. It is too much of a cost compared to a built in api |
| 10:22 | <haxjs> | syntax has the cost, but also have some benefit which method can't have: |
| 10:22 | <haxjs> | 1. never have compatibility issue (we don't know whether `at` really web compatible) |
| 10:22 | <haxjs> | 2. better ergonomic than method , especially in this case , it's not a "brand new syntax" but a new syntax which based on the well-known `a[idx]` |
| 10:22 | <haxjs> | 3. apply to other proposals like slice notation |
| 10:24 | <ljharb> | it would only make sense on indexables tho, not on map/set/etc, so to me syntax is much worse ergonomics for this |
| 10:24 | <ljharb> | i'm also skeptical that any syntax solution would be helpful for slice notation |
| 10:24 | <michaelficarra> | Bakkot: for the notes, console. what? |
| 10:24 | <haxjs> | ljharb: `a[idx]` also not apply to map/set |
| 10:24 | <michaelficarra> | tab? |
| 10:24 | <Bakkot> | tap |
| 10:24 | <michaelficarra> | actually, just please edit the notes |
| 10:24 | <ljharb> | haxjs: right, that's normal object semantics. index `-1` isn't. |
| 10:24 | <littledan> | note, console is a standard! You can contribute to it! https://github.com/whatwg/console |
| 10:24 | <michaelficarra> | that section was hard to follow |
| 10:24 | <Bakkot> | console.tap = v => (console.log(v), v) |
| 10:25 | <ljharb> | haxjs: iow, "at" semantics are *not* the same at all as bracket semantics, it's a subset of them |
| 10:25 | <haxjs> | my proposed syntax like C# 8: `a[^1]` means `a[a.length - 1]`. And it also solve the slice notation issue, `a[0:^i]` means `a.slice(0, a.length - i)` , this solve the problem of `i` be `0`. |
| 10:27 | <ljharb> | ystartsev: you have background noise i think? |
| 10:27 | <ystartsev> | shoot |
| 10:27 | <ljharb> | hard to tell in teams tho, could have been someone else |
| 10:28 | <ystartsev> | i just looked and the noise levels look low |
| 10:28 | <littledan> | I generally share ystartsev and shu 's concerns |
| 10:32 | <devsnek> | its very hard to sell things that aren't revolutionary to the committee |
| 10:32 | <Bakkot> | when they're syntax, that's probably true, yeah |
| 10:33 | <Bakkot> | high bar for syntax |
| 10:33 | <devsnek> | high bar for new global |
| 10:34 | <Bakkot> | that too, yeah |
| 10:40 | <michaelficarra> | shu: please review your notes there |
| 10:40 | <shu> | am i the transcription loser |
| 10:41 | <Bakkot> | lotta transcription losers |
| 10:41 | <Bakkot> | wish this API worked just a little better... |
| 10:41 | <Bakkot> | I might ask next time if I can record the audio privately just so that I can fix up the notes |
| 10:42 | <Bakkot> | (also I've been doing the live note fixes up till now but I'm starting to fade, so I stepped back at the start of thiis presentation; sorry other note takers) |
| 10:43 | <rricard> | it's fne |
| 10:45 | <ystartsev> | do we have enough note takers? |
| 10:45 | <rricard> | i think so |
| 10:51 | <michaelficarra> | Bakkot: it's actually really good for some people |
| 10:51 | <ystartsev> | did the note taker die? |
| 10:51 | <michaelficarra> | ystartsev: yes |
| 10:51 | <Bakkot> | restarting |
| 10:52 | <rricard> | thanks |
| 10:52 | <Bakkot> | apologies, that was me breaking it rather than a bug |
| 10:52 | <rricard> | it held quite good until now so kudos |
| 10:54 | <Bakkot> | i should tweak it so it doesn't put up partial words, I think |
| 10:54 | <Bakkot> | might try to do that over lunchbreak |
| 10:55 | <rricard> | do you know if it could generate newlines for every voice change? |
| 10:55 | <rricard> | asking for a lot probably |
| 10:56 | <rricard> | if the api exposes any kind of indicator on that |
| 11:00 | <michaelficarra> | the auto transcription really doesn't like shu |
| 11:00 | <shu> | is it because i talk in halting bursts |
| 11:01 | <michaelficarra> | Bakkot: double words are better than missing words for editing IMO |
| 11:01 | <michaelficarra> | shu: I don't think so |
| 11:01 | <devsnek> | it knows you are from google and it is scared |
| 11:01 | <ljharb> | ummm super weird, google docs just suggested that i "assign" one of the comments in the notes to my brother-in-law |
| 11:02 | <devsnek> | clippy by any other name would be as useless |
| 11:04 | <Bakkot> | michaelficarra yeah, that's my thinking too |
| 11:05 | <michaelficarra> | Bakkot: please kill transcription |
| 11:05 | <Bakkot> | dne |
| 11:05 | <devsnek> | should someone be checking off items on the github agenda |
| 11:06 | <rbuckton> | I'm here, just wasn't looking at irc |
| 11:06 | <littledan> | I do want to note that we already have established consensus on the weaker invariant where the assertion is not part of the cache key |
| 11:06 | <devsnek> | i kind of want an early error for `import 'x'; import 'x' assert { y }` |
| 11:06 | <Bakkot> | ooof, really wish the realms proposal could be moved up 30 minutes; I want to go to that one but I would also love to go to bed half an hour earlier |
| 11:07 | <ljharb> | devsnek: `Promise.all([import('x'), import('x', { assert: 'y' })])` might work as a feature test :-p |
| 11:08 | <devsnek> | did you mean to ping mark |
| 11:08 | <haxjs> | import('x', {}) is syntax error? |
| 11:09 | <devsnek> | with the proposal it is not |
| 11:09 | <haxjs> | yeah, i mean if it's syntax error, it can't be used for feature test for old engines |
| 11:09 | <devsnek> | i think ljharb meant feature testing a specific assertion, not that assertions exist |
| 11:10 | <haxjs> | oh i c. |
| 11:10 | <shu> | Bakkot: presumably it'd be really nice to retrain the transcription model on the set of our voices |
| 11:10 | <shu> | the set of speakers is relatively stable from meeting to meeting |
| 11:10 | <Bakkot> | yeah, don't think they offer that though |
| 11:11 | <Bakkot> | and I don't think you get to download the model to train yourself |
| 11:11 | <littledan> | I recommend against using dynamic import as a feature test; you're writing stuff into the module map that stays alive as long as the surrounding realm does |
| 11:11 | <ljharb> | devsnek: mark's not on irc so i settled for pinging you |
| 11:11 | <devsnek> | hah |
| 11:11 | <ljharb> | littledan: if it's a module i want anyways tho, or if it's a super teeny blob URL? |
| 11:12 | <littledan> | yeah, so that keeps the blob in the module map |
| 11:12 | <ljharb> | sure |
| 11:12 | <littledan> | you can do what you want, but I won't be really happy about these idioms getting popular |
| 11:12 | <devsnek> | `import(module {}, {})` |
| 11:12 | <ljharb> | it's pretty unlikely that will be any app's biggest memory leak :-p |
| 11:12 | <devsnek> | i wouldn't be surprised if json modules are a top leak |
| 11:12 | <devsnek> | after they are supported |
| 11:13 | <robpalme> | *** The next item will be Grouped Accessors by Ron Buckton *** (rescheduled to avoid a big gap in the session) |
| 11:59 | <robpalme> | We are starting in one minute! |
| 12:02 | <rricard> | won't be able to take notes for much long |
| 12:02 | <rricard> | if someone could take it from me |
| 12:05 | <Bakkot> | will pick it back up |
| 12:05 | <Bakkot> | I tweaked it some |
| 12:05 | <Bakkot> | not sure if it's better |
| 12:05 | <rricard> | yep seeing it |
| 12:05 | <akirose> | ty ty |
| 12:05 | <littledan> | is it an error if you have multiple getters with the same name? that's news to me, and I can't reproduce it |
| 12:05 | <rricard> | it is different |
| 12:05 | <littledan> | I thought they just acted like subsequent Object.defineProperty calls |
| 12:06 | <michaelficarra> | littledan: same |
| 12:06 | <littledan> | I think this proposal is pretty orthogonal with how error-happy we want to be. It would make sense with the sloppy semantics just as much. |
| 12:07 | <robpalme> | our major in-house class system has a grouped accessor definition that atomically defines getter/setters via a single top-level named property. Ron's proposal does it in a more elegant way by making it first-class. |
| 12:12 | <michaelficarra> | Bakkot: transcription died |
| 12:12 | <michaelficarra> | it's back |
| 12:19 | <devsnek> | i'm concerned that using accessors in a decorator has to be leaked to the consumer of the decorator |
| 12:24 | <michaelficarra> | IMO, Ron has identified a developer problem, albeit minor. I don't think the particular solution presented is viable for stage 2. But I do weakly support stage 1, assuming Ron would be okay with a different solution (which I doubt). |
| 12:25 | <devsnek> | same |
| 12:32 | <leobalter> | I like the group accessors, I don't like the idea of `x { #get, #set }`, field seems to be public but it's all private |
| 12:32 | <rbuckton> | I may be wrong about multiple accessors of the same name, but my goal was to error on mixed syntax. That's something I can revisit prior to stage 2, assuming we consider this feature. |
| 12:33 | <leobalter> | that assumes we could have `x { get, #get, set, #set }` |
| 12:35 | <devsnek> | littledan: maybe i'm misunderstanding, i thought you were saying that some decorators will want to change a property into an accessor, and that doing that has performance implications, and so the user of the decorator should have to explicitly allow that |
| 12:35 | <littledan> | devsnek: We have to make a global decision about how all decorators desugar, to meet TS's goal that we don't use cross-file knowledge in transpiling decorators |
| 12:36 | <littledan> | I mean, that goal combined with V8's goal that decorators desugar in a statically analyzable way, so they are fast to interpret, etc |
| 12:36 | <devsnek> | littledan: `class X { @y z }` -> `class X {} accessorLogic(X, y, 'z');` |
| 12:37 | <littledan> | we have to decide at parse-time whether we're making a [[Define]] field or an accessor |
| 12:37 | <devsnek> | why |
| 12:37 | <littledan> | (to meet V8's architecture goals) |
| 12:37 | <devsnek> | ah |
| 12:37 | <haxjs> | why v8 arch goals beat developer expectation? |
| 12:38 | <devsnek> | i don't understand v8's requirement there, it seems like this would be equiv to modifying X.prototype |
| 12:38 | <devsnek> | before using X |
| 12:38 | <littledan> | we're combining all the goals together in the proposal, not choosing one over the other |
| 12:38 | <devsnek> | which is a common pattern that engines already support |
| 12:39 | <haxjs> | Note most recent programming languages all move to auto property and hiding field semantic. |
| 12:40 | <littledan> | one reason we didn't select always-autoaccessor semantics for fields was the performance cost Shu described. Another reason is that it wouldn't work with Object spread {...obj} |
| 12:40 | <devsnek> | if we didn't have class fields we wouldn't have to worry about decorating them 😅 |
| 12:41 | <devsnek> | i guess technically we don't have class fields yet |
| 12:42 | <haxjs> | yes class fields have too many issues. |
| 12:43 | <haxjs> | I really against class fields because it invent too many issues than solving real problems. |
| 12:44 | <haxjs> | `{...object}` issue is a separate issue, anytime u refactor code to accessors, it will break. So no news in engineering view at all. |
| 12:46 | <devsnek> | there is no emoji for how i'm feeling |
| 12:48 | <shu> | i had technical difficulties at the beginning of this presentation |
| 12:48 | <ystartsev> | sorry for the z-index fail yall |
| 12:48 | <shu> | what was the professed motivation for this proposal? was it mainly for decorator interaction or mainly for syntax ergonomics? |
| 12:48 | <rbuckton> | both |
| 12:48 | <shu> | ok, thanks |
| 12:49 | <rbuckton> | I bring it up now because of decorators, but I've been thinking about it for awhile in general. |
| 12:49 | <haxjs> | I like this proposal generally |
| 12:50 | <haxjs> | I also hope we can have willset / didset like Swift. |
| 12:51 | <haxjs> | The proposal have some small issues but IMO, most issues are coming from other proposals (like fields), not the issue of itself. |
| 12:54 | <haxjs> | And I totally agree that decorator magically make field become accessor is a bad idea. |
| 12:56 | <drousso_> | ^ +1 |
| 13:06 | <chicoxyzzy> | grouping for objects looks a bit syntactically noisy to me `const foo = { bar { get() {...}, set(...) {...}: { internalField: { ... } } } }` where `{ internalField: { ... } } }` is an initial value of `foo.bar` |
| 13:07 | <chicoxyzzy> | for classes looks fine |
| 13:07 | <haxjs> | object normally do not use getter/setter frequently |
| 13:07 | <haxjs> | I believe it's most for classes. |
| 13:08 | <chicoxyzzy> | syntax for objects was presented on slides |
| 13:08 | <haxjs> | yes ,for complement, it should support object |
| 13:08 | <haxjs> | but I'm ok if it not |
| 13:09 | <littledan> | I'd like the question that we ask for consensus on to include a statement about the relationship with decorators, not just Stage 1, since that's ambiguous |
| 13:10 | <rbuckton> | I presented with object for comparison. I also feel that it makes more sense in classes than in object literals, but did not feel that was a reason to not consider it. |
| 13:10 | <caridy> | I'm confused with the discussion. This proposal is for the developer to have the controls while writing the code, while decorators are just giving up that control to another program. I see them as orthogonal. |
| 13:10 | <littledan> | I don't necessarily object to Stage 1 for this prposal |
| 13:10 | <rbuckton> | I don't believe this being stage 1 should block decorators, but I do think this being stage 1 gives decorators an option to consider as an alternative to auto-converting fields. |
| 13:11 | <haxjs> | I agree decorator and this proposal could be orthogonal. That means decorator should not have auto accessor semantic. |
| 13:11 | <littledan> | I remain concerned about the upgrade path issue |
| 13:11 | <littledan> | that I think people will be unhappy to have to write extra tokens in their existing decorator usage (but, the more tokens, the worse) |
| 13:12 | <haxjs> | decorator magically auto accessor change the semantic dramatically and will cause problem in many cases. |
| 13:12 | <littledan> | I proposed `trap` as an orthogonal feature for this months ago, and got pushback from decorator users about this issue |
| 13:12 | <littledan> | and I want to respect that, even as I see it as a possible alternative |
| 13:13 | <rbuckton> | Current stage-1 field decorators don't *automatically* work with the updated decorators proposal, because they would work differently. Stage-1 field decorators that convert something to an accessor do it using `Object.defineProperty`. They would have to explicitly write code to handle both Stage-1 style invocations as well as the updated proposal's decorator invocations. |
| 13:14 | <littledan> | right, the upgrade path I mean is around decorator users, not decorator authors |
| 13:14 | <littledan> | and there are minor grammar changes as well |
| 13:15 | <rbuckton> | Those decorators, as part of their upgrade path, could instead throw with a clear explanation as to what needs to be changed. Static type systems like TypeScript could use the type information of the decorator to provide a design-time error as to whether the decorated target is valid (which we already do for Stage-1 decorators). |
| 13:15 | <littledan> | but the need to write `trap` or `{get; set;}` would be a significant additional barrier |
| 13:15 | <littledan> | some decorators authors are a bit nervous about type interactions with decorators, given how TS doesn't model much right now. It'd be good to discuss what more we can do with standard decorators |
| 13:15 | <haxjs> | This is good because developer now understand it will become accessors and know that there will be different semantic. |
| 13:16 | <shu> | i see a popup in the Teams UI that says "transcription has started" |
| 13:16 | <littledan> | well, "including a decorator" is also an explicit signal |
| 13:16 | <shu> | we're also testing Teams's transcription? |
| 13:16 | <shu> | (and how do i see that?) |
| 13:17 | <rbuckton> | Without a syntactic opt-in of some kind, decorators change a field in ways a user may not expect. This can impact performance and runtime evaluation due to subclassing. I am still concerned about these issues. |
| 13:17 | <haxjs> | No, "including decorator" is just means I want decorate something, not changing semantic dramatically. Decorate something normally not breaking change. |
| 13:18 | <littledan> | I feel like, if Stage 1 means, "the committee agrees with this concern", that's something we should say explicitly |
| 13:18 | <littledan> | and record as a conclusion, so we can build on it in the decorators champion group |
| 13:18 | <rbuckton> | To me, this is similar to the discussion around decorating function declarations from several years back. If function decorators forced `let`-like semantics for a function declaration and prevented hoisting, decorating a function could break code and require refactoring. |
| 13:20 | <rbuckton> | Our solution was to just defer function decorators until after class decorators |
| 13:20 | <haxjs> | Agree! Maybe we should introduce non-hoisting function declaration like `const f() {}` so we can have function decorators. |
| 13:24 | <rbuckton> | shu: https://usercontent.irccloud-cdn.com/file/lts3X43J/image.png |
| 13:24 | <shu> | rbuckton: i don't see that |
| 13:25 | <shu> | i only have Device settings, Meeting details, and Enter full screen |
| 13:25 | <rbuckton> | It may not be available for guests :( |
| 13:29 | <littledan> | (I guess for function decorators, I just think we should go ahead with let-style semantics, since there's really no other way to do it. I don't feel like const function declarations would be worth it.) |
| 13:31 | <chicoxyzzy> | +1 |
| 13:32 | <littledan> | so overall I don't really agree with the claim that, it's absolutely necessary that the "identity decorator" do nothing. I think it would be a *nice* property, but makes sense to weigh against other things |
| 13:36 | <haxjs> | Of coz everything are tradeoff. But I really feel decorator should not change semantic like that. Especailly in some cases u only want to deocator to add some metadata, and never expect any semantic change. |
| 13:53 | <Bakkot> | yeah, shu +1, no one is going to expect `atob` to be missing in the new realm |
| 13:53 | <haxjs> | So let's add `atob` to JS ?? :P |
| 14:04 | <littledan> | people in TC39 have made security claims about all sorts of features, such as Promises, private fields, etc. Maybe a rebrand would be a way to discard "baggage" but I don't think it makes sense to hold off on a feature because of confusing claims |
| 14:05 | <caridy> | I'm ok with a rebrand to Context |
| 14:05 | <caridy> | if that will help to clear up the confusion |
| 14:07 | <haxjs> | What rebrand mean? |
| 14:07 | <leobalter> | haxjs: rename |
| 14:07 | <leobalter> | instead of Realm we would call it Context |
| 14:07 | <leobalter> | and I'm +1 for this renaming if it's useful |
| 14:08 | <ystartsev> | forgot to mention: as shu said, this is super lightweight on the js engine side, we already can do this -- most of the real work would be gecko |
| 14:08 | <robpalme> | I think Context is the lowest value word in all of computer science. perhaps second only to Data |
| 14:09 | <haxjs> | Not sure why `Context` is better than `Realm` ... |
| 14:09 | <ystartsev> | can we plz rename compartments? |
| 14:09 | <ystartsev> | I like "realm" because it sounds like we are in a fantasy novel and i think thats hilarious |
| 14:09 | <ystartsev> | ;) |
| 14:09 | <haxjs> | Yeah, it's hard for me to remember the spelling of `compartment` :) |
| 14:09 | <ystartsev> | joking aside, the name is hard for new comers |
| 14:10 | <robpalme> | if someone says "let's talk about Realms" in a computer conversation I immediately know they are talking about JS stuff |
| 14:10 | <leobalter> | I have thoughts about Compartments but I'd love to address them after we go through the Realms API (or Context API) |
| 14:10 | <ystartsev> | i love the fact that we can talk about "the primordials of a realm" and it _not_ be scifi/fantasy |
| 14:10 | <robpalme> | Compartments is good too because no one else uses that work |
| 14:10 | <ystartsev> | except for US |
| 14:10 | <ystartsev> | firefox uses compartments 😭 |
| 14:11 | <robpalme> | oh |
| 14:11 | <leobalter> | The only thing I love about the name Realms is the fact we can have Frozen Realms and this sounds like Warcraft |
| 14:11 | <ystartsev> | https://searchfox.org/mozilla-central/source/js/src/NamespaceImports.h#142 |
| 14:11 | <robpalme> | also, Realms reminds me of the cartoon Dungeons & Dragons, which is possibly the greatest cartoon of all time |
| 14:12 | <leobalter> | robpalme: well I watched it on pt-br so I missed any references, it took me a long time to know the time is originally Dungeons & Dragons. |
| 14:12 | <leobalter> | The RPG goes without translation in Brazil, at least |
| 14:13 | <ystartsev> | "zone" in spidermonkey is also good -- reminds of the book roadside picnic |
| 14:13 | <leobalter> | switching to tdz |
| 16:42 | <devsnek> | please we cannot call this contexts node already has this and it's called contexts and the overlap will be painful |
| 16:48 | <bradleymeck> | Nations, Borders, Worlds, Universes, so many options |
| 16:53 | <devsnek> | Globals |
| 17:09 | <bradleymeck> | Globe |
| 17:09 | <bradleymeck> | that contains globals at least in English implications? |
| 19:02 | <ljharb> | there's no conclusion listed on "realms" for day 2's notes - what was the result? |
| 19:14 | <Bakkot> | it was just a status update, proposal champions are still talking to HTML / browser vendors (beyond just the JS engine people) |
| 19:14 | <Bakkot> | people were positive about it in the temperature check though |
| 19:25 | <ljharb> | ah ok, thanks |
| 19:25 | <ljharb> | the title is "for stage 3" |
| 19:25 | <ljharb> | (is why i asked, i mean) |
| 19:32 | <rkirsling> | so wait, `at` is back for Strings now too? |
| 19:34 | <bradleymeck> | always has been |
| 19:35 | <ljharb> | 🔫 👨🚀 |
| 19:37 | <rkirsling> | lol. |
| 19:38 | <rkirsling> | guess I'll revert my revert then |
| 19:39 | <ljharb> | we need to be careful tho, core-js apparently shipped the old stage 1 code-point-based String.prototype.at polyfill |
| 19:39 | <ljharb> | so depending on how it installs it, there might be web compat issues |
| 19:41 | <rkirsling> | right, I just noticed that thread |
| 19:41 | <jridgewell> | Why are they shipping `at`? It was renamed to `codePointAt`, right? |
| 19:41 | <ljharb> | jridgewell: no, that's different |
| 19:41 | <ljharb> | jridgewell: there's a stage 1 proposal by mathias for String.prototype.at that returns code points |
| 19:42 | <ljharb> | jridgewell: it's basically dead at this point, and nobody should have ever shipped a polyfill for it at that early a stage, but since core-js did, we have to pay attention to it |
| 19:42 | <ljharb> | jridgewell: codePointAt returns a number, not a string code point |
| 19:43 | <ljharb> | jridgewell: like `'💩'.at(0)` would return `'💩'` |
| 19:43 | <jridgewell> | Ugh |
| 19:46 | <ljharb> | the existence of the old proposal is fine, but i'm ugh on enabling stage < 3 polyfills by default, yes :-( |
| 22:14 | <Bakkot> | "< 3 polyfills" - horse_js |
| 22:14 | <Bakkot> | (not actually) |
| 22:15 | <rkirsling> | lol |
| 22:15 | <rkirsling> | wait so the main thing I want to know is |
| 22:16 | <rkirsling> | was commitment expressed by V8 or SM to ship String.prototype.at and see what breaks? |
| 22:22 | <mathiasbynens> | historically, no |
| 22:22 | <mathiasbynens> | String.prototype.at was a ES2015 proposal |
| 22:23 | <rkirsling> | wait what |
| 22:23 | <ljharb> | rkirsling: the "item" proposal's string method tho, i think yes |
| 22:23 | <rkirsling> | yeah I mean the new one |
| 22:23 | <mathiasbynens> | ah gotcha |
| 22:23 | <rkirsling> | I didn't realize the name had come up before |
| 22:23 | <ljharb> | rkirsling: mathias' old proposal is stage 0 |
| 22:23 | <rkirsling> | that seems...complicated, but not necessarily in a way that affects web compat? |
| 22:23 | <rkirsling> | ahh cool |
| 22:23 | <ljharb> | it should probably be moved to "inactive" actually |
| 22:24 | <ljharb> | rkirsling: the issue is that core-js has a polyfill for the old String `at` proposal. depending on the way it's installed, it may, or may not, cause web compat issues |
| 22:24 | <rkirsling> | right |
| 23:55 | <rkirsling> | let's start with this instead :) https://github.com/tc39/test262/pull/2905 |
