> On Sep 11, 2017, at 4:19 PM, Marc Schlichte <marc.schlic...@googlemail.com> 
> wrote:
> 
> 
>> Am 07.09.2017 um 07:05 schrieb Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@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


_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to