Mark Hammond

We have a number of examples where CrateX depends on CrateY (eg, https://github.com/mozilla/uniffi-rs/tree/main/fixtures/ext-types) - I'm trying to understand what's different about your use-case which is broken vs that which apparently...

I would like to see this reproduced in our [ext-types](https://github.com/mozilla/uniffi-rs/tree/main/fixtures/ext-types) fixture against main. There we have many crates, all in the top-level workspace, and all of which depend on each...

> newtypes can be imported across crates in workspace setup, by use of uniffi::ffi_converter_forward! macro call, Oops - the docs should mention that, but I think that's going to go...

It would be very helpful if you could explain how your use-case is different from our fixtures and/or demonstrate your problem in our fixtures.

I'm still a little confused though - are we maybe conflating 2 different problems here: * That the same name of an exported thing from two different crates will conflict...

> And also: > > * can't separate each FFI into separate Swift targets to avoid name conflicts How is that different from the name collision I described? Re the...

Thanks - but I'm not sure your intent - I'm happy to approve it, but we don't want it landed, right?

Hi, is there any interest in removing some of the test code here? If I don't hear back soon, I'll put up the 2-line PR that actually fixes this and...

We've recently removed all `log` calls from the generated scaffolding.

This should work if you define the enum as an error - ie, use `AnError` in error positions rather than `AnEnum`. It's unfortunate, but really the only reason the distinction...