<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">2017/08/19 3:51、Chris Lattner <<a href="mailto:clattner@nondot.org">clattner@nondot.org</a>>のメール:<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 <<a href="mailto:pyunpyun@me.com" class="">pyunpyun@me.com</a>> 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, "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></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. 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. You’re unintentionally poking one of my other axes the grind. :)</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. Files can be in “initialized” and “open” states, and that changes the valid actions that can be performed on them. A mutex can be locked or unlocked etc. 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. 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. </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>