<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>On Dec 23, 2017, at 3:19 AM, Thomas Roughton via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span>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.</span><br><span></span><br><span>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’.</span><br><span></span><br><span>@complete switch nonExhaustiveEnum {</span><br><span> case a:</span><br><span> print(“a”)</span><br><span> case b:</span><br><span> print(“b”)</span><br><span> future:</span><br><span> break</span><br><span>}</span><br></div></blockquote><div><br></div>The `final switch` mentioned in the proposal seems like a good solution to this problem. <div><div><a href="http://dlang.org/statement.html#FinalSwitchStatement">http://dlang.org/statement.html#FinalSwitchStatement</a></div><div><br></div><div><br><blockquote type="cite"><div><span></span><br><span>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.</span><br><span></span><br><span>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.</span><br><span></span><br><span>Thomas</span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></div></body></html>