<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 19, 2016 at 1:39 PM, Shawn Erickson via swift-evolution <span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>For example [guard self] capture option supports one specific situation without the ability of the block to take alternate actions in the situation of weak self being nil and also requiring no return blocks. This is great obviously for that particular situation however it doesn't really help with the other situations.</div></div></blockquote><div><br></div><div>That's the beauty of it. If you want to do something else, this isn't what you want. This is just a simple bit of sugar to get rid of the very common use case where you have a nilable/void callback that you only want executed if self is not nil.</div><div><br></div><div>If you want/need to do something more complicated, then</div><div>{ [unowned self] in</div><div> guard self != nil else {</div><div> Do the other thing</div><div> }</div><div>}</div></div><div>is great. It's not boilerplate because you're doing something useful in the else case.</div><div><br></div><div>I do still prefer the [unowned self]? syntax, though. It feels so similar to object?.doSomething(). If the lvalue is nil, you get nothing!</div><div><br></div><div>Kurt</div>-- <br><div class="gmail_signature">kurt@CircleW.org<br><a href="http://www.CircleW.org/kurt/" target="_blank">http://www.CircleW.org/kurt/</a><br></div>
</div></div>