David Renshaw

What if we add public visibility to [`ReadSegmentTableResult`](https://github.com/capnproto/capnproto-rust/blob/f099544e3731a16a899e7723efeda70ea6276670/capnp/src/serialize/no_alloc_buffer_segments.rs#L10-L14), [`read_segment_table()`](https://github.com/capnproto/capnproto-rust/blob/f099544e3731a16a899e7723efeda70ea6276670/capnp/src/serialize/no_alloc_buffer_segments.rs#L16), and [`NoAllocBufferSegments::from_segment_table()`](https://github.com/capnproto/capnproto-rust/blob/f099544e3731a16a899e7723efeda70ea6276670/capnp/src/serialize/no_alloc_buffer_segments.rs#L108)? (These things are currently at private or crate-only visibility.) Then I think you would be able get the message...

> In the case of SingleSegment, segment_table_length_bytes must always be 8, and the message length is also inferred from the buffer. Hm... I agree that it looks like the first...

I removed the first parameter in 9738fed7624eddff67d2e72d75d474eae74787f6.

I opened a PR for adding public visibility tot he relevant items: #489.

Closed by #489.

> I would propose that each builder keep integer offsets into the segments in the builder, and have them borrow the segments only for the period in which they are...

It would be relatively straightforward to change the interface so that `capnp::message::Allocator::allocate_segment` returns an error rather than panicking on out-of-memory. (Note that downstream code would then need to insert `?`...

> This would require every capnp builder type to be generic over the Allocator itself, That is something I've considered before, and similarly on the read side having every `Reader`...

The bug described in #484 is maybe tangentially related to the above discussion. The bug would have been avoided if `Allocator` had a `get_segment(u32)` method. (Currently `Arena` assumes that segment...

I don't think so. Please feel free to open one.