> On 7 Sep 2017, at 07:05, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
>
>> On Sep 5, 2017, at 7:31 PM, Eagle Offshore via swift-evolution
>> <swift-evolution@swift.org> wrote:
>>
>> OK, I've been watching this thing for a couple weeks.
>>
>> I've done a lot of GCD network code. Invariably my completion method starts
>> with
>>
>> dispatch_async(queue_want_to_handle_this_on,....)
>>
>> Replying on the same queue would be nice I guess, only often all I need to
>> do is update the UI in the completion code.
>>
>> OTOH, I have situations where the reply is complicated and I need to persist
>> a lot of data, then update the UI.
>>
>> So honestly, any assumption you make about how this is supposed to work is
>> going to be wrong about half the time unless....
>>
>> you let me specify the reply queue directly.
>>
>> That is the only thing that works all the time. Even then, I'm very apt to
>> make the choice to do some of the work off the main thread and then queue up
>> the minimal amount of work onto the main thread.
>
> I (think that I) understand what you’re saying here, but I don’t think that
> we’re talking about the same thing.
>
> You seem to be making an argument about what is most *useful* (being able to
> vector a completion handler to a specific queue), but I’m personally
> concerned about what is most *surprising* and therefore unnatural and prone
> to introduce bugs and misunderstandings by people who haven’t written the
> code. To make this more concrete, shift from the “person who writes to code”
> to the “person who has to maintain someone else's code”:
>
> 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. If, in the same model, you see something like:
>
> foo()
> await bar()
> anotherQueue.async {
> baz()
> }
Couldn’t it end up being:
foo()
await bar()
await anotherQueue.async()
// on another queue
> Then it is super clear what is going on: an intentional queue hop from
> whatever foo/bar are run on to anotherQueue.
>
> I interpret your email as arguing for something like this:
>
> foo()
> await(anotherQueue) bar()
> baz()
>
> I’m not sure if that’s exactly the syntax you’re arguing for, but anything
> like this presents a number of challenges:
>
> 1) it is “just sugar” over the basic model, so we could argue to add it at
> any time (and would argue strongly to defer it out of this round of
> discussions).
>
> 2) We’d have to find a syntax that implies that baz() runs on anotherQueue,
> but bar() runs on the existing queue. The syntax I sketched above does NOT
> provide this indication.
>
> -Chris
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
