<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 16:16 , Michael Henson via swift-users <<a href="mailto:swift-users@swift.org" class="">swift-users@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">While reading the summary of a newsletter's notification about the acceptance of SE-0021's new syntax, a thought occurred to me:<br class=""><br class=""><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"><span style="color:rgb(69,69,71);white-space:pre-wrap" class="">let fn = someView.insertSubview(_:at:)<br class=""></span><code class="">let fn1 = someView.insertSubview(_:aboveSubview:)<br class=""></code><code class="">let fn2 = someView.insertSubview(_:belowSubview:)</code></blockquote><div class=""><br class=""></div><div class="">That code will create variables fn, fn1, fn2 of the correct type to hold each of the named functions.<br class=""><br class="">As I understand it, the following things are true:<br class=""><br class="">1. Member functions on instances of a class type are curried functions that strongly capture 'self'.</div><div class="">2. Any strong reference to those member functions will also prevent that instance from ever reaching ref count 0.</div><div class="">3. This isn't a new problem, just one that will become more important now that this use case is easier to... use.<br class=""><br class="">The easy fix for this situation would be to declare fn, fn1, and fn2 as weakened optionals so they don't keep someView around if it should have been dallocated. The question is... how? Is there existing syntax that means "infer the type from the right-hand-side production, except as an optional / weakened optional"?</div></div></div></blockquote><br class=""></div><div>Hey, Mike. There's no existing syntax for this today; the best you can get is a custom closure. The type can still be inferred, though:</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div>let fn3 = { [weak someView] in someView?.insertSubview($0, belowSubview: $1) }</div></blockquote><div class=""><br class=""></div><div class="">This works because the closure is a single expression, so the body can be type-checked together with the enclosing statement. If the body has actual statements in it then it is type-checked separately.</div><div class=""><br class=""></div><div class="">We don't currently have any other syntax for this, but personally I think it's not common enough to warrant it. I'd actually rather consider <i class="">disallowing</i> binding member functions like this unless the resulting closure is @noescape. That also keeps you from accidentally introducing retain cycles. But any serious language change here would have to go through the <a href="https://github.com/apple/swift-evolution/blob/master/process.md" class="">Swift Evolution Process</a>.</div><div class=""><br class=""></div><div class="">Best,</div><div class="">Jordan</div></body></html>