> On 6 Sep 2017, at 2:31 pm, Charlie Monroe <[email protected]> wrote: >> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> I think what you’re really asking for here is the “future” case mentioned in >> the Alternatives Considered section. I think that Jordan makes a good point >> that this would result in untestable code, which is bad practice. While the >> lack of clear highlighting of non-exhaustive cases is undesirable, I think >> untestable code is a much larger problem here. > > This is generally the switch! that I've suggested listed in alternatives as > well - that generally brings current behavior. For a project that is > regularly maintained, I believe that this makes sense given that the enums > are only likely to change once a year at most (with new OS releases)…
I see the logic of this position, but it traps at cases which are unforeseen unrelated to OS releases. As this proposal notes, there are cases that Apple uses internal of their frameworks that they consider private may still be passed through your API. For example, if there was a new button type, and you enumerated all public types in your method, but UIKit had a private custom button type, you couldn’t catch on it, nor would you have any idea that it existed. This isn’t related to the release cycle timing, but you’re still going to start crashing despite the fact that you believe you’ve exhaustively handled all cases. Also, we need to be thinking bigger than just the Apple Ecosystem. While Swift started on the Mac and iOS, this is hardly guaranteed, nor are release timings. Also, just because the dynamic frameworks update at regular intervals now, doesn’t mean the same will happen on Linux, where a dynamically linked framework could just update without anyone knowing. Part of the consideration of ABI stability isn’t just for Apple to ship frameworks, but for anyone to ship frameworks that are not contained within the signed bundle of the application. It is short sighted to say “well, this works for us right now” in my opinion. Part of this discussion is to mature Swift away from these kinds of assumptions (Apple, Obj-C, etc). > >> >> Either way we need a way to handle forward compatibility for our code when >> cases get added to external frameworks, that much is clear. Swift is broken >> in regards to this, and we need to handle it somehow. I’m hoping you’re not >> suggesting that we just don’t make this change at all. We need this for >> forward compatibility for framework development with Swift. >> _________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
