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

[Andrew Bennett]

Answers inline:

On Sat, Jul 30, 2016 at 2:17 PM, Félix Cloutier <felixcca at yahoo.ca> wrote:

> Seems to me that we can find similar information just from walking over a
> class's fields to build an ownership graph, and cause warnings/errors when
> you find a strong cycle.
>

This is true, but the intent is a whitelist, which is explicit and cannot
be automated. The intent is to catch as many unintentional strong
references as possible. If you walked the fields, methods, and all uses you
could get the same information, but you wouldn't know if they're
intentional.

It may be possible to imply that something owns fields, but the annotation
may need to be more specific than what that produces. For example:
closures, or collections.


> How do you deal with type erasure?
>

That's an interesting point. Currently it will behave much the same as
other collection types. The collection must designate ownership of its
associatedtypes. If that's a protocol then the ownership should be
inherited from the protocol.


> protocol Foo {}
> class A {
> var foo: Foo
> }
> class B: Foo {
> var a: A
> }
>
> // A and B can have a cycle through the Foo protocol
>
>
> Also, how do you encode that your example's "addCallback" closure
> parameter can't have a strong reference to `self`?
>

You encode it by not including it in the list of owned types. If you want
to be able to have a strong reference to self you'd need `@owns(self)`.


>
> Félix
>
> Le 29 juil. 2016 à 18:42:11, Andrew Bennett via swift-evolution <
> swift-evolution at swift.org> a écrit :
>
> I'd like an *opt-in* way to verify and prevent *unintentional strong
> references* in Swift.
>
> This can be used to verify ownership structures, and ultimately avoid
> retain cycles.
>
> Read a draft proposal here:
>
> https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md
>
> TL;DR:
>
> If you have any questions please read the proposal before asking here.
>
> It's an opt-in attribute that defines a whitelist of types something can
> own. For example:
>
> @owns(TypeA, TypeB) struct TypeC { ... }
>
> 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.
>
>
>>  - Chris
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html>
>
>
> ----
>
> Here's a link to the version of the proposal
> <https://github.com/therealbnut/swift-evolution/commit/6ab167825d802c7826804e1957eb515d3009743a> when
> I sent this email.
> _______________________________________________
> 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/21f00130/attachment.html>