[swift-evolution] SE-0166: defaults for unmapped enums?

We sometimes encounter the situation that a server will add over time new values to existing `enums`. e.g. in the `enum Animal` example `cat` gets added. To not break existing clients, we often use something like this: enum Animal: Int, Codable { case unknown = 0 case

[swift-evolution] Async Affordances Wish List

Hi, to help with async programming tasks, I could see the following affordances on async/await to be helpful: 1. Make existing Continuation Passing Style (CPS) APIs available via async/await. 2. Await with timeouts. 3. Possibility to cancel awaits. To be more specific: Ad 1. I think it

[swift-evolution] [Concurrency] Actors + Behaviors + Signals

Hi, here are some high-level thoughts on extending Actors with Behaviors and Signals. Actors + Behaviors: The set of messages an Actor might handle at a time is defined by the current behavior which can be changed with the `become` instruction: ``` behavior B1 { message m1() message m2()

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 07.09.2017 um 07:05 schrieb Chris Lattner via swift-evolution > : > > > Imagine you are maintaining a large codebase, and you come across this > (intentionally abstract) code: > > foo() > await bar() > baz() > > Regardless of what is the

Re: [swift-evolution] [Concurrency] Actors + Behaviors + Signals

an actor-method. Obviously, topics like securely passing arguments, master-worker setup, actor lookup, remote capabilities etc. are not touched here. Cheers Marc On Sun, Aug 20, 2017 at 9:43 PM, Marc Schlichte via swift-evolution < swift-evolution@swift.org> wrote: > Hi, > > her

Re: [swift-evolution] New async keyword usage

> Am 27.08.2017 um 17:48 schrieb David Hart via swift-evolution > : > > >> On 27 Aug 2017, at 06:09, Wallacy via swift-evolution >> > wrote: >> >> Chris's proposal is very explicit about the advantages of

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

I hope we come up with some genuine ideas for ReactiveStreams on Swift. For example instead of onNext()/onError() we could have a single method which takes a Result Monad. ARC memory management might require Swift specific solutions too. Also on the mindset: Often I see my Android colleagues

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

> Am 27.09.2017 um 16:37 schrieb Marc Schlichte via swift-evolution > <swift-evolution@swift.org>: > > I also think that actors and signals have to be designed together: > > E.g. how would you subscribe in your actor to a signal defined in another > actor so tha

Re: [swift-evolution] Swift and actors

The Actor paradigm is widely used in the telecommunications industry. You might want to have a look at SDL (https://en.m.wikipedia.org/wiki/Specification_and_Description_Language) with its processes similar to Actors. Btw Erlang with its early actor support started in the telecommunications

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 25.08.2017 um 19:08 schrieb Adam Kemp via swift-evolution > : > > I understand what you’re saying, but I just think trying to make synchronous, > blocking actor methods goes against the fundamental ideal of the actor model, > and it’s a recipe for disaster.

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 26.08.2017 um 02:03 schrieb Adam Kemp via swift-evolution > : > > I’m not sure I understand. What is the connection between references and > deadlocks? This is what I had in mind: To have a deadlock from async actor methods, you would need some mutual

Re: [swift-evolution] [Concurrency] modifying beginAsync, suspendAsync to support cancellation

> Am 19.08.2017 um 20:33 schrieb Marc Schlichte via swift-evolution > <swift-evolution@swift.org>: > > Hi, > > to support cancellation, I propose the following changes to `beginAsync()` > and `suspendAsync()`: > > `beginAsync()` returns an object ad

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 23.08.2017 um 12:29 schrieb Thomas via swift-evolution > : > > >> On 23 Aug 2017, at 11:28, Thomas via swift-evolution >> > wrote: >> >> 1. What happens to the actor's queue when the body of a (non

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 24.08.2017 um 22:05 schrieb Thomas via swift-evolution > : > >> >> Yes, I think it is mandatory that we continue on the callers queue after an >> `await ` on some actor method. >> >> If you `await` on a non-actor-method though, you would have to changes >>

Re: [swift-evolution] [Concurrency] async/await + actors

> Am 25.08.2017 um 01:15 schrieb Adam Kemp via swift-evolution > : > > I don’t think await should cause the actor’s queue (or any queue) to be > suspended. Actor methods should not block waiting for asynchronous things. > That’s how you get deadlocks. If an actor

[swift-evolution] [Concurrency] modifying beginAsync, suspendAsync to support cancellation

Hi, to support cancellation, I propose the following changes to `beginAsync()` and `suspendAsync()`: `beginAsync()` returns an object adhering to a `Cancelable` protocol: ``` func beginAsync(_ body: () async throws-> Void) rethrows -> Cancelable protocol Cancelable { func cancel() } ```

Re: [swift-evolution] [Concurrency] A slightly different perspective

> Am 01.09.2017 um 00:04 schrieb Nathan Gray via swift-evolution > : > > 1. Fixing "queue confusion" *must* be part of this proposal. The key bit of > "magic" offered by async/await over continuation passing is that you're > working in a single scope. A single

Re: [swift-evolution] [Concurrency] A slightly different perspective

No, as I see it, async / await without actors should behave the same way as if you pass continuations instead - especially if we auto convert CPS style functions into await/async style, the queueing behavior must not change IMHO.  CheersMarc

Re: [swift-evolution] Standard ReactiveSteam definitions for Swift

I also think that actors and signals have to be designed together:E.g. how would you subscribe in your actor to a signal defined in another actor so that it is thread safe.I could imagine that the signals used in actors are actors themselves ( maybe sharing the execution context of their

Re: [swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

A somewhat extreme alternative could be the use of IDLs and "libs as services“: A Python lib could aditionally expose its APIs (or a relevant subset of it) via an IDL. Generators would help with the necessary stub and skeleton code on both Python and Swift sides. My impression is that only big

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

We use enums also when modeling JSON responses from our servers. To allow the server side to add new cases without breaking existing clients, we always add an `undefined` case to our enums. Binary frameworks might do the same when exporting enums. When clients compile to a newer version of the