I wonder why swift still don't have "atomic" keyword for properties?
It's so much needed and huge demand!
People inventing different approaches and libraries for this.
I'd love to see swift as safe multithreading language out of the box.
Currently working on multithreading application and have to handle a lot of synchronisation. Use lock or async in queue.
Hi Sakrist,
From what I know, the roadmap for Swift to gain native concurrency features and atomics is scheduled to be addressed as part of the Swift 6 timeline
At this stage a lot of effort is being put into the Swift 5 ABI stability push, so discussions about concurrency features and atomic operations will generally be held off until after that. There has been some high level discussion around an Async-Await system specifically, though these discussions have seemed to quiet down as more pressing issues of finishing already approved proposals in time for 5.0 are being dealt with.
Thank you for update.
Oh this is going to be long wait. :)
There's that really cool proposal by @Joe_Groff about property behaviours, that could someday allow for having atomic properties - [Proposal] Property behaviors
I had seen it. Don't really like that idea. The syntax's in proposal creating more complexity then needed.
Property-level atomicity like in ObjC is usually too fine-grained and gives a false sense of safety with a lot of runtime overhead, which is one of the reasons Swift does not provide them. If you find yourself needing a lot of atomic properties, you may want to reconsider your app architecture; isolation of state among concurrent tasks with minimal, high-level synchronization around communication channels is probably going to be more correct and higher-performance.
I don't need to much atomic properties. In whole application I have one DispatchQueue.sync and just one semaphore use. All other things are handled in async sequence.
I see your point and it's make sense.
P.S.: Actually, by the end of day get rid of one lock I had.