Introduce buffer relative methods

[araujogui]

What is the problem this feature will solve?

Sequential buffer operations require manual offset tracking. This is error-prone and verbose. Many developers already create abstractions around Buffer to avoid it completely.

@nodejs/buffer

What is the feature you are proposing to solve the problem?

Introduce a new class, RelativeDataView, with relative read and write methods that automatically track a internal position. This simplifies sequential data access and reduces boilerplate.

Inspired by abstractions like Java’s ByteBuffer and Rust’s ByteBuffer.

The class should:

• Can be constructed from an TypedArray or Buffer with an optional default byte order (be or le).
• Expose relative read methods (e.g. readInt16 and readInt32).
• Expose relative write methods (e.g. writeInt16 and writeInt32), supporting method chaining.
• Expose position control methods:

position() – get/set current position.
seek(offset) – move position by offset.
mark() / reset() / rewind() – mark and restore position.
clear() – reset position to zero.
remaining() - Remaining bytes between current position and limit.

Example usage:

const buf = Buffer.allocUnsafe(16); // new ArrayBuffer(16);
const view = new RelativeDataView(buf, ByteOrder.BE);

view
  .writeInt16(42)
  .writeInt32(9000)
  .writeFloat(3.14);

view.clear(); // reset position to 0

const a = view.readInt16();    // 42
const b = view.readInt32();   // 9000
const c = view.readFloat();    // 3.14

What alternatives have you considered?

No response

[geeksilva97]

I like this feature. When I had to do parsing using Node.js I needed to come up with an abstraction to do this.

[bnoordhuis]

Counterargument: instead of Node going its own way, it's better to standardize as typed array/dataview methods.

[araujogui]

Counterargument: instead of Node going its own way, it's better to standardize as typed array/dataview methods.

Well, that's an idea but I think DataView should stay minimal. This feature adds a high-level API on top of primitives without bypassing standards.

[jasnell]

I think @bnoordhuis ' point still stands, a standard API here would be better and DataView would be a nice place for this.

[targos]

In general, I think we should try not to add new APIs to Buffer. People are supposed to use the standard APIs now.
For this specific use case, it's also quite easy to implement in userland (I maintain a library that does it myself), and the details can quickly become a matter of opinions.

[jimmywarting]

Would suggest that you make requests to suggest that DataView get upgraded to something better if the feature is missing.

[araujogui]

Got it, it makes sense, I'll create a proposal. Ty

[jasnell]

Closing this issue is likely premature. I just chatted a bit with some other TC-39 delegates about the idea of adding such methods to DataView in the language and the general response is that such a proposal would not be accepted. We have other options available such as going to WHATWG to ask them but there's also a general feeling that it is unlikely to be accepted there either. So if there's a sense here that this API would be helpful, adding something to Buffer remains an option.