Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #578 +/- ##
==========================================
- Coverage 51.64% 50.75% -0.90%
==========================================
Files 69 70 +1
Lines 33735 32315 -1420
==========================================
- Hits 17422 16400 -1022
+ Misses 16313 15915 -398 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
a112ca3 to
f02e9d4
Compare
|
Thanks. I can see how this could be useful, but I'm a bit worried about adding more complexity to the user-facing interfaces in the generated code. |
|
What do you mean by "adding more complexity"? You can already implement SetterInput for your own structs and use that where the setter supports it so But I can see making it more useful means more people using what might be considered an internal trait. If it is truly internal have you considered sealing it so others can't implement it then? Also how would you then see making it easier to convert between generated types and plain rust structs? |
f02e9d4 to
083b39c
Compare
This changes more of the setters both manually implemented and generated to accept a SetterInput.
This makes it useful to implement SetterInput on your own types to support using them with setters.
This is especially useful when you have plain rust structs the represent the capnp-struct and you just want convert one to the other and is my main use case.
I don't know if this is a breaking change like how originally implementing SetterInput was.