>> 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…
I would tend to agree, which is part of why I think “future” doesn’t make sense and should stay in the Alternatives Considered but dropped. I think the point of extensible/nonexhaustive enums is precisely so we think about what are appropriate defaults, otherwise we would just add a “fatalError” into the compilation of Switches when no case is caught, and that would be the end of this proposal. In your example, is there a fair default fallback for this behaviour? Just choose a reasonable default date style and run with it as an appropriate fallback. 95% of the time, there are more reasonable solutions than crashing just because your text on screen line breaks weirdly. Only in occasions where either a) the default case makes no sense, or b) I really cannot use a fair default in this calculation, would I fatalError in this case. This would seem to me to be far more reasonable than “I can’t hard code it, stop the presses, crash everything, blow up the world” for most cases. Additionally, it would seem wise for a framework developer to annotate why they marked their enum as “nonexhaustive” to give some hint as to a reasonable handling of these cases, where it’s not clearly evident. > >> >> 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).
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
