One of the ideas in #1272 is to bring back the MessagePackBinary class from v1. One that is optimized for spans rather than ReadOnlySequence<byte> and IBufferWriter<byte>.
In entertaining this idea, I'd prefer to not duplicate all the encoding/decoding logic in the existing v2 MessagePackReader and MessagePackWriter ref structs. We can keep the code consolidated and prove the usability of the new span-based class if we can replace much of the implementations of the reader/writer structs with calls into the new class.
I'm calling the new class MessagePackPrimitives as per @neuecc's suggestion.
I've started a proof of concept of it here.
The writer parts are looking reasonably good.
For the reader, I'm basing on a no-exceptions-thrown design, where the 4 possible outcomes are all communicated through an enum return value.
One of the ideas in #1272 is to bring back the
MessagePackBinaryclass from v1. One that is optimized for spans rather thanReadOnlySequence<byte>andIBufferWriter<byte>.In entertaining this idea, I'd prefer to not duplicate all the encoding/decoding logic in the existing v2
MessagePackReaderandMessagePackWriterref structs. We can keep the code consolidated and prove the usability of the new span-based class if we can replace much of the implementations of the reader/writer structs with calls into the new class.I'm calling the new class
MessagePackPrimitivesas per @neuecc's suggestion.I've started a proof of concept of it here.
The writer parts are looking reasonably good.
For the reader, I'm basing on a no-exceptions-thrown design, where the 4 possible outcomes are all communicated through an
enumreturn value.