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

2017-08-19 Thread Georgios Moschovitis via swift-evolution
> what's important is that the code may pause for a while during a given > expression and run other stuff in the meantime. I think that’s what `yield` actually means. In you sentence there is nothing about (a)waiting, only about pausing and ‘yielding’ the cpu time to ‘run other stuff’. -g. _

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

2017-08-19 Thread David Hart via swift-evolution
> On 20 Aug 2017, at 01:17, Chris Lattner via swift-evolution > wrote: > > >> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution >> wrote: >> >> This looks fantastic. Can’t wait (heh) for async/await to land, and the >> Actors pattern looks really compelling. >> >> One thought

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

2017-08-19 Thread Jan Tuitman via swift-evolution
Hi Joe, Thanks for the answers so far! Abrupt cancellation is indeed not a good idea, but I wander if it is possible on every place where “await” is being used, to let the compiler generate code which handles cancellation, assuming that can be cheap enough (and I am not qualified to judge if

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
On Sat, Aug 19, 2017 at 10:28 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > >> >> On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: >> >> What you’re describing is basically an earlier version of the p

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread David Ungar via swift-evolution
Chris Lattner wrote: > Also, if I were to nitpick your argument a bit, it isn’t true that the > protocol knows “nothing" about the type anyway, because the protocol has > access to self. The default implementation could conceptually use reflection > to access all the state in the type: we’re p

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

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 19, 2017, at 9:33 PM, Brent Royal-Gordon > wrote: > >> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: >> >> Regardless of which approach we take, it feels like something that needs to >> be implicit for structs and enums where value semantics is trivially >

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

2017-08-19 Thread Brent Royal-Gordon via swift-evolution
> On Aug 19, 2017, at 1:29 PM, Michel Fortin via swift-evolution > wrote: > > I'm not actually that interested in the meaning of value semantics here. I'm > debating the appropriateness of determining whether something can be done in > another thread based on the type a function is attached to

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

2017-08-19 Thread Thomas via swift-evolution
> On 20 Aug 2017, at 03:36, Brent Royal-Gordon wrote: > >> On Aug 19, 2017, at 2:25 AM, Thomas > > wrote: >> >>> I think we need to be a little careful here—the mere fact that a message >>> returns `Void` doesn't mean the caller shouldn't wait until it's done to >>

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

2017-08-19 Thread Brent Royal-Gordon via swift-evolution
> On Aug 19, 2017, at 7:41 AM, Matthew Johnson wrote: > > Regardless of which approach we take, it feels like something that needs to > be implicit for structs and enums where value semantics is trivially provable > by way of transitivity. When that is not the case we could require an > explic

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 19, 2017, at 6:42 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick > wrote: > >> On Aug 19, 2017, at 6:16 PM, Taylor Swift > > wrote: >> >> What you’re describing is basically an earlier version of t

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

2017-08-19 Thread Brent Royal-Gordon via swift-evolution
> On Aug 19, 2017, at 3:23 AM, Georgios Moschovitis via swift-evolution > wrote: > > I am wondering, am I the only one that *strongly* prefers `yield` over > `await`? > > Superficially, `await` seems like the standard term, but given the fact that > the proposal is about coroutines, I think `

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

2017-08-19 Thread Karim Nassar via swift-evolution
> On Aug 19, 2017, at 7:17 PM, Chris Lattner wrote: > > >> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> This looks fantastic. Can’t wait (heh) for async/await to land, and the >> Actors pattern looks really compelling. >> >

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
On Sat, Aug 19, 2017 at 9:31 PM, Andrew Trick wrote: > > On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal > which had a slightly weaker precondition (source >= destination) than yours > (source == destination). That one b

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

2017-08-19 Thread Brent Royal-Gordon via swift-evolution
> On Aug 19, 2017, at 2:25 AM, Thomas wrote: > >> I think we need to be a little careful here—the mere fact that a message >> returns `Void` doesn't mean the caller shouldn't wait until it's done to >> continue. For instance: >> >> listActor.delete(at: index) /

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 19, 2017, at 6:16 PM, Taylor Swift wrote: > > What you’re describing is basically an earlier version of the proposal which > had a slightly weaker precondition (source >= destination) than yours (source > == destination). That one basically ignored the Sequence methods at the > expen

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
What you’re describing is basically an earlier version of the proposal which had a slightly weaker precondition (source >= destination) than yours (source == destination). That one basically ignored the Sequence methods at the expense of greater API surface area. On Sat, Aug 19, 2017 at 9:08 PM, A

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 19, 2017, at 5:33 PM, Taylor Swift wrote: > > I agree it’s probably a bad idea to add the default arg to those two > functions. However, the default argument in initialize(repeating:count:) is > there for backwards compatibility since it already had it before and there’s > like a hun

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 19, 2017, at 6:03 PM, Taylor Swift wrote: > > > > On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick > wrote: >>> >>> The problem is I would expect to be able to safely call deinitialize() and >>> friends after calling initialize(from:). If Element is a class ty

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
On Sat, Aug 19, 2017 at 8:52 PM, Andrew Trick wrote: > >> The problem is I would expect to be able to safely call deinitialize() >> and friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling deinitialize() >> will crash.

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
>> >> The problem is I would expect to be able to safely call deinitialize() and >> friends after calling initialize(from:). If Element is a class type and >> initialize doesn’t fill the entire buffer range, calling deinitialize() will >> crash. That being said, since copy(from:bytes:) and copy

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
I agree it’s probably a bad idea to add the default arg to those two functions. However, the default argument in initialize(repeating:count:) is there for backwards compatibility since it already had it before and there’s like a hundred places in the stdlib that use this default value. On Sat, Aug

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
On Sat, Aug 19, 2017 at 6:05 PM, Andrew Trick wrote: > > On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick wrote: > >> >> On Aug 8, 2017, at 11:10 PM, Taylor Swift wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick wrote: >> >>> >>>

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

2017-08-19 Thread Chris Lattner via swift-evolution
> On Aug 19, 2017, at 8:14 AM, Karim Nassar via swift-evolution > wrote: > > This looks fantastic. Can’t wait (heh) for async/await to land, and the > Actors pattern looks really compelling. > > One thought that occurred to me reading through the section of the > "async/await" proposal on wh

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

2017-08-19 Thread Chris Lattner via swift-evolution
On Aug 19, 2017, at 2:02 AM, Susan Cheng wrote: > Hi chris, > > is a actor guarantee always process the messages in one by one? > so, can it assume that never being multiple threads try to modify the state > at the same time? Yep, that’s the idea. > P.S. i have implemented similar idea before:

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 9, 2017, at 8:51 AM, Taylor Swift wrote: > > > > On Wed, Aug 9, 2017 at 2:34 AM, Andrew Trick > wrote: > >> On Aug 8, 2017, at 11:10 PM, Taylor Swift > > wrote: >> >> >> On Wed, Aug 9, 2017 at 1:51 AM, Andrew Trick >

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Andrew Trick via swift-evolution
> On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution > wrote: > > Implementation is here: https://github.com/apple/swift/pull/11464 > > > On Sat, Aug 12, 2017 at 8:23 PM, Taylor Swift > wrote: > I’ve revised

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

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 19, 2017, at 3:29 PM, Michel Fortin wrote: > > >> Le 19 août 2017 à 11:38, Matthew Johnson a écrit : >> >> >> >> Sent from my iPad >> >> On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution >> wrote: >> > For instance, has Array value semantics

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Xiaodi Wu via swift-evolution
On Sat, Aug 19, 2017 at 3:26 PM, Goffredo Marocchi wrote: > Sorry, I thought that the default implementation in the protocol extension > was how this was provided. > > Providing Default Implementations > > You can use protocol extensions to provide a default implementation to any > method or comp

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

2017-08-19 Thread Michel Fortin via swift-evolution
> Le 19 août 2017 à 11:38, Matthew Johnson a écrit : > > > > Sent from my iPad > > On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution > mailto:swift-evolution@swift.org>> wrote: > For instance, has Array value semantics? >>> >>> By the commonly accepted definition, Array

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Goffredo Marocchi via swift-evolution
Sorry, I thought that the default implementation in the protocol extension was how this was provided. > Providing Default Implementations > You can use protocol extensions to provide a default implementation to any > method or computed property requirement of that protocol > https://developer.

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Haravikk via swift-evolution
> On 19 Aug 2017, at 19:46, Daryle Walker wrote: > >> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > >>> wrote: Am 17.08.2017 um 20:11 schrieb Haravikk vi

[swift-evolution] Preparing Swift compiler stage reentrancy in preparation for "constexpr"

2017-08-19 Thread Daryle Walker via swift-evolution
[I’m not sure which list should cover this.] I once thought of having a “#protocols(SomeTypeOrProtocol)” that was a type alias to a composition of all protocols the given type/protocol conforms to (or “Any” if none). It seems simple, but all current uses of protocols requires explicit mentions

Re: [swift-evolution] typed throws

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 19, 2017, at 2:16 PM, Xiaodi Wu wrote: > >> On Sat, Aug 19, 2017 at 2:04 PM, Matthew Johnson >> wrote: >> >> >> Sent from my iPad >> >>> On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: >>> >>> On Sat, Aug 19, 2017 at 08:29 Matthew Johnson wrote: >>

Re: [swift-evolution] typed throws

2017-08-19 Thread Xiaodi Wu via swift-evolution
On Sat, Aug 19, 2017 at 2:04 PM, Matthew Johnson wrote: > > > Sent from my iPad > > On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: > > > On Sat, Aug 19, 2017 at 08:29 Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: >> >> >> >> On Fri, A

Re: [swift-evolution] typed throws

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 19, 2017, at 12:43 PM, Xiaodi Wu wrote: > > >> On Sat, Aug 19, 2017 at 08:29 Matthew Johnson wrote: >> >> >> Sent from my iPad >> >>> On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: >>> >>> >>> On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson wrote

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Daryle Walker via swift-evolution
> On Aug 19, 2017, at 7:06 AM, Haravikk via swift-evolution > wrote: > >> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de > wrote: >>> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >>> mailto:swift-evolution@swift.org>>: >>> For me the whole point of a basic p

Re: [swift-evolution] [Pitch] Improve `init(repeating:count)`

2017-08-19 Thread Daryle Walker via swift-evolution
> On Aug 17, 2017, at 1:06 PM, Erica Sadun via swift-evolution > wrote: > > Also, for those of you here who haven't heard my previous rant on the > subject, I dislike using map for generating values that don't depend on > transforming a domain to a range. (It has been argued that `_ in` is map

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

2017-08-19 Thread Marc Schlichte via swift-evolution
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() } ``` `susp

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Xiaodi Wu via swift-evolution
On Sat, Aug 19, 2017 at 1:13 PM, Goffredo Marocchi wrote: > We can override the protocol default implementation in the extension, but > the issue I see with default implementation in Swift is that if I pass the > object created this way around in a type erased container (Any : Protocol1 > like

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Goffredo Marocchi via swift-evolution
We can override the protocol default implementation in the extension, but the issue I see with default implementation in Swift is that if I pass the object created this way around in a type erased container (Any : Protocol1 like it was common for many to pass id around in the Objective-C days,

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Xiaodi Wu via swift-evolution
On Sat, Aug 19, 2017 at 06:07 Haravikk via swift-evolution < swift-evolution@swift.org> wrote: > > On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote: > > Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution < > swift-evolution@swift.org>: > > For me the whole point of a basic protocol

Re: [swift-evolution] typed throws

2017-08-19 Thread Xiaodi Wu via swift-evolution
On Sat, Aug 19, 2017 at 08:29 Matthew Johnson wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: > > > > On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson > wrote: > >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: >> >> Joe Groff wrot

Re: [swift-evolution] SE-184 Improved Pointers

2017-08-19 Thread Taylor Swift via swift-evolution
Added those methods to the implementation and updated the proposal document. On Fri, Aug 18, 2017 at 11:42 PM, Andrew Trick wrote: > > On Aug 18, 2017, at 5:36 PM, Taylor Swift wrote: > > Should the immutable bu

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

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 19, 2017, at 8:16 AM, Michel Fortin via swift-evolution > wrote: > >>> For instance, has Array value semantics? >> >> By the commonly accepted definition, Array does not provide value >> semantics. >> >>> You might be tempted to say that it does not because it co

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

2017-08-19 Thread Georgios Moschovitis via swift-evolution
Also, notice the consistency keyword: throw, return type marker: throws (‘monadic’ Result) keyword: yield, return type marker: yields(‘monadic’ Future) -g. > On 19 Aug 2017, at 1:23 PM, Georgios Moschovitis via swift-evolution > wrote: > > I am wondering, am I the only one that *

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

2017-08-19 Thread Karim Nassar via swift-evolution
This looks fantastic. Can’t wait (heh) for async/await to land, and the Actors pattern looks really compelling. One thought that occurred to me reading through the section of the "async/await" proposal on whether async implies throws: If ‘async' implies ‘throws' and therefore ‘await' implies ‘t

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

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad On Aug 19, 2017, at 12:29 AM, Brent Royal-Gordon via swift-evolution wrote: >> On Aug 18, 2017, at 12:35 PM, Chris Lattner wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an >>> `async` method returning `Never`, even though the computatio

Re: [swift-evolution] typed throws

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 18, 2017, at 11:24 PM, John McCall wrote: > > >>> On Aug 18, 2017, at 11:43 PM, Mark Lilback wrote: >>> >>> >>> On Aug 18, 2017, at 2:27 AM, John McCall via swift-evolution >>> wrote: >>> >>> Even for non-public code. The only practical merit of typed throws

Re: [swift-evolution] typed throws

2017-08-19 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 18, 2017, at 9:19 PM, Xiaodi Wu wrote: > > > >> On Fri, Aug 18, 2017 at 8:11 PM, Matthew Johnson >> wrote: >> >> >> Sent from my iPad >> >>> On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: >>> >>> Joe Groff wrote: >>> >>> An alternative approach that embraces

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

2017-08-19 Thread Michel Fortin via swift-evolution
>> For instance, has Array value semantics? > > By the commonly accepted definition, Array does not provide value > semantics. > >> You might be tempted to say that it does not because it contains class >> references, but in reality that depends on what you do with those UIViews. > > An aspect

Re: [swift-evolution] [Concurrency] Fixing race conditions in async/await example

2017-08-19 Thread Thomas via swift-evolution
Maybe this will be handled more gracefully via the actor model. 1. if you're calling from an actor, you'd be called back on its internal queue. If you're calling from the 'main actor' (or just the main thread), you'd be called back on the main queue 2. you would just add a cancel() method to the

[swift-evolution] [Concurrency] Fixing race conditions in async/await example

2017-08-19 Thread Jakob Egger via swift-evolution
I've read async/await proposal, and I'm thrilled by the possibilities. Here's what I consider the canonical example: @IBAction func buttonDidClick(sender:AnyObject) { beginAsync { let image = await processImage() imageView.image = image } } This is exactly the kind of thing I will use

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Haravikk via swift-evolution
> On 19 Aug 2017, at 11:44, Tino Heth <2...@gmx.de> wrote: >> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>>: >> For me the whole point of a basic protocol is that it forces me to implement >> some requirements in order to conform; I can throw a

Re: [swift-evolution] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

2017-08-19 Thread Tino Heth via swift-evolution
> Am 17.08.2017 um 20:11 schrieb Haravikk via swift-evolution > : > > For me the whole point of a basic protocol is that it forces me to implement > some requirements in order to conform; I can throw a bunch of protocols onto > a type and know that it won't compile until I've finished it, deve

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

2017-08-19 Thread Georgios Moschovitis via swift-evolution
I am wondering, am I the only one that *strongly* prefers `yield` over `await`? Superficially, `await` seems like the standard term, but given the fact that the proposal is about coroutines, I think `yield` is actually the proper name. Also, subjectively, it sounds much better/elegant to me! -g

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

2017-08-19 Thread Thomas via swift-evolution
> On 18 Aug 2017, at 21:35, Chris Lattner via swift-evolution > wrote: > > Yeah, I think that actor methods deserve a bit of magic: > > - Their bodies should be implicitly async, so they can call async methods > without blocking their current queue or have to use beginAsync. I have a questio

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

2017-08-19 Thread Thomas via swift-evolution
> On 19 Aug 2017, at 07:30, Brent Royal-Gordon via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:35 PM, Chris Lattner > > wrote: >> >>> (Also, I notice that a fire-and-forget message can be thought of as an >>> `async` method returning `Never`, even though t

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

2017-08-19 Thread Andre via swift-evolution
> H29/08/19 12:41、Chris Lattner のメール: > > On Aug 18, 2017, at 8:18 PM, Andre wrote: >> If this was to be a feature at some point, when do you foresee a possible >> inclusion for it? >> Swift 5,or 6 timeframe? > > It’s hard to predict. IMO, ABI stability and concurrency are the most > import

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

2017-08-19 Thread Susan Cheng via swift-evolution
> 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