Does it make any sense for Io.Writer.writeInt() to support u7 and other such oddball ints? It would have to assume responsibility for zero-padding, to write out actual bytes… and there’s no Reader.readInt() mirror to implement the reverse…. so users of writeInt() should always just pad-up and cast themselves…? (or bitmap the ints, if the space is really important, I guess….)
I think being able to read or write something like a u7 directly has the potential for confusion - as in, what is it doing, specifically?
- Padding at the start to the nearest byte? (Most reasonable, but means sometimes you’d be effectively storing something like a u24)
- at the end? (would be very odd, but makes a bit of sense if you’re thinking of the data merely as a stream of bits rather than bytes)
- Round the width up to something common like a u8, u16 or u32?
- Silly as it would be, someone might even expect it to only read/write 7 bits, and account for that in future reads/writes by shifting and buffering at the level of individual bits!
- What about signed integers? Are they getting sign extended?
Better to make the user be explicit about what they want the written data to look like, IMO. Letting the user mindlessly write a weird bit width integer without necessarily thinking about what it’s doing will only confuse them when trying to interpret that same data later.
Maybe helpers with very explicit names describing their behaviour would be good…
4 Likes
Yes, I think it’s more trouble than it’s worth after all.
1 Like