Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 5, 2018, at 4:42 AM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 03:11 Jonathan Hull > wrote: >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu > > wrote: >> >> >> On Fri, Jan

[swift-evolution] Questions about non-exhaustive enums

I love the revision to the proposal , but I have a couple of remaining questions that don't seem to be addressed in the doc and I'm curious about: - What happens if a library maintainer adds a new case to a *@frozen* enum? - What happens

Re: [swift-evolution] why cant you initialize BinaryFloatingPoint from BinaryInteger?

Right, SE-0067 included that initializer with the caveat that implementation wouldn't be possible until the integer protocols were revised. As far as I can see, that makes this a fix that wouldn't need further SE discussion. (The generic init(exactly:) needs an implementation, too.)

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On 5. Jan 2018, at 15:52, Swift via swift-evolution > wrote: > > Hi Jordan, > > Thanks for your thoughtful reply. Comments inline... > > Sent from my iPad > > On Jan 4, 2018, at 5:37 PM, Jordan Rose >

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Clarifications here only! I don't think I have too much more to convince you; at this point we've looked at the same landscape and come to different conclusions. Although I think I'm more optimistic than you are about being able to build a binary compatibility checker. > On Jan 5, 2018, at

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

Oh, I see… the case would silently change from unexpected to default if they were both included. Hmm. I will have to think on this more. Thanks, Jon > On Jan 5, 2018, at 3:17 PM, Jordan Rose wrote: > > > >> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 5, 2018, at 00:11, Jonathan Hull via swift-evolution > wrote: > >> >> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu > > wrote: >> >> >> On Fri, Jan 5, 2018 at 01:56 Jonathan Hull >

Re: [swift-evolution] Questions about non-exhaustive enums

This is the same issue as when a library maintainer changes a class from open to closed. > On Jan 5, 2018, at 10:54 AM, Ignacio Soto via swift-evolution > wrote: > > I love the revision to the proposal > , but I

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 3, 2018, at 00:54, Jason Merchant via swift-evolution > wrote: > > Is it hard to imagine that most everyone can get what they want and keep the > syntax clean and streamlined at the same time? Without any "@" signs or other > compiler hints? For what

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

At this point I think it might be useful to outline how binary compatibility works for Objective-C on Apple platforms right now. As an app developer I’m not intimately familiar with what happens when you run an app compiled with the iOS 10 SDK on iOS 11. Are there just runtime checks to call

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Code that ends up running in a default case somewhere in one of the several places you switch over that enum that you forgot about... well, it may not break source code compatibility, but it may introduce subtle bugs... submarine bugs. Sent from my iPhone > On 5 Jan 2018, at 08:11, Goffredo

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> Le 5 janv. 2018 à 09:11, Goffredo Marocchi via swift-evolution > a écrit : > > I feel like this change will make the life easier for library authors, but > risks making it easier and easier to make mistakes in apps using the > libraries: exhaustive switching over

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> On 5 Jan 2018, at 00:38, Jordan Rose via swift-evolution > wrote: > > Furthermore, the old code needs to continue working without source changes, > because updating to a new SDK must not break existing code. (It can introduce > new warnings, but even that is

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

> On Jan 4, 2018, at 11:02 PM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 01:56 Jonathan Hull > wrote: >> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Fair concerns Gwendal, but why can’t the default in these cases be just exhaustive / frozen unless the library developer explicitly marks it as “unfrozen/non exhaustive” and the compiler can warn the users when they switch over it instead of throwing an error by default (the user can still

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

> Le 5 janv. 2018 à 10:33, Goffredo Marocchi a écrit : > > Fair concerns Gwendal, but why can’t the default in these cases be just > exhaustive / frozen unless the library developer explicitly marks it as > “unfrozen/non exhaustive” and the compiler can warn the users when

Re: [swift-evolution] DynamicMemberLookup proposal: status update

Have you seen John Holdsworth's experiments? -- Ben > On 4 Jan 2018, at 20:52, Chris Lattner wrote: > > Hi everyone, > > With the holidays and many other things behind us, the core team had a chance > to talk about python interop + the dynamic

Re: [swift-evolution] [Review] SE 0192 - Non-Exhaustive Enums

On Fri, Jan 5, 2018 at 03:11 Jonathan Hull wrote: > On Jan 4, 2018, at 11:02 PM, Xiaodi Wu wrote: > > > On Fri, Jan 5, 2018 at 01:56 Jonathan Hull wrote: > >> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via swift-evolution < >>

Re: [swift-evolution] [swift-evolution-announce] [Review] SE 0192 - Non-Exhaustive Enums

Hi Jordan, Thanks for your thoughtful reply. Comments inline... Sent from my iPad > On Jan 4, 2018, at 5:37 PM, Jordan Rose wrote: > > Hi, Dave. You're right, all these points are worth addressing. I'm going to > go in sections. > >> This whole “unexpected case” thing