If you're as concerned about code size as stdlib is then I'd be interested to know what you're writing! These are paths to terminate your application which is necessarily going to be orders of magnitude larger than stdlib is and so can "eat the cost" of a few more global db's, some loads, and a call or three.
~Robert Widmann 2016/10/03 15:14、Ben Rimmington <[email protected]> のメッセージ: > 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 <[email protected]> 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 >>> <[email protected]> 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> >>> >>> -- Ben >>> >>>> On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution >>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>> <[email protected]> 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 >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> I know that there is this note in Commonly Rejected Changes: >>>>>>> >>>>>>> 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 [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
