uniffi-rs icon indicating copy to clipboard operation
uniffi-rs copied to clipboard

New custom type system

Open bendk opened this issue 1 year ago • 20 comments

PR notes: I split this out out from #2087 so that we can discuss the custom type changes separate from the remote type changes. I think the new syntax is pretty uncontroversial, but this does require a breaking change so I wanted to make room to discuss that separate from the main conversation. On the topic of breaking changes: I tried but failed on avoiding them. Maybe it's possible with some extra work, but I don't think it's worth it at this point. How does that sound to others?


Implemented a new custom type system described in the new docs. This system is easier to use and also allows us to do some extra tricks behind the scene. For example, I hope to add a flag that will toggle between implementing FfiConverter for the local tag vs a blanket impl. It's not possible to do that with the current system and adding support would be awkward.

I wanted to keep backwards compatibility for a bit, but couldn't figure out a good way to do it. The main issue is that for the old system, if a custom type is declared in the UDL then we generate the FfiConverter implementation, while the new system expects the user to call custom_type! to create the impl. I tried to get things working by creating a blanket impl of FfiConverter for types that implemented UniffiCustomTypeConverter, but ran into issues -- the first blocker I found was that there's no way to generate TYPE_ID_META since we don't know the name of the custom type.

Removed the nested-module-import fixture. The custom type code will no longer test it once we remove the old code, since it's not using UniffiCustomTypeConverter. I couldn't think of a way to make it work again.

bendk avatar Jun 12 '24 14:06 bendk