> On Dec 23, 2017, at 3:19 AM, Thomas Roughton via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> Looking at the feedback to this proposal, it looks like a common thread is
> people wanting to make sure they’re notified when new cases are introduced
> (the ‘future’ keyword’). However, if I’m understanding correctly, the
> resistance to adding such a keyword is that it becomes complicated when
> there’s e.g. both a ‘future’ and ‘default’ case, with two different sets of
> behaviour. I missed the earlier discussion around this proposal so forgive me
> if this is a concept that’s been brought up before.
>
> A possible alternative would be to build on that concept, but place the
> weight on the ‘switch’ statement. I’d propose something like the following
> for a non-exhaustive enum that currently has cases ‘a’ and ‘b’.
>
> @complete switch nonExhaustiveEnum {
> case a:
> print(“a”)
> case b:
> print(“b”)
> future:
> break
> }
The `final switch` mentioned in the proposal seems like a good solution to this
problem.
http://dlang.org/statement.html#FinalSwitchStatement
>
> where the semantics would be that in a @complete switch statement, all known
> cases must be explicitly switched. The ‘future’ case would have the same
> run-time semantics as a default case for a non-@complete switch (I’m sticking
> with the ‘future’ name here since I think it’s clearer, but continuing to use
> ‘default’ would also work). If the external library is modified and the user
> code is then recompiled, Swift would error at compile time saying that there
> were unhandled cases.
>
> Obviously, this still requires adding keywords to the language and some
> degree of complexity, but does mean the behaviour change is isolated to a
> fairly simple compile-time check.
>
> Thomas
> _______________________________________________
> 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
