-
Notifications
You must be signed in to change notification settings - Fork 45
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
Sendability attributes #359
Conversation
|
A bit unsure where autogenerated I'll need to dig up some good examples to see what would be nicest? |
3e6d97f
to
937ad35
Compare
We still need to figure out how to handle |
937ad35
to
fb21bfb
Compare
edcae4d
to
69cce30
Compare
69cce30
to
53e3cc4
Compare
Swift recently implemented a better concept of sendability, see
NS_SWIFT_SENDABLE
andNS_SWIFT_UI_ACTOR
inFoundation/NSObjCRuntime.h
.Using these attributes, we can automatically mark
NSError
,NSDate
,NSFileHandle
and so onSend + Sync
. (ThatNSLock
and subclasses are marked sendable seems a bit like a bug? But it shouldn't matter much, since the methods on it isunsafe
anyhow, and deallocation on other threads is definitely safe).More importantly, we can automatically mark subclasses of
NSResponder
(NSView
,NSWindow
, ...) asMainThreadOnly
.To finalize the safety of that, it would be nice to run an algorithm like this on every function/method:
(Note here the difference between
includes_ns_swift_ui_actor
andis_ns_swift_ui_actor
;includes_
returns true forNSArray<NSView>
orOption<NSView>
, whileis_
doesn't).So e.g.
NSView::new() -> Id<Self>
would becomeNSView::new(_mtm: MainThreadMarker)
, whileNSWindow::view(&self) -> Id<NSView>
would stay as-is.I checked if we could make
atomic
attributes safe to access from any thread, and it turns out, we cannot, Swift still requires anawait
around these, so we must as well (can be tested on https://online.swiftplayground.run/):If the property is marked
nonisolated
though, then it is possible.