[swift-users] Optional variables from a non-optional source with type inference

[Jordan Rose]

> On Jan 25, 2016, at 16:16 , Michael Henson via swift-users <swift-users at swift.org> wrote:
> 
> While reading the summary of a newsletter's notification about the acceptance of SE-0021's new syntax, a thought occurred to me:
> 
> let fn = someView.insertSubview(_:at:)
> let fn1 = someView.insertSubview(_:aboveSubview:)
> let fn2 = someView.insertSubview(_:belowSubview:)
> 
> That code will create variables fn, fn1, fn2 of the correct type to hold each of the named functions.
> 
> As I understand it, the following things are true:
> 
> 1. Member functions on instances of a class type are curried functions that strongly capture 'self'.
> 2. Any strong reference to those member functions will also prevent that instance from ever reaching ref count 0.
> 3. This isn't a new problem, just one that will become more important now that this use case is easier to... use.
> 
> 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"?

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:

let fn3 = { [weak someView] in someView?.insertSubview($0, belowSubview: $1) }

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.

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 disallowing 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 Swift Evolution Process <https://github.com/apple/swift-evolution/blob/master/process.md>.

Best,
Jordan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-users/attachments/20160126/cd91af2b/attachment.html>