> Am 21.12.2017 um 23:48 schrieb Andrew Bennett via swift-evolution
> <swift-evolution@swift.org>:
>
> Can you go into more detail about why the core team didn't like this?
> public enum HomeworkExcuse {
> case eatenByPet
> case thoughtItWasDueNextWeek
> default // NEW
> }
>
> To me this is very close to an ideal solution, it fixes ABI concerns, it has
> sensible defaults. If it was changed a little bit:
>
> public enum HomeworkExcuse {
> case eatenByPet
> case thoughtItWasDueNextWeek
> fallback unknown // NEW
> }
>
> Then I believe you would be able to have an exhaustive switch like this:
>
> switch thing {
> case eatenByPet: break
> case thoughtItWasDueNextWeek: break
> case unknown: break
> }
>
> Which would still allow compile-time errors if new cases are introduced,
> while providing a concise way to show something is not exhaustible.
>
> This would also support existing enums with "unknown" equivalent cases would
> be able to explicitly label those fields as fallback without needing to make
> large code changes.
>
> I see no reason why you shouldn't be able to use ".unknown", which should
> still allow this to be testable.
This is an extremely elegant solution which seems to solve all problems very
nicely!!
Yes, instead of marking the enum as non-exhaustive let’s just add a placeholder
case for future cases.
I’m very much in favor of this.
-Thorsten
>
> Thanks,
> Andrew
>
> On Tue, Oct 3, 2017 at 8:10 AM, Jordan Rose via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@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.
> - 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.)
> - Untestable code is dangerous, so having a language feature inherently for
> untestable code seems bad.
>
> 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@swift.org <mailto: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>
>>>> <mailto: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 <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <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
