Re: [swift-evolution] await keyword "scope"

> On Sep 18, 2017, at 9:47 AM, Adam Kemp wrote: > >> Would it be possible to actually fix this? That is, make the code covered by >> the `await` evaluate synchronous subexpressions first, such that the code >> sample above is equivalent to this? >> >> @IBAction func buttonDidClick(sender:

[swift-evolution] Standard ReactiveSteam definitions for Swift

In Java 9 they have added standard definitions for Reactive Streams, the `Flow` class, so that third party libraries, like Akka, can interoperate. Note they haven't added an implementation of Reactive Streams, just the type definitions. A starting point for adding similar to Swift could be: http

Re: [swift-evolution] [Concurrency] Theoretical question about actors vs async

Thanks, i guess i didn't realize that async/await was in fact conceptually decoupled from the underlying task scheduling and execution mechanism, and that the gist really was in the state machine creation ( reading a bit more about c# implementation helped me understand it as well). My question

Re: [swift-evolution] Enums and Source Compatibility

Sent from my iPad > On Sep 17, 2017, at 5:02 PM, Jonathan Hull wrote: > > >> On Sep 17, 2017, at 7:55 AM, Matthew Johnson wrote: >> >> >> >> Sent from my iPad >> >>> On Sep 17, 2017, at 3:37 AM, Jonathan Hull via swift-evolution >>> wrote: >>> >>> I run into use cases like this all th

Re: [swift-evolution] Enums and Source Compatibility

> On 18 Sep 2017, at 19:20, Jordan Rose wrote: > > That's pretty much the same as this proposal except you don't have the new > keyword. I'm not sure why that really makes a difference, since they're > obviously paired, and it would limit existing libraries from declaring > exhaustive enums u

Re: [swift-evolution] Enums and Source Compatibility

“… what you're describing isn't really an enum" I’ve gotten this explanation before in reference to errors. I am confused as to what constitutes an enum and what doesn’t. -Kenny > On Sep 18, 2017, at 10:31 AM, Jordan Rose wrote: > > As mentioned, the right way to do this is with a struct: >

Re: [swift-evolution] Enums and Source Compatibility

Ah, I get it now. Even if the switch knows what to do with the unknown value, the rest of your code would have to know what to do with it, and that is unlikely. -Kenny > On Sep 18, 2017, at 10:23 AM, Jordan Rose wrote: > > > >> On Sep 16, 2017, at 15:35, Kenny Leung via swift-evolution >>

Re: [swift-evolution] Enums and Source Compatibility

I don't think unit tests help much here. In the case where an 'exhaustive' enum ought to be 'nonexhaustive', unit tests wouldn't help you catch the issue until you tried adding a new case. And in both cases, a unit test would only help if you tried to switch exhaustively over the enum, something

Re: [swift-evolution] Enums and Source Compatibility

Since I was just looking at the Default section, it wasn’t clear that the default was just for the external case. But mostly I just wasn’t paying close attention. Also, it’s not entirely clear whether nonexhaustive enums can be used within the same module, but again, I may just be missin

Re: [swift-evolution] Enums and Source Compatibility

As mentioned, the right way to do this is with a struct: public struct ConnectionDictionaryKey: RawRepresentable, Hashable { public var rawValue: String public init(rawValue: String) { … } public init(_ rawValue: String) { … } } extension ConnectionDictionaryKey { static let hostName = Con

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 15:35, Kenny Leung via swift-evolution > wrote: > > In general, I agree with everything in the proposal. > > I’d like to propose these alternative extensions for clients: > > 1) As a client of an enum, I’d like to know in the future when a new value > has been added to

Re: [swift-evolution] Enums and Source Compatibility

That's pretty much the same as this proposal except you don't have the new keyword. I'm not sure why that really makes a difference, since they're obviously paired, and it would limit existing libraries from declaring exhaustive enums until they've moved entirely to Swift 5 mode. I think the cu

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 16, 2017, at 11:35, Christopher Kornher via swift-evolution > wrote: > > > > > >> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >>> >>> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution >>> mailto

Re: [swift-evolution] Enums and Source Compatibility

That is in fact what the proposal states: > Currently, adding a new case to an enum is a source-breaking change, which is > very inconvenient for library authors. This proposal aims to distinguish > between enums that are exhaustive (meaning they will never get any new cases) > and those that a

Re: [swift-evolution] await keyword "scope"

> On Sep 15, 2017, at 4:50 AM, Brent Royal-Gordon > wrote: > >> On Sep 12, 2017, at 12:48 PM, Adam Kemp via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> @IBAction func buttonDidClick(sender:AnyObject) { >> beginAsync { >> let image = await processImage(downlo

Re: [swift-evolution] [Concurrency] Theoretical question about actors vs async

> On Sep 18, 2017, at 2:32 AM, Benjamin Garrigues via swift-evolution > wrote: > > > > Le 18 sept. 2017 à 07:59, Pierre Habouzit > a écrit : > >>> On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> I

Re: [swift-evolution] Question about async await

-Pierre > On Sep 18, 2017, at 2:04 AM, Trevör Anne Denise > wrote: > >> >> Le 18 sept. 2017 à 07:57, Pierre Habouzit > > a écrit : >> >>> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution >>> mailto:swift-evolution@swift.org>> wrote: >>> >>> He

Re: [swift-evolution] Figuring out what you get for free

To be clear, I find the stdlib already fairly well-documented. I think that the problem is more important for types from projects that are unlikely to get good documentation. > Le 17 sept. 2017 à 23:43, Dimitri Racordon via swift-evolution > a écrit : > >> - In step 2, the compiler could prop

Re: [swift-evolution] [Concurrency] Theoretical question about actors vs async

> Le 18 sept. 2017 à 07:59, Pierre Habouzit a écrit : > >> On Sep 17, 2017, at 5:00 AM, Benjamin G via swift-evolution >> wrote: >> >> I've read Chris Lattner proposal on concurrency, and if i'm correct, the >> proposal is to start implementing async / await mechanism first, then other >>

Re: [swift-evolution] Question about async await

> Le 18 sept. 2017 à 07:57, Pierre Habouzit a écrit : > >> On Sep 17, 2017, at 3:52 AM, Trevör ANNE DENISE via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hello everyone, >> >> I have a few questions about async await in Swift. >> >> Say that you have : >> >> func foo

Re: [swift-evolution] Documentation and comments

It's not clear what you are proposing or how it would be achieved. If you would like to spend some time looking into this in more detail, please feel free and post back here with the results of your investigations. Alex > On 17 Sep 2017, at 00:12, Omar Charif via swift-evolution > wrote: > >