Support no_std environments that can't ship an allocator

[TheButlah]

I'm working on some rust firmware and we are considering the use of flatbuffers. I know that the official flatc requires alloc. However, we are targetting devices that don't have enough flash space for that.

Is there any interest in having the ability to use something like heapless::Vec in planus? Its a bit of a stretch but I thought I would ask.

[TethysSvensson]

Yes, there is definitely interest! I'd even go as far as say that it was one of the original motivations for creating planus.

I think the deserialize code should already work fine without alloc. The serialize code so probably need some work, since the API doesn't support failing allocations.

Perhaps it would be good enough to put the error handling as a field on the builder instead of returning a Result?

[TheButlah]

as a field on the builder

Not sure what you meant by that 👀

[TethysSvensson]

I am considering the problem of how to check for errors while serializing. Ideally a builder that could fail would have an API like this:

fn build_table(builder: &mut planus::Builder) -> Result<planus::Offset<MyTable>> {
    let offset = MyTable::builder().field_a(17).finish(&mut builder)?;
    Ok(offset)
}

However for builders that cannot fail, having to do error handling for non-existing errors is annoying. We could probably solve this with generic associated types, if we were willing to wait until we can bump our MSRV to rust 1.65.

Alternatively we could change the API slightly to look like this:

fn build_table(builder: &mut planus::Builder) -> Result<planus::Offset<MyTable>> {
    let offset = MyTable::builder().field_a(17).finish(&mut builder);
    builder.check_for_errors()?;
    Ok(offset)
}

[TheButlah]

I would opt for the first one over the second, I don't find the second's flow of errors to be idiomatic.

I'm in no rush, I would suggest waiting until GATs if you have features from there you need