| 00:12 | <TabAtkins> | shu: What's this number destructuring thing |
| 00:17 | <jridgewell> | https://twitter.com/__Jonathanks/status/1285874999589576705 |
| 00:18 | <TabAtkins> | omg |
| 00:18 | <TabAtkins> | (thanks, i just couldn't find it in the thread) |
| 00:18 | <TabAtkins> | Hmmmm tho, b should clearly be `.142` |
| 00:19 | <TabAtkins> | otherwise it implies `3.14` and `3.140` should destructure to different b values, which is weird with literals and impossible with variables. |
| 00:21 | <Bakkot> | literals get weird anyway |
| 00:22 | <Bakkot> | let a.b = 4503599627370496.001 |
| 00:22 | <shu> | they most definitely should destructure to different b values |
| 17:17 | <akirose> | did mark go robot for anyone else |
| 17:18 | <robpalme> | no |
| 17:18 | <akirose> | i had a feeling |
| 17:19 | <akirose> | I think Shelley just joined the call actually |
| 17:21 | <haxjs> | What's the channel name? |
| 17:21 | <akirose> | #tc39-inclusion |
| 17:25 | <akirose> | Thank you mpcsh !!! |
| 17:26 | <littledan> | please advance the queue |
| 17:26 | <mpcsh> | ♥ |
| 17:26 | <ljharb> | hax's gist re "private in": https://gist.github.com/hax/5e94c7959703ea95d4ff9c9deac12988 |
| 17:28 | <shu> | curious about the "we" in the document |
| 17:29 | <ljharb> | iirc it refers to hax and his 360 colleagues |
| 17:29 | <ljharb> | they conferred 5ish hours ago |
| 17:29 | <shu> | thanks |
| 17:32 | <robpalme> | is there a link to the reification proposal? |
| 17:38 | <ljharb> | robpalme: https://github.com/jridgewell/proposal-private-symbols |
| 17:38 | <ljharb> | iirc |
| 17:42 | <robpalme> | right. that proposal did not achieve stage 1 when it was presented in Jan 2019. |
| 17:42 | <robpalme> | https://github.com/tc39/notes/blob/master/meetings/2019-01/jan-31.md#private-symbols-for-stage-1 |
| 17:42 | <jridgewell> | Correct |
| 17:43 | <jridgewell> | I do not plan on working on again |
| 17:43 | <jridgewell> | (I'm in a work meeting, no idea what's you're talking about in the committee) |
| 17:43 | <michaelficarra> | bradleymeck makes a good argument for allowing `obj."property name"` |
| 17:44 | <bradleymeck> | hahaha |
| 17:44 | <devsnek> | +1 |
| 17:44 | <Bakkot> | i like it |
| 17:44 | <devsnek> | but i have to insist |
| 17:44 | <devsnek> | on `obj.1` |
| 17:44 | <Bakkot> | also we should allow `object.0` |
| 17:44 | <devsnek> | asi be damned |
| 17:45 | <Bakkot> | are there actual ASI problems with that? |
| 17:45 | <devsnek> | Bakkot: jinx |
| 17:45 | <ljharb> | jridgewell: oh, do you have a different reified private fields proposal that's more up to date? |
| 17:45 | <devsnek> | yeah `object\n.0` is identifier and `.0` |
| 17:45 | <devsnek> | a numeric literal |
| 17:46 | <jridgewell> | No |
| 17:46 | <Bakkot> | ah right |
| 17:46 | <ljharb> | jridgewell: ah |
| 17:46 | <devsnek> | otherwise i'm sure we would already have it |
| 17:48 | <michaelficarra> | I am fine with `obj[0]` for numeric string properties |
| 17:57 | <michaelficarra> | this feels like bullying |
| 17:58 | <ystartsev> | i am... also a bit wary here |
| 17:58 | <michaelficarra> | I also don't agree that the committee can't reject stage 3 advancement in an inactionable way |
| 17:59 | <ljharb> | michaelficarra: if you'd like to make a point of order and say that that's fine |
| 17:59 | <Bakkot> | this proposal did not need to advance this fast |
| 17:59 | <ystartsev> | yeah i have a concern there. |
| 17:59 | <michaelficarra> | see ystartsev's rejection of the function impl hiding for stage 3 |
| 17:59 | <ystartsev> | yes exactly, i recently did this unilaterally |
| 17:59 | <ystartsev> | it was accepted by committee |
| 18:00 | <devsnek> | wait is function impl hiding currently blocked |
| 18:00 | <michaelficarra> | ljharb: I'm not going to stop it from advancing because I want the feature, but I think the process just now was questionable |
| 18:00 | <Bakkot> | I would be happier if we did not advance this to stage 3 at this meeting and brought it back next meeting after ljharb having talked more to haxjs |
| 18:00 | <bradleymeck> | i think we need to disseminate the difference in those proposals being rejected, but thats likely not best to do right now |
| 18:01 | <ghermeto> | I agree with Michael |
| 18:01 | <bradleymeck> | Bakkot: can you point of order that |
| 18:01 | <ystartsev> | yes. ff blocked as we considered it to have been advanced to stage 2 on the basis of having more benefits than it ultimately had. we had strong philosophical concerns about sensitive. for hide source we just weren't sure it was the right solution |
| 18:01 | <ystartsev> | cc devsnek |
| 18:01 | <michaelficarra> | devsnek: yes, blocked with no actionable recommendation |
| 18:01 | <ljharb> | hmm, haxjs may have had connection issues |
| 18:01 | <Bakkot> | it may be that the differences are irreconcilable and we have figure out if we're advancing it anyway but I don't think it needs to be rushed |
| 18:01 | <Bakkot> | bradleymeck I will bring it up to the chairs to discuss between this topic and the next |
| 18:01 | <bradleymeck> | sure |
| 18:01 | <ystartsev> | devsnek: on my side, since i blocked unilaterally, i joined the tooling meeting to try and understand concerns there and have made myself available to be convinced otherwise. i am still availabl efor that |
| 18:01 | <Bakkot> | don't necessarily want to interrupt this topic |
| 18:01 | <shu> | i still cannot understand what is being said at all |
| 18:01 | <devsnek> | ystartsev: god it |
| 18:01 | <ghermeto> | I can't hear anything... can you? |
| 18:01 | <devsnek> | got it* |
| 18:02 | <devsnek> | we have a lot of POO rn |
| 18:02 | <ljharb> | ystartsev: michaelficarra Bakkot fwiw i'm talking to hax on dm and will absolutely take 30 seconds later today to ensure my proposal stays at stage 2 if he feels like he didn't get the opportunity to object |
| 18:02 | <akirose> | ljharb haxjs is that accurate regarding connection issues? |
| 18:02 | <akirose> | ljharb: ty |
| 18:02 | <Bakkot> | ljharb he did object pretty concretely |
| 18:03 | <Bakkot> | and we tried to resolve those objections but they didn't sound super resolved |
| 18:03 | <ystartsev> | ljharb: fwiw i do support ergonomic brand checks, i just want to makee sure we treat this the right way |
| 18:03 | <Bakkot> | ditto |
| 18:03 | <ljharb> | totally understand |
| 18:03 | <ljharb> | no advancement is worth someone feeling bullied into it |
| 18:03 | <michaelficarra> | Bakkot ljharb: I want to make sure we also aren't setting a precedent around your claim that rejection of advancement to stage 3 must be actionable |
| 18:04 | <haxjs> | it seems ljharb asked me? it seems the connenction just lagged and i can't hear that |
| 18:04 | <ystartsev> | haxjs: at the moment jackworks is talking, but we will take 30 s to address this in a momeent |
| 18:04 | <ljharb> | haxjs: would you like 30 seconds later to get your objection to stage 3 on record, and we can leave it at stage 2? or are you ok with stage 3 |
| 18:04 | <ystartsev> | michaelficarra: Bakkot ljharb yes i agree here. I consider *stage 3* to have high bar for blocking advancement |
| 18:05 | <haxjs> | not ok with stage 3. but pls allow to read the notes again to see if i missed some arguments which may change my idea. |
| 18:05 | <ystartsev> | I have an internal document documenting our process for our team that outlines this so that we react appropriately per stage. I think it might make sense to make this an updated version of the process |
| 18:05 | <ljharb> | haxjs: ok, please let us know asap, once you're confirmed one way or the other we'll make sure that's addressed and in the notes |
| 18:06 | <bradleymeck> | i retroactive understanding of this last discussion will be a process discussion is also a struggle since it was a desire to pin the `#x in` proposal to a reified proposal based upon a consistency around syntax implications. It wasn't necessarily a block on the syntax of `#x in` itself, but on the lack of a seen invariant of what `@ in @@` provides |
| 18:06 | <rricard> | haxjs: noted in notes |
| 18:06 | <ljharb> | rricard: ty |
| 18:06 | <michaelficarra> | on this topic, I think we need to seriously reconsider our consensus process, possibly adopting TabAtkins' recommendation from a previous meeting (I think it was from TAG?) |
| 18:07 | <shu> | remind me what that recommendation was? |
| 18:07 | <MylesBorins> | michaelficarra do you ahve a TLDR or that process |
| 18:08 | <bradleymeck> | so the objection was valid, but requires adopting a consistency about the meaning of `@ in @@` regardless of what `@` is. that makes the argument hard to make as it isn't about semantic issues or about grammar issues, but around usage guarantees that we don't actually write down as preserved (or in my case i responded stating I don't think we guarantee it currently) |
| 18:08 | <ljharb> | personally i think there's a big difference in objecting to consensus on a stage > 2 proposal, than on a stage <= 2 proposal |
| 18:08 | <bradleymeck> | so it goes further in needing to convince people that the syntactic guarantees are something we are trying to preserve and must be solved |
| 18:08 | <devsnek> | we need a way to test for private fields that doesn't involve try/catch |
| 18:09 | <Bakkot> | ljharb stage 2 is "something like this seems like it would work", stage 3 is "we are happy with this particular solution" |
| 18:09 | <michaelficarra> | MylesBorins: I don't want to misrepresent it, we should talk to TabAtkins and also look into process documentation of other standards-setting bodies |
| 18:09 | <bradleymeck> | i don't think people are arguing we don't want a way to test for them without try/catch |
| 18:09 | <ljharb> | Bakkot: stage 2 also means "we are committing to putting a solution to this problem in the language" |
| 18:09 | <shu> | michaelficarra: i am interested in changing our consensus process |
| 18:09 | <Bakkot> | it does not mean that |
| 18:10 | <Bakkot> | it absolutely does not mean that |
| 18:10 | <ljharb> | Bakkot: the process document literally says stage 2 signifies "The committee expects the feature to be developed and eventually included in the standard" |
| 18:10 | <bradleymeck> | i think we are arguing about what kind solution is viable due to breaking what are seen as existing invariants that are held by some of the committee |
| 18:10 | <ljharb> | so it 100% means that, explicitly |
| 18:10 | <Bakkot> | ljharb "expects" is very much not "is committed to" |
| 18:10 | <ljharb> | ok fair |
| 18:10 | <Bakkot> | extremely not |
| 18:10 | <ljharb> | that's a very subtle distinction tho imo |
| 18:10 | <TabAtkins> | W3C consensus is to seek strong objections; in the absence of those we go with "consensus", which is *not* unanimous but is more than majority; it's fuzzy, but basically if it's anywhere near close we don't call it consensus. |
| 18:10 | <Bakkot> | those things are nowhere close to each other |
| 18:10 | <MylesBorins> | TabAtkins would you say that model closely reflects rough consensus? |
| 18:11 | <ljharb> | Bakkot: it also says post-acceptance changes expected are incremental |
| 18:11 | <TabAtkins> | Probably? Depends on exactly what you mean by that term, but they're in the same ballpark by my understanding. |
| 18:11 | <bradleymeck> | ljharb: but we can always drop a stage if we feel we have found something major |
| 18:11 | <ljharb> | sure |
| 18:11 | <MylesBorins> | fair enough |
| 18:11 | <Bakkot> | ljharb right, so changing the proposal a bunch at stage 2 is weird |
| 18:12 | <Bakkot> | per the process document |
| 18:12 | <Bakkot> | but blocking it is not |
| 18:12 | <akirose> | y'all see my comment about reading the READMEs on the reflector 😅 |
| 18:12 | <ljharb> | alright |
| 18:12 | <michaelficarra> | akirose: it was too small, didn't read |
| 18:13 | <akirose> | use a screenreader |
| 18:15 | <shu> | i'm confused, was there a technical issue with haxjs's audio when ljharb asked for consensus for the private-in? |
| 18:15 | <akirose> | that's the impression I got |
| 18:15 | <akirose> | or perhaps a connection issue |
| 18:15 | <shu> | in that he was still objecting to stage 3, and then we got to discussing the validity of the objection? |
| 18:15 | <michaelficarra> | shu: I think so, yes |
| 18:16 | <shu> | ok |
| 18:16 | <ljharb> | shu: he had connection issues so that's why he failed to respond |
| 18:16 | <ljharb> | shu: so we'll take 30 seconds later today to either confirm he's changed his mind ok with stage 3, or confirm that his objection stands and the proposal stays at stage 2 |
| 18:16 | <ljharb> | *and is ok |
| 18:16 | <bradleymeck> | shu: regardless of the validity it seems fine to wait a meeting, but would be good for us to figure out what even constitutes a valid concern / why this is different from E.G. function impl hiding that had a opaque block |
| 18:17 | <shu> | bradleymeck: fair, agreed good for us to figure out |
| 18:17 | <ljharb> | i do see them as different |
| 18:17 | <ljharb> | but yeah good to figure that out as a group |
| 18:17 | <bradleymeck> | my assumption is the feeling is about adopting a claim of consistency is contentious |
| 18:18 | <shu> | blocking here feels like a bad precedent |
| 18:18 | <ljharb> | there's competing claims of what "consistency" means here |
| 18:18 | <bradleymeck> | ljharb: exactly |
| 18:19 | <bradleymeck> | and likely we need to see if we as a committee are adopting a specific invariant by moving forward with either path |
| 18:19 | <ljharb> | so the objection seems like essentially, "in my model of consistency, this makes things less consistent", whereas others feel the opposite |
| 18:19 | <bradleymeck> | e.g. adopting that `X in O` mandates `O[X]` succeed for all future things (regarding ordinary objects) |
| 18:19 | <michaelficarra> | I want to take this opportunity to remind people that for stage 1, we only need to convince ourselves that there is a problem worth solving; bringing forward a completely worked proposal like this distracts from that goal |
| 18:20 | <devsnek> | is chip on irc |
| 18:20 | <akirose> | no. or at least not at the moment. |
| 18:20 | <bradleymeck> | we could also argue about succeed |
| 18:23 | <haxjs> | If obj[#x] will never exist, I have to object the proposal in current form. I would ask for alternative syntax, not overloading `in`. |
| 18:24 | <bradleymeck> | async context is kind of like incumbent but not on the realm scale :stares into the void: |
| 18:24 | <shu> | well it's like programmatic control over it |
| 18:24 | <shu> | the incumbent stuff is implicit at least |
| 18:24 | <bradleymeck> | implicit is even worse |
| 18:25 | <bradleymeck> | you don't even know what it could be, per my talk with you about only evaluating values and functions in realm A but the incumbent queueing up in realm B |
| 18:25 | <shu> | oh i think reflecting incumbents to be some programmable thing seems super bad to me |
| 18:26 | <ljharb> | akirose: we'll need 30s at some point to record in the notes that the proposal's still stage 2, and so hax can speak to the notes about why |
| 18:26 | <ljharb> | haxjs: ^ |
| 18:26 | <bradleymeck> | i think we need many more minutes than that, can we explain the why offline and in a way that we document what constraint we are trying to place on all future proposals |
| 18:27 | <ljharb> | not to set a precedent |
| 18:27 | <bradleymeck> | i still personally think this constraint applies to reification and constrains how any future reification must be designed |
| 18:27 | <ljharb> | but to record why i'm coming back in september to talk about it longer |
| 18:28 | <akirose> | Cool cool. I do not plan to open it for discussion, so haxjs if you can keep it to just what you said above, we can add it to the notes, and discussions can happen over the next two months. |
| 18:28 | <ljharb> | bradleymeck: to correct my earlier misunderstanding; there's no plan for reification, just for https://github.com/tc39/proposal-private-declarations |
| 18:28 | <bradleymeck> | i do have concerns about constraining the whole language future as a whole without agreement on the importance of the constraint we want to keep |
| 18:28 | <ljharb> | bradleymeck: so `#x` would never be a value and `obj[#x]` would never exist |
| 18:29 | <ljharb> | jridgewell: is that right? ^ |
| 18:29 | <bradleymeck> | ljharb: currently |
| 18:29 | <ystartsev> | bradleymeck: would this be considered an invariant? |
| 18:29 | <ljharb> | ystartsev: the question is, *is* it an invariant that `x in o` implies `o[x]` works |
| 18:29 | <ystartsev> | ok, good thanks for the clarification |
| 18:29 | <ljharb> | which depends on how you define "works" |
| 18:29 | <ljharb> | since it could be a getter that throws |
| 18:29 | <bradleymeck> | ystartsev: yes, I am trying to state if we have a universal objection that limits all features of the language we need to canonize it |
| 18:29 | <leobalter> | littledan: the problem I have - and other delegates shared as well - is not against the feature but understanding what is currently proposed. |
| 18:30 | <ljharb> | or a proxy that misbehaves |
| 18:30 | <ystartsev> | bradleymeck: we should also clearly identify the motivation |
| 18:30 | <bradleymeck> | ystartsev: agreed |
| 18:30 | <ystartsev> | that is why i asked, to record an invariant without the motivation or "protectedd property" could leave us open to debt that we don't know how to deal with |
| 18:30 | <bradleymeck> | ljharb: I'd just state that invariants are for ordinary objects generally |
| 18:30 | <leobalter> | littledan: I'd like to understand this better, the presentation was confusing by many reasons, but it also made me think it was a set of different things it is actually not |
| 18:31 | <littledan> | leobalter: Yeah, it was hard for me to follow the presentation. I recommend taking a look at their README. https://github.com/legendecas/proposal-async-context |
| 18:31 | <ljharb> | bradleymeck: instances with private fields are ordinary objects |
| 18:31 | <leobalter> | littledan: I can't do it in parallel with the meeting, that's the problem |
| 18:31 | <bradleymeck> | ljharb: yes, but around w/e we define "Works" to mean |
| 18:31 | <ljharb> | ah |
| 18:31 | <ljharb> | then yes |
| 18:31 | <leobalter> | littledan: I believe it would be best to recall this one and try to present it again another time |
| 18:41 | <devsnek> | drousso: async locals require overriding promise job execution |
| 18:41 | <devsnek> | which can't be done from userland |
| 18:43 | <jridgewell> | ljharb: Just catching up. |
| 18:43 | <jridgewell> | Yes, Private Declarations do not define a value |
| 18:43 | <jridgewell> | They expand the syntax form only |
| 18:44 | <ljharb> | jridgewell: so would `obj[#x]` work |
| 18:44 | <jridgewell> | Private Declarations should work fine regardless of the reification choice we make |
| 18:44 | <ljharb> | jridgewell: despite `#x` not being a value? |
| 18:44 | <devsnek> | drousso: also this is sort of like atomics in terms of usage, if you're using it you know how to use it and what it does |
| 18:44 | <jridgewell> | It could be either Map based or Symbol based |
| 18:44 | <ljharb> | jridgewell: i meant the syntax |
| 18:44 | <ljharb> | jridgewell: or would i have to do `obj.#x` |
| 18:44 | <drousso> | devsnek i would disagree with that assumption |
| 18:45 | <jridgewell> | (This works, because the Private Declarations syntax is the same as normal class fields syntax) |
| 18:45 | <devsnek> | i mean its exposed in node right now |
| 18:45 | <drousso> | i think there's a _lot_ of usage of atomics without understanding what atomics aree |
| 18:45 | <jridgewell> | No, `obj[#x]` does not work. |
| 18:45 | <jridgewell> | Only `obj.#x` |
| 18:45 | <jridgewell> | It's the exact same syntax as class fields |
| 18:45 | <devsnek> | drousso: no i mean our design of atomics |
| 18:45 | <jridgewell> | Purposefully, so that I didn't force any decisions on reification. |
| 18:45 | <shu> | drousso: the correct understanding of atomics is "always fast, always correct" |
| 18:46 | <devsnek> | we designed atomics with the assumption that they do confusing things and individual humans don't really use them |
| 18:46 | <ljharb> | jridgewell: ok thanks |
| 18:46 | <ljharb> | jridgewell: then haxjs' objection still applies, i think |
| 18:46 | <shu> | devsnek: well, no, it bottoms out at *some* individual humans |
| 18:46 | <shu> | just hopefully really tall ones |
| 18:46 | <devsnek> | lol |
| 18:47 | <Bakkot> | am reminded how much i like the private declarations proposal |
| 18:47 | <Bakkot> | really wish I'd managed to get use to use `private #x` for the class variant though |
| 18:47 | <devsnek> | private symbols but less orthogonal |
| 18:47 | <littledan> | someone who is typing needs to mute |
| 18:48 | <devsnek> | sounds like cherry blues |
| 18:48 | <bradleymeck> | jridgewell: `private #x as x;` |
| 18:48 | <Bakkot> | devsnek: private symbols but without breaking deep assumptions about the language and/or the guarantees you want from private state |
| 18:48 | <bradleymeck> | make it get really funky |
| 18:49 | <Bakkot> | littledan this was said earlier |
| 18:49 | <Bakkot> | this isn't a new thing |
| 18:49 | <jridgewell> | We can make Private Symbols *branded* (act like current Private Fields) |
| 18:50 | <jridgewell> | There are still some issues with Membranes… |
| 18:51 | <jridgewell> | But I don't plan on working on this |
| 18:51 | <devsnek> | Bakkot: the "deep assumptions" thing seems like circular logic |
| 18:51 | <littledan> | sorry for my comment. I missed some context here. |
| 18:51 | <devsnek> | the deep assumption that you can enumerate keys is the exact thing private symbols are supposed to not do |
| 18:51 | <devsnek> | so like if you're dealing with private symbols |
| 18:52 | <ljharb> | for `#x in obj`, please check the conclusion i put in the notes and update as needed (cc haxjs) |
| 18:52 | <devsnek> | "wait why is my private symbol not enumerable" seems like an uncommon thing to think |
| 18:52 | <Bakkot> | devsnek enumerating keys isn't the thing I'd worry about so much as `a[x]` is prototypical |
| 18:52 | <ljharb> | (i updated the original notes section instead of adding a tiny new one) |
| 18:52 | <Bakkot> | the only reason a.#x not being prototypical works is because it is new syntax |
| 18:52 | <devsnek> | Bakkot: it could just be prototypical |
| 18:52 | <Bakkot> | but if you reify private fields then that stops being new syntax |
| 18:52 | <ljharb> | oh nvm, i'll update the continuation |
| 18:52 | <Bakkot> | devsnek right, and then you get the "breaking guarantees you want from private state" |
| 18:52 | <devsnek> | and people who want own properties can do own property checks |
| 18:52 | <Bakkot> | one or the other |
| 18:52 | <Bakkot> | that's the point |
| 18:53 | <devsnek> | it composes perfectly |
| 18:53 | <devsnek> | with the existing language |
| 18:53 | <devsnek> | and how existing properties work |
| 18:53 | <Bakkot> | it makes private fields not do the thing that private fields are for |
| 18:53 | <devsnek> | they're for lots of things |
| 18:53 | <Bakkot> | they're for having guarantees about your code without accidentally exposing API |
| 18:54 | <devsnek> | ok to flip the argument around then you could argue that because its so obvious that they shouldn't be prototypical |
| 18:54 | <devsnek> | no one would be confused by them not being prototypical |
| 18:55 | <Bakkot> | that works fine when it's a different syntactic form, as they are in the current proposal |
| 18:55 | <Bakkot> | that stops working the instant they are reified and using the regular property access syntax |
| 18:55 | <devsnek> | but then they don't work with any concepts in the language |
| 18:55 | <devsnek> | and we end up having this issue |
| 18:55 | <bradleymeck> | `o?.#[k]` 🚢 |
| 18:56 | <Bakkot> | they work fine with the language |
| 18:56 | <Bakkot> | they work just as well as local variables do |
| 18:56 | <Bakkot> | except that they have more limitations on where they can be declared, which there is a lovely proposal to relax |
| 18:57 | <devsnek> | but they don't have the usage of local variables |
| 18:57 | <devsnek> | they compose more naturally as keys of objects |
| 18:58 | <Bakkot> | they work fine as keys of objects as well, except for the `in` limitation ljharb is proposing to rectify |
| 18:58 | <devsnek> | and adding them |
| 18:58 | <devsnek> | and deleting them |
| 18:58 | <devsnek> | and dynamically doing anything with them |
| 18:59 | <devsnek> | well i guess you can technically add them using super tricks |
| 18:59 | <Bakkot> | you can't add and delete and dynamically refer to local variables either |
| 18:59 | <jridgewell> | Adding and deleting are intentional restrictions |
| 18:59 | <devsnek> | they aren't local variables though |
| 18:59 | <Bakkot> | they are somewhere between local variables and regular properties |
| 18:59 | <ljharb> | you can't add properties to a sealed object either, or delete a nonconfigurable property |
| 18:59 | <Bakkot> | giving you the nice parts of both |
| 18:59 | <akirose> | qq ystartsev: would it be realistic to send someone else from Mozilla to some meetings? is it delegable? |
| 19:00 | <devsnek> | ljharb: them being nonconfigurable is orthogonal to them existing |
| 19:00 | <ystartsev> | akirose: i make those meetings available to all members of the spidermonkey team |
| 19:00 | <ystartsev> | but generally i am the only one that atteends |
| 19:00 | <ystartsev> | also i have more context for some issues |
| 19:00 | <akirose> | oh i assumed that part. i mean can you push someone else to attend half |
| 19:01 | <shu> | ystartsev: there's been an overflow last time |
| 19:02 | <shu> | it was not possible to schedule all of the topics given bi-weekly |
| 19:02 | <shu> | ystartsev: wait why would doing more work in between mean the meetings themselves become burdened? |
| 19:02 | <ystartsev> | if we move a lot of topics forward |
| 19:04 | <shu> | ystartsev: fwiw it is freeing once you internalize that you shouldn't be a single point of failure for all JS features for SM |
| 19:04 | <akirose> | fortnightly! |
| 19:04 | <michaelficarra> | akirose: #temporaldeadzone |
| 19:04 | <shu> | if implementer feedback is really crucial for some proposal, and you can't make it, could you delegate? |
| 19:04 | <ystartsev> | shu: i don't consider myself that, i also make it available to other sm engineers |
| 19:05 | <ystartsev> | if its really crucial and I don't have the expertise, i will have another delegate with me or have someone there who knows |
| 19:05 | <ystartsev> | this isn't an issue about delegation, its about the reality |
| 19:05 | <ystartsev> | unless a feature actually needs implementer feedback, its likely that no one will come. i don't think that is ideal and i have limited time |
| 19:05 | <akirose> | it's relevant—biweekly is a really confusing term. |
| 19:06 | <michaelficarra> | akirose: I meant we were already discussing in #tdz |
| 19:06 | <shu> | ystartsev: sorry i don't understand what the reality is you're referring to |
| 19:07 | <michaelficarra> | are we going to reconvene at 13:06P or 13:00P? |
| 19:07 | <shu> | if you are already comfortable to not coming to every one, where does the pressure come from to come to every one? |
| 19:07 | <ystartsev> | im not sure why my position is a problem |
| 19:07 | <ystartsev> | i didn't say that you have to do it biweekly on my account |
| 19:07 | <ystartsev> | i said that i havee an issue doing it weekly |
| 19:07 | <ystartsev> | and that issue stretches to the fact that at present, i am the only person from mozilla who has signed up to go to all of these |
| 19:08 | <michaelficarra> | I prefer waiting until we have too many topics for the fortnightly meetings |
| 19:08 | <ystartsev> | it is fine to do it weekly, i don't know if i will make it, thats all |
| 19:08 | <ljharb> | fwiw weekly *on tuesdays at 9am* is a problem for me because that's one of my mornings with the kids, and so far tuesdays at 9am is the time most often selected :-/ |
| 19:08 | <shu> | ystartsev: sorry, i don't actually want it weekly that much |
| 19:08 | <shu> | ystartsev: i was trying to understand the "pressured to come" issue |
| 19:09 | <shu> | which i am worried about imposing upon others |
| 19:09 | <ystartsev> | so, it would suck but i would make it work? |
| 19:09 | <ystartsev> | this was something i brought up when we were first scheduling |
| 19:20 | <littledan> | yes, again, very sorry for my inappropriate comment with Hax's topic. I didn't realize it had been discussed here, and the resolution seems reasonable for now. |
| 19:21 | <ystartsev> | shu: i cleared it up with leo -- we are on the same page |
| 19:44 | <shu> | ystartsev: great, and is that page the same as what you said before? |
| 19:49 | <shu> | leobalter: you had suggested several proposals for incubator calls, remind me what they were again? |
| 19:52 | <ystartsev> | shu: basically -- if there is enough content to do it weekly it should be done weekly |
| 19:53 | <shu> | +1 |
| 19:54 | <ystartsev> | late meeting, its harder to communicate well! |
| 19:55 | <shu> | hear hear |
| 19:55 | <shu> | i bet i'm gonna be super cranky for the european timezoned one |
| 19:55 | <ystartsev> | well, i have to say i really wish japan was in person |
| 19:56 | <ystartsev> | not looking forward to the remote version 😬 |
| 20:04 | <leobalter> | shu I'm sorry I was afk |
| 20:12 | <michaelficarra> | shu: if we're looking for more, I would nominate gibson042's JSON.parse proposal |
| 20:15 | <littledan> | To clarify (since I was asked), by "yes, again, very sorry for ..." I meant about how I didn't realize the expression of the objection was agreed-on in this room, and I was thrown off by it was raised |
| 20:17 | <devsnek> | very excited for this proposal |
| 20:18 | <rickbutton> | me too |
| 20:19 | <leobalter> | shu, please let me know what are the best ways I can help co-facilitating the incubator calls. We can schedule a chat if you prefer or just use irc/email too |
| 20:19 | <bradleymeck> | note that WebAssembly.Memory can already resize things, this is just about better ways to deal w/ all the fallout of how it must do things |
| 20:20 | <devsnek> | this wasm grow detach is like the #1 slowdown of js<->wasm rn (non-scalar types aside) |
| 20:40 | <devsnek> | did jordan get skipped |
| 20:40 | <ljharb> | yes |
| 20:40 | <ljharb> | it's ok tho |
| 20:40 | <ljharb> | i can ask both of mine together |
| 20:41 | <devsnek> | why can't i add a response to this |
| 20:41 | <ljharb> | the queue needs to be advanced |
| 20:41 | <ljharb> | akirose ^ |
| 20:41 | <ljharb> | i've preserved my item |
| 20:42 | <akirose> | it's a clarifying question |
| 20:42 | <ljharb> | akirose: it was one for the previous topic; waldemar skipped to the next full topic |
| 20:42 | <akirose> | is why you can't reply |
| 20:42 | <devsnek> | akirose: we're on " Timing considerations" |
| 20:42 | <ljharb> | ohhh |
| 20:42 | <ljharb> | right |
| 20:42 | <akirose> | devsnek: Waldemar may have gone there |
| 20:42 | <ljharb> | akirose: waldemar had already asked "auto length" and skipped my clarifying question straight to "timing considerations" |
| 20:42 | <devsnek> | oh i see what you're asying |
| 20:43 | <devsnek> | saying* |
| 20:43 | <ystartsev> | akirose: i think that next item, timing, by wsdferdksl is covered? |
| 20:44 | <akirose> | y |
| 20:55 | <devsnek> | 🎉 |
| 20:57 | <shu> | leobalter: will do, thanks for the offer |
| 21:00 | <rkirsling> | aren't EIM invariants very unusual in actually being documented? |
| 21:01 | <devsnek> | we need to bring RFC 2119 into ecmascript |
| 21:01 | <rkirsling> | hehe |
| 21:01 | <devsnek> | is something truly a specification without that first paragraph |
| 21:03 | <rkirsling> | ohh so this is about doing what we do for EIMs in lots more places |
| 21:03 | <rkirsling> | I assumed this presentation was going to be about the rationale repo, my bad |
| 21:07 | <devsnek> | we've made changes to the spec to keep LR(1) |
| 21:07 | <devsnek> | i think it was some export syntax? |
| 21:09 | <jridgewell> | Import syntax |
| 21:09 | <jridgewell> | But yup |
| 21:10 | <Bakkot> | there's still an open bug here |
| 21:10 | <devsnek> | was it +Default? |
| 21:10 | <devsnek> | guess not |
| 21:10 | <Bakkot> | with parsing `for ( async of` |
| 21:10 | <jridgewell> | It was redefining the import attributes to be valid identifiers |
| 21:11 | <jridgewell> | Right now, you can `import { for } …` |
| 21:11 | <jridgewell> | And that should throw at parse time. |
| 21:12 | <devsnek> | xs and qjs accept that |
| 21:13 | <Bakkot> | wsdferdksl excluding SAB over high-res timers seems quite prescient these days |
| 21:14 | <jridgewell> | Right, the change was to make that a parse error |
| 21:14 | <jridgewell> | But we had to undo it because it broke LR(1) |
| 21:15 | <rkirsling> | wait so this is in the spec or in a separate repo? |
| 21:15 | <bradleymeck> | import {import as ...} is wonderful |
| 21:15 | <rkirsling> | I want to ask a question but I feel like I missed something |
| 21:19 | <jridgewell> | Ohh, it _was_ `export` |
| 21:19 | <jridgewell> | https://bocoup.com/blog/i-slipped-on-javascripts-banana-peel |
| 21:23 | <akirose> | i remember that blog post! |
| 21:23 | <leobalter> | I wonder if should have a place for RFCs at TC39, like this post |
| 21:24 | <rkirsling> | this looks interesting |
| 21:28 | <ljharb> | ystartsev: making repos is cheap; i'd prefer a new repo over the reflector |
| 21:30 | <Bakkot> | yeah I would like a new private repo, announced on the reflector |
| 21:30 | <Bakkot> | that seems like the way to go |
| 21:30 | <akirose> | So my question was about where this was _intended to_ live |
| 21:31 | <ljharb> | i'd assume in the tc39 org - in a document in the spec repo, or in a separate repo |
| 21:31 | <ljharb> | eventually it should be public |
| 21:31 | <akirose> | Should it be a PR to How We Work? |
| 21:32 | <michaelficarra> | tc39/process-document? |
| 21:32 | <ljharb> | sure, once mostly agreed upon that would work too i think |
| 21:32 | <ljharb> | but if it's meant to be normative it seems like it should be in one of the repos related to normativity (process document is a good candidate too) |
| 21:33 | <akirose> | i think choosing between how we work vs process document will distinguish it's… formality? |
| 21:33 | <ljharb> | i would hope that these invariants, while changeable, otherwise constrain proposals |
| 21:35 | <rickbutton> | MylesBorins: you are unmuted |
| 21:35 | <MylesBorins> | tyvm |
| 21:35 | <MylesBorins> | that could have gone... badly |
| 21:36 | <Bakkot> | akirose I vote how-we-work because less formal hopefully means less exegesis of the document during meetings |
| 21:37 | <akirose> | i concur |
| 21:39 | <robpalme> | i thought how-we-work was considered as rough guidelines. whereas the process doc is more akin to rules. |
| 21:39 | <Bakkot> | yup |
| 21:39 | <akirose> | yeah how we work is guidance on how to participate |
| 21:39 | <ljharb> | i would prefer these end up as rules, but obv it's fine to evolve there from being guidance |
| 21:39 | <ljharb> | changeable rules, ofc |
| 21:40 | <robpalme> | maturing via HWW seems fine |
| 21:40 | <Bakkot> | I would prefer not rules, because the rules for this kind of thing need to be kind of loose, in my experience |
| 21:41 | <Bakkot> | the whole business of language design is weighing values, and it is impossible to write down all the values and their weights |
| 21:41 | <ljharb> | super sad about the loss of Object.prototype.toString :-( |
| 21:41 | <devsnek> | is it too bold to say that infallible allocation is a good invariant |
| 21:41 | <michaelficarra> | Bakkot: wasn't that ystartsev's whole thing just now? |
| 21:42 | <Bakkot> | michaelficarra ystartsev had two things: invariants in the language, and some norms around process |
| 21:42 | <Bakkot> | invariants in the language seem good to write down |
| 21:42 | <Bakkot> | the rules for advancement seem like they need to stay more flexible |
| 21:42 | <ljharb> | fair |
| 21:52 | <devsnek> | ljharb: eqeqeq doesn't autofix |
| 21:52 | <devsnek> | it refuses |
| 21:52 | <ljharb> | that is true |
| 21:53 | <ystartsev> | Bakkot: we do have the "eliding the process" segment which might help |
| 21:53 | <ystartsev> | its part of the reason I wrote a more strongly worded approach |
| 21:54 | <ystartsev> | but i am also not opposed to loosening |
| 21:55 | <Bakkot> | ystartsev I haven't had a chance to read what you actually wrote yet, so I can't actually speak to this |
| 21:55 | <rkirsling> | oh man those pings on the line are throwin' me |
| 21:55 | <ystartsev> | Bakkot: thats in the existing process -- i will get my text up in a public location asap |
| 21:55 | <Bakkot> | ah, yeah |
| 21:55 | <ystartsev> | i don't think i can do it today, as i am afraid i might make a mistake (too tired) and there were some restrictions |
| 21:56 | <Bakkot> | not rush |
| 22:00 | <bterlson> | Have to head out friends. Thanks for a great meeting!! |
| 22:00 | <ystartsev> | im also out |
| 22:00 | <ystartsev> | thanks everyone for the great meeting |
| 22:00 | <leobalter> | big thank you to the chairs and everyone who helped facilitating this meeting |
| 22:02 | <jridgewell> | Have there been any messages in #tc39-beginners? |
| 22:02 | <ljharb> | last was 1.5 hours ago |
| 22:02 | <jridgewell> | Hah |
| 22:02 | <haxjs> | This is the first time i know this channel exist |
| 22:03 | <devsnek> | jridgewell: https://www.irccloud.com/log-export/111793/irccloud-export-280155-2020-07-23-17-02-54.zip |
| 22:03 | <jridgewell> | The previous link was t39, not tc39 |
| 22:03 | <jridgewell> | I've been idling in a misspelled channel name |
| 22:03 | <devsnek> | its your channel now |
| 22:03 | <Bakkot> | someone have a link to the beginners channel? |
| 22:04 | <devsnek> | #srennigeb-93ct |
| 22:05 | <Bakkot> | thank |