schreter

I also vote for supporting this. We have capnp files with extensive documentation, which isn't propagated to the generated files in Rust. Our C++ version of the code uses a...

Right... The C++ version we have is actually generating dummy headers with C++ structs (i.e., without accessors, plain fields, and pointers for referenced structs/lists). This is used in our Doxygen...

Thanks, looks good from my side 👍.

No, unfortunately the associated constant is not that useful in the current state of affairs, but the desired functionality (creating an appropriately-sized array where to place the builder's buffer for...

Before opening a new issue I stumbled across this one. I think my problem is either the same or related. I'm experimenting with `generic_associated_types` and `(min_)type_alias_impl_trait` and found a few...

> With this change, the _private::struct_size constant goes away. Thanks. It is no problem to use the associated constant instead in our project.

No, `ReplyConsumer` is a public trait, which can be implemented by the user as needed (for example, we'd push replies into reorder buffer reordering them with read-only requests on the...

> But why does it needs a `D` to create a `ReplyConsumer` with `ReplyConsumer::from_request(D)`? The idea is to pass additional information "hidden" in `D`, which allows us to create the...

> The `ReplyConsumer` API would be like the following: `from_request` builds a `ReplyConsumer` and a receiver `Future`. You are right, we need two objects, one that we send to consume...

Nice!