-
Notifications
You must be signed in to change notification settings - Fork 229
Improve type safety in cocoa crate #200
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
https://github.com/SSheldon/rust-objc-foundation also contains some better infrastructure than we are currently using. |
Could we just start by using newtype pattern around Also in this case I am wondering if we could make some methods safe. It seems if we can guarantee E.g. let mut window: NSWindow = NSWindow::init()
.with_content_rect(rect)
.with_style_mask(mask)
.with_backing(backing)
.with_defer(false)
.build().unwrap();
let title: NSString = NSString::from_str("Hello world");
window.set_title(title) should be safe. |
Yes, that sounds reasonable to me. |
https://github.com/gfx-rs/metal-rs/ is another project that has better type safety. |
Now that This would be a breaking change. Does this crate have constraints that require it to work on earlier versions of rust? I'd be happy to submit a PR if this seems like a good way forward. It seems simpler than newtyping all the things, but maybe there are some other type-safety benefits of going the newtype route that I am missing? |
Can you write up an example of what that code would look like?
|
I think it's a pretty straightforward transformation of In this example, note that
|
Ugh, never mind, this totally doesn't work the way I thought it did, and is in fact invalid syntax. It's possible this, or something like it might work in the future: https://github.com/rust-lang/rfcs/blob/master/text/1522-conservative-impl-trait.md#limitation-to-freeinherent-functions |
This does work however:
|
What's the state on this? Newtypes seem like a suitable solution, no? |
currently all of the interfaces are implemented as traits on Id. This means there's no type safety between objects. We should probably use something like the foreign_obj_type! macro from https://github.com/gfx-rs/metal-rs/blob/master/src/lib.rs to improve things here.
The text was updated successfully, but these errors were encountered: