[swift-evolution] Standard ReactiveSteam definitions for Swift

[Howard Lovatt via swift-evolution]

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:


https://github.com/hlovatt/Concurrency-Utilities/blob/master/Concurrency%20Utilities/ReactiveStream.swift

This would be the Swift equivalent of the Java Flow class in that it
provides definitions but not implementations, which will enable third party
libraries and eventually whatever goes into Swift at language and library
levels to interoperate.

Whereas adding concurrency in general will be a long process, these
definitions could be added now.

Thoughts?

  -- Howard.

PS You can find out about Reactive Steams and the standardization of them
at http://www.reactive-streams.org/
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin Garrigues via swift-evolution]

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 regarding async / await semantic on top of actors was also answered 
by the elixir Task api, which provides those functions as well, by spawning 
special child actors.
Which makes me think that maybe this api could be used as an inspiration for 
swift, so i'll just put the link here https://hexdocs.pm/elixir/Task.html just 
in case.


> Le 18 sept. 2017 à 18:15, Pierre Habouzit  a écrit :
> 
>> 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 
  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 more evolved mechanisms (such as actors) on top later.
 
 My question after reading the many conversations (and confusion) around 
 the execution order of async / await on the mailing list is this : 
 Isn't the actor model a more "elementary" concurrency model than async / 
 await, and so, from a theoretical point of view, wouldn't it make more 
 sense to implement it first as a layer to build future other concurrency 
 mechanisms on top ?
 
 I'm putting emphasis on the "theoretical" aspect of my question, because 
 i'm 100% certain that if Mr Lattner decided to go this path, it's because 
 it makes more sense from an implementation point of view. 
>>> 
>>> Actors is a way higher level construct than async/await.
>>> 
>>> async/await is IMO an interesting low level construct that explains to the 
>>> language where your execution flow requires to be broken in two (what is 
>>> syntactically before and after the "await") to wait for some event before 
>>> the second half can be done.
>>> 
>>> Unlike Actors, it doesn't try to explain what/how/... this is done, which 
>>> makes it lower level.
>> 
>> That's also how i first thought about it, but the more i digg the subject ( 
>> especially after viewing https://youtu.be/7erJ1DV_Tlo), the more i 
>> understand actors as a fundamental unit of computation (addressable, with a 
>> state), and not a whole framework.
>> 
>> all the questions i see raised with async/await ( queue hoping, timeouts, 
>> error handling, ressource allocation, etc) simply aren't there with actors, 
>> because imho, the model is conceptually simpler ( and thus a saner basis for 
>> building concurrency).
>> 
>> I started thinking about what, in the "everything's an actor" model, 
>> async/await would mean if called from within an actor and it seems like it 
>> would mean that once the await call is made, all the messages sent to that 
>> actor are blocked until the response from that call is received ( which is 
>> dangerous if the message comes from the network, but not that much when 
>> running in the same computer). That seemed interesting but i stopped there 
>> because i wanted to have the opinion of more qualified people first.
> 
> All of this is orthogonal. async/await, is about explaining to the compiler 
> how to split sequential synchronous looking code into an asynchronous state 
> machine.
> 
> Unlike actors that attach rules and semantics to this, async/await is really 
> just about the compiler transform (which is *not* that easy, especially when 
> C stacks happen in the mix).
> 
> -Pierre
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Matthew Johnson via swift-evolution]

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 the time…
>>> 
>>> I think I would prefer to see those concrete cases in a subtype though:
>>> 
>>> enum DrinkSize {
>>> case small
>>> case medium
>>> case large
>>> }
>>> 
>>> enum SummerDrinkSize : DrinkSize {
>>> //Inherits DrinkSize’s cases
>>> case extraLarge
>>> }
>>> 
>>> Because it is a subtype, you could place a SummerDrinkSize anywhere you can 
>>> put a DrinkSize.  As a result, all switches on it would need a default case 
>>> to handle cases they hadn’t planned for. If you mark an enum with “final” 
>>> then it can’t be extended and switches can be exhaustive.
>> 
>> You have the subtype relationship backwards here.  DrinkSize is a subtype of 
>> SummerDrinkSize.  All values of DrinkSize are also valid values of 
>> SummerDrinkSize but not vice versa.  For this reason, inheritance syntax 
>> doesn't make sense.  The syntax that makes more sense is some kind of case 
>> embedding syntax:
>> 
>> enum SummerDrinkSize {
>>  cases DrinkSize
>>  case extraLarge
>> }
> 
> I disagree.  I get that the shape of a DrinkSize would always fit in a 
> SummerDrinkSize hole (ignoring the overriding/extension of methods), but the 
> fact that we are requiring ‘default’ in switches changes the calculus.  
> Basically, it changed when we decided to change whether exhaustive was the 
> default.  The point is to make people consider that they may have cases which 
> they may not expect.  That is much easier with a concrete idea of subtype, 
> which people are already used to.

Requiring developers to consider cases that may be added to an enum in the 
future is orthogonal to any potential subtype relationship between two value 
types.

> 
> 
>>> 
>>> In addition to inheriting the cases, a subtype would also inherit, and be 
>>> able to override, methods defined on the super-type.  You could use super 
>>> to call the super-type’s implementation. 
>> 
>> I think implementation sharing is a bad idea for value types.  Value 
>> subtyping should be conceptualized as a restricted mechanism for 
>> value-preserving implicit conversion.
> 
> Why?

First, this is how value subtyping already works in the case of Optional where 
`T` is a subtype of `T?`.

More generally, this approach is roughly analogous to implicit promotion in 
C-family languages.  We want `Int8` to be a subtype of `Int16`, `Int32`, `Int`, 
etc.

This approach allows a value type to have multiple value-preserving supertypes 
without the performance impact of dynamic dispatch or the complexity of 
multiple inheritance.

> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[David Hart via swift-evolution]

> 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 until they've moved entirely to Swift 5 mode. I think the 
> current proposal makes sense as is.

The difference is that it reduces the keyword soup and removes a keyword that 
will be the default behavior enums have in Swift 5. If we follow the same 
reasoning, why don’t we have nonfinal, @nonescaping, @nonDiscardableResult? Is 
it really worth adding a keyword only to support libraries while they 
transition to Swift 5?

> Jordan
> 
> 
>> On Sep 16, 2017, at 01:55, David Hart  wrote:
>> 
>> I’m still very much bothered by having 2 new keywords. I would really prefer 
>> the following plan:
>> 
>> Exhaustive by default in Swift 4
>> No new keyword in Swift 4 to change that behaviour
>> Non-exhaustive by default outside the module in Swift 5
>> exhaustive keyword to change the default behaviour
>> 
>> Like that, we don’t need nonexhaustive.
>> 
>> Thoughts?
>> David.
>> 
>>> On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution 
>>>  wrote:
>>> 
>>> Proposal updated, same URL: 
>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md.
>>> 
>>> Thanks again for all the feedback so far, everyone!
>>> Jordan
>>> 
>>> 
 On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
  wrote:
 
 Sorry, I got distracted by other tasks! Both the discussion here and 
 within Apple has moved towards making "non-exhaustive" the default, which, 
 to be honest, I too think is the best design. I'll update the proposal 
 today to reflect that, though I still want to keep both the 
 "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for 
 now (or whatever we end up naming them). The compatibility design is a 
 little less ambitious than Brent's; as currently proposed, Swift 4 mode 
 continues to default to 'exhaustive' all the time, even in the actual 
 Swift 5 release.
 
 I still want to respond to Brent's points directly, but I think you and 
 Vladimir have done a good job discussing them already. I'll send out the 
 updated proposal tomorrow, after I have a little more time to think about 
 #invalid.
 
 Thanks for putting time into this!
 Jordan
 
 
> On Sep 9, 2017, at 17:34, Rod Brown  wrote:
> 
> Jordan,
> 
> Do you have any other thoughts about the ongoing discussion here, 
> especially regarding Chris’ comments? As you’re the one pushing this 
> forward, I’d really like to know what your thoughts are regarding this?
> 
> - Rod
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org
 https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Kenny Leung via swift-evolution]

“… 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:
> 
> public struct ConnectionDictionaryKey: RawRepresentable, Hashable {
>   public var rawValue: String
>   public init(rawValue: String) { … }
>   public init(_ rawValue: String) { … }
> }
> extension ConnectionDictionaryKey {
>   static let hostName = ConnectionDictionaryKey("hostname")
>   static let databaseName = ConnectionDictionaryKey("database")
>   // …
> }
> 
> It is definitely more verbose than an enum, and it may be worth a separate 
> proposal to deal with that! But it is not part of this proposal, and what 
> you're describing isn't really an enum.
> 
> Jordan
> 
> 
>> On Sep 16, 2017, at 15:51, Kenny Leung via swift-evolution 
>> > wrote:
>> 
>> Oops, forgot something:
>> 
>> "Can there be a kind of open enum where you can add new cases in extensions?”
>> 
>> I have a use case for this. I’m trying to write a database ORM with abstract 
>> API and concrete instances for different database. So I have defined:
>> 
>> open class Database {
>>init(connectionDictionary: [ConnectionDictionaryKey:String]) {
>> self.connectionDictionary = connectionDictionary;
>> }
>> }
>> 
>> Where I have ConnectionDictionaryKey defined as an enum, with values like 
>> .hostName, .databaseName, .userName, .password, .databaseName, etc…
>> 
>> But concrete databases may have other options that need to be added to the 
>> connection dictionary. It would be nice if they could just extend 
>> ConnectionDictionaryKey with new cases.
>> 
>> -Kenny
>> 
>> 
>>> On Sep 16, 2017, at 3:35 PM, 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 an enum, since I may have to do something about it. How 
>>> about adding the “exhaustive” keyword to be used in the switch statement? 
>>> Like
>>> 
>>> exhaustive switch excuse {
>>> case eatenByPet:
>>> // …
>>> case thoughtItWasDueNextWeek:
>>> // …
>>> default:
>>> // …
>>> }
>>> 
>>> If exhaustive is used, there would be a warning if all cases aren’t covered 
>>> *even though default exists*. This means that I as the client thought I had 
>>> everything covered when I wrote this code.
>>> 
>>> As already mentioned, this makes the default case un-testable, which brings 
>>> me to
>>> 
>>> 2) All non-exhaustive enums should have the pseudo value “default” that can 
>>> be used just like a regular value. This would allow you to write code like:
>>> 
>>> teacher.failedToHandInHomework(excuse: .default)
>>> 
>>> which would allow you to trip the default case in any code you may write.
>>> 
>>> -Kenny
>>> 
>>> 
 On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution 
 > wrote:
 
 Proposal updated, same URL: 
 https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
  
 .
 
 Thanks again for all the feedback so far, everyone!
 Jordan
 
 
> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
> > wrote:
> 
> Sorry, I got distracted by other tasks! Both the discussion here and 
> within Apple has moved towards making "non-exhaustive" the default, 
> which, to be honest, I too think is the best design. I'll update the 
> proposal today to reflect that, though I still want to keep both the 
> "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for 
> now (or whatever we end up naming them). The compatibility design is a 
> little less ambitious than Brent's; as currently proposed, Swift 4 mode 
> continues to default to 'exhaustive' all the time, even in the actual 
> Swift 5 release.
> 
> I still want to respond to Brent's points directly, but I think you and 
> Vladimir have done a good job discussing them already. I'll send out the 
> updated proposal tomorrow, after I have a little more time to think about 
> #invalid.
> 
> Thanks for putting time into this!
> Jordan
> 
> 
>> On Sep 9, 2017, at 17:34, Rod Brown > > wrote:
>> 
>> Jordan,
>> 

Re: [swift-evolution] Enums and Source Compatibility

[Kenny Leung via swift-evolution]

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 
>> > 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 an enum, since I may have to do something about it. How 
>> about adding the “exhaustive” keyword to be used in the switch statement? 
>> Like
>> 
>> exhaustive switch excuse {
>> case eatenByPet:
>> // …
>> case thoughtItWasDueNextWeek:
>> // …
>> default:
>> // …
>> }
>> 
>> If exhaustive is used, there would be a warning if all cases aren’t covered 
>> *even though default exists*. This means that I as the client thought I had 
>> everything covered when I wrote this code.
>> 
>> As already mentioned, this makes the default case un-testable, which brings 
>> me to
>> 
>> 2) All non-exhaustive enums should have the pseudo value “default” that can 
>> be used just like a regular value. This would allow you to write code like:
>> 
>> teacher.failedToHandInHomework(excuse: .default)
>> 
>> which would allow you to trip the default case in any code you may write.
> 
> Brent came up with this idea as well, but after thinking it through Joe Groff 
> and I found that it doesn't really work in practice:
> 
>> It’s going to be very common to have a future value and hand it right back 
>> to the framework without looking at it, for example:
>> 
>> override func process(_ transaction: @testable Transaction) {
>>   switch transaction {
>>   case .deposit(let amount):
>> // …
>>   case .withdrawal(let amount):
>> // …
>>   default:
>> super.process(transaction) // hmm…
>>   }
>> }
>> 
>> So just making it to the ‘default’ case doesn’t guarantee that it’s testable 
>> in practice.
> 
> I'll add the actual code here to the "Testing invalid cases" section under 
> "Alternatives considered", since that's a clearer example than the paragraph 
> I wrote. (Oh, and the "exhaustive switch" is equivalent to the section on 
> "'future' cases".)
> 
> Thanks for the feedback!
> Jordan

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

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 you may not think to 
write (depending on what the enum is, of course).

In either direction, there's a potential error of omission, and if you've 
"omitted" the annotation from your library code I wouldn't assume you'd 
remember to check that specific thing in a unit test.

Jordan


> On Sep 16, 2017, at 00:44, Goffredo Marocchi  wrote:
> 
> Sorry for being naive, but aside from open (and the decision not to make it 
> the default which again hurts the users of the library),  wouldn’t the 
> playground library example be ok if the framework author had validated it 
> with unit tests?
> 
> Sent from my iPhone
> 
> On 16 Sep 2017, at 01:07, Jordan Rose via swift-evolution 
> > wrote:
> 
>> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a 
>> multi-module app; indeed, there's no real reason for a single project to do 
>> anything else. However, it is not always the right behavior for libraries 
>> that actually get distributed, whether as source or as binary. In this case 
>> we want to minimize the error of omission: in the app case, forgetting 
>> "exhaustive" is an annoyance that you notice and fix once across your code 
>> base, but in the library case forgetting the "default case" means putting 
>> out a source-breaking release, and for libraries that have binary 
>> compatibility constraints there's no recourse at all.
>> 
>> While most of the proposal deals with the experience we've had with the 
>> Apple SDKs (as written in Objective-C), we actually have run into this case 
>> in Swift already. The Swift Playgrounds app comes with a framework, 
>> PlaygroundSupport, that can be used from within a playground. It's important 
>> that when they upgrade the app, existing playgrounds don't break, since the 
>> end user may not have access to the entire code of the playground. (Remember 
>> that playgrounds are often authored by one developer or group, but then run 
>> and modified by someone else with a much lower skill level!) That means that 
>> PlaygroundSupport can't currently vend any enums that they expect playground 
>> authors to exhaustively switch over.
>> 
>> (And to make it even more specific—and appealing—one of the enums they were 
>> considering would be a representation of the Swift AST. This can obviously 
>> change from release to release, but previous switch statements should stay 
>> valid.)
>> 
>> Now, this is an example we know about, so we could certainly make it 
>> explicitly non-exhaustive. But in general we're in the same situation as 
>> 'open': if we want to be friendly to library authors, we need to make the 
>> default thing be the one that promises less, even if it means a bit of extra 
>> work in the "I-actually-own-everything" case.
>> 
>> Best,
>> Jordan
>> 
>> 
>>> On Sep 15, 2017, at 15:47, Rex Fenley >> > wrote:
>>> 
>>> Hey Jordan,
>>> 
>>> Thank you for the time writing this up. I've been following along to the 
>>> discussion somewhat closely and have kept silent because `exhaustive` was 
>>> originally set to be the default for enums. However, that changed and so 
>>> I'd like to voice my opinion, I frankly don't like this idea.
>>> 
>>> At remind we use algebraic data types religiously for managing state and 
>>> data and rely on exhaustive pattern matching to guarantee we're handling 
>>> all states in our code. We're splitting out our code across modules and 
>>> having this guarantee has been a joy to work with.
>>> 
>>> The benefit of making nonexhaustive the default for Swift 5 across all 
>>> multi-module code (besides C code) seems minimal to me. If a developer 
>>> feels like they're unnecessarily managing enum cases, they can simply add a 
>>> `default` case whenever they please. This is already the case and I'm 
>>> curious if there's every been any complaints about this and what they would 
>>> be. I'd prefer to be cautious and force exhaustive pattern matching in all 
>>> possible cases and leave it up to the developer to choose not to.
>>> 
>>> Ideally in my mind, these keywords won't be necessary. All Swift enums will 
>>> remain as they are, exhaustively pattern matched by default. Enums from C 
>>> code will be explicitly nonexhaustive in all cases.
>>> 
>>> -- 
>>> Rex Fenley  |  IOS DEVELOPER
>>> 
>>> 
>>> Remind.com  |  BLOG   |  
>>> FOLLOW US   |  LIKE US 
>>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 

Re: [swift-evolution] Enums and Source Compatibility

[Jon Shier via swift-evolution]

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 missing something.



Jon

> On Sep 18, 2017, at 1:09 PM, Jordan Rose  wrote:
> 
> 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 are non-exhaustive, and to ensure that clients handle 
>> any future cases when dealing with the latter. This change only affects 
>> clients from outside the original module.
> 
>> When a client tries to switch over a nonexhaustive enum, they must include a 
>> default case unless the enum is declared in the same module as the switch.
> 
> Do you have any suggestions on how to make this clearer in the proposal?
> 
> Jordan
> 
> 
>> On Sep 15, 2017, at 21:40, Jon Shier > > wrote:
>> 
>>  In that case Jordan, can Swift not treat it like open? i.e. Internally 
>> to a module, unmarked enums are still exhaustive by default, but when made 
>> public and used beyond the module, it becomes non-exhaustive? I think this 
>> has been discussed before and perhaps discarded as confusing, but it doesn’t 
>> seem to be any more confusing than open being the default internally and 
>> closed the default publicly. Otherwise you’re essentially forcing what is 
>> likely the vast majority of enum usage to adopt a bit of boilerplate that 
>> will only be used by the vast minority of libraries (almost entirely 
>> libraries shipped by Apple). 
>> 
>> 
>> Jon
>> 
>>> On Sep 15, 2017, at 8:07 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a 
>>> multi-module app; indeed, there's no real reason for a single project to do 
>>> anything else. However, it is not always the right behavior for libraries 
>>> that actually get distributed, whether as source or as binary. In this case 
>>> we want to minimize the error of omission: in the app case, forgetting 
>>> "exhaustive" is an annoyance that you notice and fix once across your code 
>>> base, but in the library case forgetting the "default case" means putting 
>>> out a source-breaking release, and for libraries that have binary 
>>> compatibility constraints there's no recourse at all.
>>> 
>>> While most of the proposal deals with the experience we've had with the 
>>> Apple SDKs (as written in Objective-C), we actually have run into this case 
>>> in Swift already. The Swift Playgrounds app comes with a framework, 
>>> PlaygroundSupport, that can be used from within a playground. It's 
>>> important that when they upgrade the app, existing playgrounds don't break, 
>>> since the end user may not have access to the entire code of the 
>>> playground. (Remember that playgrounds are often authored by one developer 
>>> or group, but then run and modified by someone else with a much lower skill 
>>> level!) That means that PlaygroundSupport can't currently vend any enums 
>>> that they expect playground authors to exhaustively switch over.
>>> 
>>> (And to make it even more specific—and appealing—one of the enums they were 
>>> considering would be a representation of the Swift AST. This can obviously 
>>> change from release to release, but previous switch statements should stay 
>>> valid.)
>>> 
>>> Now, this is an example we know about, so we could certainly make it 
>>> explicitly non-exhaustive. But in general we're in the same situation as 
>>> 'open': if we want to be friendly to library authors, we need to make the 
>>> default thing be the one that promises less, even if it means a bit of 
>>> extra work in the "I-actually-own-everything" case.
>>> 
>>> Best,
>>> Jordan
>>> 
>>> 
 On Sep 15, 2017, at 15:47, Rex Fenley > wrote:
 
 Hey Jordan,
 
 Thank you for the time writing this up. I've been following along to the 
 discussion somewhat closely and have kept silent because `exhaustive` was 
 originally set to be the default for enums. However, that changed and so 
 I'd like to voice my opinion, I frankly don't like this idea.
 
 At remind we use algebraic data types religiously for managing state and 
 data and rely on exhaustive pattern matching to guarantee we're handling 
 all states in our code. We're splitting out our code across modules and 
 having this guarantee has been a joy to work with.
 
 The benefit of making nonexhaustive the default for Swift 5 across all 
 

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

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 = ConnectionDictionaryKey("hostname")
  static let databaseName = ConnectionDictionaryKey("database")
  // …
}

It is definitely more verbose than an enum, and it may be worth a separate 
proposal to deal with that! But it is not part of this proposal, and what 
you're describing isn't really an enum.

Jordan


> On Sep 16, 2017, at 15:51, Kenny Leung via swift-evolution 
>  wrote:
> 
> Oops, forgot something:
> 
> "Can there be a kind of open enum where you can add new cases in extensions?”
> 
> I have a use case for this. I’m trying to write a database ORM with abstract 
> API and concrete instances for different database. So I have defined:
> 
> open class Database {
>init(connectionDictionary: [ConnectionDictionaryKey:String]) {
> self.connectionDictionary = connectionDictionary;
> }
> }
> 
> Where I have ConnectionDictionaryKey defined as an enum, with values like 
> .hostName, .databaseName, .userName, .password, .databaseName, etc…
> 
> But concrete databases may have other options that need to be added to the 
> connection dictionary. It would be nice if they could just extend 
> ConnectionDictionaryKey with new cases.
> 
> -Kenny
> 
> 
>> On Sep 16, 2017, at 3:35 PM, 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 an enum, since I may have to do something about it. How 
>> about adding the “exhaustive” keyword to be used in the switch statement? 
>> Like
>> 
>> exhaustive switch excuse {
>> case eatenByPet:
>> // …
>> case thoughtItWasDueNextWeek:
>> // …
>> default:
>> // …
>> }
>> 
>> If exhaustive is used, there would be a warning if all cases aren’t covered 
>> *even though default exists*. This means that I as the client thought I had 
>> everything covered when I wrote this code.
>> 
>> As already mentioned, this makes the default case un-testable, which brings 
>> me to
>> 
>> 2) All non-exhaustive enums should have the pseudo value “default” that can 
>> be used just like a regular value. This would allow you to write code like:
>> 
>> teacher.failedToHandInHomework(excuse: .default)
>> 
>> which would allow you to trip the default case in any code you may write.
>> 
>> -Kenny
>> 
>> 
>>> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> Proposal updated, same URL: 
>>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>>  
>>> .
>>> 
>>> Thanks again for all the feedback so far, everyone!
>>> Jordan
>>> 
>>> 
 On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
 > wrote:
 
 Sorry, I got distracted by other tasks! Both the discussion here and 
 within Apple has moved towards making "non-exhaustive" the default, which, 
 to be honest, I too think is the best design. I'll update the proposal 
 today to reflect that, though I still want to keep both the 
 "nonexhaustive" and "exhaustive" keywords for Swift 4 compatibility for 
 now (or whatever we end up naming them). The compatibility design is a 
 little less ambitious than Brent's; as currently proposed, Swift 4 mode 
 continues to default to 'exhaustive' all the time, even in the actual 
 Swift 5 release.
 
 I still want to respond to Brent's points directly, but I think you and 
 Vladimir have done a good job discussing them already. I'll send out the 
 updated proposal tomorrow, after I have a little more time to think about 
 #invalid.
 
 Thanks for putting time into this!
 Jordan
 
 
> On Sep 9, 2017, at 17:34, Rod Brown  > wrote:
> 
> Jordan,
> 
> Do you have any other thoughts about the ongoing discussion here, 
> especially regarding Chris’ comments? As you’re the one pushing this 
> forward, I’d really like to know what your thoughts are regarding this?
> 
> - Rod
 
 ___
 swift-evolution mailing list
 swift-evolution@swift.org 
 

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

> 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 an enum, since I may have to do something about it. How 
> about adding the “exhaustive” keyword to be used in the switch statement? Like
> 
> exhaustive switch excuse {
> case eatenByPet:
> // …
> case thoughtItWasDueNextWeek:
> // …
> default:
> // …
> }
> 
> If exhaustive is used, there would be a warning if all cases aren’t covered 
> *even though default exists*. This means that I as the client thought I had 
> everything covered when I wrote this code.
> 
> As already mentioned, this makes the default case un-testable, which brings 
> me to
> 
> 2) All non-exhaustive enums should have the pseudo value “default” that can 
> be used just like a regular value. This would allow you to write code like:
> 
> teacher.failedToHandInHomework(excuse: .default)
> 
> which would allow you to trip the default case in any code you may write.

Brent came up with this idea as well, but after thinking it through Joe Groff 
and I found that it doesn't really work in practice:

> It’s going to be very common to have a future value and hand it right back to 
> the framework without looking at it, for example:
> 
> override func process(_ transaction: @testable Transaction) {
>   switch transaction {
>   case .deposit(let amount):
> // …
>   case .withdrawal(let amount):
> // …
>   default:
> super.process(transaction) // hmm…
>   }
> }
> 
> So just making it to the ‘default’ case doesn’t guarantee that it’s testable 
> in practice.

I'll add the actual code here to the "Testing invalid cases" section under 
"Alternatives considered", since that's a clearer example than the paragraph I 
wrote. (Oh, and the "exhaustive switch" is equivalent to the section on 
"'future' cases".)

Thanks for the feedback!
Jordan___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

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 
current proposal makes sense as is.

Jordan


> On Sep 16, 2017, at 01:55, David Hart  wrote:
> 
> I’m still very much bothered by having 2 new keywords. I would really prefer 
> the following plan:
> 
> Exhaustive by default in Swift 4
> No new keyword in Swift 4 to change that behaviour
> Non-exhaustive by default outside the module in Swift 5
> exhaustive keyword to change the default behaviour
> 
> Like that, we don’t need nonexhaustive.
> 
> Thoughts?
> David.
> 
>> On 13 Sep 2017, at 21:16, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Proposal updated, same URL: 
>> https://github.com/jrose-apple/swift-evolution/blob/non-exhaustive-enums/proposals/-non-exhaustive-enums.md
>>  
>> .
>> 
>> Thanks again for all the feedback so far, everyone!
>> Jordan
>> 
>> 
>>> On Sep 12, 2017, at 17:55, Jordan Rose via swift-evolution 
>>> > wrote:
>>> 
>>> Sorry, I got distracted by other tasks! Both the discussion here and within 
>>> Apple has moved towards making "non-exhaustive" the default, which, to be 
>>> honest, I too think is the best design. I'll update the proposal today to 
>>> reflect that, though I still want to keep both the "nonexhaustive" and 
>>> "exhaustive" keywords for Swift 4 compatibility for now (or whatever we end 
>>> up naming them). The compatibility design is a little less ambitious than 
>>> Brent's; as currently proposed, Swift 4 mode continues to default to 
>>> 'exhaustive' all the time, even in the actual Swift 5 release.
>>> 
>>> I still want to respond to Brent's points directly, but I think you and 
>>> Vladimir have done a good job discussing them already. I'll send out the 
>>> updated proposal tomorrow, after I have a little more time to think about 
>>> #invalid.
>>> 
>>> Thanks for putting time into this!
>>> Jordan
>>> 
>>> 
 On Sep 9, 2017, at 17:34, Rod Brown > wrote:
 
 Jordan,
 
 Do you have any other thoughts about the ongoing discussion here, 
 especially regarding Chris’ comments? As you’re the one pushing this 
 forward, I’d really like to know what your thoughts are regarding this?
 
 - Rod
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

> 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 
>> > wrote:
>> 
>>> 
>>> On Sep 16, 2017, at 8:41 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> On 16 Sep 2017, at 7:22 pm, Goffredo Marocchi via swift-evolution 
>>> > wrote:
>>> 
 I am still unsure why we are choosing again a default that protects 
 library writers more than library users where it is reasonable to expect 
 the former to have better mastery of the language, to architect a library 
 with some scalability, and ability to add unit test to cover themselves 
 from issues than the latter.
>>> 
>>> Because protecting library owners protects library users.
>> 
>> If a library writer can’t remember to declare non-exhaustive enums as such, 
>> they probably will forget many more important aspects of creating a library. 
>> They probably should not be writing libraries. Arguments like this make 
>> sense on the surface, but creating libraries involves hundreds or thousands 
>> of decisions. I wish you luck in making that process idiot proof. A library 
>> linter could easily warn that exposed enums are exhaustive. The exhaustive 
>> keyword should be optional to make the decision obvious and suppress 
>> warnings. Complicating the user experience in a vain attempt to make 
>> “expert" coding safer is misguided.
> 
> This may be a little harsh, but there don’t seem to be many advocates for 
> novice and “ordinary” application developers on this list. That is not 
> unexpected given the number of extremely knowledgeable compiler and library 
> developers on this list (for whom I have the highest respect). I believe that 
> there are more creative (and probably more difficult to build) possible 
> solutions to some of the tough problems in Swift’s future. In that spirit, 
> see below.

It's definitely good to consider the effects on normal application developers!


> 
>> 
>> 
>>> 
>>> If you declare it is exhaustive and it was an oversight, and then realise 
>>> after the fact that you are wrong, you have to open it up. This will break 
>>> third party apps. It will be disallowed by the ABI compatibility 
>>> requirements.
>>> 
>>> If you declare it isn’t exhaustive due to an oversight (or perhaps you’re 
>>> just not sure yet), and then realise after the fact it is exhaustive, you 
>>> can close it up. This will not break third party apps. It will also be 
>>> allowed for ABI compatibility.
>>> 
>>> This benefits everyone. Make library owners choose a guarantee, rather than 
>>> be defaulted into it. Much like they have to declare choose to declare 
>>> “final” on a class: you can’t retroactively reneg that promise: it will 
>>> break everyone who assumed it to be the case!
>> 
>> It does not benefit the creation of 90+% of enums. It is one more arcane 
>> rule for the vast majority of developers.
> 
> The Swift compiler could offer a “strict enum exhaustiveness” (bikeshedding 
> not included) switch that could be enabled by default for library targets and 
> disabled by default for “application” targets. The switch would make not 
> explicitly specifying exhaustiveness an error or warning when enabled. 
> Perhaps this could be combined with other options that would tailor the 
> development experience for library/application developers. This would help 
> avoid “zero-sum” choices between benefitting library or application 
> developers in the future.
> 
> Xcode and the SPM should be able to distinguish between the target types and 
> generate the proper defaults. I do not believe that this is too mysterious 
> for developers. There would be learning step for developers wiring their 
> first library, but that is not necessarily a bad thing since creating a 
> reusable library requires a different mindset than creating an application.

Right now we have this notion, but the difference between library and app is 
signified by "public". My opinion is that between the choices of "multi-module 
applications have to deal with everything SwiftPM packages do" and "there are 
different rules for multi-module applications and for SwiftPM packages", the 
former is preferable just in terms of overall complexity in the language. It's 
certainly a trade-off! But that's what I'm proposing, and it should be very 
clear what to do when multi-module app developers encounter the additional 
rules that come with, well, having multiple modules.

(We're already likely to have an extra distinction between "libraries built 
with support for binary compatibility" and "libraries built to be distributed 
with their clients", but it's still better if that too avoids splitting the 
language into dialects.)

Re: [swift-evolution] Enums and Source Compatibility

[Jordan Rose via swift-evolution]

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 are non-exhaustive, and to ensure that clients handle any 
> future cases when dealing with the latter. This change only affects clients 
> from outside the original module.

> When a client tries to switch over a nonexhaustive enum, they must include a 
> default case unless the enum is declared in the same module as the switch.

Do you have any suggestions on how to make this clearer in the proposal?

Jordan


> On Sep 15, 2017, at 21:40, Jon Shier  wrote:
> 
>   In that case Jordan, can Swift not treat it like open? i.e. Internally 
> to a module, unmarked enums are still exhaustive by default, but when made 
> public and used beyond the module, it becomes non-exhaustive? I think this 
> has been discussed before and perhaps discarded as confusing, but it doesn’t 
> seem to be any more confusing than open being the default internally and 
> closed the default publicly. Otherwise you’re essentially forcing what is 
> likely the vast majority of enum usage to adopt a bit of boilerplate that 
> will only be used by the vast minority of libraries (almost entirely 
> libraries shipped by Apple). 
> 
> 
> Jon
> 
>> On Sep 15, 2017, at 8:07 PM, Jordan Rose via swift-evolution 
>> > wrote:
>> 
>> Hi, Rex. I definitely agree that 'exhaustive' is the right model for a 
>> multi-module app; indeed, there's no real reason for a single project to do 
>> anything else. However, it is not always the right behavior for libraries 
>> that actually get distributed, whether as source or as binary. In this case 
>> we want to minimize the error of omission: in the app case, forgetting 
>> "exhaustive" is an annoyance that you notice and fix once across your code 
>> base, but in the library case forgetting the "default case" means putting 
>> out a source-breaking release, and for libraries that have binary 
>> compatibility constraints there's no recourse at all.
>> 
>> While most of the proposal deals with the experience we've had with the 
>> Apple SDKs (as written in Objective-C), we actually have run into this case 
>> in Swift already. The Swift Playgrounds app comes with a framework, 
>> PlaygroundSupport, that can be used from within a playground. It's important 
>> that when they upgrade the app, existing playgrounds don't break, since the 
>> end user may not have access to the entire code of the playground. (Remember 
>> that playgrounds are often authored by one developer or group, but then run 
>> and modified by someone else with a much lower skill level!) That means that 
>> PlaygroundSupport can't currently vend any enums that they expect playground 
>> authors to exhaustively switch over.
>> 
>> (And to make it even more specific—and appealing—one of the enums they were 
>> considering would be a representation of the Swift AST. This can obviously 
>> change from release to release, but previous switch statements should stay 
>> valid.)
>> 
>> Now, this is an example we know about, so we could certainly make it 
>> explicitly non-exhaustive. But in general we're in the same situation as 
>> 'open': if we want to be friendly to library authors, we need to make the 
>> default thing be the one that promises less, even if it means a bit of extra 
>> work in the "I-actually-own-everything" case.
>> 
>> Best,
>> Jordan
>> 
>> 
>>> On Sep 15, 2017, at 15:47, Rex Fenley >> > wrote:
>>> 
>>> Hey Jordan,
>>> 
>>> Thank you for the time writing this up. I've been following along to the 
>>> discussion somewhat closely and have kept silent because `exhaustive` was 
>>> originally set to be the default for enums. However, that changed and so 
>>> I'd like to voice my opinion, I frankly don't like this idea.
>>> 
>>> At remind we use algebraic data types religiously for managing state and 
>>> data and rely on exhaustive pattern matching to guarantee we're handling 
>>> all states in our code. We're splitting out our code across modules and 
>>> having this guarantee has been a joy to work with.
>>> 
>>> The benefit of making nonexhaustive the default for Swift 5 across all 
>>> multi-module code (besides C code) seems minimal to me. If a developer 
>>> feels like they're unnecessarily managing enum cases, they can simply add a 
>>> `default` case whenever they please. This is already the case and I'm 
>>> curious if there's every been any complaints about this and what they would 
>>> be. I'd prefer to be cautious and force exhaustive pattern matching in all 
>>> possible cases and leave it up to the developer to choose not to.
>>> 
>>> Ideally in my mind, these keywords won't be necessary. All 

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

[Adam Kemp via swift-evolution]

> 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 
>> > wrote:
>> 
>> @IBAction func buttonDidClick(sender:AnyObject) {
>> beginAsync {
>> let image = await processImage(downloadImage(), resize: 
>> self.resizeSwitch.isOn)
>> displayImage(image)
>> }
>> }
> 
> 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:AnyObject) {
>   beginAsync {
>   let $temp1 = self.resizeSwitch.isOn
>   let $temp2 = await downloadImage()
>   let image = await processImage($temp2, resize: $temp1)
>   displayImage(image)
>   }
>   }

That violates the defined order of evaluation for function arguments. You could 
also write code in which the (async) first argument function call has side 
effects that alter the result of the second argument expression. I’m not saying 
that’s good code, but it’s possible, and the language defines the order of 
evaluation so that code like that will have a predictable behavior.___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Pierre Habouzit via swift-evolution]

> 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 
>>> > 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 
>>> more evolved mechanisms (such as actors) on top later.
>>> 
>>> My question after reading the many conversations (and confusion) around the 
>>> execution order of async / await on the mailing list is this : 
>>> Isn't the actor model a more "elementary" concurrency model than async / 
>>> await, and so, from a theoretical point of view, wouldn't it make more 
>>> sense to implement it first as a layer to build future other concurrency 
>>> mechanisms on top ?
>>> 
>>> I'm putting emphasis on the "theoretical" aspect of my question, because 
>>> i'm 100% certain that if Mr Lattner decided to go this path, it's because 
>>> it makes more sense from an implementation point of view. 
>> 
>> Actors is a way higher level construct than async/await.
>> 
>> async/await is IMO an interesting low level construct that explains to the 
>> language where your execution flow requires to be broken in two (what is 
>> syntactically before and after the "await") to wait for some event before 
>> the second half can be done.
>> 
>> Unlike Actors, it doesn't try to explain what/how/... this is done, which 
>> makes it lower level.
> 
> That's also how i first thought about it, but the more i digg the subject ( 
> especially after viewing https://youtu.be/7erJ1DV_Tlo 
> ), the more i understand actors as a 
> fundamental unit of computation (addressable, with a state), and not a whole 
> framework.
> 
> all the questions i see raised with async/await ( queue hoping, timeouts, 
> error handling, ressource allocation, etc) simply aren't there with actors, 
> because imho, the model is conceptually simpler ( and thus a saner basis for 
> building concurrency).
> 
> I started thinking about what, in the "everything's an actor" model, 
> async/await would mean if called from within an actor and it seems like it 
> would mean that once the await call is made, all the messages sent to that 
> actor are blocked until the response from that call is received ( which is 
> dangerous if the message comes from the network, but not that much when 
> running in the same computer). That seemed interesting but i stopped there 
> because i wanted to have the opinion of more qualified people first.

All of this is orthogonal. async/await, is about explaining to the compiler how 
to split sequential synchronous looking code into an asynchronous state machine.

Unlike actors that attach rules and semantics to this, async/await is really 
just about the compiler transform (which is *not* that easy, especially when C 
stacks happen in the mix).

-Pierre

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Pierre Habouzit via swift-evolution]

-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 
>>> > wrote:
>>> 
>>> Hello everyone,
>>> 
>>> I have a few questions about async await in Swift.
>>> 
>>> Say that you have :
>>> 
>>> func foo() async {
>>> print("Hey")
>>> await bar()
>>> print("How are you ?")
>>> }
>>> 
>>> First of all, am I right to say that :
>>> 1) If the bar function wasn't an async function, the thread would be 
>>> blocked until bar returns, at this point print("How are you ?") would be 
>>> executed and its only after that that the function calling foo() would get 
>>> back "control"
>> 
>> I don't think you can quite call await without marking foo() as async (?).
> 
> 
> Yes, that's what I meant, case one would call foo() without await if it 
> wasn't async.
> 
> 
>> 
>>> 2) Here (with async bar function), if bar() takes some time to execute,
>> 
>> Not quite, `await bar()` is afaict syntactic sugar for:
>> 
>> bar {
>> printf("How are you ?");
>> }
>> 
>> Where bar used to take a closure before, the compiler is just making it for 
>> you. bar itself will be marked async and will handle its asynchronous nature 
>> e.g. using dispatch or something else entirely.
>> This has nothing to do with "time".
> 
> 
> If it's just syntactic sugar then how does this solve this issue mentioned in 
> the concurrency manifesto ?
> "Beyond being syntactically inconvenient, completion handlers are problematic 
> because their syntax suggests that they will be called on the current queue, 
> but that is not always the case. For example, one of the top recommendations 
> on Stack Overflow is to implement your own custom async operations with code 
> like this (Objective-C syntax):"

"where" things run is not addressed by async/await afaict, but Actors or any 
library-level usage of it.

> 
> 
> Trevör
> 
> 
> 
>> 
>>> control is directly given back to the function calling foo() and, when 
>>> bar() returns, print("How are you") will be executed.
>>> 
>>> 
>>> Second question about why async/await are needed:
>>> Since calling await must be done in an async function and since async 
>>> function can only be called, then if we have :
>>> func baz() async {
>>> await foo()
>>> print("Something else")
>>> }
>>> 
>>> Does this mean that "print("Something else")" will actually be waiting for 
>>> bar() (and foo()) to complete ?
>>> If this is right, then, what surprises me a little is that in this specific 
>>> case, if all functions hadn't been async, then the execution order would 
>>> have exactly been the same, am I right ?
>>> So why are async/await needed ? Except for clarity, what do they enable 
>>> that wouldn't have been possible otherwise ? It's not exactly clear to me 
>>> sometimes because even things like futures wouldn't seem impossible to 
>>> build without async await.
>>> 
>>> About beginAsync, say that we do that on the main thread :
>>> beginAsync {
>>> await someAsyncFunction()
>>> }
>>> 
>>> Will someAsyncFunction() still be executed on the main thread if it was 
>>> defined this way ?
>>> func someAsyncFunction() async {
>>> for element in manyElements {
>>> doSomethingLong(element)
>>> }
>>> }
>>> 
>>> In this case, when will the main "choose" to execute those instructions ?
>>> 
>>> 
>>> Thank you !
>>> 
>>> Trevör
>>> 
>>> 
>>> 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Félix Cloutier via swift-evolution]

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 propose a fixit for subscript where the 
>> unknown associated type is replaced by a placeholder.
>> - Fixits from steps 2, 3, and 4 should be combined together as a single 
>> fixit.
> 
> 
> Would be nice indeed. But I too believe that we could make it way easier for 
> newcomers if the documentation was better organised. That would solve the 
> problem for most unless all the stdlib, which is what newcomers are most 
> likely to conform to.
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Benjamin Garrigues via swift-evolution]

> 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 
>> more evolved mechanisms (such as actors) on top later.
>> 
>> My question after reading the many conversations (and confusion) around the 
>> execution order of async / await on the mailing list is this : 
>> Isn't the actor model a more "elementary" concurrency model than async / 
>> await, and so, from a theoretical point of view, wouldn't it make more sense 
>> to implement it first as a layer to build future other concurrency 
>> mechanisms on top ?
>> 
>> I'm putting emphasis on the "theoretical" aspect of my question, because i'm 
>> 100% certain that if Mr Lattner decided to go this path, it's because it 
>> makes more sense from an implementation point of view. 
> 
> Actors is a way higher level construct than async/await.
> 
> async/await is IMO an interesting low level construct that explains to the 
> language where your execution flow requires to be broken in two (what is 
> syntactically before and after the "await") to wait for some event before the 
> second half can be done.
> 
> Unlike Actors, it doesn't try to explain what/how/... this is done, which 
> makes it lower level.

That's also how i first thought about it, but the more i digg the subject ( 
especially after viewing https://youtu.be/7erJ1DV_Tlo), the more i understand 
actors as a fundamental unit of computation (addressable, with a state), and 
not a whole framework.

all the questions i see raised with async/await ( queue hoping, timeouts, error 
handling, ressource allocation, etc) simply aren't there with actors, because 
imho, the model is conceptually simpler ( and thus a saner basis for building 
concurrency).

I started thinking about what, in the "everything's an actor" model, 
async/await would mean if called from within an actor and it seems like it 
would mean that once the await call is made, all the messages sent to that 
actor are blocked until the response from that call is received ( which is 
dangerous if the message comes from the network, but not that much when running 
in the same computer). That seemed interesting but i stopped there because i 
wanted to have the opinion of more qualified people first.

> 
> -Pierre
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Question about async await

[Trevör Anne Denise via swift-evolution]

> 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 
>> > wrote:
>> 
>> Hello everyone,
>> 
>> I have a few questions about async await in Swift.
>> 
>> Say that you have :
>> 
>> func foo() async {
>>  print("Hey")
>>  await bar()
>>  print("How are you ?")
>> }
>> 
>> First of all, am I right to say that :
>> 1) If the bar function wasn't an async function, the thread would be blocked 
>> until bar returns, at this point print("How are you ?") would be executed 
>> and its only after that that the function calling foo() would get back 
>> "control"
> 
> I don't think you can quite call await without marking foo() as async (?).


Yes, that's what I meant, case one would call foo() without await if it wasn't 
async.


> 
>> 2) Here (with async bar function), if bar() takes some time to execute,
> 
> Not quite, `await bar()` is afaict syntactic sugar for:
> 
> bar {
> printf("How are you ?");
> }
> 
> Where bar used to take a closure before, the compiler is just making it for 
> you. bar itself will be marked async and will handle its asynchronous nature 
> e.g. using dispatch or something else entirely.
> This has nothing to do with "time".


If it's just syntactic sugar then how does this solve this issue mentioned in 
the concurrency manifesto ?
"Beyond being syntactically inconvenient, completion handlers are problematic 
because their syntax suggests that they will be called on the current queue, 
but that is not always the case. For example, one of the top recommendations on 
Stack Overflow is to implement your own custom async operations with code like 
this (Objective-C syntax):"


Trevör



> 
>> control is directly given back to the function calling foo() and, when bar() 
>> returns, print("How are you") will be executed.
>> 
>> 
>> Second question about why async/await are needed:
>> Since calling await must be done in an async function and since async 
>> function can only be called, then if we have :
>> func baz() async {
>>  await foo()
>>  print("Something else")
>> }
>> 
>> Does this mean that "print("Something else")" will actually be waiting for 
>> bar() (and foo()) to complete ?
>> If this is right, then, what surprises me a little is that in this specific 
>> case, if all functions hadn't been async, then the execution order would 
>> have exactly been the same, am I right ?
>> So why are async/await needed ? Except for clarity, what do they enable that 
>> wouldn't have been possible otherwise ? It's not exactly clear to me 
>> sometimes because even things like futures wouldn't seem impossible to build 
>> without async await.
>> 
>> About beginAsync, say that we do that on the main thread :
>> beginAsync {
>>  await someAsyncFunction()
>> }
>> 
>> Will someAsyncFunction() still be executed on the main thread if it was 
>> defined this way ?
>> func someAsyncFunction() async {
>>  for element in manyElements {
>>  doSomethingLong(element)
>>  }
>> }
>> 
>> In this case, when will the main "choose" to execute those instructions ?
>> 
>> 
>> Thank you !
>> 
>> Trevör
>> 
>> 
>> 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org 
>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Documentation and comments

[Alex Blewitt via swift-evolution]

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:
> 
> Hi everyone,
> 
> Well I had this weird idea that I would like to share with you maybe it turns 
> out to be helpful.
> 
> So, can we somehow link comments with the code in a way that becomes updated 
> with the source code itself ?
> 
> Can we fix that issue where your documentation is automatically updated when 
> u update the source code ?
> I see everyone suffering from the fact that comments are not 100% reliable 
> since you update the code and no one remembers to update the comments above 
> etc …
> 
> I don’t know if this is an XCode thing or a swift compiler task in general … 
> but as long as I write Swift I would like to have this feature in any IDE or 
> Editor that I use, would that stop the problem at all ?
> 
> - Omar
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

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

[Dimitri Racordon via swift-evolution]

> - In step 2, the compiler could propose a fixit for subscript where the 
> unknown associated type is replaced by a placeholder.
> - Fixits from steps 2, 3, and 4 should be combined together as a single fixit.


Would be nice indeed. But I too believe that we could make it way easier for 
newcomers if the documentation was better organised. That would solve the 
problem for most unless all the stdlib, which is what newcomers are most likely 
to conform to.

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Enums and Source Compatibility

[Jon Shier via swift-evolution]

I just noticed this too. I guess I was looking too closely at the 
“Default behavior” section.The inlining caveat scares me a little, as it would 
seem to have rather drastic consequences in the future, essentially requiring 
the worst case scenario, even in the same module, if we want inlining for 
functions that use enums.


Jon

> On Sep 17, 2017, at 9:09 PM, Rod Brown via swift-evolution 
>  wrote:
> 
>> 
>> On 18 Sep 2017, at 9:46 am, Christopher Kornher > > wrote:
>> 
>> 
>>> On Sep 17, 2017, at 5:04 PM, BJ Homer >> > wrote:
>>> 
>>> Please note that, as proposed, enums are always treated as exhaustive 
>>> *within the same module*. A new user writing MyFirstEnum is likely using it 
>>> within the same module, and will thus get exhaustive behavior with no extra 
>>> keywords required.
>> 
>> • What is your evaluation of the proposal?
>>  Uh, +1
>> 
>>  • How much effort did you put into your review? A glance, a quick reading, 
>> or an in-depth study?
>>  not enough
>> 
>> Apologies for wasting everyone’s time…
> 
> Haha no problems. Yes, it seems clear people are jumping to conclusions. This 
> is a case specifically for framework developers purely for interface 
> consistency, with is *exactly* when you want the default behaviour to protect 
> you from external dependency changes.
> 
> Within the context of a single application at compile time, you will always 
> know all cases already and therefore exhaustive can become the default. Cross 
> frameworks, not so much.
> 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution