I'm not sure yet, but I'm leaning towards removing the lifetime parameter from Protocol. Lifetime parameter pro/cons:
Pros:
- Reduces the number of allocations the parser does. All identifiers (of records, fields, messages, parameters, etc.) can just be slices.
Cons:
- Since identifiers are just slices of the input, then the input needs to live longer than the slices. The IDL file contents has to be kept around as long as the protocol is used because the protocol borrows it. This could be annoying in some apps. This could be solved at the expense of adding a
Protocol.to_static method that returns Protocol<'static>.
- Adding another lifetime parameter to whatever contains a reference to a protocol can get very annoying too.
Basically, the pro is performance and the con is ergonomics. I'm not convinced that IDL file parsing speed matters a lot. Most of Rust's JSON and XML libraries make it hard or impossible to do zero-copy parsing, and I think it matters a lot more for them.
I'm not sure yet, but I'm leaning towards removing the lifetime parameter from
Protocol. Lifetime parameter pro/cons:Pros:
Cons:
Protocol.to_staticmethod that returnsProtocol<'static>.Basically, the pro is performance and the con is ergonomics. I'm not convinced that IDL file parsing speed matters a lot. Most of Rust's JSON and XML libraries make it hard or impossible to do zero-copy parsing, and I think it matters a lot more for them.