<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Chris, <div class=""><br class=""></div><div class="">This looks amazing(!) … I am really looking forward to the end result whatever that may be, because I know it will be awesome.</div><div class="">Im really excited and a lot raced though my mind while I read it...</div><div class=""><br class=""></div><div class="">———————————————</div><div class=""><h2 style="box-sizing: border-box; margin-top: 24px; margin-bottom: 16px; line-height: 1.25; padding-bottom: 0.3em; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(234, 236, 239); color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; background-color: rgb(255, 255, 255); font-size: 16px;" class="">Part 1: Async/await</h2><div style="" class=""><pre style="box-sizing: border-box; font-family: SFMono-Regular, Consolas, "Liberation Mono", Menlo, Courier, monospace; 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-top-left-radius: 3px; border-top-right-radius: 3px; border-bottom-right-radius: 3px; border-bottom-left-radius: 3px; word-break: normal; color: rgb(36, 41, 46);" class=""> <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">let</span> dataResource <span class="pl-k" style="box-sizing: border-box; color: rgb(215, 58, 73);">=</span> await <span class="pl-c1" style="box-sizing: border-box; color: rgb(0, 92, 197);">loadWebResource</span>(<span class="pl-s" style="box-sizing: border-box; color: rgb(3, 47, 98);"><span class="pl-pds" style="box-sizing: border-box;">"</span>dataprofile.txt<span class="pl-pds" style="box-sizing: border-box;">"</span></span>)<span style="" class="">
</span></pre></div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Was there any thought about introducing the concept of a <i class="">timeout when awaiting</i>?</div><div class=""><br class=""></div><div class="">Something like an `await for:` optional parameter?</div><div class="">Then, if used with try, it could go like…</div><div class=""><br class=""></div><div class=""><font face="Menlo" size="1" class=""> <font color="#d73a49" class="">let</font> dataResource = <font color="#d73a49" class="">try</font> await <b class="">for:<font color="#005cc5" class="">10</font><font color="#a2abab" class="">/*seconds*/</font></b> <font color="#005cc5" class="">loadWebResource</font>("dataprofile.txt”) <span style="color: rgb(215, 58, 73);" class="">catch </span>_<span style="color: rgb(0, 92, 197);" class=""> </span><font color="#d73a49" class="">as</font><span style="color: rgb(0, 92, 197);" class=""> </span>Timeout { //abort,retry cancel } </font></div><div class=""><br class=""></div><div class="">Timeouts should probably be handled at a higher level, but its just something that jumped out to me a little, since its something I notice sometimes people neglect to take care of… :/</div><div class=""><br class=""></div><div class=""><div class=""><br class=""></div><div class="">———————————————</div></div><div class=""><h2 style="box-sizing: border-box; margin-top: 24px; margin-bottom: 16px; line-height: 1.25; padding-bottom: 0.3em; border-bottom-width: 1px; border-bottom-style: solid; border-bottom-color: rgb(234, 236, 239); color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Helvetica, Arial, sans-serif, "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol"; background-color: rgb(255, 255, 255);" class="">Part 2: Actors</h2></div><div class="">One other thing that also jumped at me was, if we are going to have actors, and having them encapsulate/isolate state, would it also make sense to make sure that we can’t invoke state changing messages when its invalid?</div><div class=""><br class=""></div><div class="">As an example, if we had a ”downloader” actor that downloads multiple files, we wouldn't want to be able to send invalid messages such as `begin` when downloading has already ”begun”…. Would it then make more sense to have callable messages be determined by the publicly visible state of the actor instead?</div><div class=""><br class=""></div><div class="">For example, if the downloader actor hasn’t begin downloading, then the only available messages are `begin` and `addItem`, conversely if the actor is ”downloading” then the only messages it should accept are `cancel` and `getProgress`…</div><div class=""><br class=""></div><div class="">Im thinking something along the lines of merging a class with an enum I suppose… </div><div class="">Just put a gist here if you want to see what I am thinking: <a href="https://gist.github.com/andrekandore/f2539a74002d1255cfc3da58faf0f007" class="">https://gist.github.com/andrekandore/f2539a74002d1255cfc3da58faf0f007</a></div><div class=""><div style="margin: 0px; font-stretch: normal; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(23, 23, 23); background-color: rgb(251, 251, 255);" class=""><br class=""></div></div><div class="">It may add complexity but I think (at least for me) instead of writing a lot of boilerplate, it would come naturally from the "state contract"… and it could be more safe than manually doing it myself….</div><div class=""><br class=""></div><div class="">Anyways, maybe Im wrong, but just something I thought about…</div><div class=""><br class=""></div><div class="">———————————————</div><div class=""><br class=""></div><div class="">I would appreciate to hear what you think. ^_^</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Andre</div><div class=""><br class=""></div><div class=""><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class="">H29/08/18 7:25、Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>のメール:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi all,<br class=""><br class="">As Ted mentioned in his email, it is great to finally kick off discussions for what concurrency should look like in Swift. This will surely be an epic multi-year journey, but it is more important to find the right design than to get there fast.<br class=""><br class="">I’ve been advocating for a specific model involving async/await and actors for many years now. Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete. While I hope these ideas help push the discussion on concurrency forward, this isn’t in any way meant to cut off other directions: in fact I hope it helps give proponents of other designs a model to follow: a discussion giving extensive rationale, combined with the long term story arc to show that the features fit together.<br class=""><br class="">Anyway, here is the document, I hope it is useful, and I’d love to hear comments and suggestions for improvement:<br class=""><a href="https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782" class="">https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782</a><br class=""><br class="">-Chris<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class="">swift-evolution@swift.org<br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></body></html>