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.
> 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. :)
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
<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 ;-)
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.
-Chris
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
