<div dir="ltr">On Tue, Sep 13, 2016 at 10:29 PM, Karl Wagner via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><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">
<div style="padding-left:20px;padding-right:20px;padding-bottom:8px"><span class="gmail-"><div style="direction:inherit">> Honestly, I’d be fine with / prefer only allowing unowned (at all) if it’s @noescape, if that, requiring strong or weak for anything that escapes. That seems to go along with swift’s emphasis on safety. </div><div style="direction:inherit"><br></div></span><div style="direction:inherit">What?!?!! That's an extraordinary thing to say.</div><div style="direction:inherit"><br></div><div style="direction:inherit">I don't think you understand what autozeroing weak references are for. They are <b>not</b> there so that you can have gaps in your reasoning of your code, or to allow undefined behaviour. They exist so that you can have a non-retaining pointer (I.e. Unowned), where the pointee's lifetime is independent of the reference. So when the pointee does deallocate at some unknown time, the pointer reverts to nil doesn't just dangle in to invalid memory.</div><div style="direction:inherit"><br></div><div style="direction:inherit">Let's say I have some reusable functionality, like an input handler for text-processing events with a particular behaviour (maybe it does some validation or something, it's not important). I can encapsulate that as a class (maybe it can't be a struct, that's my business. Maybe it has specialised subclasses or requires identity). Now I have my UIViewController, I create and retain an instance of that class, but the object needs to dispatch events back to the UIVC so it needs a non-strong pointer to its parent.</div><div style="direction:inherit"><br></div><div style="direction:inherit">The parent and child have coupled lifetimes. There will never be an orphaned child; and if there is, and it's handling events and dispatching them nowhere, that's a serious flaw in the application logic. Of course users don't want applications to crash, but developers do! When there are failures in the application logic, I want them to be loud and obvious. Otherwise, we might as well remove all preconditions as other runtime assertions as well.</div><div style="direction:inherit"><br></div><div style="direction:inherit">Some of the comments here about unowned references are scary; you should always understand your application logic, and use of unowned pointers is completely safe if you do. If you're using weak references as a shorthand for a lack of understanding of your own code, you have a bigger problem than an esoteric crashing bug.</div><div style="direction:inherit"><br></div><div style="direction:inherit">It's similar to Linus' argument against using kernel debuggers (<a href="https://lwn.net/2000/0914/a/lt-debugger.php3" target="_blank">https://lwn.net/2000/0914/a/<wbr>lt-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.</div></div></blockquote><div><br></div><div>That's a great explanation. I wish I had more time so that I could search for posts from core team members that can elaborate on this point much better than I could. But the gist of it, as I understand it, is that trapping is safe, while proceeding despite an unexpected flaw in memory handling is unsafe, and Swift chooses safety. This is part of the reasoning behind why, for instance, "lenient" array indexing is on the commonly-rejected proposals list.</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">
<br>______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a><br>
<br></blockquote></div><br></div></div>