<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">(Sorry if you get this email twice, I realized I first sent it from an email address that is not the one I used to subscribe to this list)</div><div class=""><br class=""></div>Not only that, but placing defer at the end of a scope, where any other code may never get executed if there’s an early return, kind of violates the whole concept of control flow.<div class=""><br class=""></div><div class=""><div class="">func f() throws {</div><div class=""> let o = file(path: "")</div><div class=""> o.openFile()</div><div class=""> do {</div><div class=""> try o.write(self.data)</div><div class=""> }</div><div class=""><br class=""></div><div class=""> print("success")</div><div class=""> always { o.close() }</div><div class="">}</div></div><div class=""><br class=""></div><div class="">What happens if o.write fails? Going with always would imply that we either…</div><div class=""><br class=""></div><div class=""><u class=""><b class="">A)</b></u> put the `always` in every possible place the scope might exit, defeating the whole purpose of defer/always. Maury, I’m assuming you’re not actually suggesting that, which would leave: <u class=""><b class="">B)</b></u> if the main scope of the function exits at any point, drop down to the `always` at the end of the scope and execute it. But then, what about the surrounding code at the end of the main scope? Like I said, I think this would violate the whole concept of control flow by cherry-picking a specific type of command that is always executed within a scope, even if that command is in some place the control flow doesn’t reach.</div><div class=""><br class=""></div><div class="">Unless I’m misinterpreting something (let me know if I am) this seems less intuitive than `defer` was to begin with.</div><div class=""><br class=""></div><div class="">-Robert</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 2, 2016, at 3:17 PM, Dennis Lysenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><p dir="ltr" class="">Deferring at the end of the function removes the ability to defer actions on variables introduced in an inner scope. </p>
<br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sat, Jan 2, 2016, 1:57 PM Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have the terrible feeling something is wrong with my posts so that they get caught by spamfilters or similar…<br class="">
<br class="">
But as others stated as well:<br class="">
defer has a use case that is a little bit different from what you want to archive.<br class="">
<br class="">
> Why not use a solution that is widely used and better?<br class="">
I'm curious:<br class="">
Which languages have this "always" construct?<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Yx2mjd-2FVnspRuSokyI98NQDPqRZYgb6WnUwWeJxfAA5bPFMiYuB-2F9xby9BBJvIrS48K4dlYSuAtd-2BZIYkTIdvLDTy1BbtyfCPk8F8wXLN8HyIYZKvhCiaRrPULOD4y5-2B4BRU0P-2Bi367uxOdftXL8r4OcVTyr5ogMovn7Wc4YMtSAPBQKmmmCClsaJ7T8O53QGcfRK8yXv73ZAZ9rBgABVw-3D-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>