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

[Pierre Habouzit via swift-evolution]

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

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

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

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

> 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] Problems with generics - should be fixed for Xcode 9?

[Charlie Monroe via swift-evolution]

This IMHO isn't a bug as the behavior is not completely defined. Joanna 
mentioned that Args is not generic, but it actually is, once you address it 
from global namespace - as it inherits the T type (while not used anywhere):

NSStringFromClass(Event.Args.self)
NSStringFromClass(Event.Args.self)

-->

_TtGCC14__lldb_expr_375Event4ArgsCSo8NSString__
_TtGCC14__lldb_expr_375Event4ArgsCSo6NSDate__

Which is the root of the problem - you are currently not actually using the 
same class under different event types. It then makes a static property an 
issue as you are not able to distinguish these two scenarios with current 
language:

- is the stored property the same for all variations of the Args class?
- or does each type has its own stored property?

I can think of cases for both. And this is (from what I understood is the core 
of the problem).

@Joanna - in this particular case, I don't see the benefit of Args.empty over 
Args() as you currently create a new instance all the time. If the arguments 
are not intended to be generic, much better solution is to do something like:

class EventArgs {
public static let empty = Args()
}

class Event {
typealias Args = EventArgs
}


> On Sep 17, 2017, at 11:59 PM, Félix Cloutier via swift-evolution 
>  wrote:
> 
> I always thought that this was a bug, but I can't find it on bugs.swift.org, 
> so I'd love to know if it's meant to stay this way or not.
> 
>> Le 16 sept. 2017 à 06:32, Joanna Carter via swift-evolution 
>>  a écrit :
>> 
>> Greetings
>> 
>> Old chestnut, sort of partially solved but still problems.
>> 
>> Now we can nest types in generic types, what I want is :
>> 
>> class Event
>> {
>> class Args
>> {
>>   public static let empty = Args() // error : Static stored properties not 
>> supported in generic types
>> }
>> }
>> 
>> But the static let is not directly in the generic class.
>> 
>> So, I end up doing another convoluted workaround in the shape of :
>> 
>> class Event
>> {
>> class Args
>> {
>>   public static var empty: Args
>>   {
>> return Args()
>>   }
>> }
>> }
>> 
>> The main difference is that I have to create a new instance on every call to 
>> Args.empty instead of returning the same one.
>> 
>> Is this an oversight or as intended, with the hope of fixing it in a future 
>> version
>> 
>> Joanna
>> 
>> --
>> Joanna Carter
>> Carter Consulting
>> 
>> ___
>> 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] Problems with generics - should be fixed for Xcode 9?

[Douglas Gregor via swift-evolution]

Sent from my iPhone

> On Sep 16, 2017, at 6:32 AM, Joanna Carter via swift-evolution 
>  wrote:
> 
> Greetings
> 
> Old chestnut, sort of partially solved but still problems.
> 
> Now we can nest types in generic types, what I want is :
> 
> class Event
> {
>  class Args
>  {
>public static let empty = Args() // error : Static stored properties not 
> supported in generic types
>  }
> }
> 
> But the static let is not directly in the generic class.

It's still generic, though, because of the outer generic class, so there is a 
different static var for each specialization. For example, the following assert 
would fail:

  assert(Event.Args.empty === Event.Args.empty)



> 
> So, I end up doing another convoluted workaround in the shape of :
> 
> class Event
> {
>  class Args
>  {
>public static var empty: Args
>{
>  return Args()
>}
>  }
> }
> 
> The main difference is that I have to create a new instance on every call to 
> Args.empty instead of returning the same one.
> 
> Is this an oversight or as intended, with the hope of fixing it in a future 
> version

I'd say we consider it a bug. 

  - Doug

> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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

[Michel Fortin via swift-evolution]

It could certainly be improved:

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

And with this: you add the conformance to your type, Xcode automatically 
suggest everything you need to add, and you then add it in one click.

> Le 17 sept. 2017 à 22:13, T.J. Usiyan  a écrit :
> 
> I guess the question is, "Do we want this to be the process we expect of and 
> explain to newcomers?"
> 
> On Sun, Sep 17, 2017 at 7:32 PM, Michel Fortin via swift-evolution 
> > wrote:
>> Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution 
>> > a écrit :
>> 
>> I found that for Sequence, but Sequence is far from the only protocol with 
>> default implementations, and not all of them have maintainers willing to 
>> write and update documentation to the degree that Apple will.
> 
> How I do it is like this:
> 
> 1. Make a dummy struct (or class) that claim conformance to a protocol:
> 
> struct Z: Collection {
> }
> 
> 2. Compiling, then deciphering the errors tells me that type deduction 
> doesn't work for associated type `Index` because there is no subscript. So I 
> add one:
> 
> struct Z: Collection {
>   subscript (index: Int) -> Int {
>   get { return index }
>   }
> }
> 
> 3. Compiling again, I now get a suggestion (fixit) telling me to add 
> `startIndex` and `endIndex`. I add the suggested code:
> 
> struct Z: Collection {
>   var startIndex: Int
> 
>   var endIndex: Int
> 
>   subscript (index: Int) -> Int {
>   get { return index }
>   }
> }
> 
> 4. Compiling again, I get another suggestion (fixit) telling me I'm missing 
> `index(after:)`. I add it and write an implementation inside the braces. And 
> here I am:
> 
> struct Z: Collection {
>   func index(after i: Int) -> Int {
>   return i + 1
>   }
> 
>   var startIndex: Int
> 
>   var endIndex: Int
> 
>   subscript (index: Int) -> Int {
>   get { return index }
>   }
> }
> 
> 5. And now it compiles. Hurray!
> 
> I made a collection type and did not have to read any documentation at all. 
> The hardest step is the first one where you have to figure out how to make 
> deduction work for the associated types based on the error messages.
> 
> 
> -- 
> Michel Fortin
> https://michelf.ca 
> 
> 
> 
> -- 
> Michel Fortin
> https://michelf.ca 
> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 
> 
> 

-- 
Michel Fortin
https://michelf.ca

___
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

[T.J. Usiyan via swift-evolution]

I guess the question is, "Do we want this to be the process we expect of
and explain to newcomers?"

On Sun, Sep 17, 2017 at 7:32 PM, Michel Fortin via swift-evolution <
swift-evolution@swift.org> wrote:

> Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution <
> swift-evolution@swift.org> a écrit :
>
> I found that for Sequence, but Sequence is far from the only protocol with
> default implementations, and not all of them have maintainers willing to
> write and update documentation to the degree that Apple will.
>
>
> How I do it is like this:
>
> 1. Make a dummy struct (or class) that claim conformance to a protocol:
>
> struct Z: Collection {
> }
>
> 2. Compiling, then deciphering the errors tells me that type deduction
> doesn't work for associated type `Index` because there is no subscript. So
> I add one:
>
> struct Z: Collection {
> subscript (index: Int) -> Int {
> get { return index }
> }
> }
>
> 3. Compiling again, I now get a suggestion (fixit) telling me to add
> `startIndex` and `endIndex`. I add the suggested code:
>
> struct Z: Collection {
> var startIndex: Int
>
> var endIndex: Int
>
> subscript (index: Int) -> Int {
> get { return index }
> }
> }
>
> 4. Compiling again, I get another suggestion (fixit) telling me I'm
> missing `index(after:)`. I add it and write an implementation inside the
> braces. And here I am:
>
> struct Z: Collection {
> func index(after i: Int) -> Int {
> return i + 1
> }
>
> var startIndex: Int
>
> var endIndex: Int
>
> subscript (index: Int) -> Int {
> get { return index }
> }
> }
>
> 5. And now it compiles. Hurray!
>
> I made a collection type and did not have to read any documentation at
> all. The hardest step is the first one where you have to figure out how to
> make deduction work for the associated types based on the error messages.
>
>
> --
> Michel Fortin
> https://michelf.ca
>
>
>
> --
> Michel Fortin
> https://michelf.ca
>
>
> ___
> 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

[Rod Brown via swift-evolution]

> 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

Re: [swift-evolution] Enums and Source Compatibility

[Jonathan Hull via swift-evolution]

Ah, ok.  I had missed this too, somehow.

> On Sep 17, 2017, at 4:04 PM, BJ Homer via swift-evolution 
>  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.
> 
> -BJ
> 
> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution 
> > wrote:
> 
>> 
>>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 17 Sep 2017, at 4:35 am, Christopher Kornher > wrote:
 
> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
> > wrote:
> 
> 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.
>>> 
>>> I think the same logic goes both ways: If a library author can’t remember 
>>> to declare exhaustive enums as such, they will probably forget many more 
>>> important aspects of creating a library.
>>> 
>>> The problem here is fundamental: Exhaustive is a guarantee. A guarantee 
>>> should require action. Non-Exhaustive guarantees nothing. It makes you 
>>> safer. That is all.
>> 
>> 1) Exhaustive enums are inherently better: they allow a developer to know 
>> that they have covered all possible cases by not using a default.
>> 2) This proposal forces developers to add a keyword to get this behavior in 
>> their apps, which is common to all other languages with enums that I have 
>> used. This proposal breaks the model common to all (?) current 
>> implementations of enums. 
>> 
>> 
>>> 
 
 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.
>>> 
>>> I personally am an “ordinary” application developer.
>>> 
>>> I think the issue here is that everyone is seeing Swift as *they* intend to 
>>> use it. For App Devs, exhaustive switches are nice, which means they really 
>>> are fighting tooth and nail to keep them. I understand that. But I’m also 
>>> trying to keep my mind open for “what happens to an app I compiled in iOS 
>>> 15 that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple 
>>> or any other library author to be completely knowledgable about every case 
>>> in the future, and to audit every line of code and manually give 
>>> non-exhaustive.
>>> 
>>> Why do people want “exhaustive” to be the default?
>>> Because we like things as they are.
>> 
>> No, because it makes sense to make common things easy and uncommon things 
>> possible. 
>> 
>>> Because we like not having to consider edge cases. Because we want to 
>>> imagine that will give framework developers the control to make our lives 
>>> difficult because they’ll just be lazy and make our lives hard by not 
>>> annotating. And this certainly is a concern. But I think a larger concern 
>>> is breaking apps left, right and centre, or not being able to extend 
>>> frameworks because an earlier developer on a project made an oversight.
>> 
>> This happens all the time: Apple deprecates APIs and asked developers to use 
>> new ones. If a library writer does not run (the as-yet hypothetical ) 
>> library lint, not participate in thorough code reviews,…, they can simply 
>> create a new non-exhaustive enum and deprecate the old one. Yes, there will 
>> be some redundant function calls for a while, but again, similar things 
>> happen, even in APIs like Apple’s, that (one hopes, at least) are thoroughly 
>> reviewed. It is not the end of the world to deprecate and migrate APIs. You  
>> may remember garbage collected Objective-C, the change that “viewWillAppear” 
>> suddenly was not called when it used to be in iOS. We all survived the 
>> 

Re: [swift-evolution] Enums and Source Compatibility

[Jonathan Hull via swift-evolution]

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


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


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

Re: [swift-evolution] Enums and Source Compatibility

[Christopher Kornher via swift-evolution]

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

> -BJ
> 
> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution 
> > wrote:
> 
>> 
>>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 17 Sep 2017, at 4:35 am, Christopher Kornher > wrote:
 
> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
> > wrote:
> 
> 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.
>>> 
>>> I think the same logic goes both ways: If a library author can’t remember 
>>> to declare exhaustive enums as such, they will probably forget many more 
>>> important aspects of creating a library.
>>> 
>>> The problem here is fundamental: Exhaustive is a guarantee. A guarantee 
>>> should require action. Non-Exhaustive guarantees nothing. It makes you 
>>> safer. That is all.
>> 
>> 1) Exhaustive enums are inherently better: they allow a developer to know 
>> that they have covered all possible cases by not using a default.
>> 2) This proposal forces developers to add a keyword to get this behavior in 
>> their apps, which is common to all other languages with enums that I have 
>> used. This proposal breaks the model common to all (?) current 
>> implementations of enums. 
>> 
>> 
>>> 
 
 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.
>>> 
>>> I personally am an “ordinary” application developer.
>>> 
>>> I think the issue here is that everyone is seeing Swift as *they* intend to 
>>> use it. For App Devs, exhaustive switches are nice, which means they really 
>>> are fighting tooth and nail to keep them. I understand that. But I’m also 
>>> trying to keep my mind open for “what happens to an app I compiled in iOS 
>>> 15 that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple 
>>> or any other library author to be completely knowledgable about every case 
>>> in the future, and to audit every line of code and manually give 
>>> non-exhaustive.
>>> 
>>> Why do people want “exhaustive” to be the default?
>>> Because we like things as they are.
>> 
>> No, because it makes sense to make common things easy and uncommon things 
>> possible. 
>> 
>>> Because we like not having to consider edge cases. Because we want to 
>>> imagine that will give framework developers the control to make our lives 
>>> difficult because they’ll just be lazy and make our lives hard by not 
>>> annotating. And this certainly is a concern. But I think a larger concern 
>>> is breaking apps left, right and centre, or not being able to extend 
>>> frameworks because an earlier developer on a project made an oversight.
>> 
>> This happens all the time: Apple deprecates APIs and asked developers to use 
>> new ones. If a library writer does not run (the as-yet hypothetical ) 
>> library lint, not participate in thorough code reviews,…, they can simply 
>> create a new non-exhaustive enum and deprecate the old one. Yes, there will 
>> be some redundant function calls for a while, but again, similar things 
>> happen, even in APIs like Apple’s, that (one hopes, at least) are thoroughly 
>> reviewed. It is not the end of the world to deprecate and migrate APIs. You  
>> may 

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

[Michel Fortin via swift-evolution]

> Le 17 sept. 2017 à 18:00, Félix Cloutier via swift-evolution 
> > a écrit :
> 
> I found that for Sequence, but Sequence is far from the only protocol with 
> default implementations, and not all of them have maintainers willing to 
> write and update documentation to the degree that Apple will.

How I do it is like this:

1. Make a dummy struct (or class) that claim conformance to a protocol:

struct Z: Collection {
}

2. Compiling, then deciphering the errors tells me that type deduction doesn't 
work for associated type `Index` because there is no subscript. So I add one:

struct Z: Collection {
subscript (index: Int) -> Int {
get { return index }
}
}

3. Compiling again, I now get a suggestion (fixit) telling me to add 
`startIndex` and `endIndex`. I add the suggested code:

struct Z: Collection {
var startIndex: Int

var endIndex: Int

subscript (index: Int) -> Int {
get { return index }
}
}

4. Compiling again, I get another suggestion (fixit) telling me I'm missing 
`index(after:)`. I add it and write an implementation inside the braces. And 
here I am:

struct Z: Collection {
func index(after i: Int) -> Int {
return i + 1
}

var startIndex: Int

var endIndex: Int

subscript (index: Int) -> Int {
get { return index }
}
}

5. And now it compiles. Hurray!

I made a collection type and did not have to read any documentation at all. The 
hardest step is the first one where you have to figure out how to make 
deduction work for the associated types based on the error messages.


-- 
Michel Fortin
https://michelf.ca 



-- 
Michel Fortin
https://michelf.ca

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

Re: [swift-evolution] Enums and Source Compatibility

[BJ Homer via swift-evolution]

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.

-BJ

> On Sep 17, 2017, at 3:20 PM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> 
>>> On Sep 17, 2017, at 6:33 AM, Rod Brown via swift-evolution 
>>>  wrote:
>>> 
>>> 
 On 17 Sep 2017, at 4:35 am, Christopher Kornher  wrote:
 
 On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
  wrote:
 
 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.
>> 
>> I think the same logic goes both ways: If a library author can’t remember to 
>> declare exhaustive enums as such, they will probably forget many more 
>> important aspects of creating a library.
>> 
>> The problem here is fundamental: Exhaustive is a guarantee. A guarantee 
>> should require action. Non-Exhaustive guarantees nothing. It makes you 
>> safer. That is all.
> 
> 1) Exhaustive enums are inherently better: they allow a developer to know 
> that they have covered all possible cases by not using a default.
> 2) This proposal forces developers to add a keyword to get this behavior in 
> their apps, which is common to all other languages with enums that I have 
> used. This proposal breaks the model common to all (?) current 
> implementations of enums. 
> 
> 
>> 
>>> 
>>> 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.
>> 
>> I personally am an “ordinary” application developer.
>> 
>> I think the issue here is that everyone is seeing Swift as *they* intend to 
>> use it. For App Devs, exhaustive switches are nice, which means they really 
>> are fighting tooth and nail to keep them. I understand that. But I’m also 
>> trying to keep my mind open for “what happens to an app I compiled in iOS 15 
>> that I compiled for iOS 11?” And this gives me pause. I can’t ask Apple or 
>> any other library author to be completely knowledgable about every case in 
>> the future, and to audit every line of code and manually give non-exhaustive.
>> 
>> Why do people want “exhaustive” to be the default?
>> Because we like things as they are.
> 
> No, because it makes sense to make common things easy and uncommon things 
> possible. 
> 
>> Because we like not having to consider edge cases. Because we want to 
>> imagine that will give framework developers the control to make our lives 
>> difficult because they’ll just be lazy and make our lives hard by not 
>> annotating. And this certainly is a concern. But I think a larger concern is 
>> breaking apps left, right and centre, or not being able to extend frameworks 
>> because an earlier developer on a project made an oversight.
> 
> This happens all the time: Apple deprecates APIs and asked developers to use 
> new ones. If a library writer does not run (the as-yet hypothetical ) library 
> lint, not participate in thorough code reviews,…, they can simply create a 
> new non-exhaustive enum and deprecate the old one. Yes, there will be some 
> redundant function calls for a while, but again, similar things happen, even 
> in APIs like Apple’s, that (one hopes, at least) are thoroughly reviewed. It 
> is not the end of the world to deprecate and migrate APIs. You  may remember 
> garbage collected Objective-C, the change that “viewWillAppear” suddenly was 
> not called when it used to be in iOS. We all survived the elimination of GC 
> and moving our view initialization code. Libraries and developers can survive 
> mistakes and improvements.
> 
> ABI stability does not require foolproof, immutable, ABIs. In essence, it is 
> just a guarantee that the build system won’t require rebuilds if library 
> source code stays the same, or is added to, not that applications will never 
> have to be 

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

[Félix Cloutier via swift-evolution]

I found that for Sequence, but Sequence is far from the only protocol with 
default implementations, and not all of them have maintainers willing to write 
and update documentation to the degree that Apple will.

Félix

> Le 14 sept. 2017 à 15:10, Kyle Murray  a écrit :
> 
> 
>> However, I find that I'm having trouble figuring out what I get for free 
>> when I implement a protocol. In principle, I like conditional conformances 
>> and synthesized implementation of protocol methods, but I find that they 
>> both make it harder to figure out what I need to implement, and what are 
>> going to be the performance characteristics of methods that I choose to not 
>> implement.
> 
> 
> If you're thinking specifically about the standard library, the documentation 
> for protocols like Sequence shows whether a member is required, and whether 
> it provides a default implementation.
> 
> https://developer.apple.com/documentation/swift/sequence#2923865 
> 
> 
> Have you noticed that before, or is it still tricky to find requirements 
> given the presentation?
> 
> -Kyle

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

Re: [swift-evolution] Problems with generics - should be fixed for Xcode 9?

[Félix Cloutier via swift-evolution]

I always thought that this was a bug, but I can't find it on bugs.swift.org, so 
I'd love to know if it's meant to stay this way or not.

> Le 16 sept. 2017 à 06:32, Joanna Carter via swift-evolution 
>  a écrit :
> 
> Greetings
> 
> Old chestnut, sort of partially solved but still problems.
> 
> Now we can nest types in generic types, what I want is :
> 
> class Event
> {
>  class Args
>  {
>public static let empty = Args() // error : Static stored properties not 
> supported in generic types
>  }
> }
> 
> But the static let is not directly in the generic class.
> 
> So, I end up doing another convoluted workaround in the shape of :
> 
> class Event
> {
>  class Args
>  {
>public static var empty: Args
>{
>  return Args()
>}
>  }
> }
> 
> The main difference is that I have to create a new instance on every call to 
> Args.empty instead of returning the same one.
> 
> Is this an oversight or as intended, with the hope of fixing it in a future 
> version
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> ___
> 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

[Rod Brown via swift-evolution]

> On 17 Sep 2017, at 4:35 am, Christopher Kornher  wrote:
> 
>> On Sep 16, 2017, at 11:28 AM, Christopher Kornher via swift-evolution 
>> > wrote:
>> 
>> 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.

I think the same logic goes both ways: If a library author can’t remember to 
declare exhaustive enums as such, they will probably forget many more important 
aspects of creating a library.

The problem here is fundamental: Exhaustive is a guarantee. A guarantee should 
require action. Non-Exhaustive guarantees nothing. It makes you safer. That is 
all.

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

I personally am an “ordinary” application developer.

I think the issue here is that everyone is seeing Swift as *they* intend to use 
it. For App Devs, exhaustive switches are nice, which means they really are 
fighting tooth and nail to keep them. I understand that. But I’m also trying to 
keep my mind open for “what happens to an app I compiled in iOS 15 that I 
compiled for iOS 11?” And this gives me pause. I can’t ask Apple or any other 
library author to be completely knowledgable about every case in the future, 
and to audit every line of code and manually give non-exhaustive.

Why do people want “exhaustive” to be the default? Because we like things as 
they are. Because we like not having to consider edge cases. Because we want to 
imagine that will give framework developers the control to make our lives 
difficult because they’ll just be lazy and make our lives hard by not 
annotating. And this certainly is a concern. But I think a larger concern is 
breaking apps left, right and centre, or not being able to extend frameworks 
because an earlier developer on a project made an oversight.

Its in everyone’s best interest to think before we put handcuffs on, no matter 
how painful that is. Even if that means you make apps where you just write 
“default: fatalError(“I don’t handle unreachable defaults”)"

And lets be clear: Swift isn’t an app development language. It also isn’t a 
framework development language. It’s a multipurpose language designed to Take 
Over The World™. This means we need to think holistically about what is better 
for everyone. Not just ourselves.

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

The Swift team have fundamentally opposed such pushes for “compiler modes” for 
a long time. I don’t expect they will embrace them now, nor do I 

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

[Benjamin G via swift-evolution]

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.

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

[swift-evolution] Question about async await

[Trevör ANNE DENISE via swift-evolution]

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"
2) Here (with async bar function), if bar() takes some time to execute, 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

Re: [swift-evolution] Enums and Source Compatibility

[Jonathan Hull via swift-evolution]

> On Sep 16, 2017, at 11:35 AM, Christopher Kornher via swift-evolution 
>  wrote:
> 
> 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.

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

Re: [swift-evolution] Enums and Source Compatibility

[Jonathan Hull via swift-evolution]

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.

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. 

It is a bigger overhaul, but I think it actually ends up being semantically 
simpler for the end user.  Basically, you can do the same types of things you 
can with classes... with the same syntax (just without the reference-type-ness).

It just so happens that this would also solve the problem of adding cases to 
(non-final) library enums, because switches of the enums would need to handle 
default/unexpected cases.  That is a very abstract/confusing problem for end 
users who don’t write libraries to understand though.  I think it is much 
easier to explain “final” as being the same as it is in classes, in that it 
prevents subclassing… which means you know what all the cases are.

More work (also more powerful), but semantically simpler. It just combines 
concepts we already know...

Thanks,
Jon


> On Sep 16, 2017, at 3:51 PM, 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