• Another issue is when an asynchronous completion-handler method is part of an Objective-C protocol. For example, the `NSURLSessionDataDelegate` protocol 1 includes this protocol requirement:

• - (void)URLSession:(NSURLSession*)session

• dataTask:(NSURLSessionDataTask *)dataTask

• didReceiveResponse:(NSURLResponse *)response

• completionHandler:(void (^)(NSURLSessionResponseDisposition disposition))completionHandler;

• Existing Swift code might implement this requirement in a conforming type using its completion-handler signature

• func URLSession(

• _ NSURLSession, dataTask: NSURLSessionDataTask, didReceiveResponse: NSURLResponse,

• completionHandler: (NSURLSessionResponseDisposition) -> Void) { ... }

• while Swift code designed to take advantage of the concurrency model would implement this requirement in a conforming type using its

async

signature

• func URLSession(_ NSURLSession, dataTask: NSURLSessionDataTask, didReceiveResponse: NSURLResponse) async -> NSURLSessionResponseDisposition { ... }

• Implementing both requirements would produce an error (due to two Swift methods having the same selector), but under the normal Swift rules implementing only one of the requirements will also produce an error (because the other requirement is unsatisfied). Swift’s checking of protocol conformances will be extended to handle the case where multiple (imported) requirements have the same Objective-C selector: in that case, only one of them will be required to be implemented.