Oh. That&#39;s great. Very useful. Thanks for the info.<span></span><br><br>On Thursday, September 15, 2016, Jordan Rose &lt;<a href="mailto:jordan_rose@apple.com">jordan_rose@apple.com</a>&gt; 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&#39;t dangling in debug builds; they&#39;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&#39;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 &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="javascript:_e(%7B%7D,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" target="_blank">swift-evolution@swift.org</a>&gt; 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&#39;t have optional unowned pointers in swift and Jordan said he didn&#39;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&#39;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&#39;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&#39;d like to be able to reference non-owning instance methods.</span></div><div><br><div style="font-family:&#39;Helvetica Neue&#39;,&#39;Helvetica&#39;,Helvetica,Arial,sans-serif;font:&#39;-apple-system-body&#39;"><a href="https://itunes.apple.com/app/apple-store/id922793622?pt=814382&amp;mt=8&amp;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, &lt;<a>Rick Mann</a>&gt; wrote:<br><br></div><div><pre><br>&gt; On Sep 13, 2016, at 22:34 , Xiaodi Wu via swift-evolution &lt;<a dir="ltr">swift-evolution@swift.org</a>&gt; wrote:
<br>&gt;  
<br>&gt; It&#39;s similar to Linus&#39; 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,&#39;cvml&#39;,&#39;swift-evolution@swift.org&#39;);" 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>