Revisiting requiring explicit `self.` when passing a method as an escaping closure

Evolution Pitches
4

I am +1 for this, but I think that if we are going to introduce such a breaking change, we may as well add some syntactic sugar for passing self weakly, since this is something that you often mean to do when passing a method as a closure, but forget about it since the compiler doesn't stop you.

Right now if we want to do it, we go like:

webService.fetchKittenPhotos(completion: { [weak self] args in self?.displayKittenPhoto(args) })

which seems a bit ugly to me, especially as the number of arguments of the method grows.

Maybe something like

webService.fetchKittenPhotos(completion: [weak self]?.displayKittenPhotos)

In this case the type of the expression [weak self]?.displayKittenPhotos would be ((Args) -> Result)? (assuming the the type of the method itself was (Args) -> Result). And if the signature of a higher order function doesn't allow nil arguments, we could write

webService.fetchKittenPhotos(completion: [weak self]?.displayKittenPhotos ?? {})

But that doesn't seem to look good to me either. Maybe someone has a better idea about it?

2 Likes