| 05:53 | <bakkot> | why do the dataview methods default to big-endian |
| 05:54 | <bakkot> | who is running JS on big-endian systems and why did we decide they should get the simpler form |
| 05:56 | <bakkot> | sidebar: we should probably expose endianness as a constant somewhere |
| 05:57 | <bakkot> | it is kind of unfortunate that it's implementation-defined but since it is we at least ought to let you test for it without having to write a value and read it back |
| 08:54 | <littledan> | who is running JS on big-endian systems and why did we decide they should get the simpler form |
| 08:55 | <littledan> | it is kind of unfortunate that it's implementation-defined but since it is we at least ought to let you test for it without having to write a value and read it back |
| 15:10 | <bakkot> | Sure but is there an actual (valid) use case for that? |
| 15:10 | <bakkot> | since they don't fall back to the platform default |
| 15:11 | <bakkot> | bare float64Array[x] = y does fall back to the platform default, so if you write a value using that syntax and then want to read it with a DataView you need to know which endianness to specify for the DataView methods |
| 19:38 | <littledan> | Sure but who is forcing you to use the DataView methods? |
| 20:32 | <ljharb> | lol is that a serious question? there's a reason dataview exists |
| 20:50 | <littledan> | Well, I don’t really see any particular logic to the system beyond, TypedArray is for when you want to use native endianness, and DataView is when you want explicit endianness |
| 21:01 | <Kris Kowal> | Unfortunately, DataView is not that orthogonal to other TypedArrays in its design. It’s also useful for heterogenous data like a serial protocol buffer, for which big-endian is indeed a great default, or an allocation arena for structs, where little-endian would be a great default. |
| 21:06 | <littledan> | Well, it’s unergonomic but can’t you superimpose different TypedArrays on top of the same arraybuffer to do that heterogeneous, native endian access? |
| 21:07 | <littledan> | If we enable more, it seems like ergonomics would be the motivation, right? |
| 21:11 | <Kris Kowal> | You also need to superimpose your Uint64Array at 8 initial offsets, and do some math to choose. |
| 21:12 | <Kris Kowal> | So, yes, ergonomics. |
| 21:12 | <Kris Kowal> | As opposed to contortion. |
| 21:14 | <littledan> | So, sure, I have nothing against an ergonomics-motivated way to get at the platform endianness, for the sake of passing into the DataView methods |
| 21:14 | <littledan> | *BigUint64Array |
| 21:14 | <littledan> | Also when you use that API please write a note to the poor implementers who did all the work and weren’t sure if it was useful |