> 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