[swift-evolution] Enums and Source Compatibility

[Vladimir.S]

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