I agree with previous commenters. I very much support improved exhaustiveness analysis reducing the circumstances where a default clause is necessary. But I think requiring it unless the compiler can *prove* you have covered every possibility communicates important information that facilitates reasoning to readers / maintainers of the code.
> On Oct 3, 2016, at 12:41 PM, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> wrote: > > -1 from me as well. This suggestion falls into the same category as those > about making `else` optional after `guard`, which is repeatedly rejected. > Since code is read more often than written, explicit handling of the default > case never hurts and can increase clarity. Not having to write `default: > break` offers no help in writing correct code and IMO can't justify new > syntax or the changing of a well-known control statement. > > On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > -1 in general. I want smarter exhaustiveness analysis, but I don’t want to > be able to ignore cases that “can’t happen” (so say we, writer of bugs) when > they’re clearly in the domain of possible values that can be fed to a > switch-case. Exhaustiveness guarantees wellformedness of a program that does > happen to go wrong, and makes it much easier to verify the correctness of the > flow of control of the containing block because all points from the switch > must be covered. We also don’t have the type-level tools to convince the > checker to allow you to remove unreachable cases. If it’s really a problem > that you are writing default cases everywhere, just bailout in a fatal error > with a nice description. It never hurts. > > ~Robert Widmann > >> On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> I know that there is this note in Commonly Rejected Changes >> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md>: >> >> Remove support for default: in switch and just use case _:: default is >> widely used, case _ is too magical, and default is widely precedented in >> many C family languages. >> I really like to use the switch instead of if case for pattern matching, >> just because it’s neat block design. I do not want to remove default from >> switches because it’s a must have and powerful feature. >> >> I’d like to know why switches must be exhaustive. >> >> switch someValue { >> >> case …: >> // Do something >> >> case …: >> // Do something else >> >> default: >> () // useless nop; do nothing when no pattern matched >> } >> >> // VS: >> >> if case … { >> >> } else if case … { >> >> } else if case … { >> >> } // No need for `else` >> Can’t we make default optional, or at least on non-enum values? >> >> >> >> >> -- >> Adrian Zubarev >> Sent with Airmail >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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