<div dir="ltr">Answers inline:<div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 30, 2016 at 2:17 PM, Félix Cloutier <span dir="ltr"><<a href="mailto:felixcca@yahoo.ca" target="_blank">felixcca@yahoo.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.</div></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><br></div><div>How do you deal with type erasure?</div></div></blockquote><div> </div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><br></div><div><div></div><blockquote type="cite"><div>protocol Foo {}</div><div>class A {</div><div><span style="white-space:pre-wrap"> </span>var foo: Foo</div><div>}</div><div>class B: Foo {</div><div><span style="white-space:pre-wrap"> </span>var a: A</div><div>}</div></blockquote><blockquote type="cite">// A and B can have a cycle through the Foo protocol</blockquote><div><br></div>Also, how do you encode that your example's "addCallback" closure parameter can't have a strong reference to `self`?</div></div></div></blockquote><div><br></div><div>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)`.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><span class="HOEnZb"><font color="#888888"><br><div><br></div></font></span><div><div><div><div><div><div><div><div><span class="HOEnZb"><font color="#888888"><div><span style="color:rgb(0,0,0);font-family:'Lucida Grande';font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;display:inline!important;float:none">Félix</span>
</div>
<br></font></span><div><blockquote type="cite"><div><div class="h5"><div>Le 29 juil. 2016 à 18:42:11, Andrew Bennett via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br></div></div><div><div><div class="h5"><div dir="ltr"><div>I'd like an <b>opt-in</b> way to verify and prevent <b>unintentional strong references</b> in Swift.</div><div><br></div><div>This can be used to verify ownership structures, and ultimately avoid retain cycles.<br></div><div><br></div><div>Read a draft proposal here:</div><div><a href="https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md" target="_blank">https://github.com/therealbnut/swift-evolution/blob/therealbnut-explicit-ownership/proposals/NNNN-explicit-ownership-type-attribute.md</a><br></div><div><br></div><div><div>TL;DR:</div><div><br></div><div><div>If you have any questions please read the proposal before asking here.</div></div><div><br></div><div><div>It's an opt-in attribute that defines a whitelist of types something can own. For example:</div><div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><br></div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><span style="color:rgb(187,44,162)">@owns</span>(TypeA, TypeB) <span style="color:rgb(187,44,162)">struct </span>TypeC { ... }</div><div style="margin:0px;font-size:11px;line-height:normal;font-family:menlo"><br></div></div></div></div><div>I wrote this a few months ago, but we weren't accepting additive proposals. Now we're explicitly looking for something like this:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="white-space:pre-wrap">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.</span> </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> - <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160725/025676.html" target="_blank">Chris</a></blockquote><div><br></div><div>----</div><div><br></div><div>Here's a link to the version of the <a href="https://github.com/therealbnut/swift-evolution/commit/6ab167825d802c7826804e1957eb515d3009743a" target="_blank">proposal</a> when I sent this email.</div></div></div></div><span class="">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></div></div></div></div></div></div></div></div></div></blockquote></div><br></div></div>