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

> 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

> 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 >>

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

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

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

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

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

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

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

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

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

> 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

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

> 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

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

> 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

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

> 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:

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

> 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

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

> On Aug 19, 2017, at 7:17 PM, Chris Lattner 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

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

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

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

> 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

> 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

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

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,

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

> 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

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

> 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

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

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

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

>> >> 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

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

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,

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

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

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

> 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 >

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

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

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

> 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:

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

> 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

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

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 >>

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

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

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

> 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

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 >

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

> On 19 Aug 2017, at 19:46, Daryle Walker wrote: > >> 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:

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

[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

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: >>> >>>

Re: [swift-evolution] typed throws

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 >>

Re: [swift-evolution] typed throws

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: >>> >>> >>>

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

> 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 >>>

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

> 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

[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] [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance

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 :

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

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

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

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

Re: [swift-evolution] typed throws

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 >>

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

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

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

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

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

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

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

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

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

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`

Re: [swift-evolution] typed throws

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: >>>

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

>> 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

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

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

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

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

> 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 >> >: >> For me the whole point of a basic protocol is that it forces me to implement >> some requirements in

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

> 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

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

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!

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

> 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

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

> 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

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

> 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

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

> 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