Mark Hammond
Mark Hammond
> Actually I think this is fine and preferable. Sorry I didn't note this before, but I was a bit confused here. I'm not sure it does make sense for...
A complication here is that traits are always lifted as callbacks - trying to round-trip traits ends up with foreign wrappers each time. This is quite unlike interfaces which manage...
Ben and I chatted about this briefly and agreed the comment I wrote above is what we should do in the short term, and longer term we might be able...
Great! I *think* it will entail that for traits, instead of generating https://github.com/mozilla/uniffi-rs/blob/main/uniffi_macros/src/export/trait_interface.rs#L17 for the scaffolding we instead will generate closer to https://github.com/mozilla/uniffi-rs/blob/main/uniffi_macros/src/object.rs#L9. I'm sure there will be some devil...
I've not heard of anyone with plans to do this soon.
Yep, a PR would be welcome!
> without the potential of shrink_to performing an extra copy. I don't understand the extra copy shrink_to implies, and why it doesn't work here - isn't the problem the extra...
> My understanding is that if the capacity overflows `i32::MAX`, but not the length, then the `shrink_to()` call will allocate a new vec with less capacity and copy the data...
This is stale now that #1976 has landed, right?
I think there's a good case to be made that this should work the same as records. cc @jeddai