[swift-evolution] Enums and Source Compatibility

[Kevin Nattinger]

> On Oct 2, 2017, at 2:10 PM, Jordan Rose via swift-evolution <swift-evolution at swift.org> 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 <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org> <mailto:swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> _______________________________________________
>> 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>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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