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

[Félix Cloutier]

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.

How do you deal with type erasure?

> 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`?

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 <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/20160729/77386445/attachment.html>