| 00:00 | <Mathieu Hofman> | and yes I expected to be called out for that one |
| 00:00 | <bakkot> | counterpoint: i really want composite keys |
| 00:00 | <Michael Ficarra> | doesn't matter, we do the right thing |
| 00:00 | <ljharb> | i also want them, but i'm not sure why the two are linked |
| 00:00 | <Mathieu Hofman> | Manually building tries is a pain |
| 00:00 | <bakkot> | this proposal is just composite keys |
| 00:00 | <bakkot> | that is the whole proposal |
| 00:00 | <bakkot> | if I understand correctly |
| 00:00 | <ljharb> | oh |
| 00:01 | <ljharb> | right, but can't it just, like, do the nested weakmap + a finalization-registered weakref, in the spec? |
| 00:01 | <nicolo-ribaudo> | A goal of the presentation is for delegates to say "yeah let's just do composite keys", or "let's do R&T" |
| 00:01 | <Jesse (TC39 🇺🇸)> | I can't bother my pretty head with NaN and -0 |
| 00:01 | <ljharb> | then a composite key of the same object will never observably be a different object |
| 00:01 | <bakkot> | then you can't do a composite key of only primtiives |
| 00:01 | <bakkot> | which is bad and dumb |
| 00:01 | <ljharb> | have a parallel Map for that? |
| 00:01 | <bakkot> | then you leak |
| 00:01 | <bakkot> | which is bad and dumb |
| 00:01 | <ljharb> | only primitives go in the Map |
| 00:02 | <snek> | yeah that leaks |
| 00:02 | <ljharb> | oh |
| 00:02 | <ljharb> | hm |
| 00:02 | <bakkot> | this space is well-explored in userland |
| 00:02 | <snek> | you can't ever collect those entries because they're forgable |
| 00:02 | <ljharb> | then i guess we need === overloaded |
| 00:02 | <bakkot> | the links from the slides have a few different approaches |
| 00:03 | <Luca Casonato> | if you do the finalizationregistry thing, it does not leak if a composite key of only primitives become unreachable, even with a map, no? |
| 00:04 | <snek> | is the implementor worry that it will slow down all === occurances |
| 00:04 | <Mathieu Hofman> | It has to leak, because the components of the composite key would always be forgeable, the composite of them is forgeable |
| 00:04 | <kriskowal> | Yeah, I defined a bunch of collections before Map was added to the language, where you brought your own contentEquals contentCompare, which I suppose is analogous to species. |
| 00:04 | <Michael Ficarra> | is the implementor worry that it will slow down all |
| 00:04 | <bakkot> | I guess we could in principle say that a composite key of only primitives cannot be held weakly |
| 00:04 | <Luca Casonato> | what is this a response to? |
| 00:04 | <bakkot> | and maybe that solves the problem? |
| 00:05 | <Luca Casonato> | oh right yes obviously |
| 00:05 | <ljharb> | that seems perfectly reasonable |
| 00:05 | <Mathieu Hofman> | but what if it's an object ? |
| 00:05 | <ljharb> | (it makes an even stronger case for a built-in "isWeakable" predicate, ofc) |
| 00:05 | <nicolo-ribaudo> | I was expecting you to say "this breaks the predicate to check when I can put something in a weakmap" |
| 00:05 | <nicolo-ribaudo> | Oh there it is :) |
| 00:05 | <bakkot> | I do not understand the question |
| 00:06 | <ljharb> | having a non-weakable object is def weird too |
| 00:06 | <Mathieu Hofman> | See above discussion. An object is currently expected to be usable as a weak map key |
| 00:07 | <Michael Ficarra> | having a non-weakable object is def weird too |
| 00:07 | <ljharb> | they're both differently weird. which is weirder in aggregate |
| 00:08 | <bakkot> | (this would also require the thing from the previous presentation where non-extensible objects could not get stamped with private fields, incidentally) |
| 00:09 | <Michael Ficarra> | ooooo composite keys would obviate Array.prototype.uniqBy 😮 |
| 00:09 | <Michael Ficarra> | god I need this |
| 00:10 | <bakkot> | ... would they? |
| 00:10 | <bakkot> | I feel like they'd make it better tbh |
| 00:11 | <Michael Ficarra> | well that was entirely coincidental |
| 00:11 | <canadahonk> | whats the 4th form of equality? |
| 00:12 | <bakkot> | ===, ==, Object.is, SameValueZero |
| 00:12 | <canadahonk> | ohh SameValueZero |
| 00:12 | <littledan> | I was imagining that this would replace SameValueZero |
| 00:12 | <nicolo-ribaudo> | Also in [].includes? |
| 00:12 | <bakkot> | I mean, yeah, if we're modifying existing APIs |
| 00:14 | <snek> | shu: is it still held that === for r&t is too expensive? |
| 00:14 | <shu> | yes |
| 00:15 | <snek> | 😔 |
| 00:15 | <bakkot> | also reminder of the old https://github.com/tc39/proposal-richer-keys/tree/master/compositeKey |
| 00:16 | <bakkot> | these were === via interning (and requiring at least one weak component) instead of modifying collections |
| 00:16 | <bakkot> | but same goal |
| 00:21 | <bakkot> | also, phrasing these as "composite keys" makes it clear that you shouldn't be using these all over the place |
| 00:21 | <bakkot> | e.g. a new Object.entries-like API would not return these |
| 00:23 | <shu> | if they are actually composite keys and composite keys only, is the recursive part of it needed? |
| 00:24 | <bakkot> | I would want it to, so I wouldn't have to manually flatten the results of my .toKey methods everywhere |
| 00:26 | <shu> | fair enough |
| 00:26 | <bakkot> | (and it's not like it's any slower to do it recursively vs me manually flattening. faster, probably, since you can have a fast path if I was using actually the same inner object) |
| 00:28 | <bakkot> | libraries are allowed to have expectations and we're definitely allowed to break those expectations |
| 00:28 | <bakkot> | we added new typeofs! |
| 00:30 | <Michael Ficarra> | that was not good for some minifiers |
| 00:31 | <bakkot> | but that was ok |
| 00:31 | <Michael Ficarra> | only because I fixed them promptly |
| 00:32 | <Mathieu Hofman> | I expect this would be less brutal than new typeof |
| 00:32 | <ljharb> | p sure the forever goodness of new primitives outweighs one person's minifier fixing effort tho |
| 00:33 | <rekmarks> | Ashley Claymore: is there a repo for your r&t work? Is it just https://github.com/tc39/proposal-record-tuple? |
| 00:33 | <bakkot> | so, would -0 to 0 when using them in a map? |
| 00:33 | <bakkot> | presumably yes? |
| 00:33 | <littledan> | could we have more help from notetakers? |
| 00:33 | <nicolo-ribaudo> | I can help |
| 00:33 | <bakkot> | kind of annoying; that could be expensive. but I guess just don't have -0 |
| 00:34 | <littledan> | why would it? it'd just normalize during calculation of the hashcode itself, and then do comparison SameValueZero-wise |
| 00:34 | <Chris de Almeida> | do we need a PoO? |
| 00:34 | <littledan> | no |
| 00:34 | <littledan> | oh, yeah... because that's what maps do with scalars... |
| 00:35 | <littledan> | maybe we should just skip it here, though, since it'd be weird if the identity didn't actually match the first one that put it in |
| 00:35 | <bakkot> | Iiiiiiiii guess that would be ok? |
| 00:35 | <bakkot> | but in that case it would be better if we didn't normalize -0 |
| 00:36 | <bakkot> | too late for that though |
| 00:36 | <Aki> | PSA: The notes today are missing lots of summaries and conclusions. Please, speakers, make sure you record those while they're still fresh in your head. Take 5 minutes to save Samina & me thirty. |
| 00:36 | <Ashley Claymore> | I was exploring a slightly different design here: https://github.com/acutmore/proposal-keyby what I presented today needs a home (maybe the existing R&T repo?) |
| 00:50 | <Justin Ridgewell> | Is this James Snell speaking? |
| 00:50 | <Michael Ficarra> | yes |
| 00:53 | <snek> | is implementation slowness the only thing holding back r&t === (and other operator overloads like decimal addition?) |
| 00:53 | <Ashley Claymore> | the feedback also included the risk of changing existing JIT code |
| 00:54 | <Ashley Claymore> | i.e. the one line spec change does not map to a one line c++ change |
| 00:54 | <shu> | usual complexity concerns if it incentivizes ever-more-complex interning schemes |
| 00:54 | <shu> | harder and harder to tune |
| 05:04 | <ljharb> | (please nobody be concerned that the notes doc is no longer accessible; turns out hackmds are all fully indexed by google) |
| 07:44 | <eemeli> | I trust that the notes doc will be made accessible again at some point? |
| 08:08 | <ZiJian Liu> | Hi, thank you for everyone's feedback, this is the problem-statement document of the proposal Number.isSafeNumeric. If there are any questions or suggestions, feel free to comment in the Github Issue. Link: https://github.com/Lxxyx/proposal-number-is-safe-numeric/issues/4 Chris de Almeida |
| 13:48 | <snek> | what is the concrete implementation of `MV(str) is MV(F(MV(str)))`? Do you just have to check every possible "worthy"(?) serialization (e.g. unnormalized scientific notation, `0.N` vs `.N`, etc...) of the floating point value? |
| 14:14 | <ZiJian Liu> |
|
| 14:16 | <snek> | yeah I mean my point is that computers can't literally do MV(a) is MV(b) (otherwise floats wouldn't exist and we could all go home lol), so I imagine the only reasonable implementation to be a routine that switches through comparing different serializations depending on the format of the input. |
| 14:18 | <ZiJian Liu> | Thank you for the reply, yes, so this is pseudocode, not an actual implementation (just a convenient way to understand the problem, sorry for the confusion, I might need to make a special note about this formula) |
| 14:19 | <snek> | no it's fine to discuss abstractly, I'm just asking the room how they would approach concrete implementation |
| 14:30 | <Jesse (TC39 🇺🇸)> | I might have an internal representation of digit strings that would allow me to at least do an equality check |
| 14:31 | <snek> | so you'd first attempt to canonicalize the input I guess? |
| 14:58 | <waldemar> | What happened to yesterday's notes document? I get Access Denied trying to review it. |
| 15:08 | <Jesse (TC39 🇺🇸)> | so you'd first attempt to canonicalize the input I guess? |
| 15:13 | <Michael Ficarra> | What happened to yesterday's notes document? I get Access Denied trying to review it. |
| 15:42 | <Chris de Almeida> | The top secret notes document link (and TCQ link) were leaked, presumably by being present in the hackmd schedule, which gets indexed by search engines. We will share a new notes doc link on the reflector issue for the meeting. Also perhaps a new TCQ link. |
| 15:43 | <nicolo-ribaudo> | How do search engines find the hackmd document in the first place? Was it linked somewhere? |
| 15:45 | <Chris de Almeida> | not sure, but one way is that the hackmd links are sometimes shared in these public matrix channels, which get logged and those pages get indexed |
| 15:46 | <Chris de Almeida> | the hackmd pages themselves are not really a problem to be accessible (except maybe that anyone can edit them) -- but the fact the notes doc and tcq links appeared on them is the bigger issue |
| 17:03 | <Chris de Almeida> | new notes doc link is up on the reflector issue: https://github.com/tc39/Reflector/issues/547 |
| 17:16 | <Chris de Almeida> | new TCQ link is up on the reflector issue as well |
| 17:48 | <Chris de Almeida> | as the prophecy foretold |
| 18:01 | <Chris de Almeida> | many thanks to our note-takers from yesterday! 👏👏👏👏👏👏👏
|
| 18:01 | <nicolo-ribaudo> |
|
| 18:03 | <Michael Ficarra> | ooohh I actually didn't know we had the right to a minority report |
| 18:03 | <Michael Ficarra> | I appreciate that |
| 18:06 | <nicolo-ribaudo> | 📣📣📣 The new TCQ link is in the Reflector |
| 18:09 | <hax (HE Shi-Jun)> | I don't think single blocker is the issue, the issue is "unequal authority". |
| 18:10 | <hax (HE Shi-Jun)> | Is there any example of minority report in our history?? |
| 18:11 | <Michael Ficarra> | @hax (HE Shi-Jun) I don't think it was common knowledge that we had that ability |
| 18:11 | <Michael Ficarra> | so I'm not aware of any |
| 18:15 | <canadahonk> | 📣 don't forget to request more breakout session topics for this afternoon! https://github.com/tc39/Reflector/issues/552 |
| 18:22 | <bakkot> | I like the canPlayAudio API! |
| 18:22 | <Michael Ficarra> | I believe it's empty string actually |
| 18:22 | <Michael Ficarra> | which is close-enough to false |
| 18:23 | <ljharb> | ah thanks, it was off the top of my head |
| 18:23 | <Michael Ficarra> | an equally non-committal kind of false |
| 18:32 | <bakkot> | ok but SABs are actually good |
| 18:32 | <bakkot> | people should pick examples which are unambiguously bad if they want to make this point |
| 18:32 | <littledan> | if we had blocked SharedArrayBuffer in TC39, it wouldn't've blocked it from shipping, just reduced TC39's scope as it was standardized somewhere else |
| 18:33 | <littledan> | right, invoking Crockford and ES4 is also fraught here... |
| 18:33 | <shu> | the counterfactuals that mark invoke would not be a better outcome |
| 18:34 | <shu> | we simply don't have agreed upon goals for the language |
| 18:35 | <shu> | a veto in TC39 does not change those goals, and they will be realized in another way |
| 18:35 | <littledan> | my understanding is, historically, Mark, Waldemar, Crockford, Dave Herman and Allen W-B innovated/invented the block during the ES4 process; it is not a historical constant in this committee |
| 18:35 | <ljharb> | however, sometimes that realization is not "good faith" participation. |
| 18:35 | <littledan> | sometimes, but yeah |
| 18:35 | <littledan> | definitely in the SAB case |
| 18:35 | <bakkot> | if base64 had taken a single additional meeting I was going to do it in whatwg |
| 18:36 | <bakkot> | I was very close already |
| 18:36 | <ljharb> | iow sometimes if an entity hacks around an objection in TC39, it's not actually a good faith action. |
| 18:36 | <shu> | is your end goal to make sure everyone participates in tc39 in good faith? |
| 18:36 | <shu> | or is your goal to evolve the language? |
| 18:36 | <ljharb> | hopefully we're already there. |
| 18:36 | <shu> | the whole enterprise of standardization at all is a means to an end |
| 18:36 | <ljharb> | "evolve the language" implies good change. all change is not good change. |
| 18:36 | <shu> | it is not the end |
| 18:36 | <littledan> | I don't think "good faith" is a very useful lens. The committee has already advanced a lot in that we're not constantly referring to "good faith", which I think is a sign of... good faith |
| 18:37 | <Aki> | But I agree with Mark that generally, the dissent isn't to solving the problem overall |
| 18:37 | <Michael Ficarra> | I don't think "good faith" is a very useful lens. The committee has already advanced a lot in that we're not constantly referring to "good faith", which I think is a sign of... good faith |
| 18:37 | <bakkot> | one person's hacking around an objection in one standards body is another person's making progress in a less sclerotic organization |
| 18:38 | <shu> | i don't think good or bad faith matters |
| 18:38 | <ljharb> | all progress is also not always good process. |
| 18:38 | <shu> | who's saying that? |
| 18:38 | <ljharb> | maybe nobody, just making sure it's explicit |
| 18:38 | <canadahonk> | should we interrupt for the POO |
| 18:39 | <littledan> | well, there are clearly hypothetical things people could do that are bad faith, like behaving anticompetitively with respect to the standard under discussion, which is prohibited by Ecma rules (as it is in all standards bodies). But I don't think that ever happens here. |
| 18:39 | <Aki> | (I also agree with Michael Saboff—it has happened. It's just not usual) |
| 18:39 | <shu> | agreed, good clarification. that is a much dire form of bad faith that we basically never see here |
| 18:39 | <snek> | tc39 is the only standards committee i've interacted with where it feels like non-megacorps can drive any form of change. i don't think blocks are the only component of that but i think giving large equal power is definitely an important part of it. everything will have good faith and bad faith, and all you can do is strive for processes to be as non-destructive as possible. |
| 18:40 | <James M Snell> | @mlsaboff:matrix.org: if you'd like, I'm volunteering to collaborate on a concrete proposal for how the block process can be improved |
| 18:41 | <littledan> | equality is an important value of TC39; I don't think Michael's proposal questions that. |
| 18:41 | <canadahonk> | ngl i was onboard with the proposal but this (great) view has completely changed my mind |
| 18:41 | <ljharb> | but it does lessen it, even if unintentionally |
| 18:41 | <shu> | i don't understand mark's point |
| 18:42 | <canadahonk> | for the most part only big companies/browsers have more than 1 delegate so they could block themselves but smaller companies could not |
| 18:42 | <bakkot> | mark thinks it is important that browser vendors not have more power than everyone else |
| 18:42 | <shu> | if you believe browsers have de facto veto, no change to process (which is de jure) can change that |
| 18:42 | <bakkot> | since browser vendors necessarily have a veto, the only solution to keep parity is for everyone to have a veto |
| 18:43 | <shu> | ah, but, tc39 rules do not bound anybody to ship anything |
| 18:43 | <shu> | thus the disparity between de facto and de jure |
| 18:43 | <ljharb> | right, exactly |
| 18:43 | <snek> | oh of course i don't think it intentionally does. i would consider it more to be an emergent check against the power of implementors technically having their own "lone veto" anyway. not that i am accusing them of taking advantage of that at all. |
| 18:43 | <ljharb> | but the good faith part is that if browser makers provide consensus for stage 3, then they have in fact committed to shipping it |
| 18:43 | <ljharb> | if they weren't going to (or aren't able to commit to) ship it, or decide later not to, it's incumbent to block stage 3 or propose demotion |
| 18:43 | <Jesse (TC39 🇺🇸)> | I think this shoulnd't be a breakout topic |
| 18:44 | <bakkot> | strong +1, this is a topic for the whole committee |
| 18:44 | <canadahonk> | i can copy the queue into notes if people would like |
| 18:44 | <shu> | the current process actively is at odds with this mode IMO |
| 18:44 | <shu> | i'll speak to it later on the queue if we get to it |
| 18:45 | <shu> | ah we're tabling this? |
| 18:45 | <littledan> | we are continuing this afternoon |
| 18:46 | <littledan> | we will have an overflow topic, at least to go through the queue |
| 18:47 | <shu> | ljharb: in short, my view is that the veto culture in TC39 in practice works out to that stage advancement can mean "can we live with this proposal", not necessarily "are we actively supporting this proposal" |
| 18:47 | <ljharb> | oh i agree. but "live with" imo includes "will ship" whether you support it or not |
| 18:47 | <bakkot> | I didn't add myself to the queue because it was clear that we weren't going to get there, but I did have a topic to add re: often there is only ~two active voices of support for a proposal so requiring (in some cases) >2 active voices to veto seems silly |
| 18:47 | <shu> | and if we can merely live with something but do not actively support something, the committment to shipping it ASAP is not there |
| 18:48 | <ljharb> | i guess i really don't understand why a browser wouldn't block it in that case |
| 18:48 | <ljharb> | the expectation is that basically everyone will ship it in stage 3 |
| 18:48 | <shu> | there are many cases where we play catch up to reduce interop risk |
| 18:48 | <snek> | i will take merely live with over active support. like, the success rate seems pretty high? |
| 18:48 | <shu> | "will ship" on whose timeline? |
| 18:48 | <ljharb> | ok, so you're saying where you're gambling that others will ship it first, so that you're forced to play catchup? |
| 18:48 | <shu> | no |
| 18:48 | <littledan> | I wouldn't be opposed to increasing the support threshold. (But I also see the point about not making the veto threshold too high) |
| 18:49 | <ljharb> | i think it would be perfectly fine for a browser to say "consensus, but we won't ship first" - that way if every browser says that, we all know we have a problem |
| 18:49 | <Rob Palmer> | I wanted to push back on Mark's final statement that definitively stated "the rule we have is the only one that can work." We should be open to suggestions for process improvement. And it sounds like James Snell has ideas. And there are some the chair group has considerd too. So I'd like to be open minded and not assume it's a problem we cannot solve. |
| 18:49 | <shu> | that's fair, if you want that to be more explicit, that's a concrete change to the process we can talk about |
| 18:49 | <shu> | but priorities change, product strategies change |
| 18:49 | <ljharb> | oh sure |
| 18:49 | <bakkot> | yeah, my preferred solution would be to require significantly more active support for a proposal to advance, and then also raise the threshold for a veto. |
| 18:49 | <shu> | you want us to be locked in to some direction, you want promises. there will be no promises |
| 18:49 | <bakkot> | the change to require at least 2 active supporters was good |
| 18:49 | <littledan> | ultimately, if all browsers don't want to ship something, we should figure out how to coordinate on what the language is and not leave things indefinitely ambiguous. It's OK if you change your mind and decide against something. |
| 18:50 | <ljharb> | and a change doesn't imply bad faith at all, but i think it's incumbent on a browser to notify the committee if the "will ship" status changes |
| 18:50 | <Andreu Botella> | but priorities change, product strategies change |
| 18:50 | <bakkot> | but 2 active supporters and no active dissenters is such a low bar for changes to the language, we should have a higher bar |
| 18:50 | <Andreu Botella> | someone else can implement the proposal |
| 18:50 | <shu> | huh? |
| 18:50 | <Michael Saboff> | The point that I wanted to make last night is that for me, stage three is not intent to ship, it is we should start implementing. This is based on other priorities. |
| 18:50 | <ljharb> | maybe the reverse? "will ship" doesn't imply "will implement"? |
| 18:51 | <canadahonk> | 2 supporters from different representations? |
| 18:51 | <rekmarks> | Has anything failed to make it from stage 3 to 4 due to lack of browser implementations? |
| 18:51 | <shu> | right, my position has been stage 3 is an option to ship |
| 18:51 | <nicolo-ribaudo> | Decorators |
| 18:51 | <shu> | we reserve the right but are not obligated |
| 18:51 | <bakkot> | well, https://github.com/tc39/proposal-regexp-legacy-features is 8 years old |
| 18:51 | <bakkot> | I don't know about "failed" |
| 18:51 | <ljharb> | we can't obligate anyone. but the intention should be to ship imo |
| 18:51 | <bakkot> | because at any time people could implement it |
| 18:51 | <Andreu Botella> | huh? |
| 18:52 | <shu> | V8's position is we don't want to be the first to ship |
| 18:52 | <bakkot> | strictly speaking I don't think we said they had to be from different organizations but I don't think the question has actually arisen |
| 18:52 | <shu> | i take issue with that characterization |
| 18:52 | <ljharb> | that is fine but i think this is the first time that's been stated, and it's been stage 3 for a long time |
| 18:53 | <nicolo-ribaudo> | I mean, it's every browser's position. None of the browser is individually responsible, but it means that the proposal will not go to stage 4 unless somebody changes their mind |
| 18:53 | <Michael Ficarra> | Has anything failed to make it from stage 3 to 4 due to lack of browser implementations? |
| 18:53 | <littledan> | that's fine, but a major function of the standards committee is to coordinate expectations and plans; we can't force anyone to do anything, but I hope we can eventually understand each others' plans so we can help others in the JS ecosystem. |
| 18:53 | <littledan> | namely SIMD |
| 18:53 | <canadahonk> | |
| 18:54 | <ljharb> | what stage 4 requires is intentionally vague because nobody agrees on it, happy to provide more context later |
| 18:54 | <shu> | my question is then why can no individual browser be convinced to be the first to ship? |
| 18:54 | <shu> | we have different leadership, different priorities too |
| 18:54 | <bakkot> | the actual concern is not the nominal stage, it's whether it goes in browsers |
| 18:54 | <kriskowal> | Also polymorphic covers new Amount.from({value: "1/2", unit: "cup", precision: "1/16"}) |
| 18:54 | <bakkot> | something actually being stage 4 is pretty irrelevant |
| 18:54 | <littledan> | that's fine, so, eventually we should be able to digest all of that and figure out, OK so should we cancel the proposal |
| 18:54 | <Michael Ficarra> | I was thinking about Object.observe, but also that |
| 18:55 | <ljharb> | that was stage 2 |
| 18:55 | <rekmarks> | Stage 4 implies (requires?) browser implementations, though? |
| 18:55 | <littledan> | yeah this was a prominent block of Stage 3, by Yehuda |
| 18:55 | <snek> | the exact text is "implementations" not "browsers" |
| 18:55 | <littledan> | (and it was the right call!) |
| 18:55 | <Andreu Botella> | we have different leadership, different priorities too |
| 18:55 | <rekmarks> | But doesn't that always mean browsers in practice? |
| 18:55 | <snek> | its purposely vague, and in practice if the 3 largest js implementations don't ship something its problematic to call it "standardized" |
| 18:55 | <shu> | i'm not sure i understand the question |
| 18:56 | <Michael Ficarra> | Stage 4 implies (requires?) browser implementations, though? |
| 18:56 | <canadahonk> | per process doc "Two compatible implementations which pass the Test262 acceptance tests... Significant in-the-field experience with shipping implementations, such as that provided by two independent VMs" |
| 18:56 | <Chengzhong Wu> | only two are required |
| 18:56 | <shu> | having an implementation is a very small part of the decision to ship something |
| 18:56 | <canadahonk> | but in practice browsers yes |
| 18:56 | <ljharb> | nobody will make something stage 4 if it has zero browser implementations, no matter what the process doc says |
| 18:56 | <bakkot> | we have always required at least one browser but IIRC we've allowed some trivial things to go forward with only one browser actually finished implementing, if there was an implementation in babel or something |
| 18:57 | <rekmarks> | Seems sensible 👍️ |
| 18:57 | <bakkot> | for anything nontrivial we're going to need two browsers though yes |
| 18:58 | <shu> | these are not my words, but reflects on browser dynamics in W3C and WHATWG: https://ln.hixie.ch/?start=1721260117&count=1 |
| 18:58 | <bakkot> | huh, I didn't realize hixie was still writing on web stuff |
| 18:58 | <shu> | the footnote made it seem like he was goaded into it :) |
| 18:59 | <Michael Ficarra> | @Jesse (TC39 🇺🇸) Decimal as presented is normalised? |
| 18:59 | <ljharb> |
i'm not sure that's really true anymore tho :-/ |
| 18:59 | <nicolo-ribaudo> | Yes |
| 19:02 | <bakkot> | it is definitely true that a user of Firefox will choose to use Chrome or Safari if web pages don't work in Firefox |
| 19:02 | <bakkot> | not clear that there are choices beyond that |
| 19:02 | <bakkot> | (which is very sad) |
| 19:03 | <ljharb> | right |
| 19:03 | <snek> | whatwg/ietf (for example) continue to exist because they are effectively just implementors and no one else. tc39 continues to exist because it only attempts to steer implementations, it doesn't throw random stuff in and just expect it to then be implemented. anything further than tc39 doesn't exist anymore because its irrelevant to our shared reality. finding a good place within this spectrum is difficult, and i think some perhaps underdiscussed component of these arguments is where people think tc39 should land on this. |
| 19:03 | <littledan> | I'm not sure if that describes IETF... |
| 19:04 | <ryzokuken> | IETF WGs vary rather widely to make that sort of a generalization |
| 19:05 | <rekmarks> | This basically describes the power dynamics that exist between standards and implementors in cryptocurrency / blockchain as well (opportunity to coin the name of a Law here, folks) |
| 19:05 | <littledan> | do we have a link to the slides for this presentation? |
| 19:05 | <nicolo-ribaudo> | https://docs.google.com/presentation/d/1050DHlNOzcN-8LqJQ_6z8j-LryXgEqOcLfcVzkhJyEk/edit#slide=id.p, from the agenda |
| 19:06 | <rekmarks> | It's past tense 😉 |
| 19:07 | <jschoi> | Perhaps it would be “Hixie’s Law”, but I suspect that Hixie has made many other statements that one could enshrine as “laws”. Or maybe Hixie would say someone else came up with it first and told him. |
| 19:08 | <rekmarks> | Rarely do the coiners get to choose the law they lend their names to |
| 19:09 | <jschoi> | That smells like a new law to me… |
| 19:11 | <bakkot> | Stigler's Law of Eponymy, arguably |
| 19:11 | canadahonk | retires from note editing, could another person please aid |
| 19:13 | <jschoi> |
Oh, thank goodness, I was hoping that it would be autological. |
| 19:13 | <nicolo-ribaudo> | Fyi, there is a proposed breakout session for Decimal/Measure/Amount |
| 19:13 | <Aki> | Still need another notetaker |
| 19:13 | <Aki> | i think |
| 19:14 | <ryzokuken> | will pause for volunteers after this topic |
| 19:14 | <jschoi> | I’ll do it, I’ll get in a minute. |
| 19:15 | <eemeli> | @littledan:matrix.org: Regarding champion groups, I agree, but in this case the sole champion is not available. |
| 19:15 | <nicolo-ribaudo> | Agree, I think it's good going through the committee this time |
| 19:17 | <jschoi> | Could someone link the file with the speaker abbreviations? |
| 19:17 | <littledan> | sure, fine to discuss in committee if people want. I can see how in some cases it might be ambiguous whether a coworker in the same company is an appropriate choice. |
| 19:17 | <canadahonk> | https://github.com/tc39/notes/blob/main/delegates.txt |
| 19:17 | <ryzokuken> | https://github.com/tc39/notes/blob/main/delegates.txt |
| 19:19 | <jschoi> | Does anyone have slides for this new presentation? |
| 19:19 | <bakkot> | re: current topic, is the string "1234.567800000000033833202905952930450439453125" supposed to be allowed? |
| 19:19 | <jschoi> | I'm assuming they're not on the agenda. |
| 19:19 | <shu> | i have a hard time finding "most people are not aware of ieee754" compelling. it permeates to too much of the language beyond just storing values |
| 19:19 | <ljharb> | they're on the hackmd (via the reflector) |
| 19:20 | <Chengzhong Wu> | it's the previous one |
| 19:20 | <Chengzhong Wu> | not the one is presenting? |
| 19:20 | <Michael Ficarra> | if it's just about u64, it should be parsed by BigInt(), not Number() |
| 19:20 | <ljharb> | oh |
| 19:21 | <Michael Ficarra> | re: current topic, is the string "1234.567800000000033833202905952930450439453125" supposed to be allowed? |
| 19:21 | <bakkot> | ("1234.567800000000033833202905952930450439453125" is notable because it is the exact decimal representation of the float denominated by 1234.5678 in JS) |
| 19:21 | <bakkot> | well, as currently written it would not be |
| 19:21 | <Michael Ficarra> | don't pay attention to what is written, try to understand what they're going for |
| 19:22 | <shu> | this spreadsheet use case is very weird to me |
| 19:22 | <Michael Ficarra> | what is written has been wrong a dozen times in the last week |
| 19:22 | <bakkot> | I am unclear on what they're going for |
| 19:22 | <Jesse (TC39 🇺🇸)> | yes I think so? |
| 19:22 | <shu> | if your initial input happens to be representable "exactly" as float64, then you opt into ieee754 arithmetic on the sheet? |
| 19:22 | <shu> | if your initial input isn't, then you opt into big decimal arithmetic? |
| 19:22 | <bakkot> | "1234.567800000000033833202905952930450439453125" does arguably lose precision, in the sense that when you display the corresponding number to users it is going to be different than the input |
| 19:22 | <Michael Ficarra> | yeah that's weird |
| 19:23 | <kriskowal> | Last I checked, Uber’s JS API gateway is in this same exact world of pain. |
| 19:23 | <bakkot> | so if this is about losing precision when displaying values not just when parsing them, that string should be rejected |
| 19:23 | <snek> | so i woke up at 3am and spent like two hours interrogating the examples and motivation and came to the conclusion that they want "MV(str) is MV(F(str))" (assuming that MV(str) is defined to exist). |
| 19:24 | <snek> | secondarily, i find the motivation... not motivating enough |
| 19:24 | <kriskowal> | I expect a solution to this problem to look more like “can this string be captured in a bigint” (rejecting strings with decimals) and “can this tring be captured in a float64” (rejecting apparent integers with more digits than fit in a mantissa) |
| 19:24 | <Michael Ficarra> | so i woke up at 3am and spent like two hours interrogating the examples and motivation and came to the conclusion that they want "MV(str) is MV(F(str))" (assuming that MV(str) is defined to exist). |
| 19:25 | <kriskowal> | Or maybe even specifically “can this string be captured in an int64” because that’s what’s going to be important to Java, Go, &c |
| 19:25 | <bakkot> | isn't that what they said in the last presentation |
| 19:25 | <Michael Ficarra> | isn't that what they said in the last presentation |
| 19:25 | <bakkot> | and does that mean "1234.567800000000033833202905952930450439453125" is rejected? |
| 19:25 | <bakkot> | well, I guess last presentation also included Number.MAX_SAFE_INTEGER |
| 19:26 | <bakkot> | but other than that |
| 19:26 | <snek> | i believe that to be equiv (but more confusing cuz of the extra tostring decimal representation in the middle) |
| 19:27 | <ljharb> | can one currently implement MV() in JS in a practical sense? |
| 19:27 | <bakkot> | actually, wait, snek did you meant to write MV(F(str)) or MV(ToString(F(str)) |
| 19:27 | <Michael Ficarra> | I don't think so, because of the way we tostring |
| 19:27 | <bakkot> | on the RHS |
| 19:27 | <snek> | those are equiv if Number(ToString(n)) is n holds, no? |
| 19:28 | <ljharb> | ok so does this mean that the use case would be solved with either "give me the MV string of this string" or with a function that implements the screenshotted comparison? |
| 19:28 | <snek> | "give me the mv string of this string" is not... a thing |
| 19:28 | <Michael Ficarra> | those are equiv if |
| 19:28 | <jschoi> | The slide link on the HackMD page’s Day 3 section seem to be to the old slides, unless I’m missing something. |
| 19:29 | <ljharb> | right, i'm asking if, should we provide such an API, would that suffice (not that i'm proposing that) |
| 19:29 | <nicolo-ribaudo> | ryzokuken: Advance the queue |
| 19:29 | <snek> | no i mean we can't provide such an api |
| 19:29 | <snek> | mv isn't a concrete thing, its the abstract idea of numbers |
| 19:29 | <Michael Ficarra> | chairs, please advance the queue |
| 19:30 | <Michael Ficarra> | I think we're getting at the key part here: this proposal is both about representing a float and presenting a float to the user |
| 19:31 | <bakkot> | we can absolutely provide it if we want to |
| 19:31 | <ljharb> | i assumed we could just provide a string representing it |
| 19:31 | <snek> | you mean just as the substring of the source code for that value? |
| 19:31 | <sffc> | My suggestion for the exact condition to determine if a number is safe: https://github.com/Lxxyx/proposal-number-is-safe-numeric/issues/3 |
| 19:31 | <ljharb> | and then you can literally type MV(str) === MV(String(+str)) in your code |
| 19:32 | <bakkot> | oh I meant we could provide "give me the string which is the exact decimal representation of this double" |
| 19:32 | <snek> | oh, i don't think that's what ljharb means |
| 19:32 | <bakkot> | or if we had decimal we could have it give you the decimal |
| 19:32 | <bakkot> | every double has a (very) finite decimal representation so it's feasible |
| 19:33 | <nicolo-ribaudo> | We have that, right? .toFixed(n) with the highest n that doesn't throw (34?) |
| 19:34 | <bakkot> | exact decimal representations don't have trailing zeros but you could trim those off I guess |
| 19:34 | <bakkot> | also you need more than 34 |
| 19:34 | <Michael Ficarra> | I think it's bounded at 100 |
| 19:35 | <Jesse (TC39 🇺🇸)> | maybe better would be toPrecision(34) |
| 19:35 | <bakkot> | you might need 1076 |
| 19:35 | <bakkot> | so |
| 19:35 | <bakkot> | bounded at 100 is not going to do it |
| 19:35 | <ljharb> | (ES2018 bumped it up to 100, iirc) |
| 19:35 | <Michael Ficarra> | |
| 19:36 | <snek> | i'm fine with raising the limits of toFixed to any arbitrary amount. i find this proposal unconvincing though. |
| 19:36 | <Michael Ficarra> | looks like an implementation restriction |
| 19:36 | <bakkot> | (2.22507385850720187716e-308 is the smallest normal double and its representation has 1074 digits after the 0.) |
| 19:36 | <nicolo-ribaudo> | But that's not a solution to this proposal, that check would return false for 0.1 |
| 19:36 | <snek> | yes that's why i mentioned it separately |
| 19:39 | <Michael Ficarra> | we don't need a proposal to see if a string remains unchanged after round-tripping through floats, you can just do String(+s) === s |
| 19:40 | <nicolo-ribaudo> | That doesn't work with notations like .1 and 1e4 |
| 19:40 | <Michael Ficarra> | String(parseFloat(s)) === s |
| 19:40 | <snek> | it also doesn't work for 0,1, which this proposal doesn't solve |
| 19:40 | <bakkot> | you don't want "string remains unchanged", you want "MV of the string remains unchanged" |
| 19:40 | <bakkot> | which is harder! |
| 19:40 | <nicolo-ribaudo> | String(parseFloat("1e1") === "10" |
| 19:40 | <shu> | yeah i'm also not convinced the serialization use case can't be done with existing APIs |
| 19:41 | <Michael Ficarra> | you don't want "string remains unchanged", you want "MV of the string remains unchanged" |
| 19:42 | <Michael Ficarra> | |
| 19:42 | <bakkot> | I guess I did not understand that use case |
| 19:42 | <nicolo-ribaudo> | I would expect the solution to this proposal to return true in that case |
| 19:46 | <bakkot> | also I keep mentioning this but in fact the spec allows freedom in some cases for what the ToString of a number even is, so this would not be the same on all platforms |
| 19:46 | <Michael Ficarra> | man, the word "represent" is really causing us some problems this meeting |
| 19:46 | <Michael Ficarra> | we keep using it in different ways |
| 19:46 | <Michael Ficarra> | "represent" often means "stands in for" (even if different) |
| 19:46 | <Michael Ficarra> | people keep using it to mean "is 1-1 with" |
| 19:46 | <snek> | we should stop having decimal be the default serialization of numbers in js |
| 19:46 | <Jesse (TC39 🇺🇸)> | "exact representation" |
| 19:46 | <snek> | just show the 64 bits |
| 19:47 | <Michael Ficarra> | just show the 64 bits |
| 19:47 | <bakkot> | we should always have had the default serialization be the full exact value |
| 19:47 | <Jesse (TC39 🇺🇸)> | y'all making me cry |
| 19:48 | <bakkot> | that would also solve the 0.1 + 0.2 problem |
| 19:48 | <kriskowal> | I agree with shu that using isSafeNumeric to decide whether it’s safe to capture a stringy number in either a number or decimal is unsound. |
| 19:48 | <bakkot> | because you'd write 0.1 in the console and it would print as something else |
| 19:48 | <ljharb> | as an f64, can you not use Float64Array to do that? |
| 19:48 | <bakkot> | you can use a Float64 array to read the bits, yes |
| 19:48 | <shu> | %a baby |
| 19:48 | <bakkot> | you can't use it to read the exact decimal representation |
| 19:48 | <bakkot> | that's harder |
| 19:48 | <ljharb> | no i mean, put the number in, pull it out, and compare the result? |
| 19:49 | <bakkot> | nnnnno |
| 19:49 | <littledan> | but it's not pretty enough! |
| 19:49 | <ljharb> | oh but you mean producing an f64 string is harder, gotcha |
| 19:49 | <bakkot> | putting a number into a Float64Array doesn't do... anything |
| 19:49 | <Jesse (TC39 🇺🇸)> | would be funny to have some kind of range semantics: you typed "x", but the best I can do is this range of things here, pick one |
| 19:49 | <ljharb> | oh |
| 19:49 | <kriskowal> | The alternate problem statement I proposed is much more consistent an int32 to Number parser that rejects integers in the int64 upper range, or an float64 to Number parser that rejects strings that express numbers that can only be faithfully captured in decimal |
| 19:49 | <bakkot> | it's already a Float64 |
| 19:50 | <bakkot> | kriskowal: can you state your problem statement again? |
| 19:50 | <ljharb> | right |
| 19:50 | <shu> | i say this without judgment: i think nicolo's idea to get people to understand IEEE754 is the most actionable next step. i get the feeling people are ascribing utility to the proposal based on misunderstanding of how floats work |
| 19:50 | <shu> | utility at best, soundness at worst |
| 19:50 | <ljharb> | http://www.2ality.com/2012/04/number-encoding.html is a great read on the topic, i believe |
| 19:50 | <nicolo-ribaudo> | I see that the person who I would like to volunteer reacted with 👍️! |
| 19:51 | <bakkot> | that is a good article but does not sufficiently emphasize that the actual value represented by the JS number 0.1 is in fact a different mathematical number |
| 19:51 | <nicolo-ribaudo> | Maybe I'll give the presentation if nobody else wants to, but not at the next meeting |
| 19:52 | <bakkot> | and that JS number represents many different mathematical numbers |
| 19:52 | <Andreu Botella> | i just want a presentation full of words like "recurring decimal in base 2" |
| 19:53 | <snek> | this is somewhat good but still misses out on some of the big aha moments i think https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html |
| 19:53 | <kriskowal> | For purposes of interoperating with other languages that are obliged to represent their native int64 and decimal types as strings for transmission through JSON, JavaScript would benefit from methods for parsing int32 to number and parsing float64 to number, rejecting strings that are out of the range that can be safely captured by those types. |
| 19:53 | <bakkot> | process point: if multiple people have expressed that they are uncomfortable with stage advancement, I would like chairs to not ask for stage advancement or ask if anyone is "withholding consensus" |
| 19:53 | <bakkot> | if multiple people have expressed that they are uncomfortable with stage advancement it is clear we do not have consensus |
| 19:53 | <Michael Ficarra> | furiously trying to recall whether I reacted with 👍️ before this |
| 19:53 | <bakkot> | making people actually say "I personally am stopping this" is bad |
| 19:54 | <bakkot> | what does "out of the range that can be safely captured by those types" mean |
| 19:55 | <bakkot> | does that include "0.1" or not |
| 19:55 | <Richard Gibson> | even this seems ill-defined... would such a function accept or reject "0.3"? What about "0.30000000000000004"? |
| 19:56 | <kriskowal> | I reject the problem of discriminating a safe subset of decimal or int64 for representation in float64. If the sender is using a string, a JavaScript program that manipulates it needs to use the corresponding native representation, albeit bigint for int64. I accept that a function for serializing bigint to stringy representations of int64 is useful if it handles overflow either with throw or wrap. |
| 19:57 | <Jesse (TC39 🇺🇸)> | what's interesting about this is that there's such a concrete developer pain here but so hard to pin down what the problem is |
| 19:57 | <kriskowal> | And I also reject that it’s okay to capture decimal in a number for purposes of presenting the same precision to the user. For that, the original string should always suffice. |
| 19:58 | <littledan> | Please nominate breakout session topics at https://github.com/tc39/Reflector/issues/552 |
| 19:58 | <shu> | my reluctance is that developer pain feels awfully close to the blanket "ieee754 is counterintuitive and a pain", which isn't a problem we can solve with a helper function |
| 19:59 | <kriskowal> | I agree, the problem of truncating int64 is much more interesting than mishandling string representations of decimal. Whether another language is providing a decimal or float64 is very clearly discriminated by whether it’s captured in a JSON string or number |
| 20:01 | <kriskowal> | That is, if you receive an integer as a string, the sender either represented that as int64 or decimal. The API proxy should be in a position to know which is which and parse it accordingly. |
| 20:02 | <kriskowal> | Yeah, I am resigned that even my generous interpretation suggests an underlying misunderstanding of the architecture problem. |
| 20:03 | <kriskowal> | Which is definitely common, but can’t be solved with more methods. |
| 20:05 | <kriskowal> | And I’m almost absolutely certain that every company using JavaScript as an API proxy for terminating HTTP JSON and forwarding or fanning out to Java and Go is also truncating enums that weren’t in the IDL whenever the API proxy was last deployed. |
| 20:09 | <Richard Gibson> | at what time is the meeting resuming? |
| 20:14 | <bakkot> | Presumably top of the hour |
| 20:14 | <ZiJian Liu> | Thank you all for the feedback on Number.isSafeNumeric, this has been a rare experience and journey for me, I will continue to improve the proposal, thank you all for your guidance 😆 |
| 20:24 | <kriskowal> | Know that Alibaba is not alone. JavaScript’s mismatched number type tower with most languages is a headache felt everywhere. |
| 20:25 | <Chris de Almeida> | appreciate this feedback. we need to be clear though. it is common that people express reservations or dissent but do not intend to outright block advancement. we also saw that some folks had modified their stances. it is also common when someone is blocking to ask them to clearly state their reasons FTR. someone may say they are, e.g. "unconvinced" and sometimes this implies a block, and sometimes it does not. we need to err on the side of being clear and unambiguous |
| 20:28 | <ZiJian Liu> | Yes, I have to deal with similar issues every day, which gives me a headache. Thank you for your feedback, it made me realize that I need to improve my perspective on the problem. Perhaps looking at the issue from the perspective of the entire JavaScript system would be a more suitable problem-statement. |
| 20:29 | <ljharb> | however, it's also better to err on the side of non-advancement - an easily fixable problem if there's consensus for it - rather than advancement, which is much harder to "fix" if there's not. |
| 20:31 | <Chris de Almeida> | sure. in that case, you are referring to committee decision, correct? (in any case, the stakes are much lower at stage 1, but I don't disagree) |
| 20:43 | <canadahonk> | 📣 ~15 mins left to suggest breakout sessions https://github.com/tc39/Reflector/issues/552 |
| 21:00 | <bakkot> | I don't think we ought to think of this in terms of "is there a block or not": that equates "consensus" with "no explicit blocking". I disagree with that. We say that "explicit blocking" implies "not consensus" but I don't think that this means "no explicit blocking" implies "consensus". And I think if at least two people have publicly stated they are not convinced (and there is not a huge upswell of support from everyone else), then this is clearly not consensus. |
| 21:01 | <bakkot> | Specifically, it can be the case that there is clearly not consensus even if no one has explicitly stated that they are blocking. |
| 21:01 | <bakkot> | And I don't think we ought to ask people if they are "blocking" in that case. |
| 21:02 | <bakkot> | A delegate can insist, but it should not be the default. |
| 21:03 | <Chris de Almeida> | there were several people who supported advancement, and there were some folks who changed from negative to positive positions. in the end, the chairs are not comfortable making the decision for the committee, and we were not clear on what the result was |
| 21:05 | <bakkot> | That's fair, but even in such cases I would like to phrase this as asking the committee whether we have consensus, rather than asking specific people if they're blocking. |
| 21:06 | <bakkot> | I personally at least am much more comfortable saying "I don't think we have consensus" (even in cases when I support a proposal!), on the basis of people's expressed discomfort, than I am saying "I am blocking" |
| 21:06 | <ptomato> | what do you see as the material difference between those two things? |
| 21:06 | <bakkot> | "whether the committee has consensus" is something one can have an opinion on without necessarily having an opinion on the proposal itself |
| 21:06 | <Chris de Almeida> | I hear you. but this is exactly the issue -- we sometimes get a response like "I don't think we have consensus". that is not a definite conclusion |
| 21:07 | <bakkot> | It is a definite conclusion unless someone disagrees with it |
| 21:07 | <Chris de Almeida> | so then we are getting a meta-consensus on whether we agree that we don't have consensus? |
| 21:08 | <bakkot> | if it comes to that, sure |
| 21:09 | <bakkot> | I don't think it is usually going to be the case that there is wide disagreement about whether we have consensus unless there was only one person who objected to something |
| 21:09 | <bakkot> | or if someone says "I think we have consensus" and other people say "no, actually I didn't like that and didn't speak up" or something |
| 21:09 | <bakkot> | which can happen! |
| 21:10 | <bakkot> | but that's a discovery of new information rather than a disagreement per se |
| 21:10 | <snek> | how do the "syntax bar is very high" folks feel about this possible statement on syntax |
| 21:10 | <bakkot> | well |
| 21:11 | <bakkot> | I would drop the "where desugarging is not possible" part |
| 21:33 | <Michael Ficarra> | what's the value of actually getting "consensus" here instead of just understanding this point? |
| 21:34 | <Michael Ficarra> | we're not binding ourselves to anything in particular, these are just suggestions about what we "should" think about |
| 21:34 | <Michael Ficarra> | I guess @nicolo-ribaudo's topic may cover this |
| 21:35 | <Ashley Claymore> | For using, the request is that the desugaring is simpler for engines.But it sounded like shu said that if the desugaring is simple then that's a motivation to not implementing it at all? |
| 21:35 | <shu> | correct |
| 21:35 | <Ashley Claymore> | I interpret this to mean syntax should be neither simple or complex to transform |
| 21:35 | <bakkot> | incidentally the using issue is https://github.com/tc39/proposal-explicit-resource-management/issues/215 |
| 21:36 | <bakkot> | it is technically pure sugar but it's really annoying in this one edge case |
| 21:36 | <bakkot> | so, maybe littledan's proposal should be understood to mean we eliminate this sharp not-quite-sugar edge that provides little corresponding benefit |
| 21:37 | <bakkot> | (or would do so were the proposal coming through the process now) |
| 21:37 | <shu> | i interpret it to mean that if you want a pure DX syntax that's a nice, easy, local transform, that sounds good, i see no reason for engine support there to get most of the benefit of such a proposal |
| 21:37 | <nicolo-ribaudo> | Would this mean consider transpiler "implementer feedback" as first class as browser implementer feedback during stage 3? |
| 21:37 | <shu> | but i'd support such a feature to be blessed as standard |
| 21:37 | <Michael Ficarra> | can somebody screenshare the captured queue? |
| 21:37 | <Michael Ficarra> | @Rob Palmer ^? |
| 21:38 | <bakkot> | yes though also browsers are often basically transpilers for sugar, so there's not that much difference |
| 21:39 | <Michael Ficarra> | returning to overflow items is giving me whiplash |
| 21:39 | <Michael Ficarra> | people need to set better timeboxes |
| 21:39 | <Ashley Claymore> | that makes sense. I personally marry this with improved dev-tooling where the tooling transform can be made more transparent to the developer. |
| 21:43 | <ljharb> | "2 must support", when did we make that a requirement? i don't see it in the process doc |
| 21:43 | <ljharb> | i know it's ideal but it seems like it quietly evolved in people's minds to be a requirement over time |
| 21:44 | <bakkot> | we did make it explicit at some point |
| 21:44 | <nicolo-ribaudo> | I remeber having an explicit process discussion about it ~2 years ago |
| 21:44 | <bakkot> | should have written it down |
| 21:44 | <Chris de Almeida> | I recall this |
| 21:44 | <Chris de Almeida> | I don't recall where it got documented |
| 21:44 | <Chris de Almeida> | (or if) |
| 21:44 | <ljharb> | a notes link would be good, and someone should make a PR to the process doc then |
| 21:45 | <ljharb> | because i recall it coming up but my feeling is that it was never made a requirement, just a guideline/ideal |
| 21:45 | <littledan> | I did write it down somewhere, let me find it... |
| 21:45 | <bakkot> | here we go https://github.com/tc39/notes/blob/main/meetings/2023-01/jan-30.md#a-procedure-for-multiple-active-supporters-in-committee-to-achieve-consensus |
| 21:45 | <bakkot> | it's still in PR, linked from that notes section |
| 21:46 | <ljharb> | https://github.com/tc39/notes/blob/main/meetings/2023-01/jan-30.md#conclusionresolution is the conclusion |
| 21:46 | <littledan> | ah sorry about that... https://github.com/tc39/how-we-work/pull/122 |
| 21:46 | <littledan> | does anyone want to pick this up? |
| 21:46 | <Chris de Almeida> | I nominate JHD |
| 21:47 | <ljharb> | ahhh voluntold |
| 21:48 | <littledan> | I did ask in that PR whether it should move into the process-document and no one answered. Any thoughts here? |
| 21:48 | <ljharb> | i think probably polishing the wording in how-we-work, and then separately, adding a quick sentence to the process doc that links to it? |
| 21:49 | <Michael Ficarra> | i think probably polishing the wording in how-we-work, and then separately, adding a quick sentence to the process doc that links to it? |
| 21:49 | <littledan> | OK sure sounds good thanks |
| 21:55 | <littledan> | last call on additional breakout session topics: https://github.com/tc39/Reflector/issues/552 |
| 21:56 | <Michael Ficarra> | when do we vote on breakout sessions? |
| 21:58 | <littledan> | right after this session |
| 21:58 | <littledan> | actually you can already vote if you feel like it, since the last call on breakout session topics was an hour ago in principle |
| 21:59 | <littledan> | the voting link is a comment in that thread |
| 22:00 | <Michael Ficarra> | have we ever had a single-member veto for Stage 4 advancement? |
| 22:00 | <shu> | yeah what are we solving for there |
| 22:00 | <shu> | i'm confused |
| 22:00 | <ljharb> | yes, on two occasions. |
| 22:01 | <shu> | oh really? |
| 22:01 | <ljharb> | but as i said to mark, i don't think that "3 → 4" is actually the problem michael and sympathizers are trying to solve |
| 22:02 | <shu> | i really want to hear what chip has to say |
| 22:03 | <shu> | very ominous phrasing |
| 22:03 | <nicolo-ribaudo> | yes, on two occasions. |
| 22:03 | <snek> | i feel like really bad moments in the current process are rare enough in comparison to all the time that it works that they are a better fit for e.g. per-occurrence CoC as mentioned before, rather than full rule changes. |
| 22:03 | <ljharb> | dynamic import, and private fields in |
| 22:03 | <littledan> | yeah no we figured this out during class fields |
| 22:03 | <ljharb> | the former was good faith and ended up being bypassed by shipping on the web outside the committee during the intervening years, the latter ended up being resolved by updating the process doc. |
| 22:04 | <snek> | was that the 360 thing? |
| 22:04 | <ljharb> | yes |
| 22:05 | <shu> | look of course nobody wants rules |
| 22:05 | <shu> | but this is the only technology we have to scale social interaction! this is like, the history of civilization! |
| 22:07 | <Michael Ficarra> | was that the 360 thing? |
| 22:07 | <shu> | my disagreement with mark is that mark's world is great is everyone was a mark |
| 22:07 | <shu> | which is very much not the case |
| 22:07 | <snek> | the member org was called 360 |
| 22:07 | <bakkot> | this is what dan is currently saying |
| 22:07 | <bakkot> | I agree also |
| 22:08 | <bakkot> | browser markers also have a de-facto anti-veto |
| 22:08 | <bakkot> | they can just implement things if they want to! |
| 22:08 | <bakkot> | cf import() |
| 22:08 | <nicolo-ribaudo> | Do browsers have a veto? Like, if Google and Mozilla were to implement something, would Apple keep refusing? |
| 22:08 | <ljharb> | that'd be up to market pressures |
| 22:08 | <jschoi> | Tail-call optimization, right? |
| 22:09 | <bakkot> | cough PTC cough |
| 22:09 | <shu> | browsers as a category do not have a unitary veto, it is unstable for that exact reason. interop risk is real |
| 22:09 | <shu> | i think that speaks more to PTC the feature than the general pressure |
| 22:09 | <bakkot> | yeah that's a special case |
| 22:09 | <shu> | like, you know, see captureStackTrace |
| 22:10 | <littledan> | oops, we really should've put msaboff's topic before mine |
| 22:10 | <littledan> | I didn't realize he was leaving right now |
| 22:12 | <bakkot> | I am probably also going to have to leave before getting to my point, which is this: we should consider requiring a higher bar to block proposals which have a higher level of support. if only one or two people are enthusiastic a feature, then a single person who is anti-enthusiastic ought to be enough to stop it going forward. if many people are enthusiastic about a feature, possible we should require more than single person who is anti-enthusiastic to stop it going forward. |
| 22:12 | <littledan> | +1 to what Erik Marks says |
| 22:15 | <canadahonk> | if someone really wanted to they could argue all browser vendors are one financial entity |
| 22:16 | <snek> | several governments are doing that rn |
| 22:16 | <Michael Ficarra> | we all derive our livelihoods from web technologies existing |
| 22:16 | <canadahonk> | that's not what i meant :P |
| 22:16 | <Michael Ficarra> | is this collusion? |
| 22:17 | <shu> | standardization is literally legal collusion, yes |
| 22:17 | <shu> | that's why we do it, so it's not illegal |
| 22:17 | <shu> | we = all of us, not google |
| 22:18 | <littledan> | yeah, antitrust law has specific carveouts to encourage standards |
| 22:18 | <jschoi> | “Big Tech” as homogenous monolith. |
| 22:18 | <rekmarks> | Much like "Government" |
| 22:18 | <littledan> | it was initially unclear whether companies could even collaborate on open source, whether that would consist of an antitrust violation. We're all past that now, though |
| 22:18 | <canadahonk> | big government want to take away your javascript!! |
| 22:19 | <jschoi> | “All standards must be de facto. No, actually, de facto standards are collusion too. Every company must design their own power plug.” |
| 22:19 | <littledan> | yeah, standards bodies organize themselves to have uniformly open membership and such so that they don't constitute collusion |
| 22:20 | <snek> | uniformly open to those with deep pockets |
| 22:20 | <snek> | oh sorry this is not tdz |
| 22:21 | <littledan> | well, Ecma, Unicode and W3C genuinely have membership open |
| 22:22 | <littledan> | and we all genuinely do the technical development work through committees of membership |
| 22:23 | <littledan> | (the WHATWG antitrust legal argument is more subtle, though...) |
| 22:25 | <nicolo-ribaudo> | Reflector link for breakout sessions: https://github.com/tc39/Reflector/issues/552 |
| 22:26 | <canadahonk> | 📣 https://github.com/tc39/Reflector/issues/552#issuecomment-2672116236 vote 🫵 |
| 22:32 | <Chengzhong Wu> | do we still use the tcq during the breakout sessions? |
| 22:33 | <nicolo-ribaudo> | Probably depends on the size of each session. Creating TCQ meeting is open, so facilitators can do it |
| 22:35 | <rbuckton> | I'm unclear as to which sessions are overlapping, as I'd like to participate in both the TS discussion and the pattern matching one |
| 22:43 | <rbuckton> | Can we post the final list of breakouts somewhere for the remote attendees? |
| 22:44 | <rekmarks> | Will there be zoom meetings for the breakouts? |
| 22:49 | <nicolo-ribaudo> | These are the ones happening |
| 22:49 | <Rob Palmer> | If anyone wants to dial-in to the workgroup on Type Annotations that Mark Miller has proposed, please dial into the zoom that we used for plenary now. It will run for the next 40 mins until 15:30PT. |
| 22:49 | <nicolo-ribaudo> | 1 starting soon, and 2 later |
| 22:49 | <nicolo-ribaudo> | Facilitators will share a call link |
| 22:49 | <rbuckton> | So annotations and pattern matching overlap? That's unfortunate. |
| 22:50 | <shu> | i have no idea what's happening for remotes |
| 22:50 | <Rob Palmer> | Remotes can dial in. |
| 22:50 | <shu> | does anyone want me to attend any of the sessions |
| 22:51 | <shu> | lol what is that map |
| 22:51 | <littledan> | attend whichever session you're interested in. I'd be happy if you joined the JSSugar discussion |
| 22:51 | <shu> | is that a map of intestines |
| 22:52 | <nicolo-ribaudo> | That's my art |
| 22:52 | <sffc> | Small JS Engines meet link https://meet.google.com/csp-utwi-cqy |
| 22:53 | <littledan> | Is anyone interested in pattern matching? It's just Luca and me here; we'll close this session if no one wants to join |
| 22:54 | <rbuckton> | I would join remotely |
| 22:54 | <littledan> | OK perfect, I'll set up a zoom now |
| 22:55 | <littledan> | pattern matching call: https://bloomberg.zoom.us/j/93962399209?pwd=Uwg6q9dCYMWBNRTCux51qgKgW2uah4.1 |
| 23:09 | <rekmarks> | Is there a tcq for type stripping? |
| 23:11 | <nicolo-ribaudo> | @robpalme:matrix.org^ |
| 23:14 | <canadahonk> | when does breakout session #1 officially end? |
| 23:14 | <littledan> | 3:20 |
| 23:14 | <Rob Palmer> | Type Annotations discussion doc |
| 23:16 | <Michael Ficarra> | ecma262 PR burn-down break-out session video call: https://f5networks.zoom.us/j/2545766102 |
| 23:16 | <Michael Ficarra> | starting in 9 minutes |
| 23:23 | <naugtur> | There will likely be pressure on the engines to do the erasing transparently like Deno supporting TS created pressure on Node.js to do something, so eventually it will happen. If the syntax allowed the parser to, after finding an opening sequence, ignore all characters until a specific character or short sequence is reached, that would make the cost of ignoring it similar to leaving whitespace in. Is that option on the table at all? |
| 23:23 | <sffc> | Stdlib breakout notes: https://docs.google.com/document/d/17u9l-TRdEasF5cKHJnTmcBUNRqGQpsYxLNraV8sChfw/edit?tab=t.0 |
| 23:25 | <littledan> | session two starting now |
| 23:26 | <littledan> | Continuation of layering/JSSugar discussion starting now in https://bloomberg.zoom.us/j/98987937963?pwd=fSfw9H9kwiZ3269am0s5v3bT9k4TRO.1 |
| 23:26 | <littledan> | shu: it'd be great if you joined |
| 23:27 | <shu> | is that happening now? |
| 23:27 | <rekmarks> | Ashley Claymore: what is the turbofish thing? Is it documented anywhere? |
| 23:27 | <shu> | this is already different from the photo of the whiteboard |
| 23:28 | <rekmarks> | this is already different from the photo of the whiteboard |
| 23:30 | <Ashley Claymore> | I'll find a link. But it's: TypeScript: |
| 23:30 | <Ashley Claymore> | because new Set<T>([]) is already valid JS |
| 23:30 | <ljharb> | would TS add a setting to require the syntax and forbid the old? |
| 23:30 | <Ashley Claymore> | I can't speak for TS but I think that would add a lot of value |
| 23:31 | <ljharb> | if TS users were pushed into only using the erasable subset then that might actually approach the “unfork” goal |
| 23:31 | <ljharb> | otherwise i don’t think it achieves it |
| 23:32 | <Ashley Claymore> | danielrosenwasser and I were talking about transforms that VSCode (and other IDEs) could do when a file is renamed from .js to .ts.The turbofish could be one that is applied when renaming .ts to .js |
| 23:32 | <Ashley Claymore> | as one idea |
| 23:32 | <Anthony Bullard> | That should be a LSP thing, not VSCode |
| 23:33 | <ljharb> | unforking can’t happen without a clear/likely path to.ts and .tsx etc dying out |
| 23:34 | <Anthony Bullard> | And getting rid of enums |
| 23:34 | <rekmarks> | “unfork” meaning “it all literally is the same language”? |
| 23:34 | <rekmarks> | (while ensuring no runtime costs for engines) |
| 23:34 | <ljharb> | yep |
| 23:34 | <Anthony Bullard> | rekmarks: I think it means TypeScript is an implementation of a Type system for JavaScript and nothing else |
| 23:34 | <ljharb> | that TS users are only using tsc to typecheck, basically |
| 23:35 | <ljharb> | it could be an optional downleveler, i suppose |
| 23:35 | <ljharb> | presumably there’d also be an easy transform from tsdoc to this new syntax |
| 23:35 | <rekmarks> | Getting erasure-only as a tsc compiler option would be an amazing start |
| 23:35 | <ljharb> | there’s other issues beyond that, but one of the primary goals is unforking, and i can’t see how that end state isn’t a requirement for unforking to be achieved. |
| 23:36 | <Anthony Bullard> | presumably there’d also be an easy transform from tsdoc to this new syntax |
| 23:50 | <Anthony Bullard> | Strangely the only ones I can find covert JSDoc to d.ts files and not inline |
| 23:51 | <rbuckton> | There's been some interest from some of the NodeJS maintainers about trying to bring enum back to TC39, in part so that it could be used in a type-stripping only mode, just based on the sheer number of TS developers using enum. |
| 23:53 | <rbuckton> | enum does have some advantages over {}, especially when working with numbers/bitflags. |
| 23:54 | <Anthony Bullard> | Enum with its current TS implementation is considered an anti-pattern today, not to say that a native enum implementation in ES would not be much better (since most C-like languages have them) |
| 23:55 | <James M Snell> | There's been some interest from some of the NodeJS maintainers about trying to bring |
| 23:55 | <rbuckton> | Which parts are what you'd consider an anti-pattern? |
| 23:55 | <James M Snell> | Largely just in terms of expanding language syntax |
| 23:59 | <rbuckton> |
|