2017/08/19 3:51、Chris Lattner <[email protected]>のメール: >> On Aug 17, 2017, at 10:50 PM, Andre <[email protected]> wrote: >> Part 1: Async/await >> >> let dataResource = await loadWebResource("dataprofile.txt") >> >> >> Was there any thought about introducing the concept of a timeout when >> awaiting? >> >> Something like an `await for:` optional parameter? >> Then, if used with try, it could go like… >> >> let dataResource = try await for:10/*seconds*/ >> loadWebResource("dataprofile.txt”) catch _ as Timeout { //abort,retry cancel >> } >> >> 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… :/ > > 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. 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...
>> Part 2: Actors >> 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? >> >> 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? > > Yes, I completely agree and know what you’re talking about here. You’re > unintentionally poking one of my other axes the grind. :) Wow great! ^^ > 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. > > One abstraction that has been developed in the industry is the notion of > typestate (https://en.wikipedia.org/wiki/Typestate_analysis), 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 ;-) I would very very much look forwards to that manifesto and would love to help out in any way in supporting such a concept! > 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. Definitely true, that. ― If this was to be a feature at some point, when do you foresee a possible inclusion for it? Swift 5,or 6 timeframe? 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. Andre iPadから送信 > -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
