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
}
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
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
