<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">2017/08/19 3:51、Chris Lattner &lt;<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>&gt;のメール:<br><div><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">On Aug 17, 2017, at 10:50 PM, Andre &lt;<a href="mailto:pyunpyun@me.com" class="">pyunpyun@me.com</a>&gt; wrote:<div><blockquote type="cite" class=""><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><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></div></div></blockquote><div><br class=""></div><div>Something like this could definitely be built and added later: the sketch for async/await is intentionally kept as minimal as possible. &nbsp;That said, this seems like it is wandering into territory that would make sense to be API, rather than first class language feature.</div></div></div></blockquote><div>I see, yea, the only reason I brought it up is because it jumped out as an important concept in my mind that a lot of times seems to get neglected when people write async operations (e.g “how long am I willing to wait for this to finish”.... there are a lot of times I have to force quit apps that’s freeze or become non-responsive, and it’s almost alway waiting to acquire some resource) so i just felt it would be good to have upfront support in some manner for timeouts...</div><br><blockquote type="cite"><div><div><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div class=""><span style="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</span></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></div></blockquote><div><br class=""></div><div>Yes, I completely agree and know what you’re talking about here. &nbsp;You’re unintentionally poking one of my other axes the grind. &nbsp;:)</div></div></div></blockquote><div>Wow great! ^^</div><br><blockquote type="cite"><div><div><div>This desire (to have conceptual “states” that a type moves through) is something that is super common. &nbsp;Files can be in “initialized” and “open” states, and that changes the valid actions that can be performed on them. &nbsp;A mutex can be locked or unlocked etc. &nbsp;Being able to express these invariants is highly related to pre and post conditions.</div><div><br class=""></div><div>One abstraction that has been developed in the industry is the notion of typestate (<a href="https://en.wikipedia.org/wiki/Typestate_analysis" class="">https://en.wikipedia.org/wiki/Typestate_analysis</a>), which underlies common abstractions in static analyzer tools like the Clang Static Analyzer. &nbsp;I would love to see these ideas developed and built out at some point in time, and perhaps the next time I get a long block of time I’ll write another manifesto on those ideas ;-)</div></div></div></blockquote><div>I would very very much look forwards to that manifesto and would love to help out in any way in supporting such a concept!</div><br><blockquote type="cite"><div><div><div>Coming back to your point, these ideas apply just as much to structs and classes as they do actors, so I think it should be a feature orthogonal to actors.</div></div></div></blockquote><div>Definitely true, that.&nbsp;</div><div><br></div><div>—</div><div><br></div><div>If this was to be a feature at some point, when do you foresee a possible inclusion for it?</div><div>Swift 5,or 6 timeframe?</div><div><br></div><div>Meanwhile I will go and start playing with the languages (plaid etc) in the typestate theory wiki link you just shared! I’m glad there is a formal theory behind this, very cool.</div><div><br></div><div>Andre</div><div><br></div><span style="background-color: rgba(255, 255, 255, 0);">iPadから送信</span><div><br><blockquote type="cite"><div><div><div>-Chris</div></div></div></blockquote></div></body></html>