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

Rod Brown rodney.brown6 at icloud.com
Thu Aug 17 19:11:17 CDT 2017


> On 18 Aug 2017, at 9:56 am, Rod Brown via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
> Hi Chris,
> 
> I love what I’ve read so far. I just have one curiosity from my cursory look over the proposal.
> 
> It seems that in transitioning API to an Async Await system, the completion handler’s type becomes the return type. How would you handle bridging in Foundation API that already has a return type, eg URLSession returns you data tasks, and then fires a completion handler. Perhaps I missed something. I’m sure you could always form a tuple as well, just curious the thoughts on that.

Just as a follow up, thinking this through I’m not sure combining it with this completion handler argument tuple is helpful here, because you generally want access to the data task during execution for cancellation, progress handling etc.

The Async await system doesn’t seem to work well with handling setting something and allowing duplicate return types at different times like a lot of the foundation API is written, does it? I’m not sure how this is solved in C#.


> 
> Thanks,
> 
> Rod
> 
>> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clattner at nondot.org> wrote:
>>> 
>>> Hi all,
>>> 
>>> As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift.  This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast.
>>> 
>>> I’ve been advocating for a specific model involving async/await and actors for many years now.  Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete.  While I hope these ideas help push the discussion on concurrency forward, this isn’t in any way meant to cut off other directions: in fact I hope it helps give proponents of other designs a model to follow: a discussion giving extensive rationale, combined with the long term story arc to show that the features fit together.
>>> 
>>> Anyway, here is the document, I hope it is useful, and I’d love to hear comments and suggestions for improvement:
>>> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>> 
>> Oh, also, one relatively short term piece of this model is a proposal for adding an async/await model to Swift (in the form of general coroutine support).  Joe Groff and I wrote up a proposal for this, here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619
>> 
>> and I have a PR with the first half of the implementation here:
>> https://github.com/apple/swift/pull/11501
>> 
>> The piece that is missing is code generation support.
>> 
>> -Chris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170818/eca7b80f/attachment.html>


More information about the swift-evolution mailing list