[swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)

[Colin Barrett]

> On Jul 30, 2016, at 12:21 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> I wrote this a few months ago, but we weren't accepting additive proposals. Now we're explicitly looking for something like this:
>> 
>> Memory ownership model: Adding an (opt-in) Cyclone/Rust inspired memory ownership model to Swift is highly desired by systems programmers and folks who want predictable and deterministic performance (for example, in real time audio processing code).  More pertinent to the goals of Swift 4, this feature is important because it fundamentally shapes the ABI.  It informs code generation for “inout", how low-level “addressors” work in the ABI, impacts the Swift runtime, and will have a significant impact on the type system and name mangling. 
> 
> Memory ownership is about something slightly different than this.  In the context of Swift, the model we’re looking for is:
> 
> - You can completely ignore memory ownership features of the language, and get very far into development with Swift.  This is in stark contrast with Rust and Cyclone, which require you to grapple with it up front.  This means that in the Swift context, this will be more of a “power user” feature, instead of essential part of the model.
> 
> - You can choose to use the memory ownership features by adding extra annotations, giving better performance and control over ARC.  Right now we have very limited options for avoiding ARC overhead in critical loops, largely forcing you to drop down to unsafe constructs.  We’d prefer the model to be “you can add more annotations to your code to get better performance, allowing the compiler statically verify correctness instead of dynamically”.

Has any thought been giving to opting in something analogous in the other direction—i.e. less performant, but less work for the programer? Specifically, I’ve long thought that an annotation opting into a runtime cycle collector (a la http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf <http://researcher.watson.ibm.com/researcher/files/us-bacon/Bacon01Concurrent.pdf>) would be very helpful for situations where, as you mention, performance is not (currently) critical.

-Colin

> - Memory ownership control is an extremely non-trivial feature, which will probably drive us to add first class move semantics and region types to the language.  This will also call for significant standard library extensions.  It will pay for this complexity by making it easy to ignore the complexity if you don’t want it, and by the fact that the standard library and other stuff can go much faster.
> 
> - As a Stage 2 feature, I can imagine an opt-in mode that “forces” the use of these features, for code that wants to guarantee deterministic performance.  This is what enables the use of swift in realtime audio applications, for example.
> 
> While some initial brainstorming and scoping has been done in this area, we’re far from having a concrete design.  We have a few folks who are experts at Rust that are helping contribute ideas and experience to this though.  
> 
> If you have more specific questions, feel free to ask about it.
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160730/53617cc5/attachment.html>