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@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@swift.org <mailto: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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
