> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution > <[email protected]> wrote: > > >> On Aug 17, 2017, at 4:56 PM, Rod Brown <[email protected] >> <mailto:[email protected]>> 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 >> <[email protected] <mailto:[email protected]>> wrote: >> >>> >>>> On Aug 17, 2017, at 3:24 PM, Chris Lattner <[email protected] >>>> <mailto:[email protected]>> 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 >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
