[swift-evolution] [Concurrency] async/await + actors

[Chris Lattner]

> On Sep 11, 2017, at 4:19 PM, Marc Schlichte <marc.schlichte at googlemail.com> wrote:
> 
> 
>> Am 07.09.2017 um 07:05 schrieb Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>>:
>> 
>> 
>> Imagine you are maintaining a large codebase, and you come across this (intentionally abstract) code:
>> 
>> 	foo()
>> 	await bar()
>> 	baz()
>> 
>> Regardless of what is the most useful, I’d argue that it is only natural to expect baz() to run on the same queue/thread/execution-context as foo and bar. 
> 
> But what if `bar` was defined like this in a pre async/await world:
> 
> `bar(queue: DispatchQueue, continuation: (value: Value?, error: Error?) -> Void)`
> 
> ^ There are several existing APIs which use this pattern of explicitly providing the queue on which the continuation should run.
> 
> My expectation (especially as a maintainer) would be that the async/await version exhibits the same queueing semantics as the `old` CPS style - whatever that was (implicitly on the main-queue, implicitly on some background queue or explicitly on a provided queue).

I can understand that expectation shortly after the migration from Swift 4 to Swift 5 (or whatever).  However, in 6 months or a year, when you’ve forgotten about the fact that it happened to be implemented with callbacks, this will not be obvious.  Nor would it be obvious to the people who maintain the code but were never aware of the original API.

We should design around the long term view, not momentary transition issues IMO.

> Also, a related question I have: Will / should it be possible to mix-and-match CPS and async/await style for system APIs? I would say yes, so that we can transfer to the new async/await style at our own pace. 

The proposal does not include any changes to system APIs at all, such a design will be the subject of a follow-on proposal.

-Chris


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