The plan for Swift feature-parity #429
Labels
A-framework
Affects the framework crates and the translator for them
A-objc2
Affects the `objc2`, `objc2-exception-helper` and/or `objc2-encode` crates
enhancement
New feature or request
help wanted
Extra attention is needed
Milestone
I've been quite focused on this project simply being "improve the safety of Objective-C in Rust", but @silvanshade recently proposed that we try to reach higher than just that, instead try going for "something that is (at least somewhat) competitive with Swift".
This required a bit of a mental shift for me, but ultimately, I think it is the right way to go about it. This change in mindset should help me realize that tooling, e.g. good
rust-analyzer
and debugger support, is really important, and we should spend effort on that not just in this project, but also in requesting changes to Rust to make it possible.A few subtasks:
header-translator
as a public tool)icrate
#310)Allocated
andId
Id<NSButton>
toId<NSView>
, since callingId::into_super
(potentially many times) is quite cumbersome. Maybe the coerce unsized feature will do it for us?#[distributed_slice]
, as suggested by epage in their blog post about testing would be really nice for makingdeclare_class!
cleaner.linkme
static
s would work similar toextern
statics, in that you can't performconst
operations on them.#[distributed_slice]
aka a method to enumerate tests rust-lang/testing-devex-team#3.Sel
with each function, very similar to what Swift does.MainThreadMarker
,AutoReleasePool<'p>
and availability easier to use (contexts & capabilities)msg_send!
/msg_send_id!
/extern_methods
.extern_methods
such that error spans point to the definition of the method, instead of the macro invocation itself.const
support to allow us to do Create blocks with BLOCK_HAS_SIGNATURE #442 without the user needing to write out the type themselves.header-translator
work intobindgen
.objc2
support incbindgen
.The text was updated successfully, but these errors were encountered: