| 17:39 | <ljharb> | the spec doesn't define a "code unit" or a "code point", and there's enough ambiguity that they could either be a string or an integer (since either is easily convertible to the other). what type of thing would you expect them to be? |
| 17:46 | <jmdyck> | Depends what you mean by "expect". Over the course of a few PRs, they've become more like an opaque type. E.g., you can't just do arithmetic on a code point, you have to ask for its numeric value and then do arithmetic on that instead. |
| 17:49 | <jmdyck> | (I think that transition is not quite complete.) |
| 18:00 | <bakkot> | definitely not a string |
| 18:00 | <bakkot> | I would not treat them as integers either though |
| 18:01 | <ljharb> | what are they, then? |
| 18:02 | <jmdyck> | What is a Boolean? What is undefined? |
| 18:02 | <ljharb> | so its its own primitive type? |
| 18:03 | <ljharb> | that's a fine answer - like a spec enum - but then, would you say that "how to represent it in JS" is a judgement call? |
| 18:04 | <jmdyck> | Isn't "how to represent it" always a judgement call? |
| 18:09 | <jmdyck> | more specifically, I think it's a judgement call whether you represent a code point via UTF-8 or UTF-32 or something else. |
| 18:30 | <ljharb> | ok |
| 18:31 | <bakkot> | yeah I mean it's always a judgement call |
| 18:33 | <bakkot> | if you were writing typescript I would tell you to use a phantom brand but presumably you are not |
| 18:34 | <bakkot> | https://www.typescriptlang.org/play?#code/C4TwDgpgBAwg9gEwgVQHYEthQLxVQVwFsAjCAJygDIoBvKAfXuLIENUEAuKAcgGNEI+DMG5QAvgG4AUFIA2ELAA8u8JGkw4oABglQA9HqjkycMnIVQQKgeqy4tUFgGdYN4boNRC+J1lJHFMFl0XkwgA |
| 18:35 | <bakkot> | if you're asking for practical advice, in JS I'd either just use a number and try to be very disciplined about which things are code units and which are not, or use an explicit { type: 'code unit', value: number } wrapper so that they were not interchangeable |
| 18:35 | <bakkot> | (of course IMO the better way to prevent that sort of confusion is TypeScript, but.) |
| 20:36 | <Michael Ficarra> | yooo you can do phantom types in TypeScript? |
| 20:36 | <Michael Ficarra> | I may have to actually check out this TypeScript thing some day |
| 20:36 | <Michael Ficarra> | not today though |
| 20:42 | <bakkot> | yeah though I guess in that example it's not exactly "phantom" |
| 20:43 | <Michael Ficarra> | yeah it can technically be satisfied by something without putting the phantom type on it |
| 20:43 | <Michael Ficarra> | it's a close-enough hack |
| 20:44 | <bakkot> | https://github.com/Z3Prover/z3/blob/30a2ced9aa7f97e7c896072c11a64549b4dde899/src/api/js/scripts/make-ts-wrapper.ts#L378-L383 |
| 20:44 | <bakkot> | is a more phantom-y example |
| 20:45 | <bakkot> | the type parameter is only used to tell the type system about the relationships between types, not for the actual data in any way |
| 20:56 | <Michael Ficarra> | ljharb: https://github.com/tc39/ecma262/releases/tag/es2023 pretty sure it was approved on the 27th, not the 29th (today) |
| 21:10 | <ljharb> | whoops, thanks, not sure where I got 29th |