Re: [swift-evolution] Enums and Source Compatibility

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

Re: [swift-evolution] Enums and Source Compatibility

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

[swift-evolution] Enums and Source Compatibility

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

Re: [swift-evolution] Subscripts assignable to closure vars

> On Sep 15, 2017, at 13:00, John McCall via swift-evolution > wrote: > >> >> On Sep 15, 2017, at 3:45 PM, Joanna Carter via swift-evolution >> > wrote: >> >> Just came across this. >> >> I want to be

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

i think in general the API docs could be organized in a more helpful way. On Fri, Sep 15, 2017 at 3:30 PM, Kyle Murray via swift-evolution < swift-evolution@swift.org> wrote: > > However, I find that I'm having trouble figuring out what I get for free > when I implement a protocol. In principle,

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

> 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

Re: [swift-evolution] Enums and Source Compatibility

> On Sep 14, 2017, at 20:59, Chris Lattner wrote: > > >> On Sep 13, 2017, at 12:17 PM, Jordan Rose via swift-evolution >> > wrote: >> >> Proposal updated, same URL: >>

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

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

Re: [swift-evolution] Subscripts assignable to closure vars

> On Sep 15, 2017, at 3:45 PM, Joanna Carter via swift-evolution > wrote: > > Just came across this. > > I want to be able to hold onto the reference to a subscript "method" for > later use. > > Assigning the subscript to a var in the init of a type raises a

[swift-evolution] Subscripts assignable to closure vars

Just came across this. I want to be able to hold onto the reference to a subscript "method" for later use. Assigning the subscript to a var in the init of a type raises a segmentation fault. Should this - could this - be allowed? protocol DataProvider { associatedtype ItemType