Mark Hammond

> The #[uniffi::constructor] macro can be attached to a function on a uniffi::Recrod As implied by @jplatte, the actual bug here is that the attribute is allowed there. Regarding the...

> 2\. I would like expose other than memberwise init in Swift Does that mean "instead of the default constructor" or "as well as the default ctor"?

The entire "constructor" concept here is a foreign one - so a "private primary constructor" doesn't really make sense - from the bindings POV, this would just mean "no constructor"....

So records could have constructors, like objects do, but just no "primary" constructor (that would be reserved for the local existing init). That sounds good to me! I'm not sure...

> So to me, I have a hard time seeing and argument against supporting methods on Record I wrote: > I'm not sure about how methods would work though -...

> support for non-mutating methods (fn get_foo_with_logic(&self) -> Foo) This is a good example of the footgun I mentioned and why I'm not a huge fan of this. The Rust...

Without advocating for either position, an alternative would be to not support it for dictionaries but add good getter/setter support to interfaces. For many use-cases this would *look* much like...

It's worth nothing that Mozilla ships an iOS browser by leveraging uniffi so swift is very important to us, but some of these perspectives aren't necessarily shared by all iOS...

My point is just that an existing high-profile and (to the core uniffi team) very important consumer of the swift bindings does exist which uses different patterns. A decision about...

> So I would re-frame this feature request as supporting exported impl blocks for non-object types (records, but also enums). Yeah, there are 2 parts to this: * Should uniffi...