On Aug 18, 2017, at 2:09 PM, Adam Kemp <adam.k...@apple.com> wrote:
>> On Aug 18, 2017, at 12:34 PM, Adam Kemp <adam.k...@apple.com
>> <mailto:adam.k...@apple.com>> wrote:
>>> For instance, say you’re handling a button click, and you need to do a
>>> network request and then update the UI. In C# (using Xamarin.iOS as an
>>> example) you might write some code like this:
>>>
>>> private async void HandleButtonClick(object sender, EventArgs e) {
>>> var results = await GetStuffFromNetwork();
>>> UpdateUI(results);
>>> }
>>>
>>> This event handler is called on the UI thread, and the UpdateUI call must
>>> be done on the UI thread. The way async/await works in C# (by default) is
>>> that when your continuation is called it will be on the same
>>> synchronization context you started with. That means if you started on the
>>> UI thread you will resume on the UI thread. If you started on some thread
>>> pool then you will resume on that same thread pool.
>>
>> I completely agree, I would love to see this because it is the most easy to
>> reason about, and is implied by the syntax. I consider this to be a
>> follow-on to the basic async/await proposal - part of the Objective-C
>> importer work, as described here:
>> https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#fix-queue-hopping-objective-c-completion-handlers
>>
>> <https://gist.github.com/lattner/429b9070918248274f25b714dcfc7619#fix-queue-hopping-objective-c-completion-handlers>
> Maybe I’m still missing something, but how does this help when you are
> interacting only with Swift code? If I were to write an asynchronous method
> in Swift then how could I do the same thing that you propose that the
> Objective-C importer do? That is, how do I write my function such that it
> calls back on the same queue?
You’re right: if you’re calling something written in Swift, the ObjC importer
isn’t going to help you.
However, if you’re writing an async function in Swift, then it is reasonable
for us to say what the convention is and expect you to follow it. Async/await
doesn’t itself help you implement an async operation: it would be turtles all
the way down… until you get to GCD, which is where you do the async thing.
As such, as part of rolling out async/await in Swift, I’d expect that GCD would
introduce new API or design patterns to support doing the right thing here.
That is TBD as far as the proposal goes, because it doesn’t go into runtime
issues.
>>> Another difference between the C# implementation and this proposal is the
>>> lack of futures. While I think it’s fair to be cautious about tying this
>>> proposal to any specific futures implementation or design, I feel like the
>>> value of tying it to some concept of futures was somewhat overlooked. For
>>> instance, in C# you could write a method with this signature:
>> ...
>>>
>>> The benefit of connecting the async/await feature to the concept of futures
>>> is that you can mix and match this code freely. The current proposal
>>> doesn’t seem to allow this.
>>
>> The current proposal provides an underlying mechanism that you can build
>> futures on, and gives an example. As shown, the experience using that
>> futures API would work quite naturally and fit into Swift IMO.
>
> I feel like this is trading conceptual complexity in order to gain compiler
> simplicity. What I mean by that is that the feature feels harder to
> understand, and the benefit seems to be that this feature can be used more
> generally for other things. I’m not sure that’s a good tradeoff.
>
> The other approach, which is to build a specific async/await feature using
> compiler transformations, may be less generic (yield return would have to
> work differently), but it seems (to me) easier to understand how to use.
>
> For instance, this code (modified from the proposal):
>
> @IBAction func buttonDidClick(sender:AnyObject) {
> doSomethingOnMainThread();
> beginAsync {
> let image = await processImage()
> imageView.image = image
> }
> doSomethingElseOnMainThread();
> }
>
> Is less straightforward than this:
>
> @IBAction async func buttonDidClick(sender:AnyObject) {
> doSomethingOnMainThread();
> let imageTask = processImage()
> doSomethingElseOnMainThread();
> imageView.image = await imageTask
> }
This isn’t a fair transformation though, and isn’t related to whether futures
is part of the library or language. The simplification you got here is by
making IBAction’s implicitly async. I don’t see that that is possible, since
they have a very specific calling convention (which returns void) and are
invoked by objc_msgSend. OTOH, if it were possible to do this, it would be
possible to do it with the proposal as outlined.
-Chris
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
