[swift-evolution] The Non-Exhaustive Enums proposal kills one of Swift's top features - change proposal

Rod Brown rodney.brown6 at icloud.com
Fri Dec 22 06:09:02 CST 2017

I think you make a fair point here - either case is currently untestable in a non-exhaustive enum.

Perhaps this pushes harder on the “future” case and a way we can test this in Unit Tests when we @testable import other frameworks to simulate an additional case.

> On 22 Dec 2017, at 5:36 am, Kevin Nattinger via swift-evolution <swift-evolution at swift.org> wrote:
>>> [...]
>> Hi, Nacho. This is discussed in the proposal as "'future' cases" under "Alternatives considered". The main blocker was that such a case becomes untestable (see also "Testing invalid cases"). That didn't seem like an acceptable state of affairs to me or to the people I had originally discussed the proposal with, but maybe the community feels differently?
> As you state in the proposal, using `default` instead is exactly as untestable, in exactly the same way. Using that as an argument against future but not default is disingenuous. And default additionally introduces the enormous issue of killing compile-time safety, while future does not..
>> I would love if someone could think of something I haven't yet; by no means do I think I'm the only one who can have ideas in this space.
>> Jordan
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171222/fe14830a/attachment.html>

More information about the swift-evolution mailing list