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

[Andrew Bennett]

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
> dynamically”.
>
> - 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160730/81672e27/attachment.html>