-
Notifications
You must be signed in to change notification settings - Fork 70
Alternatives to ProtocolObject #686
Copy link
Copy link
Open
Labels
A-objc2Affects the `objc2`, `objc2-exception-helper` and/or `objc2-encode` cratesAffects the `objc2`, `objc2-exception-helper` and/or `objc2-encode` cratesenhancementNew feature or requestNew feature or requestquestionThere is no such thing as a dumb one!There is no such thing as a dumb one!
Metadata
Metadata
Assignees
Labels
A-objc2Affects the `objc2`, `objc2-exception-helper` and/or `objc2-encode` cratesAffects the `objc2`, `objc2-exception-helper` and/or `objc2-encode` cratesenhancementNew feature or requestNew feature or requestquestionThere is no such thing as a dumb one!There is no such thing as a dumb one!
I suspect it may be possible for us to basically never need to use
ProtocolObject, but instead rely on the compiler to do the work of figuring out which traits are valid for which objects.I've experimented a bit with
#[derive(CoercePointee)]in bb1ae6f, to show that some of it can indeed work through that. If we also changed message sending such that&dyn NSObjectProtocoltranslates toNonNull<AnyObject>, then using protocol objects would look very, very similar to normal Rust code (methods take&dyn MyProtocoland end up returningRetained<dyn MyProtocol>).One worry is that the vtable may be included in the final binary, that would have to be thoroughly tested beforehand.
We also need to do a more detailed soundness analysis before all this is over.
Another venue to investigate is the relationship between
MessageandRefEncode, and if we could possibly make theMessagetrait bedyn-compatible?