fatalError has defaults for its arguments so it can be used as a nullary unreachable function already.
~Robert Widmann > On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution > <swift-evolution@swift.org> wrote: > > Instead of using `fatalError(_:file:line:)` in `default` cases, would a > public `unreachable()` function be more efficient? > > e.g. <https://github.com/apple/swift/pull/2379 > <https://github.com/apple/swift/pull/2379>> > > -- Ben > >> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> -1 from me too. >> >> Avoiding having to write "default: break" isn't a good justification to >> introduce new syntax. It would make the understanding of case switches >> harder without providing any real benefit for the syntax bloat. >> >> João Pinheiro >> >> >>> On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution >>> <swift-evolution@swift.org <mailto: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 > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
