[swift-evolution] Swift null safety questions

Austin Zheng austinzheng at gmail.com
Mon Mar 13 23:23:42 CDT 2017

We might as well go all the way and have actors and some form of software transactional memory, or at least the low-level building blocks to create something of the sort.

> On Mar 13, 2017, at 9:18 PM, Brent Royal-Gordon <brent at architechies.com> wrote:
>> On Mar 13, 2017, at 5:54 PM, Matthew Johnson <matthew at anandabits.com> wrote:
>> I suspect you're right about this for the most part but I think we will want the ability for "failable processes" (or whatever they're called) to have read-only access to shared state that outlives them.  What I can't imagine is allowing them write access to state that is shared.
> The problem there is that shared data in Swift always has a retain count, so we'd need some way to track when code in one of these "mini-processes" retains an external object so we can release it if it crashes. Perhaps you'd need to wrap a proxy type around shared objects (or instances containing shared objects, like Array and String) and the proxies would register themselves with the runtime as needing emergency cleanup beyond unceremonious deallocation of their "mini-process"'s memory space. This is all doable; it just needs to be designed and done. 
> -- 
> Brent Royal-Gordon
> Sent from my iPhone

More information about the swift-evolution mailing list