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
We do this for FFI functions, but we don't do it for structs or callback function types. This could lead to name collisions if two crates export traits with the same name.
UniFFI structs / callback functions that are always defined like ForeignFuture and ForeignFutureFree should not be prefixed IMO. It's cleaner to have a single definition of those. This maybe means we need to continue using if-guards like swift does, or maybe we could implement a method that combines/dedups the FFI definitions from multiple ComponentInterface instances.
The text was updated successfully, but these errors were encountered:
We do this for FFI functions, but we don't do it for structs or callback function types. This could lead to name collisions if two crates export traits with the same name.
UniFFI structs / callback functions that are always defined like
ForeignFuture
andForeignFutureFree
should not be prefixed IMO. It's cleaner to have a single definition of those. This maybe means we need to continue using if-guards like swift does, or maybe we could implement a method that combines/dedups the FFI definitions from multiple ComponentInterface instances.The text was updated successfully, but these errors were encountered: