Re: [swift-evolution] Enums and Source Compatibility

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 {

Re: [swift-evolution] Enums and Source Compatibility

> 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

[swift-evolution] Question about async await

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

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

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

Re: [swift-evolution] Enums and Source Compatibility

> 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

Re: [swift-evolution] Question about async await

> 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

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

> 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

Re: [swift-evolution] Enums and Source Compatibility

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

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

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

Re: [swift-evolution] Enums and Source Compatibility

> 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

Re: [swift-evolution] Enums and Source Compatibility

> 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

Re: [swift-evolution] Enums and Source Compatibility

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

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

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

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

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

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

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

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

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)

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

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

Re: [swift-evolution] Enums and Source Compatibility

> 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

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

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>