<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I've read Chris Lattner proposal on concurrency, and if i'm correct, the proposal is to start implementing async / await mechanism first, then other more evolved mechanisms (such as actors) on top later.<div class=""><br class=""></div><div class="">My question after reading the many conversations (and confusion) around the execution order of async / await on the mailing list is this : </div><div class="">Isn't the actor model a more "elementary" concurrency model than async / await, and so, from a theoretical point of view, wouldn't it make more sense to implement it first as a layer to build future other concurrency mechanisms on top ?</div><div class=""><br class=""></div><div class="">I'm putting emphasis on the "theoretical" aspect of my question, because i'm 100% certain that if Mr Lattner decided to go this path, it's because it makes more sense from an implementation point of view. </div></div></div></blockquote><br class=""></div><div>Actors is a way higher level construct than async/await.</div><div><br class=""></div><div>async/await is IMO an interesting low level construct that explains to the language where your execution flow requires to be broken in two (what is syntactically before and after the "await") to wait for some event before the second half can be done.</div><div><br class=""></div><div>Unlike Actors, it doesn't try to explain what/how/... this is done, which makes it lower level.</div><div><br class=""></div><div>-Pierre</div><br class=""></body></html>