> On Sep 18, 2017, at 9:47 AM, Adam Kemp wrote:
>
>> Would it be possible to actually fix this? That is, make the code covered by
>> the `await` evaluate synchronous subexpressions first, such that the code
>> sample above is equivalent to this?
>>
>> @IBAction func buttonDidClick(sender:
> On Sep 15, 2017, at 4:50 AM, Brent Royal-Gordon
> wrote:
>
>> On Sep 12, 2017, at 12:48 PM, Adam Kemp via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> @IBAction func buttonDidClick(sender:AnyObject) {
>> beginAsync {
>> let image = await processImage(downlo
> On Sep 12, 2017, at 12:48 PM, Adam Kemp via swift-evolution
> wrote:
>
> @IBAction func buttonDidClick(sender:AnyObject) {
> beginAsync {
> let image = await processImage(downloadImage(), resize:
> self.resizeSwitch.isOn)
> displayImage(image)
> }
> }
Would it be poss
Totally agree with Adam.
> Am 13.09.2017 um 00:39 schrieb Adam Kemp via swift-evolution
> :
>
>> On Sep 12, 2017, at 2:40 PM, Wallacy wrote:
>>
>> "No, the order of execution is well-defined. The problem isn’t in which
>> order the arguments are executed. The problem is when that evaluation
> On Sep 12, 2017, at 2:40 PM, Wallacy wrote:
>
> "No, the order of execution is well-defined. The problem isn’t in which order
> the arguments are executed. The problem is when that evaluation happens with
> respect to when we return to the run loop. That’s an entirely new problem
> with as
"No, the order of execution is well-defined. The problem isn’t in which
order the arguments are executed. The problem is when that evaluation
happens with respect to when we return to the run loop. That’s an entirely
new problem with async/await. In Swift today it is not possible to write
code that
> On Sep 12, 2017, at 1:00 PM, Wallacy wrote:
>
> So, the problem is a predefined order to evaluate the values, not a "second"
> await.
No, the order of execution is well-defined. The problem isn’t in which order
the arguments are executed. The problem is when that evaluation happens with
r
Em ter, 12 de set de 2017 às 16:48, Adam Kemp via swift-evolution <
swift-evolution@swift.org> escreveu:
>
> I think that decision makes sense for try/throws, but I feel like the
> await keyword is fundamentally different from that. The pitfalls of not
> understanding how the code is transformed a
>> I think that decision makes sense for try/throws, but I feel like the await
>> keyword is fundamentally different from that. The pitfalls of not
>> understanding how the code is transformed and how it will behave at runtime
>> are much greater with await than with try.
>>
>> If you have a l
> On Sep 11, 2017, at 1:42 PM, Adam Kemp wrote:
>
>> Yes, this is a reasonable concern. We debated it heavily in the Swift 2
>> timeframe when introducing error handling (as other’s have pointed out, it
>> works the same way).
>>
>> This is a tradeoff between the readability benefits of mark
> On Aug 28, 2017, at 11:19 PM, Chris Lattner wrote:
>
>
>> On Aug 28, 2017, at 1:09 PM, Adam Kemp via swift-evolution
>> mailto:swift-evolution@swift.org>> wrote:
>>
>> I decided to split this out to its own thread because it seems orthogonal to
>> other issues being discussed.
>>
>> When
> On Aug 28, 2017, at 1:09 PM, Adam Kemp via swift-evolution
> wrote:
>
> I decided to split this out to its own thread because it seems orthogonal to
> other issues being discussed.
>
> When I read this line from the proposal:
>
> await decodeImage(dataResource.get(), imageResource.get())
>
I don't believe that having "await" everywhere will remind you that you have to
precalculate and cache operands to suspending operations. In fact, it sounds
like your goal is not to enforce that every async operation is gated behind
`await`, but to ensure that developers cache the operands of as
> On 28 Aug 2017, at 22:37, Adam Kemp via swift-evolution
> wrote:
>
> I explained what the value is already. It identifies clearly in your code
> where the suspension points are. Each place you see “await” would mark a
> location where your code may yield and allow other things to happen. Th
I'm not convinced by this example. If webProfilePath and imagePath are
mutable, then the expression you wrote is extremely difficult to reason
about even without any async/await. I fail to see how three awaits are
better than one in helping out the situation.
On Mon, Aug 28, 2017 at 15:37 Adam Kemp
I explained what the value is already. It identifies clearly in your code where
the suspension points are. Each place you see “await” would mark a location
where your code may yield and allow other things to happen. Those are points
where state could change unexpectedly. It’s important for someo
"Try" does the same, but I do not know anyone who prefers to repeat the
same keyword several times.
return try func0(try func1(), try func2())
I do not think there's any value in knowing how many interim steps also
need "await" ... In practice, you have to wait for everyone anyway.
Em seg, 28
I decided to split this out to its own thread because it seems orthogonal to
other issues being discussed.
When I read this line from the proposal:
await decodeImage(dataResource.get(), imageResource.get())
It’s not clear to me where the asynchronous call is. There are three function
calls on
18 matches
Mail list logo
