[swift-evolution] RFC: Preventing Retain Cycles (Memory Ownership Model)
cacoyi at gmail.com
Fri Jul 29 23:59:57 CDT 2016
Thanks for the detailed response :)
My mistake, I was thinking more in terms of managing a user's expectations
regarding ownership and avoiding retain cycles.
What you've described sounds great. I imagine it should only affect this
proposal if the solution it provides adds additional checks for users
accidentally taking strong references.
On Sat, Jul 30, 2016 at 2:21 PM, Chris Lattner <clattner at apple.com> wrote:
> On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution <
> 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
> - 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
> If you have more specific questions, feel free to ask about it.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution