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

[John McCall]

> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Aug 17, 2017, at 4:56 PM, Rod Brown <rodney.brown6 at icloud.com <mailto:rodney.brown6 at icloud.com>> 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.
> 
> Ah, e.g. this one:
> 
> extension URLSession {
> 
>     /*
>      * data task convenience methods.  These methods create tasks that
>      * bypass the normal delegate calls for response and data delivery,
>      * and provide a simple cancelable asynchronous interface to receiving
>      * data.  Errors will be returned in the NSURLErrorDomain, 
>      * see <Foundation/NSURLError.h>.  The delegate, if any, will still be
>      * called for authentication challenges.
>      */
>     open func dataTask(with request: URLRequest, completionHandler: @escaping (Data?, URLResponse?, Error?) -> Swift.Void) -> URLSessionDataTask
> }
> 
> Returning a tuple is an option, but probably wouldn’t provide the right semantics.  The URLSessionDataTask is supposed to be available immediately, not just when the completion handler is called.  The most conservative thing to do is to not have the importer change these.  If they should have async semantics, they can be manually handled with an overlay.
> 
> In any case, I wasn’t aware of those APIs, thanks for pointing them out.  I added a mention of this to the proposal!

Arguably these could be converted to return both the formal return value and a future.  That would be a rather heroic rule for automatic import, though.

John.

> 
> -Chris
> 
> 
>> 
>> Thanks,
>> 
>> Rod
>> 
>> On 18 Aug 2017, at 8:25 am, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>>> 
>>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner <clattner at nondot.org <mailto: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 <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 <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 <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 <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/20170817/dea170fd/attachment.html>