Closed jcornaz closed 1 year ago
I am closing this for now.
Looks like I misunderstood the initial use case which was not serialization for message passing, but more FFi. And I think that should be done on user-defined structs, not on the types provided by this crate.
Overall, I am not keen on adding serialization support for the types of parser as that's an unnecessary increase of API surface and coupling for the dependent crate. After all, there is a well-defined serialized form: the beancount syntax itself. Two software may communicate with each other using that language.
Of course, that may have a performance cost. But I would like to wait until I observe a performance problem worth solving first. I do not want to prematurely optimize at the cost of a more fragile API.
@blais mentioned here an interest in making protobuf messages from the output of this parser, for interop with other languages (like python).
I think we may potentially add the crate protobuf as an optional dependency and conditionally implement the relevant traits on the structs.
Example: