[holonsoftFounder]

Property support

A protocol member may now be a property as well as a field. The same attributes work on both.

The test that carries the weight is the first one: the same protocol declared once with fields and once with properties, covering every supported type (sbyte through decimal, Guid, DateTime, enum, string), has to produce byte for byte the same frame. It does.

Properties cost nothing

The accessors were already compiled expressions; MakeMemberAccess emits a call to the getter or setter, and the JIT inlines a trivial auto property accessor into the same code a field access produces.

Method	fields	properties
Read 38 byte POCO	58.91 ns / 56 B	60.76 ns / 56 B
Read into reused instance	31.24 ns / 0 B	28.40 ns / 0 B
Write 38 byte POCO	57.02 ns / 64 B	56.83 ns / 64 B

The read row is 3% apart, the other two are inside the noise in the other direction. Allocation is identical everywhere.

The old restriction came from FieldInfo being wired through ConverterFieldInfo, FastInvoke and the range violation event, not from anything about the conversion itself.

What is accepted and what is not

• An init only or private setter is fine, so a POCO can stay immutable from the outside and still be filled from a frame. Verified empirically rather than assumed: Expression.Assign on an init property compiles and runs.
• A property carrying the attribute with no setter is rejected at Prepare() with a message that says why, since reading a frame would have to assign it.
• Computed properties, indexers and static properties without the attribute are ignored, not rejected, so they can sit next to the protocol members undisturbed.
• A bool property occupies one byte, not the four Marshal.SizeOf(typeof(bool)) reports. There is a test for exactly that, because GetByteCount and the writer would otherwise agree on the wrong number and nothing else would notice.

IBufferWriter

ConvertToByteArray(T, IBufferWriter<byte>) writes a frame into a pipeline's own buffer.

The trap it has to avoid: GetSpan(n) may return more than n bytes. The cursor gets exactly the frame and Advance is told the frame length, not the span length. TestBufferWriterApi checks this with a writer that deliberately over-returns and fills the spare room with a marker, then writes several frames and asserts they stay contiguous.

Write into a reused buffer	56.15 ns	0 B
Write into an IBufferWriter	57.17 ns	0 B

About a nanosecond for the GetSpan/Advance pair, and nothing allocated.

BREAKING

OnRangeViolationDelegate takes a MemberInfo instead of a FieldInfo, because FieldInfo cannot describe a property. One word for most handlers:

// 3.x
void OnRangeViolation(FieldInfo field, out ConverterRangeViolationBehaviour behaviour)
// 4.0
void OnRangeViolation(MemberInfo member, out ConverterRangeViolationBehaviour behaviour)

A handler that read field.FieldType has to ask the member for it, which is the part that will not be obvious from the compiler error, so the README upgrade section spells it out.

ConverterFieldInfo<T>.FieldInfo is now Member (a MemberInfo), with MemberType alongside. It was removed rather than left returning null for properties, so the failure is a compile error and not a NullReferenceException at runtime.

README

Rewritten to lead with the numbers, per your request: the speed table is now the first thing after the one line description, with the zero allocation loop as a code sample, the "byte order is free" point, and the garbage-per-second figure at 100k msg/s. The baseline-before-v4.md pointer sits next to it, since the credibility is in the method being checkable.

Safety

150/150 green, 20 of them new. Golden vectors unmoved.

🤖 Generated with Claude Code