PHPhotoLibrary.performChanges(_:completionHandler:) not escaping?!

Question

Created Jan ’21

Replies 2

Boosts 0

Participants 2

I do not really have a problem with it, but am wondering just theoretically...

PHPhotoLibrary's performChanges(_:completionHandler:) exists. How come completionHandler closure is not declared as escaping, when changeBlock is declared as escaping?

Or more general question:
If I define a function with two closure parameters where the second closure is called after the first one is finished, and the first closure is escaping, does the second closure have to be escaping as well?

Answered by OOPer in 655997022

How come completionHandler closure is not declared as escaping

Generally, two closure parameters may be independent each other, so one is escaping and the other is non-escaping would be possible.

But in this case, completionHandler is also escaping. In Swift (at least, in recent Swifts, I do not know where the clear documentation about this exists), Optional closure type is implicitly treated as escaping.

In fact, Xcode shows an error writing something like this:

Code Block     func myFunc(_ completion: (Bool, Error?)->Void) { //<- non-escaping, non-Optional closure
        library.performChanges({
            //...
        }, completionHandler: completion) //-> Passing non-escaping parameter 'completion' to function expecting an @escaping closure
    }

If I define a function with two closure parameters where the second closure is called after the first one is finished, and the first closure is escaping, does the second closure have to be escaping as well?

Two closure parameter may be independent. If you can assure that the second closure may only be called in the execution context of the method (meaning it may never executed after completion of the method) it has no need to be escaping.
(Though, the second closure is called after the first one is finished and the second closure may only be called in the execution context of the method leads a conclusion that the first parameter also has no need to be escaping.)

Boost

Answer 1

OOPer OP

Jan ’21

Accepted Answer

How come completionHandler closure is not declared as escaping

Generally, two closure parameters may be independent each other, so one is escaping and the other is non-escaping would be possible.

But in this case, completionHandler is also escaping. In Swift (at least, in recent Swifts, I do not know where the clear documentation about this exists), Optional closure type is implicitly treated as escaping.

In fact, Xcode shows an error writing something like this:

Code Block     func myFunc(_ completion: (Bool, Error?)->Void) { //<- non-escaping, non-Optional closure
        library.performChanges({
            //...
        }, completionHandler: completion) //-> Passing non-escaping parameter 'completion' to function expecting an @escaping closure
    }

If I define a function with two closure parameters where the second closure is called after the first one is finished, and the first closure is escaping, does the second closure have to be escaping as well?

Two closure parameter may be independent. If you can assure that the second closure may only be called in the execution context of the method (meaning it may never executed after completion of the method) it has no need to be escaping.
(Though, the second closure is called after the first one is finished and the second closure may only be called in the execution context of the method leads a conclusion that the first parameter also has no need to be escaping.)

0

Answer 2

aleksa.topic OP

Jan ’21

Optional closure type is implicitly treated as escaping

actually answers my question. I was not aware of that.
This makes completionHandler escaping, and the world in harmony again :)

Thanks! :)

0