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
Currently, nested capnp struct definitions translate into rust codegen builders/readers /etc that contain ALL possible generic types, even if they do not use them. For example:
The SubStruct mod's structs contain both T and R generic types, even though they only use R.
root_struct::sub_struct::Builder<T,R>
Here are some examples of some awkward usage this can potentially cause:
let builder = TypedBuilder::<sub_struct::Owned<XXXX_unused_XXXXX, some_struct::Owned>>::new_default();
fn write_to_builder(builder: sub_struct::Builder<XXXX_unused_XXXXX, some_struct::Owned>);
Given the changes in this recent commit, is there any architectural reason it would not be possible to expand the concept of only including used generic types in struct/interface/group definitions instead of only unions? From some of my own (albeit limited) tests, it seems like it would be ok.
The text was updated successfully, but these errors were encountered:
Currently, nested capnp struct definitions translate into rust codegen builders/readers /etc that contain ALL possible generic types, even if they do not use them. For example:
The
SubStruct
mod's structs contain bothT
andR
generic types, even though they only useR
.root_struct::sub_struct::Builder<T,R>
Here are some examples of some awkward usage this can potentially cause:
Given the changes in this recent commit, is there any architectural reason it would not be possible to expand the concept of only including used generic types in struct/interface/group definitions instead of only unions? From some of my own (albeit limited) tests, it seems like it would be ok.
The text was updated successfully, but these errors were encountered: