Provide explicit borrowed-view vs owned-copy APIs

[Hihi142]

Hi, thanks for Vest.

I'd like to suggest exposing two clearly separated API modes:

• borrowed / view-based: parsed values borrow from the input buffer
• owned / copy-based: parsed values are detached copies of the input data

Right now, the zero-copy direction seems to be the default, but from the API it is not always immediately clear whether a result is:

• a borrow/view into the original input buffer, or
• an owned copy

In some cases I encountered, an owned copy is actually preferred over a borrow.

It would be helpful if Vest could make this distinction explicit, for example with two API families such as:

• parse_borrowed / parse_view
• parse_owned

and possibly matching generated types like:

• FooRef<'a>
• FooOwned

This would make ownership semantics much clearer for users and reduce confusion around lifetimes vs copied data.

Thanks for considering it.

[y1ca1]

Thanks for giving Vest a try! Having both borrowed and owned versions of parsing and the output types indeed sounds useful.

Right now, the zero-copy direction seems to be the default, but from the API it is not always immediately clear whether a result is: a borrow/view into the original input buffer, or an owned copy

To clarify, currently Vest parsers would copy "small" types like u16/u32, borrow "large" types like byte slices, and allocate for collection types like vectors (though the elements inside the vector would still be borrowed/copied forms depending on whether they are large/small). The constructed types then transitively copy/borrow/allocate during parsing.

We do plan to make our parsing API more flexible in the future by supporting check/validation-only mode (so absolute zero-copy), eager parsing mode (so mostly zero-copy, but allocating for collection formats), and lazy parsing mode (so less automation/ergonomics, but more flexibility and absolute zero-allocation). To get the owned values (which would necessarily incur copy and possibly allocation), the easiest way is probably to properly specify and provide trait imps for the ref-types. Stay tuned :)