Yes, but <https://github.com/apple/swift/pull/2379> uses `Builtin.unreachable()` because it:
> "Saves a bit of code size in the standard library by eliminating some > static strings and function calls." Clang has both `__builtin_unreachable()` and `llvm_unreachable()`: <http://clang.llvm.org/docs/LanguageExtensions.html#builtin-unreachable> <http://llvm.org/docs/CodingStandards.html#assert-liberally> -- Ben > On 3 Oct 2016, at 20:01, Robert Widmann <devteam.cod...@gmail.com> wrote: > > 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 <mailto: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
