You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
I'm not sure yet, but I'm leaning towards removing the lifetime parameter from
Protocol
. Lifetime parameter pro/cons:Pros:
Cons:
Protocol.to_static
method 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.
The text was updated successfully, but these errors were encountered: