<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Jonathan,</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">You've mentioned the desire to have 'async' defer calling 'await', but I haven't seen a detailed design yet. For example, is the following code valid?</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature"></div><div id="AppleMailSignature"> let image = async fetchImage()</div><div id="AppleMailSignature"><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"> let image2 = async fetchImage()</span></div><div> let deferredThings = [image1, image2]</div></div><div id="AppleMailSignature"><div><br></div><div>If so, what is the type of 'deferredThings'? And how does it not count as 'using' the values.</div><div><br></div><div>If the above code is not valid, how is this situation better than the suggested use of a Future type to allow concurrent async requests?</div><div><br></div><div><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"> let future1 = Future { await fetchImage() }</span></div><div id="AppleMailSignature"><div id="AppleMailSignature"><span style="background-color: rgba(255, 255, 255, 0);"> let future2 = Future { await fetchImage() }</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> let deferredThings = [future1, future2]</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);">Note that in this example, 'deferredThings' has a concrete type, and we can inspect its values.</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div>You keep bringing up this suggestion, so I must be missing something, but it seems to me that your suggestion is covered by Futures. Why is calling with 'async' better?</div><div><br></div></div></div>-BJ</div><div><br>On Sep 3, 2017, at 6:01 PM, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><br class=""><div><blockquote type="cite" class=""><div class="">On Sep 3, 2017, at 9:04 AM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Sep 3, 2017, at 4:00 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><div class=""><div class="Singleton" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="">Please don’t read too much into the beginAsync API. It is merely a strawman, and intended to be a low-level API that higher level abstractions (like a decent futures API) can be built on top of. I think it is important to have some sort of primitive low-level API that is independent of higher level abstractions like Futures.<br class=""><br class="">This is all a way of saying “yes, having something like you propose makes sense” but that it should be part of the Futures API, which is outside the scope of the async/await proposal.<br class=""></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">But it would be nice for all high-level APIs that conform to a<span class="Apple-converted-space"> </span><b class="">Awaitable</b><span class="Apple-converted-space"> </span>protocol to be used with<span class="Apple-converted-space"> </span><b class="">await</b><span class="Apple-converted-space"> </span>without having to reach for a<span class="Apple-converted-space"> </span><b class="">get</b><span class="Apple-converted-space"> </span>property or something similar everytime.</div></div></div></div></blockquote><br class=""></div><div class="">The futures API that is outlined in the proposal is just an example, it isn’t a concrete pitch for a specific API. There are a bunch of improvements that can (and should) be made to it, it is just that a futures API should be the subject of a follow-on proposal to the basic async/await mechanics.</div></div></div></blockquote><br class=""></div><div>Would it be possible to have the manifesto be a series of proposals then? I really think it is important for us to look at how all of these things fit together. I agree that async/await should come first, but looking at how concrete things like Futures would work may help to inform the design of async/await. We should do the back-propigation in our design before anything is locked in...</div><div><br class=""></div><div>The thing I would most like to see as a quick follow-on to async/await is the ability to use the ‘async’ keyword to defer ‘await’. This feels very natural, is highly optimizable by the compiler, and it allows for a lot of very common use-cases which are not covered well by pure async/await. I think it would have a large impact on the eventual design/implementation of futures (and at least some impact on the design of async/await).</div><br class=""><div class="">Thanks,</div><div class="">Jon</div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>