Oh. That's great. Very useful. Thanks for the info.<span></span><br><br>On Thursday, September 15, 2016, Jordan Rose <<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>> 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"><div>Unowned pointers aren't dangling in debug builds; they're more like zombie-detection, where you get a deterministic trap if you access them after the original instance is strong-released for the last time. I can't remember if this is enabled in release builds as well; under -Ounchecked they do become unsafe-unretained.</div><div><br></div><div>Jordan</div><div><br></div><br><div><blockquote type="cite"><div>On Sep 14, 2016, at 10:51, Callionica (Swift) via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div>How do you figure unowned pointers help you detect errors? Dangling pointers give you no guarantees.<br><br>On Wednesday, September 14, 2016, Karl Wagner via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div>Sorry to hijack the thread, but I was working to fix the fact that we can't have optional unowned pointers in swift and Jordan said he didn't think anybody ever asked for it before. It made me worry about the kind of practices swift is encouraging.</div><div><br></div><div>The overhead of using weak pointers isn't massive, but it involves locking and updating global tables (<a href="http://stackoverflow.com/questions/23689155/lots-of-overhead-for-weak-property" target="_blank">http://stackoverflow.com/ques<wbr>tions/23689155/lots-of-overhea<wbr>d-for-weak-property</a>)<span>. Unowned pointers don't have this overhead, and can also help you detect errors because they are fail-deadly.</span></div><div><span><br></span></div><div><span>But yeah, I'd like to be able to reference non-owning instance methods.</span></div><div><br><div style="font-family:'Helvetica Neue','Helvetica',Helvetica,Arial,sans-serif;font:'-apple-system-body'"><a href="https://itunes.apple.com/app/apple-store/id922793622?pt=814382&mt=8&ct=how_i_email" target="_blank">This</a> is how I Email now</div></div></div><div><div><br><br><blockquote type="cite" style="margin:1ex 0 0 0;border-left:1px #ccc solid;padding-left:0.5ex"><div>On Sep 14, 2016 at 7:45 am, <<a>Rick Mann</a>> wrote:<br><br></div><div><pre><br>> On Sep 13, 2016, at 22:34 , Xiaodi Wu via swift-evolution <<a dir="ltr">swift-evolution@swift.org</a>> wrote:
<br>>
<br>> It's similar to Linus' argument against using kernel debuggers (<a dir="ltr" href="https://lwn.net/2000/0914/a/lt-debugger.php3" target="_blank">https://lwn.net/2000/0914/a/l<wbr>t-debugger.php3</a>). Understanding your code at a level above the source, and being careful, make you a better developer. There are no features in swift which compensate for a lack of understanding about how your code works.
<br>
<br>Get off my lawn!
<br>
<br>
<br>--
<br>Rick Mann
<br><a dir="ltr">rmann@latencyzero.com</a>
<br>
<br>
<br></pre></div></blockquote></div></div></div></blockquote>
______________________________<wbr>_________________<br>swift-evolution mailing list<br><a href="javascript:_e(%7B%7D,'cvml','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/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br></div></blockquote></div><br></div></blockquote>