| 00:08 | <shu> | for the ResizableArrayBuffer rounding discussion, i filed two issues: https://github.com/tc39/proposal-resizablearraybuffer/issues/23 and https://github.com/tc39/proposal-resizablearraybuffer/issues/24 to separate the questions of rounding maxByteLength vs byteLength, please let me know of your thoughts in there |
| 00:14 | <devsnek> | shu: is there a chance the rounding could be used for fingerprinting? |
| 00:17 | <shu> | devsnek: yeah, i called that out in the presentation. depending on the degree of implementation latitude allowed |
| 00:18 | <shu> | devsnek: i'm not sure how much of a fingerprinting concern that is vs other vectors |
| 00:18 | <devsnek> | yeah, its nice to keep a handle on though |
| 00:19 | <shu> | it'll tell you the version(s) of the VM you're on, probably, but not much else |
| 00:19 | <shu> | that kind of fingerprinting is inherently built-in via other vectors as well |
| 01:58 | <shu> | rbuckton: do you happen to have any links to positive or negative sentiment expressed for match indices? |
| 01:58 | <shu> | a recent refinement of the blink shipping process is evidence supporting "developer signal" |
| 01:59 | <shu> | i thought we have captured in the notes somewhere that non-browser dev practitioners (e.g. ljharb) would use match indices if they were available, but i can't find it |
| 02:05 | <ljharb> | i don't have concrete use cases off hand, but i have clear memories of needing this functionality in the past |
| 02:06 | <ljharb> | shu: probably not, but does 304 votes on https://twitter.com/ljharb/status/1154100770985242624 help? |
| 02:09 | <shu> | ljharb: yes it does! |
| 02:09 | <ljharb> | yay |
| 02:09 | <shu> | well, at least obliquely |
| 02:09 | <ljharb> | it's not *no* signal, i guess |
| 02:09 | <shu> | the amount of votes show that a some devs in the wild care about it |
| 02:10 | <ljharb> | a few replies also |
| 02:10 | <shu> | and we can probably reasonably extrapolate that a portion of the 300 participants are non-browser devs |
| 02:10 | <shu> | yeah, the replies are good |
| 02:10 | <shu> | i am not happy about this new shipping process requirement, given that i think tc39 already represents practitioner constituents directly through delegates such as yourself |
| 02:11 | <shu> | but otoh, having evidence too show there's positive sentiment does seem fair |
| 02:11 | <ljharb> | sure |
| 02:11 | <ljharb> | but also, a tweet "do yall like this?" from a chromium account would probably answer that rapidly |
| 02:11 | <shu> | what am i, devrel? |
| 02:11 | <ljharb> | lol |
| 02:12 | <shu> | (no disparagement too devrel, but being that popular seems hard) |
| 02:12 | <shu> | stupid key sticking on the mba keyboard |
| 13:10 | <littledan> | I'm pretty unsympathetic to both the strong-pro and strong-con arguments on return |
| 13:11 | <littledan> | I don't think that we have to care so much about programmers suddenly generating an intuition that do expressions get their own return semantics |
| 13:11 | <littledan> | I mean, there's a completely unbounded amount of possible intuitions people could get. It just isn't possible to control for these. |
| 13:12 | <littledan> | On the other hand, I don't mind restricting the "power" of do expressions to not let them do control flow that jumps over their boundaries; that feels reasonable |
| 18:00 | <robpalme> | anyone having trouble getting into the meeting? |
| 18:00 | <robpalme> | we have 16 folk in |
| 18:09 | <rkirsling> | littledan: I don't think I understand what position you're expressing (aside from the last sentence which makes sense) |
| 18:09 | <littledan> | rkirsling: That, I'd be OK with return being permitted or prohibited from do expressions |
| 18:10 | <littledan> | what I disagree with is the strong arguments that it must be included or excluded |
| 18:10 | <rkirsling> | ah yeah. I agree with that |
| 18:12 | <michaelficarra> | haxjs: are you currently available for your presentation? |
| 18:15 | <michaelficarra> | is the transcription bot dead? |
| 18:15 | <michaelficarra> | never mind, it just got congested |
| 18:17 | <ryzokuken> | is IRCCloud okay? |
| 18:17 | <rickbutton> | works for me |
| 18:18 | <ljharb> | given that it wouldn't make any sense at all to allow `return` in `async do`, it seems like thats a consistency argument to forbid `return` in `do`. |
| 18:18 | <ryzokuken> | rickbutton: do you see the netsplits? |
| 18:18 | <ryzokuken> | or is it something on my end? |
| 18:18 | <ljharb> | what is graalix (sp) ? |
| 18:18 | <rickbutton> | only if the return returns from the surrounding function, not the do ljharb, but yes i agree with the consistency argument |
| 18:19 | <rkirsling> | oh phew it's back |
| 18:19 | <ljharb> | rickbutton: true. if it returns just from the `do` it could work in both |
| 18:19 | <rkirsling> | supposedly unstable more than completely out: https://twitter.com/IRCCloud/status/1354490157563572228 |
| 18:23 | <gibson042> | ljharb: I've seen it as "grawlix" |
| 18:23 | <gibson042> | https://en.wiktionary.org/wiki/grawlix |
| 18:23 | <ljharb> | gibson042: ty |
| 18:24 | <ljharb> | rkirsling: i must be on ipv4, i didn't notice any issues |
| 18:24 | <TabAtkins> | ljharb: I dont' understand - why wouldn't it make sense to `return` in `async do`? |
| 18:24 | <TabAtkins> | It seems to make exactly as much sense as returning in a sync do. |
| 18:24 | <ljharb> | TabAtkins: kevin explained, because the containing function has already returned |
| 18:25 | <TabAtkins> | OH WAIT |
| 18:25 | <TabAtkins> | I'm being dumb, ignore me |
| 18:25 | <TabAtkins> | Yeah, the async context would prevent a `return` from escaping |
| 18:25 | <ljharb> | right |
| 18:25 | <ljharb> | "early exiting the `do` with an explicit value" makes sense in both |
| 18:25 | <ljharb> | but "early returning the containing function" can only work in sync do |
| 18:25 | <ystartsev> | I had the same comment as shu, but yep that is our concern as well |
| 18:26 | <TabAtkins> | Yes. So I agree, given that I think `async do` is a must-have on top of sync-do, and `return` would *necessarily* do something local in async-do, *and* `return` in sync-do has two different obvious things it could do, we should just ban `return` in sync-do. |
| 18:27 | <rickbutton> | i still argue that only one of those obvious things is obvious |
| 18:27 | <rickbutton> | (to me, a return inside a do does not imply return from outer function) |
| 18:28 | <ljharb> | TabAtkins: that is my conclusion as well |
| 18:28 | <TabAtkins> | i popped a comment on the queue to state it on record |
| 18:28 | <ljharb> | sweet |
| 18:29 | <TabAtkins> | rickbutton: It was perfectly obvious to me that it would return from outer function, so my statement was correct that there are two obvious things. ^_^ |
| 18:29 | <rickbutton> | yeah i understand i just really want to be able to early return from these |
| 18:30 | <ljharb> | make a follow-on for a new keyword to do it :-p |
| 18:30 | <TabAtkins> | yup |
| 18:30 | <rickbutton> | gross |
| 18:30 | <ljharb> | `return.from.do.expression value` |
| 18:30 | <rickbutton> | early_exit |
| 18:30 | <ljharb> | `return.{} value` |
| 18:30 | <rickbutton> | do.return |
| 18:30 | <ljharb> | ha, nice |
| 18:30 | <rickbutton> | ugh, they keep getting worse |
| 18:31 | <TabAtkins> | meta properties are real :millie-bobby-brown-mind-blown-gif: |
| 18:31 | <ljharb> | `do.yield` |
| 18:31 | <rickbutton> | gotta get do generators first |
| 18:31 | <ljharb> | oh_no.jpg |
| 18:32 | <rickbutton> | I'm gonna keep playing devils advocate and say that you could say the opposite, that the fact that async-do return can only work one way, that sync should just also work that way |
| 18:32 | <rickbutton> | troll.png |
| 18:33 | <ljharb> | ban it from both, yes |
| 18:33 | <ljharb> | (i don't actually care about yield either way) |
| 18:34 | <ljharb> | wsdferdksl: what's the confusion about `this`? |
| 18:34 | <ljharb> | littledan: jinx, you owe me a coke |
| 18:34 | <littledan> | haha |
| 18:36 | <littledan> | I guess Waldemar was doing a kind of reductio ad absurdum and wasn't actually arguing to ban `this` |
| 18:36 | <littledan> | so, I don't think I'll follow up with it in the issues |
| 18:37 | <michaelficarra> | maybe we disable transcription for this topic? |
| 18:38 | <ryzokuken> | michaelficarra: I guess it would be best to manually transcribe? |
| 18:38 | <TabAtkins> | I also don't understand what the `this` confusion could even possibly be. Where would you get the `this` binding other than from the outer context? |
| 18:39 | <michaelficarra> | ryzokuken: I think so, yes |
| 18:47 | <ystartsev> | huh.. is that the right understanding ljharb? i was thinking that the brand check would be from the class, and you wouldn't need to check each one? |
| 18:48 | <ljharb> | ystartsev: it depends how rigorous you need to be; technically you can have one private field installed on a number of objects, and other private fields on other objects |
| 18:48 | <TabAtkins> | rickbutton: I'm curious why your intuition says that `return` in sync-do should be block-local, but `await` and `yield` escape the block. |
| 18:48 | <ljharb> | ystartsev: but it's pretty obscure. in the common case, the checks are basically the same - whether "has one field", "has all fields", or hax's "is class C" |
| 18:49 | <rickbutton> | TabAtkins: I don't think await and yield should escape the block, if return doesn't either |
| 18:49 | <ystartsev> | cool, thanks for clarifying |
| 18:49 | <ljharb> | ystartsev: so for the common case, it's just about which is clearer to understand. my argument is that both are needed for that, and mine is the lower-level one that the higher-level one can be built with; hax's can add the higher-level one on top. |
| 18:49 | <TabAtkins> | Ah, k. So that makes sync-do much less useful in async contexts. (yield is definitely of marginal utility either way) |
| 18:50 | <TabAtkins> | Hmmmm I can feel my intuition reconfiguring, I'll have to write an issue. |
| 18:50 | <rickbutton> | yeah, you would instead use an async do in an async context |
| 18:51 | <rickbutton> | yeah plz do, ill comment my thoughts too. im not an objector either way, do/async do will have great utility either way |
| 18:51 | <TabAtkins> | Ehhh that's just more keywords scattered about. Would mean that if your do-expr needs to await something, you have to prefix it with `await async` |
| 18:51 | <rickbutton> | further down the rabbit hole, do inside async is implicitly an async do |
| 18:51 | <rickbutton> | feels gross |
| 18:52 | <rickbutton> | actually nvm |
| 18:52 | <littledan> | I'm kinda confused by examples. None of them field initializers, so instances will either have all fields or none, so I don't understand this point about checking all of the fields. You should only ever check one. |
| 18:52 | <rkirsling> | rickbutton: no that distinction was addressed |
| 18:53 | <ystartsev> | wsdferdksl: do you want to ask that clarifying question now or is it ok to wait until he finishs? |
| 18:53 | <rickbutton> | yes, sorry missing words from that sentence, i mean to suggest that as an alternative to requiring an async do inside async ctx in order to await inside do, not that async/sync do inside async ctx are the same |
| 18:53 | <rickbutton> | but either way bad idea ignore it |
| 18:59 | <robpalme> | it sounds like, if the class uses class.hasInstance, we expect the implementation to tag the instances somehow so that the check can occur later. and the reason for the "if" is that this tagging may have a memory overhead. |
| 19:04 | <ljharb> | ystartsev: 3 replies,. waldemar's is first |
| 19:05 | <ystartsev> | whoops, it jumped ahead |
| 19:08 | <ljharb> | ooh, very good question |
| 19:12 | <littledan> | to be concrete, it sounds like Hax is proposing that this get added in the same way as methods (at the beginning of the fields). Is that accurate? |
| 19:13 | <ljharb> | it's not clear if it would install a new field and check for that, or if it would check for "all expected private fields" |
| 19:14 | <littledan> | OK, it sounds like the idea is to leave this as an open question for later |
| 19:17 | <ljharb> | ystartsev: these are stage 2 concerns, can we maybe defer them? |
| 19:18 | <jridgewell> | just now joining. How does `hasInstance` work with subclasses? |
| 19:19 | <ljharb> | jridgewell: it'd return true as long as the subclass called super, i assume |
| 19:19 | <ljharb> | just like `#x in o` would |
| 19:19 | <jridgewell> | Ok |
| 19:22 | <littledan> | I support Stage 3 |
| 19:32 | <michaelficarra> | I am deeply appreciative of the unique perspective that Bradley brings to committee :-) |
| 19:32 | <akirose> | me too! |
| 19:33 | <wsdferdksl> | Agree |
| 19:34 | <akirose> | also something i was thinking about is how much i respect how a handful of y'all are super comfortable saying "i don't know" (Bradley included) when relevant. the committee does better work because of it. |
| 19:40 | <shu> | ystartsev: request for facilitator to keep discussion on GC short |
| 19:40 | <shu> | it's not that material imo |
| 19:40 | <gibson042> | haxjs: given `class C extends class{constructor(v){return v}} { constructor(){super(...arguments)} #a; #x = (()=>{throw new Error()})(); #b; }`, evaluating `new C({})` will add private field #a but *not* #b |
| 19:40 | <ystartsev> | ok |
| 19:42 | <haxjs> | @gibson042 , I understand that. The issue is whether such edge case is strong enough to support another individual syntax feature for that. |
| 19:42 | <gibson042> | what do you mean by "another" individual syntax? |
| 19:42 | <littledan> | maybe we can ask for acknowledgement? |
| 19:44 | <bradleymeck> | forgot i had to connect, sorry |
| 19:44 | <bradleymeck> | littledan: to my knowledge per my reading, a finalizer never *must* fire, but it appeared it cannot fire if its target is stored in a private field? |
| 19:45 | bradleymeck | goes back rereading weakrefs |
| 19:46 | <haxjs> | @gibson042 I mean use `#x in o` to test these edge cases. |
| 19:47 | <gibson042> | yes, the point of this proposal is to make it more ergonomic to detect the presence vs. absence of a private field |
| 19:47 | <gibson042> | it adds no new capability, just syntax sugar |
| 19:48 | <shu> | what is going on |
| 19:48 | <ystartsev> | we want to make sure we don't go ahead without a soun check |
| 19:49 | <ljharb> | we don't want technical difficulties or language barriers to cause someone's voice to go unheard. |
| 19:49 | <shu> | ah okay, sg |
| 19:51 | <wsdferdksl> | ystartsev: Thank you for herding cats this morning! |
| 19:51 | <ystartsev> | that was one of the harder ones! |
| 19:51 | <littledan> | well-done ystartsev ! |
| 19:51 | <rickbutton> | fantastic job |
| 19:52 | <wsdferdksl> | I agree |
| 19:53 | <ljharb> | ystartsev: +1, thank you very much for chairing a contentious topic so calmly |
| 19:54 | <shu> | +2 |
| 19:57 | <robpalme> | can the google folk make sure Frank Tang is around to present next |
| 19:58 | <shu> | i will ping him |
| 19:58 | <shu> | first up after lunch? |
| 19:58 | <robpalme> | it's ok - he is here on the call |
| 20:01 | <Bakkot> | if anyone is in touch with the person who was on the call as "Zelda Jay", can you ask them to add their preferred abbreviation to https://github.com/tc39/notes/blob/master/delegates.txt ? |
| 20:02 | <Bakkot> | (or tell me which one it is, if they're already on it) |
| 20:11 | <ljharb> | i believe it's LZU |
| 20:12 | <ljharb> | haxjs ^ can you confirm? |
| 20:12 | <haxjs> | confirm what? |
| 20:13 | <ljharb> | haxjs: that zeldajay is limin zhu |
| 20:13 | <haxjs> | Ok I will check that |
| 20:14 | <ljharb> | thanks! |
| 20:14 | <ljharb> | (if not, then "which abbreviation in delegates.txt is zeldajay") |
| 20:14 | <haxjs> | It should be LZJ |
| 20:15 | <ljharb> | aha ty |
| 20:15 | <haxjs> | zeldjay is Zhi Jie Li (LZJ) I believe |
| 20:15 | <ljharb> | https://github.com/tc39/notes/blob/master/delegates.txt#L372, perfect |
| 20:15 | <ljharb> | Bakkot: ^ |
| 20:15 | <ljharb> | i remembered an L and a Z but wasn't sure which :-) |
| 20:15 | <Bakkot> | thanks! |
| 20:15 | <haxjs> | he is not online now, i will update if i make it wrong. |
| 20:15 | <ljharb> | perfect |
| 20:23 | <Bakkot> | I made a survey about do-expressions. I'd highly appreciate if delegates could fill it out; it should only take a second: https://docs.google.com/forms/d/e/1FAIpQLScyNcGNfjoJXMTmfBkLRMREKCP2TihiFGqc26HhjL4710qdiA/viewform?usp=sf_link |
| 20:24 | <Bakkot> | akirose / other chairs: if we have a spare minute or two today, I'd like to speak on the VC to ask people to fill it out |
| 20:27 | <akirose> | robpalme: heads up ☝🏻 would you like me to explicitly put it on the schedule? |
| 20:28 | <robpalme> | plz |
| 20:29 | <ystartsev> | Bakkot: can i share it with my team? |
| 20:29 | <Bakkot> | ystartsev sure! |
| 20:29 | <ystartsev> | sweet |
| 20:30 | <Bakkot> | ask them to put "(mozilla)" in their "who are you", maybe, so I know who they are? |
| 20:30 | <robpalme> | *** we restart at 12:50 PT *** i.e. 10 mins earlier than usual |
| 20:31 | <ystartsev> | Bakkot: will do -- if any get missed and you aren't sure you can run the names by me and i will confirm if they are from my team |
| 20:31 | <Bakkot> | √ |
| 20:49 | <robpalme> | *** we are starting in 1 minute *** |
| 20:51 | <robpalme> | bakkot - are you good with notes? |
| 20:52 | <Bakkot> | robpalme yup |
| 20:52 | <robpalme> | thank you (i forgot to ask) |
| 21:00 | <sffc> | I'm prepared to give eraDisplay for Stage 1 today if there's time |
| 21:00 | <sffc> | it's currently scheduled for tomorrow |
| 21:01 | <robpalme> | thank you, sffc, I think we will take you up on that |
| 21:25 | <michaelficarra> | since all these functions are going to have different names, should we have a `Symbol.brandChecker` that is a getter for the brand checking function for that particular built-in? |
| 21:25 | <Bakkot> | not sure if seroius |
| 21:25 | <Bakkot> | but |
| 21:25 | <Bakkot> | no |
| 21:25 | <ljharb> | michaelficarra: on the constructor or the instance? |
| 21:25 | <michaelficarra> | the contructor |
| 21:26 | <ljharb> | either way, if we had a symbol, it wouldn't be robust unless that property was nonconfigurable/nonwritable |
| 21:26 | <michaelficarra> | Array.isArray is nonconfigurable? |
| 21:26 | <ljharb> | oh i see what you mean |
| 21:26 | <rickbutton> | suggestion: put a [[Brand]] Symbol on Map, make Object.hasBrand(myMap, Map) |
| 21:27 | <michaelficarra> | these things are robust only when you already have a pointer to them |
| 21:27 | <ljharb> | so not Map.isMap(), but just Map[Symbol.brandChecker]? |
| 21:27 | <michaelficarra> | rickbutton: that also works |
| 21:27 | <ljharb> | rickbutton: right, a single global method that looks up a symbol would be one approach |
| 21:27 | <michaelficarra> | ljharb: or both |
| 21:27 | <ljharb> | sure |
| 21:27 | <ljharb> | i'm fine with that, especially if the thing behind the symbol is a cacheable function |
| 21:27 | <michaelficarra> | yeah, it can be the same value |
| 21:30 | <bradleymeck> | littledan: per my comment; I'm curious if reliable check exists how/why it would differ from a public API for class.hasInstance |
| 21:31 | <ljharb> | bradleymeck: because regular classes wouldn't need to have anything by default more than `instanceof` |
| 21:31 | <ljharb> | bradleymeck: however if there's a symbol protocol, a user class could choose to make it more robust than that |
| 21:33 | <bradleymeck> | ljharb: if I install a Symbol.hasInstance on a 3rd party it wouldn't actually check that class has the internal slots |
| 21:33 | <ystartsev> | littledan ljharb can we write down the context that came to light regarding the thinking around brand checks? I can bug you next week. |
| 21:33 | <ljharb> | bradleymeck: right - but if that class author did so then it could check that |
| 21:33 | <ystartsev> | also, if anyone is curious, at() is not currently shipping. i believe we only had it behind a flag and that has not changed: https://bugzilla.mozilla.org/show_bug.cgi?id=1681371 |
| 21:33 | <ystartsev> | we almost turned it on |
| 21:33 | <ystartsev> | but the web compat issue came up just before we did |
| 21:33 | <bradleymeck> | ljharb: if it makes it non-configurable/writable yes, but this seems extremely uncommoon |
| 21:33 | <ljharb> | ystartsev: i don't know if anything "came to light", i think it's just that my request for module blocks made dan realize this was a problem worth solving holistically |
| 21:34 | <ljharb> | whereas i've always thought this, but thought it was a nonstarter given previous committee reaction to it |
| 21:34 | <ystartsev> | ljharb: i mean around the reasoning for the invariant |
| 21:34 | <ystartsev> | sorry, if that wasn't clear |
| 21:34 | <ystartsev> | because iiuc the context might be worth writing down? |
| 21:34 | <ljharb> | oh. i'm not sure there's any new reasoning? it's basically "make sure the thing i'm given is the thing i'm expecting" |
| 21:34 | <ljharb> | is, not "has the same interface as" |
| 21:36 | <ljharb> | shu: tbh the easiest fix for them is to add `'$' +` to the assignment/lookup of the key |
| 21:37 | <littledan> | which library was that? |
| 21:37 | <michaelficarra> | I thought the SugarJS usage was compatible though |
| 21:37 | <littledan> | these compatibility issues often have to do with how the methods are installed |
| 21:37 | <littledan> | like, if they are installed unconditionally, it's fine |
| 21:37 | <michaelficarra> | exactly, which Is why I think it was okay |
| 21:38 | <jridgewell> | I think they are using it as a map |
| 21:38 | <jridgewell> | Eg, random setting/lookup of keys |
| 21:38 | <jridgewell> | And `at` is a valid key for them |
| 21:39 | <rkirsling> | yeah 'at' is key from a query string of theirs |
| 21:39 | <littledan> | haxjs: Can we make sure that the version numbers are written in the notes so it can be followed up on later? |
| 21:40 | <haxjs> | sugarjs first version to 1.3.9 |
| 21:40 | <haxjs> | corejs 0.2.0 to the version they released 2 month ago |
| 21:41 | <ljharb> | wait, core-js 3 had string.prototype.at? |
| 21:41 | <haxjs> | yes |
| 21:41 | <ljharb> | i thought core-js 3 stopped shipping pre-stage-3 proposals by default, hm |
| 21:41 | <haxjs> | they always have. |
| 21:41 | <haxjs> | no, if u import 'core-js' u will have everything. |
| 21:41 | <haxjs> | include pre-stage-3 |
| 21:41 | <ljharb> | ouch, ok |
| 21:41 | <shu> | ljharb: i'm just waiting for them to respond; yes, i imagine there're a variety of ways to do a quick fix |
| 21:42 | <ljharb> | core-js has almost disrupted as much as mootools by now :-( |
| 21:42 | <haxjs> | the good news is babel-runtime will not take these polyfills. |
| 21:43 | <haxjs> | but still very dangerous |
| 21:43 | <haxjs> | especially string case is very subtle. |
| 21:52 | <Bakkot> | survey: https://docs.google.com/forms/d/e/1FAIpQLScyNcGNfjoJXMTmfBkLRMREKCP2TihiFGqc26HhjL4710qdiA/viewform?usp=sf_link |
| 21:53 | <Bakkot> | https://docs.google.com/forms/d/e/1FAIpQLScyNcGNfjoJXMTmfBkLRMREKCP2TihiFGqc26HhjL4710qdiA/viewform?usp=sf_link |
| 21:55 | <haxjs> | There are some questions all options can't match my opinion precisely :) |
| 22:02 | <Bakkot> | haxjs feel free to use the "other concerns" box to explain in more depth! |
| 22:04 | <haxjs> | Yes, already submit. |
| 22:11 | <michaelficarra> | "at least as useful as an existing feature" seems like a high/arbitrary bar IMO |
| 22:19 | <akirose> | so we're all clear, and I _think_ this is a theme of the comments but also i seem to be struggling to follow complex thoughts this afternoon, nothing we do will eliminate the fact that humans are making these decisions and humans are fallible |
| 22:20 | <littledan> | server-side apps have resource limitations as well |
| 22:20 | <akirose> | we're not trying to pretend that we can magically objective (yes i'm using that as a verb) our decisions, right? |
| 22:20 | <littledan> | but, yeah, I agree, we should consider all of these things |
| 22:24 | <wsdferdksl> | Agenda for tomorrow afternoon is rapidly shrinking… |
| 22:26 | <brad4d> | re: .at() I was surprised that a single website was sufficient to force unshipping. Is bricklink especially important? |
| 22:27 | <brad4d> | It's a LEGO marketplace. :) |
| 22:28 | <robpalme> | so... yes? |
| 22:29 | <brad4d> | I guess I'm kind of amazed that we ever manage to ship anything - not trying to be mean if that how it sounded |
| 22:29 | <akirose> | we take "don't break the web" very seriously |
| 22:29 | <rkirsling> | the sins of the past have certainly made adding methods to builtins difficult |
| 22:29 | <ljharb> | space jam website 4 eva |
| 22:29 | <michaelficarra> | someone needs a space jam link |
| 22:30 | <michaelficarra> | ljharb: lol beat me to it |
| 22:30 | <akirose> | lolol |
| 22:30 | <rkirsling> | https://spacejam.com |
| 22:31 | <brad4d> | in this case it's clearly a business that would be harmed - if it were, say, my personal website, that wouldn't have forced unshipping would it? |
| 22:31 | <ystartsev> | this is starting to sound all very familiar |
| 22:32 | <ljharb> | brad4d: there's no hard rule, but it tends to depend on popularity and cultural relevance a bit |
| 22:32 | <ljharb> | brad4d: iow, would web users switch browsers if that was what it took to make your website work? |
| 22:32 | <michaelficarra> | brad4d: I think it's much more about popularity than "does someone's livelihood depend on this?" |
| 22:32 | <ljharb> | if the answer is "my mom would" then i doubt it'd obstruct anything |
| 22:32 | <rkirsling> | data is collected by the browser vendors to see whether stuff seems to have broken |
| 22:33 | <ljharb> | but if the answer is "tens of thousands of people would" it might matter |
| 22:33 | <rkirsling> | that data is extremely important wrt stage 4 advancement |
| 22:34 | <ystartsev> | I feel like something like a framework would work reallywewll here |
| 22:34 | <ystartsev> | for designing studies |
| 22:35 | <rickbutton> | re: bricklink, imo it would be harmful to use any other metric than traffic/browser usage, tc39 shouldn't take an opinion on the usefulness of a website to the greater web |
| 22:35 | <rkirsling> | ^ |
| 22:35 | <Bakkot> | well, and how broken the page was |
| 22:36 | <ljharb> | agreed |
| 22:36 | <Bakkot> | "can't spin your 3d objects" is less serious than "can't log in", or whatever |
| 22:36 | <rickbutton> | sure |
| 22:36 | <rickbutton> | also depends on actual impact to said site |
| 22:36 | <ljharb> | rickbutton: well. i think it's reasonable when there's small usage, if the site is still particularly important for some other reason, that we protect it |
| 22:36 | <akirose> | historical significance ain't nuthin. (though the manner in which we introduce our own biases is a whole other conversation) |
| 22:36 | <rickbutton> | sure ljharb, would be real unfortunate if we shipped a proposal that broke tc39.es, even it if doesn't get much traffic :) |
| 22:37 | <ljharb> | ha, yes |
| 22:37 | <ljharb> | altho i'd hope evangelism would help us there |
| 22:37 | <rickbutton> | or maybe broke the website that hawaii used to send nuclear bomb alerts, for example |
| 22:37 | <rickbutton> | (wasn't a browser break that caused that, was a misclick) |
| 22:38 | <shu> | brad4d: to be clear, that was not a TC39 decision to unship |
| 22:39 | <shu> | brad4d: that is a product decision i made for v8 and chrome, and someone else made for safari |
| 22:39 | <rkirsling> | that too |
| 22:39 | <brad4d> | also related to .at(): even if unshipping hadn't occurred, wouldn't it have been too soon to ask for stage 4? |
| 22:39 | <rkirsling> | tc39's decision is really based on "are browser vendors willing to ship this" |
| 22:39 | <shu> | brad4d: it would've had 3 shipping implementations, so no, seems fine? |
| 22:39 | <rickbutton> | it would have landed in chrome and safari if not for the unship |
| 22:39 | <brad4d> | https://github.com/tc39/how-we-work/blob/master/champion.md |
| 22:39 | <rkirsling> | no it would have been the perfect time to ask for Stage 4 |
| 22:39 | <brad4d> | "significant in-the-field experience" |
| 22:39 | <rkirsling> | the problem was detected in the nick of time |
| 22:40 | <brad4d> | doesn't that mean it has to have been out there and being used by developers for some reasonable period of time? |
| 22:40 | <ystartsev> | shu: sorry i think i came across as overly negative there |
| 22:40 | <shu> | brad4d: canary was shipping for whole release cycle, almost |
| 22:40 | <shu> | brad4d: we don't have a quantified "reasonable period of time" |
| 22:40 | <shu> | ystartsev: oh i didn't take that tone at all |
| 22:40 | <ystartsev> | i actually agree with what you were saying, i mostly wanted to add that -- hopefully there are tools and we are sort of trying to do that |
| 22:40 | <ystartsev> | with limited success so far, but hey |
| 22:41 | <shu> | ystartsev: i think it's really great you're doing the research group and it is a strict improvement where applicable |
| 22:41 | <ljharb> | brad4d: anyone using it would have to still work when it's absent |
| 22:41 | <shu> | ystartsev: in a way i was calling for more staffing investment in standards work |
| 22:41 | <ljharb> | brad4d: we don't worry about websites that are already broken on multiple browsers |
| 22:41 | <ystartsev> | shu: i totally support that |
| 22:42 | <brad4d> | shu: I thought you'd need your monitoring data to show a signifcant usage existed of `.at()` in real websites before you could move to stage 4 |
| 22:43 | <shu> | brad4d: oh, certainly not |
| 22:43 | <shu> | brad4d: popularity is not a requirement |
| 22:44 | <brad4d> | hmmm, I thought lack of sufficient usage was one reason why the various "field" proposals haven't moved to stage 4 |
| 22:44 | <shu> | ystartsev: cf how product features are aggressively (overly so!) a/b tested with data that may get abused etc |
| 22:44 | <shu> | ystartsev: we operate almost on the other end of the spectrum, and as such much of our debate is about how we feel, and how we think others would feel, about these proposals |
| 22:44 | <ystartsev> | yes, thats something that we need to be careful about -- that is where qualitative or mixed methods can help |
| 22:45 | <shu> | we of course _cannot_ a/b test feature proposals, because the output is interoperability |
| 22:45 | <shu> | yes, agree |
| 22:45 | <ljharb> | brad4d: not usage, just shipping |
| 22:45 | <ystartsev> | It also depends on the kind of question we want to answer (or if we know what the question really is) |
| 22:45 | <ystartsev> | This is something I've been thinking about in terms of our problem statements |
| 22:46 | <ljharb> | brad4d: afaik the combined class fields proposal was waiting on editor reviews of the updated PR, as well as more unflagged browser implementations |
| 22:47 | <rkirsling> | yeah JSC has been very behind on shipping those |
| 22:47 | <shu> | i thought igalia was helping out with implementation |
| 22:49 | <ystartsev> | Bakkot: halp |
| 22:49 | <Bakkot> | w? |
| 22:49 | <ystartsev> | i think the bot can be stopped? |
| 22:49 | <Bakkot> | ah, was gonna capture this bit too |
| 22:49 | <ystartsev> | never mind |
| 22:49 | <Bakkot> | will do the notes msyelf |
| 22:49 | <ystartsev> | spoke too soon |
| 22:51 | <rickbutton> | cant imagine a situation where we want to ship a proposal that has -no- support |
| 22:53 | <ystartsev> | 🤔 |
| 22:54 | <littledan> | I don't really see why we'd need a process change to note committee members' comments in the conclusion section of the notes for Stage 3 advancement, since the notes format is not described in the process document |
| 22:55 | <ljharb> | agreed |
| 22:58 | <Bakkot> | btw a feature of the notes bot is that it fixes some of the common substitutions the speech-to-text API makes: https://github.com/bakkot/transcribe-to-gdocs/blob/master/replacements.js#L5-L56 |
| 22:58 | <Bakkot> | which grows as I notice more |
| 22:59 | <Bakkot> | and when other people volunteer to take notes I can add them more readily and improve the experience for all future note takers |
| 22:59 | <Bakkot> | (hint hint) |
| 22:59 | <michaelficarra> | hahaha I didn't notice tempura |
| 22:59 | <shu> | copying over from my clarifications in tdz to here for more visibility |
| 22:59 | <shu> | what i'm asking is, concretely: |
| 23:00 | <shu> | so nothing formal, but that if you have direct anecdotal evidence of developer sentiment |
| 23:00 | <shu> | 14:55:52 it would be good to either relay that in committee discussion for it to be recorded in the notes, or, |
| 23:00 | <shu> | 14:56:14 if you are yourself a non-browser developer, put that hat on and speak to your own sentiment for whether you would use that or not |
| 23:00 | <shu> | 14:56:20 we already do this, but it's often implicit |
| 23:00 | <shu> | 14:56:36 some of us are very explicit, like yehuda |
| 23:00 | <shu> | 14:56:42 who often says "i would use this in ember today" |
| 23:00 | <shu> | 14:56:53 but if it were reflected in the notes that makes my life a lot easier |
| 23:01 | <ystartsev> | ok, thats clear, thanks |
| 23:04 | <shu> | ystartsev: from chrome's pov there's no work from other browser vendors |
| 23:04 | <shu> | "developer" here means non-web browser developer |
| 23:06 | <littledan> | I think we can simply call for folks to make statements about how they feel about this as a web developer, and write these in the minutes in the conclusion |
| 23:07 | <littledan> | (or, as JS developers in general) |
| 23:07 | <littledan> | we also have the frameworks and tools calls as a data source (though recent attendance of framework calls has been poor). The notes are public. |
| 23:16 | <shu> | littledan: +1 sgtm |
| 23:17 | <shu> | littledan: yes, i was already planning to use the minutes of the frameworks calls, thanks for calling that out |
| 23:19 | <jridgewell> | I see that _30m Revisiting RegExp.escape, Jordan Harband_ got moved to the end of the third day, which is now done? |
| 23:19 | <jridgewell> | But I don’t see it discussed in the notes |
| 23:20 | <jridgewell> | Should this on the agenda for day 4? |
| 23:20 | <ljharb> | jridgewell: we didn't have time |
| 23:20 | <ljharb> | the draft schedule will surely be updated for day 4, not sure when it'll be |
| 23:24 | <Bakkot> | can I get an admin of the tc39 org to make me an admin of the do-expressions repo? https://github.com/tc39/proposal-do-expressions/ |
| 23:24 | <Bakkot> | dave is fine with this but he's not an admin and so can't do it himself |
| 23:24 | <Bakkot> | (not sure who admins are, so not sure who to ping) |
| 23:25 | <ljharb> | Bakkot: chairs |
| 23:30 | <ljharb> | haxjs: don't forget to transfer your class brand checks repo into tc39-transfer |