| 06:33 | <bakkot> | updated the base64 proposal and added a playground. would love feedback on the proposal API (and the contents of the playground, the design of which I ripped off wholesale from temporal) https://tc39.github.io/proposal-arraybuffer-base64/ |
| 17:11 | <dminor> | Chris de Almeida: re: the declined TC39 meeting, it looks like Rob created the meeting and then invited the TC39 Events Calendar. I think the way to fix it is for someone to create a new Chairs Meeting directly on the TC39 Events Calendar and for Rob to then remove the existing one. If you share your preferred email address with me, I can give you write access to the TC39 Events Calendar. |
| 18:12 | <Michael Ficarra> | I would rename the "alphabet" option to something like "alphabetName" so we know it's an identifier and not the alphabet itself being passed in (without referring to docs) |
| 18:13 | <Michael Ficarra> | alternatively, actually pass the alphabet in and define constants for standard ones |
| 18:22 | <bakkot> | I was imaging you could specify either by identifier or by an entire alphabet |
| 18:22 | <bakkot> | as long as we don't want to support identifiers which are exactly 64 characters long we can just let the name be overloaded, and not require the user to find the constants somewhere |
| 18:24 | <Michael Ficarra> | well that's certainly creative |
| 20:19 | <TabAtkins> | ...huh, having an overlapping value space which is definitely disjoint in practice is very interesting. |
| 20:21 | <TabAtkins> | Might be too magic when we can just have two different options in the bag, but it does avoid us having to answer the question of what to do when the author specifies both, I guess. |
| 20:22 | <bakkot> | yeah |
| 20:22 | <bakkot> | also, I dunno it's not that magic |
| 20:22 | <bakkot> | no more so than new Temporal.TimeZone('UTC'); and new Temporal.TimeZone('+00:00'); both working |
| 20:25 | <Michael Ficarra> | it's not even like we couldn't have a well-known alphabet have a 64-character name, it just can't refer to some other alphabet, which would be a misleading name to say the least |
| 20:26 | <bakkot> | right, also the space is even more constrained because all 64 characters need to be unique, which... you are probably not going to run into an identifier which looks like that |
| 20:28 | <Michael Ficarra> | can't wait to see the TypeScript type for it |
| 20:38 | <littledan> | any should work |
| 20:47 | <TabAtkins> | Can typescript represent strings of a particular length? |
| 20:47 | <TabAtkins> | If not, then worst case you can just type it as String (no need to fall all the way down to any) |
| 20:48 | <littledan> | Of course, was joking |
| 20:48 | <TabAtkins> | man distinguishing shitposts from serious suggestions can get really hard sometimes |
| 20:58 | <bakkot> | the question of what typescript "can" represent is somewhat complicated because it has a very powerful type system |
| 20:59 | <bakkot> | I am confident there is a way to abuse it into representing "strings of length 64" but it is not something built in and you'd probably get a horrible error message |
| 20:59 | <ljharb> | maybe some nonsense with template literal types |
| 21:05 | <TabAtkins> | just do a disjuction of literals, with the known keywords and all, uh, 128^64 valid alphabet literals? |
| 21:08 | <bakkot> | unfortunately it refuses to represent unions larger than ~10k members, because it is a coward |
| 21:18 | <TabAtkins> | Sigh, guess we'll have to throw the whole idea out, then. |
| 22:51 | <Michael Ficarra> | RFC 4648 has like base32 and stuff, is there any way that could be added in the future? |
| 22:53 | <bakkot> | see https://github.com/tc39/proposal-arraybuffer-base64#what-other-encodings-should-be-included-if-any |
| 22:54 | <bakkot> | and specifically https://github.com/tc39/proposal-arraybuffer-base64/issues/7#issuecomment-872536851 |