<div dir="ltr"><div>Makes sense. But if i'm reading its right (and the original proposal too), in this case we don't have only a syntax sugar, we actually gain another ways to use.</div><div><br></div><div>First, because Future actually need another proposal, and <span style="color:rgb(33,33,33)">beginAsync</span> (to me) does not apear to be that rare! "Fire and Forget" is pretty common when we use Cocoa.</div><div><br></div><div><div>Second, because in this way we don't need to handle with Future anymore. Like i see on the other Threads, people tends to believe the "Future" is a more powerful, and only what is needed. Because that (not only that) we cant prevent something like this:</div><div><br></div></div><div><pre style="box-sizing:border-box;font-family:SFMono-Regular,Consolas,"Liberation Mono",Menlo,Courier,monospace;font-size:13.6px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(246,248,250);border-radius:3px;word-break:normal;color:rgb(36,41,46)"><span class="m_7210755241940155774inbox-inbox-m_5050892322987072943inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">func</span> <span class="m_7210755241940155774inbox-inbox-m_5050892322987072943inbox-inbox-pl-en" style="box-sizing:border-box;color:rgb(111,66,193)">someAsyncFunc</span>() <span class="m_7210755241940155774inbox-inbox-m_5050892322987072943inbox-inbox-pl-k" style="box-sizing:border-box;color:rgb(215,58,73)">-></span> Future<User> </pre></div><div><br></div><div>So, after the Future class be implemented, we will need to handle with two patterns at same time! Sometime we will use "await someAsyncFunc()" other times, we will be forced to call someAsyncFunc().get().</div><div><br></div><div>Using only async/await is pretty easy to learn and teach. And the ability to only "wrap" at asynchronous context and "unwrap" using only these two keywords appear be worth.</div><div><br></div><div>Use async keyword to make a function asynchronous.</div><div>Use async keyword to make a closure asynchronous.</div><div>Use async keyword at call side to capture the "reference" and only "unwrap" later. (maybe send to some other place too).</div><div>Use await to get the value from a async function/closure.</div><div><br></div><div>And after that, "Future" can be implement in any way because will not be a public API anymore (I do not know, but there may also be some opportunities for optimization as well), and we only need to care about when we need to "keep the reference" from some async call.</div><div><br></div><div>And possibly, they will not need to create any Future type! The variable type will be "async User" as long as it is not "unwrapped". ( suspend/defer/abandon still possible)</div><div><br></div><div><div class="gmail_quote"><div dir="ltr">Em sex, 25 de ago de 2017 às 02:15, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> escreveu:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Aug 24, 2017, at 4:40 AM, Trevör ANNE DENISE via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_7210755241940155774m_2566164309940984250Apple-interchange-newline"><div><div style="word-wrap:break-word">Hello Swift community,<div><br></div><div>I was really interested by the recent<i> Task-based concurrency manifesto</i> and <i>Concrete proposal for async semantics in Swift.</i></div><div><i><br></i></div><div>Looking at beginAsync() and Futures, I had an idea for a new syntax based on the `async` keyword, I'd love to hear your feedback about this idea:</div><div><a href="https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md" target="_blank">https://github.com/adtrevor/Swift-ideas/blob/master/New%20async%20keyword%20usage.md</a></div><div><br></div><div>Would such a syntax make any sense?</div></div></div></blockquote><br></div></div><div style="word-wrap:break-word"><div>Yes, it is entirely possible that we will want to provide more syntactic sugar than the proposal suggests: the proposal is intentionally designed to be minimal, so we can get it in place, get experience using it, then decide whether any specific syntactic pain point is significant enough to be worth adding additional sugar/complexity.</div><div><br></div><div>As has been mentioned in other threads, the hope is that “beginAsync” is actually extremely rare in practice. If that is the case, there is little point to sugaring it.</div></div><div style="word-wrap:break-word"><div><br></div><div>-Chris</div><div><br></div><br></div>_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</blockquote></div></div></div>