Hi Chris,
This looks amazing(!) … I am really looking forward to the end result whatever
that may be, because I know it will be awesome.
Im really excited and a lot raced though my mind while I read it...
———————————————
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… :/
———————————————
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?
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`…
Im thinking something along the lines of merging a class with an enum I
suppose…
Just put a gist here if you want to see what I am thinking:
https://gist.github.com/andrekandore/f2539a74002d1255cfc3da58faf0f007
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….
Anyways, maybe Im wrong, but just something I thought about…
———————————————
I would appreciate to hear what you think. ^_^
Cheers,
Andre
> H29/08/18 7:25、Chris Lattner via swift-evolution
> <swift-evolution@swift.org>のメール:
>
> Hi all,
>
> 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.
>
> 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.
>
> Anyway, here is the document, I hope it is useful, and I’d love to hear
> comments and suggestions for improvement:
> https://gist.github.com/lattner/31ed37682ef1576b16bca1432ea9f782
>
> -Chris
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
