Allow foreign implementations of PartialEq, Eq, Hash etc traits

[mgeisler]

From reading the manual and searching a bit, I don't think it's currently possible for my uniffi::Object and uniffi::Record types to expose their PartialEq, Eq, Hash, etc implementations?

Right now, I used a cheap workaround in my PR:

#[uniffi::export]
impl SigningIdentity {
    /// Is `self` equal to `other`?
    fn equals(&self, other: &Self) -> bool {
        self == other
    }
}

Ideally, the PartialEq impl would make it through. In Python, the __eq__ method could be wired up to delegate to PartialEq::eq, etc. The consequence of not having this is that things like assertions become more cumbersome.

Have I missed something in the manual about this?

[mhammond]

It should be possible for objects - https://mozilla.github.io/uniffi-rs/udl/interfaces.html#exposing-methods-from-standard-rust-traits. It's not possible for records because records have no methods (and it's not immediately obvious we should fix that, given every method call would involve moving the entire record over the FFI, then constructing an object on the rust side, then making the call, which would obviously be very expensive for very large records)

[mhammond]

See also https://github.com/mozilla/uniffi-rs/tree/main/fixtures/trait-methods

[mgeisler]

It should be possible for objects - https://mozilla.github.io/uniffi-rs/udl/interfaces.html#exposing-methods-from-standard-rust-traits.

Oh, thank you! I need to read the UDL section of the manual much more carefully 😄 I've been hoping to avoid it and just use the proc-macros. I see they support this too, so that's neat.

It's not possible for records because records have no methods (and it's not immediately obvious we should fix that, given every method call would involve moving the entire record over the FFI, then constructing an object on the rust side, then making the call, which would obviously be very expensive for very large records)

Very good point...

For the case of a derived Eq, I guess one could deal with records by generating the same implementation in the target language — compare field by field. Eventually, this should bottom out in an object or in a primitive type. That should give all the nice properties one would expect: short-circuiting if two fields don't match, cheap since nothing is sent back to Rust.

One could do similar things for Debug, Display, and Hash. In general, this would only be correct if people don't customize these implementations on the Rust side. That might suggest that

#[derive(Debug, uniffi::Object)]
#[uniffi::export(Debug)]
struct TodoList {
   ...
}

should be

#[derive(uniffi::Object)]
#[uniffi::derive_and_export(Debug)]
struct TodoList {
   ...
}

which would mean that UniFFI is fully responsible for deriving and exposing a standard Debug implementation.

[mhammond]

I can see how records might do this for eq. Display needs a Rust impl IIUC. For Debug, the subset of supported types is such that maybe we could think about generating this by default. Or maybe some way of flagging this as something described as, eg, a "simple" type which flags both eq and default get implemented by default? hash is unclear - would it be necessary in some future for everyone to agree on the hash algo?

[mgeisler]

Display needs a Rust impl IIUC

Good point! So the logic could be that UniFFI will emit an implementation in the target language for traits which can be derived in Rust. The implementation will do the same as the Rust implementation, but in the target language.

Traits like Display won't be in scope for this since they cannot be derived and so we don't have a default implementation to mimic in the target language.

hash is unclear - would it be necessary in some future for everyone to agree on the hash algo?

I haven't checked what deriving Hash does in Rust, but I imagine it just accumulates hash values for every field. So it should be easy to implement this in the target language.

I would like to try implementing this at some point — if/when we find that we need this.