[Concurrency] Interoperability with Objective-C

Douglas_Gregor · 2020-11-10T06:00:59.945Z

alex.vasenin:

I think we need to find a better example than AVAssetImageGenerator.generateCGImagesAsynchronously(forTimes:completionHandler:) , because it calls its completion handler exactly once per each requested time .

Hah! Serves me right for grabbing a convenient API without checking the documentation. Thank you, I'll pick another example with slightly more care.

AnotherUser:

Does Swift do any static checks on the function it's translating before calling it async ? I imagine it would be rather awkward if an Obj-C function called its completion handler more (or less) than once, breaking a fundamental assumption of async functions. Does it have access to the Obj-C implementation, or does it just assume that the creator followed the standard convention?

It does not have access to the ObjC implementation, so it has to make an assumption based on the convention. If that assumption is wrong, it's up to the ObjC declaration to state that it should not be imported as async with __attribute((swift_async(none))).

Doug

Douglas_Gregor · 2020-11-10T06:02:50.315Z

smontgomery:

Methods in XPC protocols have async semantics and may include a completion handler block parameter. But if they do include a completion handler, its ObjC selector piece is usually suffixed reply: , WithReply: , or similar, without the word “completion”. I’m not sure if this is actually required by NSXPC, but the documentation encourages that convention and anecdotally it seems very common within Apple.

Should the inference rules in this proposal be expanded to also include block parameters whose labels have the suffix reply: ?

That's a good idea; I hadn't seen this convention before.

smontgomery:

I suspect this naming convention would not show up in an audit of Apple’s public APIs since XPC protocols are typically wrapped by external-facing API, but Swift developers would likely encounter this within their own codebases which interact with XPC services or daemons.

It does show up a couple of dozen times in the public SDKs.

Doug

Douglas_Gregor · 2020-11-10T06:04:36.348Z

Douglas_Gregor:

fbruneau:
A common pattern is to have a method that takes a completion handler, but also returns an NSProgress .
- (NSProgress *)doSomethingThatTakesALongTimeWithCompletionHandler:(void (^)(MyResult * _Nullable, NSError * _Nullable))completionHandler;
That's an interesting idea! I'll look into it, thank you.

I looked into a bit further, and it's a bit tricky to make this work. The issue is that the translation is a two-way street: we could import an NSProgress-returning method as async and ignore the progress (for example), but we don't have a way to implement a corresponding @objc method in Swift and produce a reasonable NSProgress result for Objective-C.

Doug

Michael_Ilseman · 2020-11-10T16:48:50.588Z

This looks awesome! I am happy to see such a good interoperability story (and even happier to not worry about the details).

If the method can deliver an error and a given parameter has the _Nullable_result nullability qualifier (see the section on Objective-C attributes below), it will be imported as optional. Otherwise, it will be imported as non-optional.

Taking a default view of a nil parameter signifying a failure is interesting and pretty aggressive!

Ben_Cohen:

A default of optional when true optionals are rare is essentially a technical debt generator.

Ben_Cohen:

when you correct the misannotation it will not break their source.
...
Switching to a non-optional value is guaranteed to break the caller's source
...
the majority of callback results are not truly optional

These are pretty good arguments. Do you have a rough feel of the ratio from the ~1k APIs in the iOS 14.0 SDK mentioned in the document?

AnotherUser · 2020-11-10T19:52:57.170Z

Douglas_Gregor:

It does not have access to the ObjC implementation, so it has to make an assumption based on the convention. If that assumption is wrong, it's up to the ObjC declaration to state that it should not be imported as async with __attribute((swift_async(none))) .

This makes sense. I assume then in the case that an ObjC method fails to call its completion handler that the Swift call would never return. What exactly is the behavior then if a translated ObjC method calls its completion handler more than once?

Douglas_Gregor · 2020-11-10T20:02:36.115Z

AnotherUser:

What exactly is the behavior then if a translated ObjC method calls its completion handler more than once?

This is described in https://github.com/DougGregor/swift-evolution/blob/concurrency-objc/proposals/NNNN-concurrency-objc.md#completion-handlers-must-be-called-exactly-once:

Fortunately, because the compiler itself is synthesizing the block that will be passed to completion-handler APIs, it can detect both problems by introducing an extra bit of state into the synthesized block to indicate that the block has been called. If the bit is already set when the block is called, then it has been called multiple times. If the bit is not set when the block is destroyed, it has not been called at all. While this does not fix the underlying problem, it can at least detect the issue consistently at run time.

Are you asking what the specific failure mode will be?

Doug

AnotherUser · 2020-11-10T20:29:39.933Z

Douglas_Gregor:

Are you asking what the specific failure mode will be?

Thank you for the link. I was mainly worried that some strange undefined behavior would be introduced in such cases. I would expect the program to crash when the issue is detected. Is that the case?

Douglas_Gregor · 2020-11-10T21:06:00.488Z

AnotherUser:

I would expect the program to crash when the issue is detected. Is that the case?

Either that or have the runtime produce a warning that the task is stuck and cannot be completed. It's easy to do either once we've detected the condition.

Doug

fbruneau · 2020-11-11T11:26:36.029Z

Looking at [Concurrency] Structured concurrency, I guess the Objective-C -> Swift import could work by having the progress being imported as a property of the underlying Task.

For instance, if we had the method described before, you could do:

async let result = try doSoethingThatTakesALongTime()
let progress = $result.progress // access the underlying `Task` and extract the progress from it

For the case of the @objc method implemented in swift, the progress could be generated by the system and made accessible, for instance using a single on Task:

func doSoethingThatTakesALongTime() throws async -> MyResult
{
   let progress = Task.current.progress // get a progress that the method can update, attach children, ...
}

or by passing it as a parameter of the method:

func doSoethingThatTakesALongTime(progress: Progress) throws async -> MyResult
{
}

What do you think?

Douglas_Gregor · 2020-11-17T06:46:39.249Z

fbruneau:

For instance, if we had the method described before, you could do:
async let result = try doSoethingThatTakesALongTime()
let progress = $result.progress // access the underlying `Task` and extract the progress from it
For the case of the @objc method implemented in swift, the progress could be generated by the system and made accessible, for instance using a single on Task :
func doSoethingThatTakesALongTime() throws async -> MyResult
{
   let progress = Task.current.progress // get a progress that the method can update, attach children, ...
}

It's plausible, with enough coupling between Task and Progress. This are has not yet been explored in depth.

Doug

frameworklabs · 2020-11-29T20:49:33.866Z

What are the ideas on existing API where the asynchronous continuation is not via a completion handler function but through a delegate method?

frameworklabs · 2020-11-30T17:47:32.290Z

Here is an example of what I mean:

    let p: CBPeripheral = ...
    p.discoverServices()

Now control flow continues in the delegate:

class MyDelegate: CBPeripheralDelegate {
  func peripheral(_ peripheral: CBPeripheral, 
     didDiscoverServices error: Error?) {
       ...
     }
  }
  ...
}

It would be so much nicer to have discoverServices as an async method of course.

Douglas_Gregor · 2020-11-30T18:44:05.187Z

frameworklabs:

class MyDelegate: CBPeripheralDelegate {
  func peripheral(_ peripheral: CBPeripheral, 
     didDiscoverServices error: Error?) {
       ...
     }
  }
  ...
}
It would be so much nicer to have discoverServices as an async method of course.

Yeah. This is the goal behind the not-properly-pitched @asyncHandler, where you will be able to write:

class MyDelegate: CBPeripheralDelegate {
  @asyncHandler
  func peripheral(_ peripheral: CBPeripheral, 
     didDiscoverServices error: Error?) {
       ...
     }
  }
  ...
}

And this synchronously-called function's body will behave "as if" wrapped in a call to Task.runDetached making the body effectively async.

Doug

John_McCall · 2020-11-30T18:55:17.463Z

The right approach for APIs with more structure to their async-ness than just a completion handler is to look at it carefully, decide what that extra structure is trying to achieve, and then think about how to capture it in a more lexically-structured way so that ultimately the whole thing can be an async operation. In many cases there's an "operation" object that exists pretty much solely to provide a handle for cancellation, which can be made into an implementation detail of the API by setting up a Swift cancellation handler that triggers it. (We haven't pitched the cancellation-handler API yet.) In more complex cases where there's a lot of back-and-forth with the API, I think it really just needs to be restructured as an async API where the intermediate back-and-forth is done with a delegate (or whatever) but the final results are delivered normally as the return value.

frameworklabs · 2020-12-01T12:29:03.141Z

Ok, this asyncHandler allows me to use await in delegate Methods - that’s nice but I think John answered what I had in mind - i.e. be able to call the method like this:

await try peripheral.discoverServices()
// continue control flow here and not in some delegate handler

adamkemp · 2020-12-03T01:47:04.746Z

Douglas_Gregor:

The first and third signatures are identical except for being synchronous and asynchronous, respectively. The async/await design accounts for such overloading by favoring synchronous functions in synchronous contexts and asynchronous functions in asynchronous contexts. This overloading should avoid breaking source compatibility.

I’m confused by this because the async/await spec actually calls this out as explicitly disallowed:

Note that we follow the design of throws in disallowing overloads that differ only in async

These statements seem to be in conflict.

Jumhyn · 2020-12-03T02:03:42.268Z

IIUC the current state of the proposals is such that directly defining functions overloaded on async-ness is illegal, but Objective-C import rules are permitting to create Swift entry points which are effectively overloads on async-ness.

Douglas_Gregor · 2020-12-03T05:23:39.483Z

Jumhyn:

IIUC the current state of the proposals is such that directly defining functions overloaded on async -ness is illegal, but Objective-C import rules are permitting to create Swift entry points which are effectively overloads on async -ness.

Yes, that's correct. This also isn't new: The Objective-C translation into Swift has always bent some redeclaration rules, leaving it to overload resolution to sort out the expected behavior. In pure Swift, you can also end up with async and synchronous overloading if the two declarations come from different modules.

I'll need to update this interoperability proposal's wording to account for the change to the async/await proposal, though, so this isn't confusing.

Doug

Douglas_Gregor · 2020-12-09T00:06:59.593Z

Pitch #2 thread here

djp · 2022-01-06T02:37:04.278Z

Large organizations running decades old business NEED to bridge objc legacy to Swift. For pure "great Swift experience" you must sacrifice pretty much of man-hour.