Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: > > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall wrote: > >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >>> wrote: >>>

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

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 18, 2017, at 6:50 AM, Elviro Rocca wrote: > Here's my thoughts: > > - You might have been too soft on the callback-based syntax of many Cocoa > APIs: those are really bad, and in general a pain to use. Of course a import > strategy for future Swift will

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

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 18, 2017, at 12:40 PM, Thomas wrote: > > >> On 18 Aug 2017, at 21:11, Joe Groff wrote: >> >> >>> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >>> wrote: >>> >>> I think that awaiting on the

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 18, 2017, at 7:19 AM, Michel Fortin wrote: > > Great writeup. Here's a few comments about the manifesto, actors and value > semantics specifically. > > > # About actors and data isolation > > Can I call global functions like sin(x) in an actor? Surely you

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

2017-08-18 Thread Adam Kemp via swift-evolution
I am very interested in the async/await proposal. I will say up front that I have experience using C#’s async/await (with Cocoa via Xamarin) so I am biased towards what I am familiar with. That said, I think there are some advantages to the way C# does it that the current proposal is missing

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

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 2:15 PM, Chris Lattner via swift-evolution > wrote: > > >> On Aug 18, 2017, at 7:19 AM, Michel Fortin > > wrote: >> >> Great writeup. Here's a few comments about the manifesto,

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

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 18, 2017, at 12:34 PM, Adam Kemp wrote: > For instance, say you’re handling a button click, and you need to do a > network request and then update the UI. In C# (using Xamarin.iOS as an > example) you might write some code like this: > > private async void

Re: [swift-evolution] typed throws

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 17, 2017, at 11:27 PM, John McCall via swift-evolution > wrote: > > Essentially, you give Error a tagged-pointer representation to allow > payload-less errors on non-generic error types to be allocated globally, and > then you can (1) tell people to not

Re: [swift-evolution] typed throws

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution > wrote: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson > > wrote: >> One related topic that isn’t discussed is type errors. Many third party

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 6:36 AM, Jonathan Hull via swift-evolution > wrote: > The typed throws discussion brought me back to an old thought. > > I would really like to see a new structural type, similar to tuples, which > act as an anonymous enum. These would actually

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 18, 2017, at 6:17 AM, Thomas via swift-evolution > wrote: > > I have been writing a lot of fully async code over the recent years (in objc) > and this all seems to fit well with what we're doing and looks like it would > alleviate a lot of the pain we have

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

2017-08-18 Thread David Beck via swift-evolution
https://gist.github.com/davbeck/e3b156d89b2e9d97bb5a61c59f8a07f7 # Async Await I love this proposal so much. Much of it is exactly how I’ve thought Swift’s concurrency model should look over the last year. Making async a return attribute just like `throws` seems like the right solution to me.

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread Robert Bennett via swift-evolution
The better solution would be to allow the creation of new enums from the union of existing enums, which was proposed recently. On Aug 18, 2017, at 2:36 PM, John McCall via swift-evolution wrote: >> On Aug 18, 2017, at 6:36 AM, Jonathan Hull via swift-evolution >>

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

2017-08-18 Thread Thomas via swift-evolution
> On 18 Aug 2017, at 20:57, Chris Lattner wrote: > >> I'm a bit worried about the mention of dispatch_sync() here (although it may >> just be there to illustrate the deadlock possibility). I know the actor >> runtime implementation is not yet defined, but just wanted to

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Daniel Dunbar via swift-evolution
> On Aug 17, 2017, at 3:47 PM, Taylor Swift wrote: > > > > On Thu, Aug 17, 2017 at 3:50 PM, Daniel Dunbar > wrote: > > > On Aug 17, 2017, at 9:26 AM, Taylor Swift via swift-evolution > >

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

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 3:11 PM, Joe Groff via swift-evolution > wrote: > >> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >> wrote: >> >> I think that awaiting on the result of an actor method ends up being pretty >>

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread Adrian Zubarev via swift-evolution
Wasn’t Joe Groff and Daniel Duan proposing anonymous enum cases in some of the early draft of the ‘Normalize Enum Case Representation’ proposal? Maybe it’s time to revive that topic. Matthew Johnson has also some interesting ideas in hist gist:

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

2017-08-18 Thread Erica Sadun via swift-evolution
> On Aug 17, 2017, at 9:29 PM, Taylor Swift wrote: > On Thu, Aug 17, 2017 at 9:06 PM, Erica Sadun via swift-evolution > > wrote: > >> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu >

Re: [swift-evolution] typed throws

2017-08-18 Thread Christopher Kornher via swift-evolution
> On Aug 18, 2017, at 7:38 AM, Matthew Johnson via swift-evolution > wrote: > > I would like to reiterate the point I made in the question that spawned this > thread: there are *many* Swift libraries for writing async code of various > sorts which are *already*

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 2:19 PM, Adrian Zubarev > wrote: > > Wasn’t Joe Groff and Daniel Duan proposing anonymous enum cases in some of > the early draft of the ‘Normalize Enum Case Representation’ proposal? > > Maybe it’s time to revive that topic. > >

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

2017-08-18 Thread Thomas via swift-evolution
> On 18 Aug 2017, at 21:11, Joe Groff wrote: > > >> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution >> wrote: >> >> I think that awaiting on the result of an actor method ends up being pretty >> similar (in terms of

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

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 17, 2017, at 10:50 PM, Andre 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

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 17, 2017, at 11:33 PM, Brent Royal-Gordon > wrote: > >> On Aug 17, 2017, at 3:24 PM, Chris Lattner via swift-evolution >> wrote: >> >> Anyway, here is the document, I hope it is useful, and I’d love to hear >> comments and

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 18, 2017, at 8:13 AM, Johannes Weiß wrote: > > Hi Chris & swift-evo, > > (Given the already lengthy thread I tried to separate my points and keep them > reasonably short to allow people to skip points they don't care about. I'm > very happy to expand on the

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

2017-08-18 Thread Taylor Swift via swift-evolution
On Fri, Aug 18, 2017 at 1:23 PM, Erica Sadun wrote: > I want to avoid breaking math. > it’s not that deep,,, the `for _ in 0 ..< n` loop is exactly the same thing except more verbose. In fact, that’s how your proposed ` Array.init(count:generator:)` would be implemented.

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

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 17, 2017, at 11:53 PM, Jan Tuitman via swift-evolution > wrote: > > Hi, > > > After reading Chris Lattners proposal for async/await I wonder if the > proposal has any way to cancel outstanding tasks. > > I saw these two: > > @IBAction func

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

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 18, 2017, at 11:56 AM, David Beck wrote: > ## Conversion of imported Objective-C APIs > > One issue I see with the importer is that the conventions for callbacks > aren’t as strict as NSError ** methods were. For instance, URLSession > completion blocks include

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 12:05 PM, Joe Groff wrote: > > >> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution >> > wrote: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson >>

Re: [swift-evolution] typed throws

2017-08-18 Thread Michael Ilseman via swift-evolution
Wouldn’t switching from `async` to `async throws` be both a source and ABI break for libraries? If so, there is a library evolution argument to `async` also encompassing throws as a reasonable default. It's likely that the non-throwing-ness of many `async` operations is an artifact of the

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 4:40 AM, Gwendal Roué wrote: > Hello all, > > I'm also on the "side" of untyped errors, but I can imagine how other > developers may like a stricter error hierarchy. It surely fits some > situations. > > Enter Result and Result: > > Since

Re: [swift-evolution] typed throws

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 18, 2017, at 11:09 AM, John McCall via swift-evolution > wrote: > >> I think you're right that wrapping errors is tightly related to an effective >> use of typed errors. You can do a reasonable job without language support >> (as has been discussed on the

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

2017-08-18 Thread Joe Groff via swift-evolution
> On Aug 18, 2017, at 11:57 AM, Chris Lattner via swift-evolution > wrote: > > I think that awaiting on the result of an actor method ends up being pretty > similar (in terms of implementation and design tradeoffs) as dispatch_sync. > That said, my understanding

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

2017-08-18 Thread David Beck via swift-evolution
An argument could be made that throws should precede the function definition, but since that ship has sailed, async should probably join it at the end, since it modifies the way the function returns. In other words, async doesn't change how the method gets run, but how and when it returns. On

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 1:09 PM, John McCall wrote: > >> >> On Aug 18, 2017, at 10:19 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >> On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at

Re: [swift-evolution] pure functions

2017-08-18 Thread Chris Lattner via swift-evolution
Splitting this out from the concurrency thread: > > On Aug 18, 2017, at 6:12 AM, Matthew Johnson wrote: >> On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: >> >>> In the manifesto you talk about restrictions on passing functions across an >>>

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 18, 2017, at 12:23 PM, Thomas wrote: > > >> On 18 Aug 2017, at 20:57, Chris Lattner wrote: >> >>> I'm a bit worried about the mention of dispatch_sync() here (although it >>> may just be there to illustrate the deadlock possibility). I know

Re: [swift-evolution] pure functions

2017-08-18 Thread David Sweeris via swift-evolution
> On Aug 18, 2017, at 12:11, Chris Lattner via swift-evolution > wrote: > > Splitting this out from the concurrency thread: > >> >>> On Aug 18, 2017, at 6:12 AM, Matthew Johnson wrote: On Aug 17, 2017, at 11:53 PM, Chris Lattner

Re: [swift-evolution] pure functions

2017-08-18 Thread Andrew Trick via swift-evolution
> On Aug 18, 2017, at 2:45 PM, David Sweeris via swift-evolution > wrote: > > If we define our semantics carefully enough, could we realistically make it > so that "@pure" or "@impure" (or whatever) would simply be a note to the > compiler, letting it skip that bit

Re: [swift-evolution] typed throws

2017-08-18 Thread Xiaodi Wu via swift-evolution
Joe Groff wrote: An alternative approach that embraces the open nature of errors could be to represent domains as independent protocols, and extend the error types that are relevant to that domain to conform to the protocol. That way, you don't obscure the structure of the underlying error value

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Greg Parker via swift-evolution
> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution > wrote: > > On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift > wrote: > I don’t think the “is this library functionality or standard library >

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

2017-08-18 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

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Saagar Jha via swift-evolution
Just thought I’d link the previous thread on this topic: https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160704/023927.html . I had promised to write a proposal for it back then, but never got

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

2017-08-18 Thread Mike Sanderson via swift-evolution
I can’t speak to the more low-level implications, but to the extent this is essentially “syntactic sugar for completion handlers,” I can base my opinion on making iOS apps in different contexts for about 5 years. (Long enough to remember when Objective-C Blocks as completion handlers were the

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Xiaodi Wu via swift-evolution
On Fri, Aug 18, 2017 at 7:39 PM, Taylor Swift wrote: > > > On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu wrote: > >> On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker wrote: >> >>> >>> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via

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

2017-08-18 Thread Yuta Koshizawa via swift-evolution
Hi, I have a question about the proposed `async/await`. Are `throws async` and `await try` allowed? I think we have three options. 1. allows only `async throws`-`try await` 2. allows both `async throws`-`try await` and `throws async`-`await try` and does not distinguish them 3. allows both and

Re: [swift-evolution] pure functions

2017-08-18 Thread Chris Lattner via swift-evolution
As Andy says, the major problem is that public API (which you can't see the implementation of in general) would all need to be marked up properly. -Chris > On Aug 18, 2017, at 2:45 PM, David Sweeris wrote: > > >> On Aug 18, 2017, at 12:11, Chris Lattner via

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution > > wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall

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

2017-08-18 Thread Taylor Swift via swift-evolution
Should the immutable buffer pointer types also get deallocate()? On Fri, Aug 18, 2017 at 7:55 PM, Andrew Trick wrote: > > On Aug 15, 2017, at 9:47 PM, Taylor Swift via swift-evolution < > swift-evolution@swift.org> wrote: > > Implementation is here:

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 18, 2017, at 6:56 PM, Xiaodi Wu wrote: > > Joe Groff wrote: > > An alternative approach that embraces the open nature of errors could be to > represent domains as independent protocols, and extend the error types that > are relevant to that

Re: [swift-evolution] typed throws

2017-08-18 Thread Xiaodi Wu via swift-evolution
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 the open nature of errors could be > to represent domains

Re: [swift-evolution] typed throws

2017-08-18 Thread Xiaodi Wu via swift-evolution
On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution < swift-evolution@swift.org> wrote: > > > Sent from my iPad > > On Aug 18, 2017, at 1:27 AM, John McCall wrote: > > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution < >

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Taylor Swift via swift-evolution
On Fri, Aug 18, 2017 at 8:09 PM, Xiaodi Wu wrote: > On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker wrote: > >> >> On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> On Thu, Aug 17, 2017 at 6:46 PM, Taylor

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

2017-08-18 Thread Adam Kemp via swift-evolution
Thanks for the quick response! > On Aug 18, 2017, at 1:15 PM, Chris Lattner wrote: > > On Aug 18, 2017, at 12:34 PM, Adam Kemp > wrote: >> For instance, say you’re handling a button click, and you need to do a >> network

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread Jonathan Hull via swift-evolution
It is different though. Sure, with a little bit of sugar, it can be used to make something that looks a bit like union types, but it should avoid the complexity in the type checker which caused that to be on the rejected list. In this case 'Int | String' is just sugar for '.int(Int) |

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

2017-08-18 Thread Andre via swift-evolution
2017/08/19 3:51、Chris Lattner のメール: >> On Aug 17, 2017, at 10:50 PM, Andre wrote: >> Part 1: Async/await >> >> let dataResource = await loadWebResource("dataprofile.txt") >> >> >> Was there any thought about introducing the concept of a timeout when

Re: [swift-evolution] typed throws

2017-08-18 Thread Xiaodi Wu via swift-evolution
On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson wrote: > > On Aug 18, 2017, at 6:15 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> >> Sent from my iPad >> >>

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 6:29 PM, Xiaodi Wu wrote: > > On Fri, Aug 18, 2017 at 6:19 PM, Matthew Johnson > wrote: > >> On Aug 18, 2017, at 6:15 PM, Xiaodi Wu > > wrote:

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

2017-08-18 Thread Chris Lattner via swift-evolution
> On Aug 18, 2017, at 6:04 PM, Yuta Koshizawa wrote: > > Hi, I have a question about the proposed `async/await`. > > Are `throws async` and `await try` allowed? I think we have three options. > > 1. allows only `async throws`-`try await` > 2. allows both `async

Re: [swift-evolution] typed throws

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 17, 2017, at 11:27 PM, John McCall wrote: > Even for non-public code. The only practical merit of typed throws I have > ever seen someone demonstrate is that it would let them use contextual lookup > in a throw or catch. People always say "I'll be able to

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> 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 I have >> ever seen someone demonstrate

Re: [swift-evolution] typed throws

2017-08-18 Thread David Waite via swift-evolution
> Typed throws is something we need to settle one way or the other, and I agree > it would be nice to do that in the Swift 5 cycle. > > For the purposes of this sub-discussion, I think there are three kinds of > code to think about: > 1) large scale API like Cocoa which evolve (adding

Re: [swift-evolution] [Concurrency] choice of actor model

2017-08-18 Thread Shams Imam via swift-evolution
Do you have example communication patterns for the actor model/asynchronous messaging context? It would be interesting to see if selectors could be used to simplify programming such patterns. Regards, Shams. On Sat, Aug 19, 2017 at 10:47 AM, Jonathan Hull wrote: > The issue of

Re: [swift-evolution] typed throws

2017-08-18 Thread Mark Lilback via swift-evolution
> > 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 I have > ever seen someone demonstrate is that it would let them use contextual lookup > in a throw or catch. People

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

2017-08-18 Thread Andrew Trick via swift-evolution
> On Aug 18, 2017, at 5:36 PM, Taylor Swift wrote: > > Should the immutable buffer pointer types also get deallocate()? Both UnsafePointer and UnsafeBufferPointer should get deallocate. The Raw API already has those methods. -Andy > On Fri, Aug 18, 2017 at 7:55 PM,

Re: [swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 8:13 PM, Jonathan Hull wrote: > > It is different though. > > Sure, with a little bit of sugar, it can be used to make something that looks > a bit like union types, but it should avoid the complexity in the type > checker which caused that to be on the

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

2017-08-18 Thread Chris Lattner via swift-evolution
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 important things the community faces in

Re: [swift-evolution] [Concurrency] choice of actor model

2017-08-18 Thread Jonathan Hull via swift-evolution
The issue of a lack of ordering is one that actually comes up a lot in Swift, and we don’t have a good answer for it in general. That might be something we want to take a deeper look at in the Swift 5 timeframe (at least to talk about options). It would help more than just concurrency…

[swift-evolution] [Concurrency] choice of actor model

2017-08-18 Thread Shams Imam via swift-evolution
Disclaimer: this was work done during my graduate study. It was presented in front of an audience that included Gul Agha who appreciated the work. The Actor model is great concurrency model to build on top of thanks to its data isolation and asynchronous message processing properties. However,

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

2017-08-18 Thread Yuta Koshizawa via swift-evolution
`beginAsync(_:)` is a sort of poor man's `Future`—it guarantees that the async function will start, but throws away the return value, and *might* throw away the error unless it happens to get thrown early. Given that its ability to return information from the body is so limited, I frankly don't

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

2017-08-18 Thread Chris Lattner via swift-evolution
On Aug 18, 2017, at 2:09 PM, Adam Kemp wrote: >> On Aug 18, 2017, at 12:34 PM, Adam Kemp > > wrote: >>> For instance, say you’re handling a button click, and you need to do a >>> network request and then update the UI. In C#

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 19, 2017, at 12:25 AM, John McCall via swift-evolution > 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 >>>

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

2017-08-18 Thread Brent Royal-Gordon via swift-evolution
> 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 computation *does* >> terminate eventually. I'm not sure how to handle that, though) > >

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution > wrote: > Splitting this off into its own thread: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >> One related topic that isn’t discussed is type errors. Many third

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Xiaodi Wu via swift-evolution
On Fri, Aug 18, 2017 at 6:55 PM, Greg Parker wrote: > > On Aug 17, 2017, at 5:16 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Thu, Aug 17, 2017 at 6:46 PM, Taylor Swift > wrote: > >> I don’t think the “is this library

Re: [swift-evolution] typed throws

2017-08-18 Thread Charlie Monroe via swift-evolution
> On Aug 18, 2017, at 10:22 AM, John McCall wrote: > >> On Aug 18, 2017, at 3:28 AM, Charlie Monroe > > wrote: >>> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >>>

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

2017-08-18 Thread Brent Royal-Gordon via swift-evolution
> On Aug 17, 2017, at 11:59 PM, Félix Cloutier via swift-evolution > wrote: > > The purpose of `beginAsync` is to start an `async` function while firewalling > against the propagation of the `async` keyword to the caller. `beginAsync` > does not return a value. By

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 3:28 AM, Charlie Monroe wrote: >> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution >> wrote: >>> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >>> wrote: >>>

Re: [swift-evolution] typed throws

2017-08-18 Thread Gwendal Roué via swift-evolution
Hello all, I'm also on the "side" of untyped errors, but I can imagine how other developers may like a stricter error hierarchy. It surely fits some situations. Enter Result and Result: Since Swift "native" errors don't fit well with asynchronous APIs, various ways to encapsulate them

Re: [swift-evolution] typed throws

2017-08-18 Thread Charlie Monroe via swift-evolution
> On Aug 18, 2017, at 8:27 AM, John McCall via swift-evolution > wrote: > >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew

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

2017-08-18 Thread Félix Cloutier via swift-evolution
I'm glad to see this moving forward. I have a few questions and comments. First, I'd like it if someone could clarify for me what beginAsync and suspendAsync "actually do", and how they interact with `async` functions. I'm throwing a lot of good will at this but my brain is still fairly

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

2017-08-18 Thread Brent Royal-Gordon via swift-evolution
> On Aug 17, 2017, at 11:34 PM, Brent Royal-Gordon via swift-evolution > wrote: > > * I haven't yet read the rest of the thread—this email is already long enough. The detailed async/await proposal cleared up a few bits for me—in particular, I clearly misunderstood

Re: [swift-evolution] typed throws

2017-08-18 Thread Tino Heth via swift-evolution
> The only practical merit of typed throws I have ever seen someone demonstrate > is that it would let them use contextual lookup in a throw or catch. People > always say "I'll be able to exhaustively switch over my errors", and then I > ask them to show me where they want to do that, and

Re: [swift-evolution] typed throws

2017-08-18 Thread John McCall via swift-evolution
> On Aug 18, 2017, at 3:24 AM, Tino Heth <2...@gmx.de> wrote: > > >> The only practical merit of typed throws I have ever seen someone >> demonstrate is that it would let them use contextual lookup in a throw or >> catch. People always say "I'll be able to exhaustively switch over my >>

[swift-evolution] Fast enums (was: typed throws)

2017-08-18 Thread Jonathan Hull via swift-evolution
The typed throws discussion brought me back to an old thought. I would really like to see a new structural type, similar to tuples, which act as an anonymous enum. These would actually be a distinct type from enums (not sure what to call them), in the same way that structs and tuples are

Re: [swift-evolution] typed throws

2017-08-18 Thread Tino Heth via swift-evolution
> There's no reason we couldn't do some tooling work to expose emergent > information about what kinds of errors are thrown by the current > implementation of a function, and maybe even check that against the current > documentation. Certainly, it should be possible to document particularly >

Re: [swift-evolution] pitch: Unified libc import (again)

2017-08-18 Thread Xiaodi Wu via swift-evolution
Not “fundamentally” incompatible: var stderr = FileHandle.standardError /* Conform FileHandle to TextOutputStream */ print("foo", to: ) On Fri, Aug 18, 2017 at 01:39 Brent Royal-Gordon wrote: > On Aug 17, 2017, at 8:20 PM, Xiaodi Wu via swift-evolution < >

Re: [swift-evolution] typed throws

2017-08-18 Thread Johannes Weiß via swift-evolution
Hi John, tl;dr I think throws should be optionally typed. Ie. `func someSyscall(...) throws(POSIXError) -> Int` should be just as legal as `func doSomeFancyCocoaOperation() throws -> Void`. > [...] >> Here is where I think things stand on it: >> - There is consensus that untyped throws is the

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
Sent from my iPad On Aug 18, 2017, at 1:27 AM, John McCall wrote: >> On Aug 18, 2017, at 12:58 AM, Chris Lattner via swift-evolution >> wrote: >> Splitting this off into its own thread: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson

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

2017-08-18 Thread Michel Fortin via swift-evolution
Great writeup. Here's a few comments about the manifesto, actors and value semantics specifically. # About actors and data isolation Can I call global functions like sin(x) in an actor? Surely you need to be able to do that. But how can the compiler know which functions are safe to use and

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

2017-08-18 Thread Matthew Johnson via swift-evolution
> On Aug 18, 2017, at 9:19 AM, Michel Fortin via swift-evolution > wrote: > > Great writeup. Here's a few comments about the manifesto, actors and value > semantics specifically. > > > # About actors and data isolation > > Can I call global functions like sin(x)

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

2017-08-18 Thread Elviro Rocca via swift-evolution
I'm also available to help on the topic of pure functions, if you need any :) Elviro > I suggested a little while ago on this list some principles based on this > that would allow for the compiler to enforce value semantics with a `pure` > attribute and I'm currently working on a draft

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

2017-08-18 Thread Elviro Rocca via swift-evolution
Thanks a lot for this piece: it was a great read, that could serve as primer to most discussions about async programming in general, also thanks to the various links and references. Here's my thoughts: - You might have been too soft on the callback-based syntax of many Cocoa APIs: those are

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

2017-08-18 Thread Thomas via swift-evolution
I have been writing a lot of fully async code over the recent years (in objc) and this all seems to fit well with what we're doing and looks like it would alleviate a lot of the pain we have writing asyc code. # Extending the model through await I'm a bit worried about the mention of

Re: [swift-evolution] typed throws

2017-08-18 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 17, 2017, at 11:58 PM, Chris Lattner wrote: > > Splitting this off into its own thread: Thanks. I considered starting a thread but decided to ask about it first in case it was considered out of scope for Swift 5. > >> On Aug 17, 2017, at

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

2017-08-18 Thread Alejandro Martinez via swift-evolution
This has been a long awaited topic so I'm really excited to see the conversation start! After reading the manifesto and the proposal there is one thing that keeps wondering in my head, and is making async implicitly throwing. It the common case it makes sense, but there is a part of the proposal

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

2017-08-18 Thread Matthew Johnson via swift-evolution
Sent from my iPad > On Aug 17, 2017, at 11:53 PM, Chris Lattner wrote: > >> On Aug 17, 2017, at 7:39 PM, Matthew Johnson wrote: >> This is fantastic! Thanks for taking the time to write down your thoughts. >> It’s exciting to get a glimpse at

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

2017-08-18 Thread Johannes Weiß via swift-evolution
Hi Chris & swift-evo, (Given the already lengthy thread I tried to separate my points and keep them reasonably short to allow people to skip points they don't care about. I'm very happy to expand on the points.) Thanks very much for writing up your thoughts/proposal, I've been waiting to see

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

2017-08-18 Thread Thomas via swift-evolution
The compiler could rewrite this: print(await dataModel.getNumberOfEntries()) actor func getNumberOfEntries() -> Int { return theList.count } as this: dataModel.getNumberOfEntries(_internalQueue) { count in print(count) } actor func getNumberOfEntries(queue: DispatchQueue, handler: Int