+1 for everything Vladimir says - which is why I'm pushing for switch! (just like try!, etc.) which would preserve current behavior.
> On Oct 2, 2017, at 5:25 PM, Vladimir.S via swift-evolution > <swift-evolution@swift.org> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
