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

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 imperat

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

> 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 how closely coupled `await` w

Re: [swift-evolution] typed throws

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

Re: [swift-evolution] typed throws

> 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 Johnson wrote: >>> One related topic that isn’t discu

Re: [swift-evolution] typed throws

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

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

> 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 the time `beginAsync` returns

Re: [swift-evolution] typed throws

> 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: >>> Splitting this off into its own thread: >>> On Aug 17, 2017, at 7:39 PM, Matth

Re: [swift-evolution] typed throws

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

Re: [swift-evolution] typed throws

> 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 >>> mailto:swift-evolution@swift.org>> wrote: On Aug 18, 2017, at 12:58 AM, Chri

Re: [swift-evolution] typed throws

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

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

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 diffe

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

Not “fundamentally” incompatible: var stderr = FileHandle.standardError /* Conform FileHandle to TextOutputStream */ print("foo", to: &stderr) 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 < > swift-evolution@swift.org> wro

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

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 the (possible) road ahead. > > Happy to. > >>

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

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 dispatch_s

[swift-evolution] Wouldn't publishing directives (for strong type-aliases) make implicitly-synthesized conformance obsolete? (was: [Accepted] SE-0185 - Synthesizing Equatable and Hashable conformance)

> On Aug 17, 2017, at 1:04 PM, Chris Lattner via swift-evolution > wrote: > >> On Aug 17, 2017, at 5:00 AM, Haravikk via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On 17 Aug 2017, at 11:42, Robert Bennett >> > wrote: >>> >>> Chris mention

Re: [swift-evolution] typed throws

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 7:39 PM, Matthew Johnso

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

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

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

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 th

Re: [swift-evolution] typed throws

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 r

Re: [swift-evolution] typed throws

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 wrote: >>> One related topic that isn’t discussed is

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

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 wh

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

> 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) in an actor? Surely you need

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

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 propos

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

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 t

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

> From: Jan Tuitman via swift-evolution > To: swift-evolution@swift.org > Date: 08/18/2017 02:54 AM > Subject: [swift-evolution] [Concurrency] async/await + actors: cancellation > Sent by: swift-evolution-boun...@swift.org > > Hi, > > > After reading Chris Lattners proposal for async/await I wond

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

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

Re: [swift-evolution] typed throws

> 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 throw errors that require allo

Re: [swift-evolution] typed throws

> 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 >> libraries use a Result type with typed errors. M

Re: [swift-evolution] typed throws

> On Aug 18, 2017, at 12:05 PM, Joe Groff wrote: > > >> On Aug 17, 2017, at 9:58 PM, Chris Lattner via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> On Aug 17, 2017, at 7:39 PM, Matthew Johnson >> > wrote: >>> One related topic that isn’t d

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

> 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 > mailto:swift-evolution@swift.org>> wrote: > >> On Aug 17, 2017, at 6:56 PM, Xiaodi Wu > > wrote: >> >> On Thu, Aug 17, 2017 at 7:51 PM, Erica Sadu

Re: [swift-evolution] typed throws

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 initia

Re: [swift-evolution] typed throws

> 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* using typed errors via `Result

Re: [swift-evolution] typed throws

> 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: >>> Splitting this off into its own thread: >>> On Aug 17, 2017, at 7

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

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. But I don’t see anyone s

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

> 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 > > mailto:swift-evolution@swift.org>> wrote: > > > > I know this has come

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

> 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 be a distinct type from enu

Re: [swift-evolution] typed throws

> 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 Swift "native" errors don't fit

Re: [swift-evolution] typed throws

> 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 list in the past). On the

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

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 parameter? > Then, if used

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

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

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

> 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 writing asyc code. Great,

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

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 be needed, but I wouldn't conside

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

> 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 buttonDidClick(sender:AnyObject) { > //

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

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 >> wrote: >> The typed throws d

Re: [swift-evolution] typed throws

> 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 12:58 AM, Chris Lattner via swift-evolution wrote: Sp

Re: [swift-evolution] pure functions

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 >>> actor message. You didn’t discuss pure function

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

> 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 is that thread explosion in G

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

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

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

> 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 need to be > able to do th

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

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: https://gist.github.com/anandabits/5b7f8e3836387e8

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

> 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 >> similar (in terms of implementation and design tradeoffs)

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

> 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 mention that >> dispat

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

> 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. > > Matthew Johnson has also some interesti

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

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 out

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

> 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 suggestions for improvement: >> https://gist.github.com/lat

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

> 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 implementation and design tradeoffs) as dispatch_sync. >>

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

> 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, actors and value >> semantics specifically. >> >> >> # Abo

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

> 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 result of an actor method ends up being pretty >>> similar (in terms o

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

> 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 points.) > > Thanks very

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

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 response, data and error,

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

> 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 the actor >>> runtime implementation is n

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

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 HandleButtonClick(object sender

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

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 request and then update the UI. In C# (using

Re: [swift-evolution] pure functions

> 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 wrote: In the manifesto you talk about restric

Re: [swift-evolution] pure functions

> 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 of analysis for the functio

Re: [swift-evolution] pure functions

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 swift-evolution >> wrote: >> >>

Re: [swift-evolution] typed throws

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 < > swift-evolution@swift.org> wrote: > >> Split

Re: [swift-evolution] typed throws

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

Re: [swift-evolution] typed throws

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 >> >> On Aug 18, 2017, at 1:27 AM, John McCall wrote

Re: [swift-evolution] typed throws

> 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: >> >> On Fri, Aug 18, 2017 at 09:20 Matthew Johnson via swift-evoluti

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

> 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 > functionality” argument is worth having, but if stdout and std

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 > wrote: > I’ve revised

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

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 ar

Re: [swift-evolution] typed throws

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 w

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

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 functionality or standard library >> functio

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

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) | .string(

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

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 great

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

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: https://github.com/apple/swift/pull/11464 > >

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

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 Swift >> wrote: >> >>> I don’t think th

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

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 swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> On Thu, Aug

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

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 di

Re: [swift-evolution] typed throws

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 domain to conform to th

Re: [swift-evolution] typed throws

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 as independent protocols, and extend the erro

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

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 >> awaiting? >> >> Something like an

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

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# (using Xamarin.iOS as an >>> example) you m

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

> 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 throws`-`try await` and `throws

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

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 the short term, so y

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

> 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, Andrew Trick

Re: [swift-evolution] typed throws

> > 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 always say "I'll be able to e

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

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

Re: [swift-evolution] typed throws

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 exhaustively switch > over my

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

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

Re: [swift-evolution] typed throws

> 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 is that it would let them use contextual >> l

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

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

Re: [swift-evolution] typed throws

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

Re: [swift-evolution] typed throws

> 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 >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> Even for non

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

> 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 rejected list. In

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

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 a lack of orderin

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

> 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) > > Yeah, I think that acto