[swift-evolution] Enums and Source Compatibility

[Charlie Monroe]

> On Sep 6, 2017, at 8:50 AM, Rod Brown <rodney.brown6 at icloud.com> wrote:
> 
> 
>> On 6 Sep 2017, at 2:31 pm, Charlie Monroe <charlie at charliemonroe.net <mailto:charlie at charliemonroe.net>> wrote:
>>> On Sep 6, 2017, at 5:44 AM, Rod Brown via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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.

Fully understood, though when you are in the middle of some calculation, you are unlikely to do anything by fatalError in the "future" case...

Imagine e.g. your DateFormatter and you get a new Style in the formatting - what do you do? Fallback on a different one? I personally would simply call fatalError in the future case anyway...

> 
> 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
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170906/e212632e/attachment.html>