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

> On Jul 30, 2016, at 3:21 PM, Colin Barrett wrote: > >> - 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

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

> On Jul 30, 2016, at 12:21 AM, Chris Lattner via swift-evolution > wrote: > > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution > > wrote: >> I wrote this a few months ago, but we weren't

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

This is very interesting, but it'll probably be a little while before I can fully get my head around it. One query though; an example mentioned is adding @owns(Element) to the Generator protocol, but associated types feel a little different to me; you mention using the strong keyword as an

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

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

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

Answers inline: On Sat, Jul 30, 2016 at 2:17 PM, Félix Cloutier 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

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

On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution 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

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

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

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

Interesting, I'm not familiar with the history of the feature in Rust. Are you able to provide more details on what went wrong in practice? This proposal may be different, this is not attempting to do it without GC. What I'm suggesting still uses ARC (assuming you were counting ARC as GC). It

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

Rust attempted this sort of type-directed cycle prevention early in its development, when it was attempting to provide language-supported shared references without GC, and it didn't work out well for them in practice. -Joe > On Jul 29, 2016, at 6:42 PM, Andrew Bennett via swift-evolution >

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

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: