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 old

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 it's worth, the original versio

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

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 >> mailto:swift-evolut

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 > > wrote: >>> On Jan 4, 2018, at 10:31 PM, Xiaodi Wu via s

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 have a couple of > remaining

[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] [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 5, 2018 at 01:56 Jonathan Hull > > wrot

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.) https://git

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 > wrote: > >> Hi, Dave. You're right, all these points are

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 is only a problem 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 member

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 < >> swift-evolution@swift.org> wrote: >> >> >> On Fri, Jan 5, 2018 at 00:21

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 they > switch over

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 treat

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 enums is a good important f

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 Ma

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 something that should be conside

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 >> mailto:swift-evolution@swift.org>> wrote: > >> >> On Fri, Jan 5, 2018 at 00:21 Cheyo Jimenez >