Re: [swift-evolution] Enums and Source Compatibility

> > It’s really only an issue for people whose frameworks are used across > variously-distributed apps (your own, or other peoples’). The typical > dynamic library use-case. Those people already know to be careful, so why > make non-exhaustive the default for everybody? It’s a fair point. > > Get

Re: [swift-evolution] Retroactive protocol inheritance

This is mentioned in the Generics Manifesto as "Conditional Conformances via Protocol Extensions": < https://github.com/apple/swift/blob/master/docs/GenericsManifesto.md#conditional-conformances-via-protocol-extensions > While it would be a very powerful and useful feature, it's apparently also ve

[swift-evolution] Retroactive protocol inheritance

With Swift 4 out, I’ve started using the numeric protocols quite a bit, and they are great! One thing I find myself wishing for is a protocol that extends Numeric while also allowing division—a Field protocol, if you will. I have implemented several algorithms generically over FloatingPoint becaus

Re: [swift-evolution] Question about async await

Good article. Thanks. Em sex, 22 de set de 2017 às 14:24, Kenny Leung via swift-evolution < swift-evolution@swift.org> escreveu: > Here’s more stuff I found on how this could work. It’s slowly becoming > less murky to me. > > http://blog.stephencleary.com/2013/11/there-is-no-thread.html > > -Kenny

Re: [swift-evolution] Question about async await

Here’s more stuff I found on how this could work. It’s slowly becoming less murky to me. http://blog.stephencleary.com/2013/11/there-is-no-thread.html -Kenny > On Sep 20, 2017, at 7:19 AM, Adam Kemp via swift-evolution > wrote:

Re: [swift-evolution] [Discussion] Resources

This is one of the big blockers for our iOS team in moving to SwiftPM. Not all of our internal libraries have resources, but at the very least our UI libraries contain xibs and some images, and more commonly our libraries at least have a Localizable.strings file. We've started moving over to r

Re: [swift-evolution] [Discussion] Resources

I have never once felt a need to distribute a library with an icon On Fri, Sep 22, 2017 at 10:43 AM, Karl Wagner via swift-evolution < swift-evolution@swift.org> wrote: > > > On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution < > swift-evolution@swift.org> wrote: > > > > Hi everybody! > >

Re: [swift-evolution] [Discussion] Resources

> On 21. Sep 2017, at 18:51, Karl Wagner via swift-evolution > wrote: > > Hi everybody! > > I’m really happy that Swift 4 is out, and it’s great that there’s already so > much active discussion about Swift 5 (concurrency, etc). I find I’m running > in to language roadblocks less and less, an

Re: [swift-evolution] Enums and Source Compatibility

> On 22. Sep 2017, at 17:21, Karl Wagner via swift-evolution > wrote: > >> >> On 21. Sep 2017, at 00:51, Rex Fenley via swift-evolution >> mailto:swift-evolution@swift.org>> wrote: >> >> Hi Jordan, >> >> I've been keeping up with most of the discussion since I last emailed about >> my conc

Re: [swift-evolution] Enums and Source Compatibility

> On 21. Sep 2017, at 00:51, Rex Fenley via swift-evolution > wrote: > > Hi Jordan, > > I've been keeping up with most of the discussion since I last emailed about > my concern about making nonexhaustive the default mode for enums. So far I am > still strongly in the camp of exhaustive by de

Re: [swift-evolution] Different types for getter and setter

It would be awesome to have the property behaviours proposal being resurrected. I'm the weird one that would like to have "set only" properties, but obviously adding them to the language doesn't make much sense unless we have a bigger tool to make this kind of stuff. On Tue, Sep 19, 2017 at 11:52