<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,&nbsp;<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, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; 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, &quot;Liberation Mono&quot;, 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="">&nbsp; &nbsp;&nbsp;<font color="#d73a49" class="">let</font>&nbsp;dataResource &nbsp;=&nbsp;<font color="#d73a49" class="">try</font> await <b class="">for:<font color="#005cc5" class="">10</font><font color="#a2abab" class="">/*seconds*/</font></b>&nbsp;<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="">&nbsp;</span>Timeout { //abort,retry cancel }&nbsp;</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, &quot;Segoe UI&quot;, Helvetica, Arial, sans-serif, &quot;Apple Color Emoji&quot;, &quot;Segoe UI Emoji&quot;, &quot;Segoe UI Symbol&quot;; 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…&nbsp;</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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt;のメール:</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. &nbsp;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. &nbsp;Handwaving only goes so far, so some folks asked me to write them down to make the discussion more helpful and concrete. &nbsp;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>