> On Oct 2, 2017, at 2:10 PM, Jordan Rose via swift-evolution > <[email protected]> wrote: > > I don't think I have anything to say on this topic that I haven't already > said: > > - Switching exhaustively over non-exhaustive enums is uncommon.
[Citation Needed] As I pointed out in my email in the review thread, there are a significant number of enums in Apple's own frameworks that are commonly switched over exhaustively. Additionally, uncommon or not, when this does come up, it's an enormous issue. Big enough that "it's uncommon" isn't sufficient justification for ignoring it. > - It's more important for a library to build without errors when its > dependencies change than it is to get an error. (This doesn't apply to > warnings, though.) Not sure I agree with this. In fact I think if anything it's more important for libraries than clients. Especially in the case of a new enum value it should support but doesn't. > - Untestable code is dangerous, so having a language feature inherently for > untestable code seems bad. A `default` case in the same situation is just as untestable, as you even point out in the proposal. Why do you keep using this as an argument against `future` but not `default`? > > None of that negates your points; it just affects the weighting of whether or > not 'future' or 'switch!' is worth it. However, I've added a link to your > email in the proposal proper so that the Core Team and wider review audience > have a chance to decide differently. > > Jordan > > >> On Oct 2, 2017, at 08:25, Vladimir.S via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> Sorry to bother, but I still can't understand how the proposed change >> *without* a 'future' case in switch will change our life and what would be >> our steps to support our code and to not make our code buggy. >> If I misunderstand something - sorry, please point me on this and I hope >> this also help some one like me to understand the subject better. >> >> For example. I use OAuth2 framework, built by Carthage. Did add the >> OAuth2.framework to my project. >> >> Currently OAuth2 exports 'public enum OAuth2Error'. I do have a place in my >> code where I switch on each case of such error instance to do my best with >> error: generate detailed description for user, other additional steps >> depending on error. >> >> Will/should author of OAuth2 make OAuth2Error 'exhaustive' ? No. >> Will new cases be added to that enum in future: Most likely Yes. >> Do I need to switch on each case in my code? Yes. >> Can I currently rely on compiler to keep my error processing in sync with >> error cases defined in framework? Yes. >> Can new cases appear in *run-time* of my app: NO, framework in embedded. >> Will I be able to rely on compiler after the proposed change? No?! >> What should I do to keep my switch in sync with OAuth2Error cases after each >> update of OAuth2 library(framework)? Manually check if new cases are added?! >> Configure lint/other tools to help me with this?! >> >> What I, as a developer, as a consumer of framework, need - is a way to >> exhaustively switch on *some* external non-exhaustive enums *at the moment >> of compilation*. And we can accomplish this only(AFAICT) with 'future' case >> in 'switch'. >> In case we'll have 'future' case my life will not be *worse* for this >> project : I'll add it to my switch and still can receive help from compiler >> to keep switch exhaustive. >> >> I don't support the opinion that we can't introduce 'future' case because of >> we can't test it: >> >> 1. Not being able to keep my switch exhaustive when I need this, and so not >> being able to provide users of my app with best experience - IMO is worse. >> 2. In my particular example, 'future' case will be *never* called, if I >> understand correctly. >> 3. If switch on non-exhaustive enum is exhaustive by fact, we can't test the >> 'default' branch also. So, 'future' is in same position here with 'default' >> 4. I believe if we'll decide we need 'future' case - we can suggest a way to >> call code in that case during the test process. >> >> Seems like for embedded frameworks we should apply the same rules(regarding >> enums) as for sources, as we compile the app with concrete binary of >> framework and there just can't be new cases in enums. No? >> >> Thank you for your time. >> Vladimir. >> >> On 01.10.2017 3:00, Slava Pestov via swift-evolution wrote: >>>> On Sep 30, 2017, at 4:46 PM, Karl Wagner via swift-evolution >>>> <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>> wrote: >>>> >>>> I don’t see how it’s impractical. Quite a lot about how the library should >>>> be optimally compiled and used depends on what you plan to do with it. If >>>> it’s going to be installed somewhere private and you can guarantee clients >>>> will always have the latest version, you can assume all data types are >>>> final, @_fixed_layout, @exhaustive, whatever (essentially in-module). An >>>> example of that would be a library embedded inside an iOS app bundle. If >>>> it’s going to be installed somewhere public and expose some API (like >>>> Apple’s frameworks), then you’re going to have to think about binary >>>> compatibility. >>>> >>>> That also means that in-app libraries are optimised as much as they can >>>> be, and that resilience-related changes on the declaration side can be >>>> limited to the limited set of Swift developers who truly have to care >>>> about that. >>> We do plan on exposing an -enable-resilience flag which basically does what >>> you describe. When a library is built without -enable-resilience, all types >>> are assumed to be fixed layout, etc. However, we don’t want language flags >>> to change language semantics, so exhaustive/nonexhaustive still make sense >>> even when building without resilience, I think. When you switch over a >>> non-exhaustive enum that came from a library built without >>> -enable-resilience, the compiler can still use the most efficient possible >>> access pattern and assume that no new cases will be introduced, but the >>> type checker would still require a default case to be present. The >>> optimizer can then basically strip out the default case as dead code. >>> Slava >>>> >>>> - Karl >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
