| 03:02 | <bakkot> | how do people feel about bit packing? like if I want to represent 0, 2, or 4 booleans, I could do that by having a |
| 03:02 | <bakkot> | this doesn't come up much (ever?) on the web platform but is very common in other spaces |
| 03:08 | <rbuckton> | We do that all the time in the TypeScript compiler, and there are more than a few packages built with TS that use bitflags-based enums |
| 03:09 | <rbuckton> | Well, not exactly as you described I suppose |
| 03:17 | <bakkot> | yeah, flags specifically is a slightly different case, I think |
| 03:17 | <bakkot> | here it's a combination of a flag-like thing and a (small) int |
| 04:16 | <bakkot> | to be clear this would be specifically for a standard library API (https://github.com/tc39/proposal-arraybuffer-base64/issues/21#issuecomment-1601938101), not just in general |
| 06:35 | <Ashley Claymore> | Genuine q: Is it common to do that in languages that don't have unions/typed-structs/low-bit-width-integers? Feels more like the type of thing I would see in C/Rust style languages, (as a first reaction) |
| 08:09 | <shu> | bakkot: bit packing into object fields? |
| 08:09 | <shu> | i think that makes more sense in structs than in ordinary objects |
| 09:53 | <Rob Palmer> | π―π΅π―π΅π―π΅ Reminder π―π΅π―π΅π―π΅
|
| 14:19 | <littledan> |
Note, TC39 in Japan is at risk of not happening unless we see more interest. So please fill this out. Even if you arenβt sure about your availability, it would be good to hear that (it is an option in the survey). If you are aware of whether someone else is likely to attend, but they are unable to fill this out (e.g. they are on leave), letβs get that communicated somehow as well. |
| 14:36 | <shu> | does 262 require denormals to be supported? |
| 14:36 | <shu> | the Number section reads like yes, but https://tc39.es/ecma262/#sec-number.min_value reads like no |
| 16:06 | <bakkot> | bakkot: bit packing into object fields? |
| 16:07 | <bakkot> | the space of values to represent in this case is small enough to fit into a Uint32, so we could just use a Number, but that's more opaque for consumers than using separate object fields |
| 17:29 | <Michael Ficarra> | the Number section reads like yes, but https://tc39.es/ecma262/#sec-number.min_value reads like no |
| 17:30 | <Michael Ficarra> | should we normative PR to change the Number.MIN_VALUE requirements? |
| 17:31 | <bakkot> | no, we should add a clarifying note |
| 17:31 | <bakkot> | per https://esdiscuss.org/topic/denormalized-numbers |
| 17:32 | <Michael Ficarra> | so like... if your implementation is not compliant, please make it non-compliant in this way? |
| 17:32 | <bakkot> | yes |
| 17:32 | <bakkot> | "Implementations are required to support denormalized numbers. However, non-conforming implementations which do not denormalized numbers should set Number.MIN_VALUE to the smallest value they are capable of representing" |
| 17:33 | <Michael Ficarra> | it would still be normative IMO to replace that sentence with a note |
| 17:33 | <Michael Ficarra> | we should needs-consensus PR that |
| 17:33 | <bakkot> | I really do not think that's normative |
| 17:33 | <bakkot> | it's what it already says, for one thing |
| 17:37 | <Michael Ficarra> | I guess it's fine since it is only talking about non-conforming implementations, which the committee doesn't really have any jurisdiction over |
| 17:37 | <Michael Ficarra> | and the statement it's making, on behalf of committee, is already being made today |
| 17:54 | <littledan> | I don't understand what normative change you want to make |
| 17:54 | <littledan> | couldn't we just add a note that says "hey, to be clear, denormals are really supported in JS" |
| 17:54 | <littledan> | (if we consider the current text to be unclear) |
| 17:56 | <littledan> |
|
| 17:59 | <Michael Ficarra> | I don't understand what normative change you want to make |
| 18:00 | <littledan> | it's kinda discouraged to say "should" in a note... but anyway, yes, I'm fine with the editors just deciding on whatever sort of change here would be the clearest |
| 18:00 | <Michael Ficarra> | tbh I'm surprised to see not that many responses from TC39 delegates who live in East Asia. Should we do more to make this survey visible to that group? |
| 18:02 | <Michael Ficarra> | On that point, Bergen is kinda out of the way, even for Europeans, so I'm not sure how much we really succeeded with lowering the barrier with that choice of venue |
| 18:02 | <littledan> | well, we had a vote comparing multiple locations and chose Bergen, right? |
| 18:03 | <littledan> | like Barcelona was also in the running but wasn't selected |
| 18:03 | <littledan> | there are many EU-based delegates |
| 18:03 | <Michael Ficarra> | Barcelona would be way better for accomplishing the accessibility goal IMO |
| 18:06 | <Michael Ficarra> | before the venue selection goes to a vote next time, the chairs should make sure they all meet our accessibility goals (not saying they didn't here, just that for me it doesn't appear to have met the bar) |
| 18:09 | <Michael Ficarra> | Tokyo, on the other hand, should be very easy to get to from anywhere in APAC |
| 18:15 | <TabAtkins> | it's kinda discouraged to say "should" in a note... but anyway, yes, I'm fine with the editors just deciding on whatever sort of change here would be the clearest |
| 18:16 | <littledan> | Note: One shouldn't use should in non-normative text |
| 18:40 | <Michael Ficarra> | TabAtkins: We can't impose any requirements at all on non-conforming implementations, so what do you think the note should say? |
| 18:41 | <TabAtkins> | Sure you can. They just won't be a tested comformance class |
| 18:41 | <TabAtkins> | We put normative requirements on *authors* sometimes |
| 18:42 | <TabAtkins> | (not that you necessarily need to make this normative; just saying) |
| 18:47 | <bakkot> | yes sorry I did not mean a literal note |
| 18:47 | <bakkot> | I just meant that we add those sentences to the existing prose, which is not currently a note |
| 19:06 | <littledan> | yes the concept of "multiple conformance classes" is necessary to make sense of the statement currently in the spec |
| 19:06 | <littledan> | We put normative requirements on *authors* sometimes |
| 19:45 | <shu> | i don't even know what it means to put normative requirements on authors |
| 19:45 | <shu> | do i put "conformant JS dev" on my resume |
| 19:45 | <TabAtkins> | It means you tell them what to do (or more likely dont' do) and then are allowed to snark at them on social media when they do it anyway) |
| 19:46 | <shu> | but at the same time do not build such a check into the language/API itself? |
| 19:46 | <shu> | or is it like, an uncheckable requirement? |
| 19:47 | <bakkot> | I have never needed permission to snark at people though I guess I generally avoid doing so on social media |
| 19:48 | <shu> | yes, i like to do it to their face |
| 19:54 | <littledan> | remember when we almost said that JS developers should use semicolons? |
| 19:55 | <Chris de Almeida> | ASI was a mistake |
| 19:57 | <TabAtkins> | Yeah authors just aren't a testable conformance class, it's fine |
| 20:02 | <Andreu Botella> | it's more like the opposite, authors imposing a testable conformance class onto JS spec editors, what with the multiple Array.p.group renames |
| 20:06 | <Rob Palmer> | My impression is that the anti-semicolon movement has mostly gone away. I follow many trendy JS influencers and their code is littered with semicolons. |
| 23:08 | <ljharb> | imo we missed the window to be ahead of the game by declining to tell people to write code properly :-/ |