<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">I think that there is risk here but I don't think it is serious enough one to be with making changes for.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">1. For most classes there is no problem because everything is managed by ARC anyway so will clean up without special consideration (few of my classes require a deinit). </span></div><div><span style="background-color: rgba(255, 255, 255, 0);">2. It doesn't seem surprising that if init did not succeed that deinit will not run.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">I suppose the risk is greatest where the nil is a result of a returned value from a call made being passed up as explicit `return nil` or `throw` are more visible. </span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">If something were to be changed I wonder if in cases where a failable init exists in a class with a deinit the init could still be responsible for the clean up but must also call an special empty function to confirm to compiler that the situation has been handled. Not sure on name but maybe `deinited()`. Maybe it would just be a warning if not called. Treatment could maybe be similar to warnings where super calls are not made.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Joseph</span></div></div><div><br></div><div><br>On Jan 26, 2016, at 9:39 PM, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr"><span style="font-size:13px">Absolutely, I agree with you. Of course, this was a simplified example, you can easily construct an example where just reordering isn’t going to cut it.</span><div style="font-size:13px"><br></div><div style="font-size:13px">It’s not hard to do things right in the current model. We can reorder statements, write wrappers, or think of different solutions altogether. Once you understand how it works, it’s very easy to write correct code.</div><div style="font-size:13px"><br></div><div style="font-size:13px">However, my complaint is that it’s now also easy to make a mistake. In the previous model, it wasn’t so easy (the previous model was simpler: an init would always be matched by a deinit).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 26, 2016 at 6:39 PM, Douglas Gregor <span dir="ltr"><<a href="mailto:dgregor@apple.com" target="_blank">dgregor@apple.com</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"><span class=""><br><div><blockquote type="cite"><div>On Jan 26, 2016, at 9:15 AM, Chris Eidhof via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word">Now that we can return nil from a failable initializer without having initialized all the properties, it’s easier to make a mistake. For example, consider the following (artificial) code:<div><br></div><div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"><span style="color:#bb2ca2">class</span> MyArray<T> {</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';color:rgb(112,61,170)"><span> </span><span style="color:#bb2ca2">var</span><span> pointer: </span>UnsafeMutablePointer<span><</span><span style="color:#4f8187">T</span><span>></span></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">var</span> capacity: <span style="color:#703daa">Int</span></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';min-height:15px"> <br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">init</span>?(capacity: <span style="color:#703daa">Int</span>) {</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#4f8187">pointer</span> = <span style="color:#703daa">UnsafeMutablePointer</span>.<span style="color:#3d1d81">alloc</span>(capacity)</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">if</span> capacity > <span style="color:#272ad8">100</span> {</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';color:rgb(0,132,0)"><span> </span>// Here we should also free the memory. In other words, duplicate the code from deinit.</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">return</span> <span style="color:#bb2ca2">nil</span></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> }</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">self</span>.<span style="color:#4f8187">capacity</span> = capacity</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';min-height:15px"> <br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> }</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';min-height:15px"> <br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> <span style="color:#bb2ca2">deinit</span> {</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT';color:rgb(79,129,135)"><span> </span>pointer<span>.</span><span style="color:#3d1d81">destroy</span><span>(</span>capacity<span>)</span></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"> }</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'">}</div></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"><br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'">In the `return nil` case, we should really free the memory allocated by the pointer. Or in other words, we need to duplicate the behavior from the deinit.</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"><br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'">Before Swift 2.2, this mistake wasn’t possible, because we knew that we could count on deinit being called, *always*. With the current behavior, return `nil` is easier, but it does come at the cost of accidentally introducing bugs. As Joe Groff pointed out, a solution would be to have something like “deferOnError” (or in this case, “deferOnNil”), but that feels a bit heavy-weight to me (and you still have to duplicate code).</div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'"><br></div><div style="margin:0px;line-height:normal;font-family:'Akkurat TT'">In any case, I think it’s nice that we can now return nil earlier. I don’t like that it goes at the cost of safety, but I realize it’s probably only making things less safe in a small amount of edge cases.</div></div></div></blockquote><br></div></span><div>Let’s re-order the statements in your example:</div><div><br></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><span class=""><div><div><font face="Menlo">class MyArray<T> {</font></div></div><div><div><font face="Menlo"> var pointer: UnsafeMutablePointer<T></font></div></div><div><div><font face="Menlo"> var capacity: Int</font></div></div><div><div><br></div></div><div><div><font face="Menlo"> init?(capacity: Int) {</font></div></div></span><span class=""><div><div><span style="font-family:Menlo"> if capacity > 100 {</span></div></div><div><div><font face="Menlo"> // Here we should also free the memory. In other words, duplicate the code from deinit.</font></div></div><div><div><font face="Menlo"> return nil</font></div></div><div><div><font face="Menlo"> }</font></div></div><div><div><font face="Menlo"> self.capacity = capacity</font></div></div></span><div><div><div><font face="Menlo"> pointer = UnsafeMutablePointer.alloc(capacity)</font></div></div><div></div><div><span style="font-family:Menlo"> }</span></div></div><div><div><font face="Menlo"> </font></div></div><div><div><font face="Menlo"> deinit {</font></div></div><div><div><font face="Menlo"> pointer.destroy(capacity)</font></div></div><div><div><span style="font-family:Menlo"> }</span></div></div><div><div><font face="Menlo">}</font></div></div></blockquote><div><div><br></div><div>If the initializer returns ‘nil’ and we still call deinit, we end up destroying a pointer that was never allocated.</div><div><br></div><div>If you come from an Objective-C background, you might expect implicit zeroing of the allocated block to help here. However, Swift doesn’t have that, because many Swift types don’t have a “zero” state that’s safe to destroy. For example, anything with a member of non-optional reference type, e.g.,</div><div><br></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div><div><font face="Menlo">class ClassWrapper {</font></div></div><div><div><font face="Menlo"> var array: MyArray<String></font></div></div><div><div><font face="Menlo"><br></font></div></div><div><div><font face="Menlo"> init(array: MyArray<String>) {</font></div></div><div><div><font face="Menlo"> self.array = array</font></div></div><div><div><font face="Menlo"> }</font></div><div><font face="Menlo"><br></font></div><div><font face="Menlo"> deinit {</font></div><div><font face="Menlo"> print(array) // array is a valid instance of MyArray<String></font></div><div><font face="Menlo"> }</font></div></div><div><div><font face="Menlo">}</font></div></div></blockquote><div><div><br></div><div>A valid ClassWrapper instance will always have an instance of MyArray<String>, even throughout its deinitializer.</div><div><br></div><div>The basic property here is that one cannot run a deinitializer on an instance that hasn’t been fully constructed (all the way up the class hierarchy).</div><div><br></div></div><div><span style="white-space:pre-wrap"> </span>- Doug</div><div><br></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Chris Eidhof</div>
</div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>