RFC: buffer.pack*/buffer.unpack*

[Crazyblox]

Rendered

A more-fundamental approach that absolves the need for per-type read/write functions whilst being less verbose, providing more versatility, and reducing the exposed surface area for bugs in user code.

[ishtar112]

Do let it be known that prior RFCs that proposed introducing new parameters to existing APIs have been rejected [in part] because such changes are not backwards compatible.

[Crazyblox]

Do let it be known that prior RFCs that proposed introducing new parameters to existing APIs have been rejected [in part] because such changes are not backwards compatible.

Valid. In current runtime the tail is sunk and doesn't raise an error; if changed, lots of data would be written unintentionally to the buffer, with OOBs being the following consequence. I'll seek to update this.

Some current thoughts I have:

• An overload where buffer.write*(buffer: buffer, index: number, value: {number}) is a current thought as the value type changes distinctly, and this pattern isn't depended on as it currently errors in runtime.
  This feels particularly nasty, and I can only imagine the performance implications are not great. Not being able to do this with buffer.read* feels like a dead end.
• Adding separately named functions to the buffer library, such as buffer.pack* and buffer.unpack* to better-define intent. This could allow retaining the current RFC where ...number and count are used, whilst replacing read*/write* with pack*/unpack*.
  This does add bloat to the library and it would have to be warranted by how compelling the use-cases are.
  It would still be less verbose, provide more versatility, and reduce the exposed surface area for bugs in user code.

Edit: I have decided to go with buffer.pack*/buffer.unpack* with my latest revision.