[swift-evolution] [Pitch] Flattening the function type of unapplied instance methods

Joe Groff jgroff at apple.com
Mon Feb 22 17:18:00 CST 2016

> On Feb 22, 2016, at 3:11 PM, Kevin Lundberg <kevin at klundberg.com> wrote:
> I personally use the existing behavior in some of my code, by providing the reference to the method directly to a method/function that takes a closure as a parameter. A modified excerpt from my code:
>     let observer = NSNotificationCenter.defaultCenter().addObserverForName(LoginSuccess, object: nil, queue: nil, usingBlock: weakify(self, self.dynamicType.userDidLogin))
> (Note: This usage normally would lead to a retain cycle, but I wrap the method reference in this weakify() function which handles weakly applying self to the returned method reference.)
> Un-currying method references would make this pattern harder to apply, so if there was a way to resolve this behavior without removing the current flexibility that the curried behavior offers, I would prefer that. Un-currying mutating methods only would be one option, but that seems a bit ugly. 
> However, if there isn't a way to fix it without changing existing behavior, I'd prefer the un-curried form everywhere to removing static method access outright.

If I understand the intent of `weakify` correctly, I think this kind of use case is already pretty severely curtailed by our removing the tuple splat feature, since you can no longer make `weakify` generic across multiple method signatures. Like the tuple splat feature, an explicit variadic splatting feature ought to make this possible for flattened method signatures:

func weakify<Class: class, Args, Result>(instance: Class, method: (Class, Args...) -> Result) -> (Args...) -> Result {
  return {[weak instance] args... in method(instance, args...) }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160222/9636a84c/attachment.html>

More information about the swift-evolution mailing list