<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">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. </div><div style="direction: inherit;"><br></div>~Robert Widmann</div><div><div style="direction: inherit;"><br></div>2016/10/03 15:14、Ben Rimmington <<a href="mailto:me@benrimmington.com">me@benrimmington.com</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><div class="">Yes, but <<a href="https://github.com/apple/swift/pull/2379" class="">https://github.com/apple/swift/pull/2379</a>> uses `Builtin.unreachable()` because it:</div><div class=""><br class=""></div><div class=""></div><blockquote type="cite" class=""><div class="">"Saves a bit of code size in the standard library by eliminating some</div><div class="">static strings and function calls."</div></blockquote><div class=""><br class=""></div><div class="">Clang has both `__builtin_unreachable()` and `llvm_unreachable()`:</div><div class=""><br class=""></div><div class=""><<a href="http://clang.llvm.org/docs/LanguageExtensions.html#builtin-unreachable" class="">http://clang.llvm.org/docs/LanguageExtensions.html#builtin-unreachable</a>></div><div class=""><br class=""></div><div class=""><<a href="http://llvm.org/docs/CodingStandards.html#assert-liberally" class="">http://llvm.org/docs/CodingStandards.html#assert-liberally</a>></div><div class=""><br class=""></div><div class="">-- Ben</div></div><br class=""><div><blockquote type="cite" class=""><div class="">On 3 Oct 2016, at 20:01, Robert Widmann <<a href="mailto:devteam.codafi@gmail.com" class="">devteam.codafi@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">fatalError has defaults for its arguments so it can be used as a nullary unreachable function already.<div class=""><br class=""></div><div class="">~Robert Widmann<br class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 3, 2016, at 2:50 PM, Ben Rimmington via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">Instead of using `fatalError(_:file:line:)` in `default` cases, would a public `unreachable()` function be more efficient?</div><div class=""><br class=""></div><div class="">e.g. <<a href="https://github.com/apple/swift/pull/2379" class="">https://github.com/apple/swift/pull/2379</a>></div><div class=""><br class=""></div><div class="">-- Ben</div></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 3 Oct 2016, at 18:50, João Pinheiro via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-1 from me too.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">João Pinheiro</div><div class=""><br class=""></div><div class=""><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 03 Oct 2016, at 19:41, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">-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.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Oct 3, 2016 at 11:39 AM, Robert Widmann via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class="">-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.</div><div class=""><br class=""></div><div class="">~Robert Widmann</div><br class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="h5"><div class="">On Oct 3, 2016, at 6:14 AM, Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="m_237158121097854913Apple-interchange-newline"></div></div><div class=""><div class=""><div class="h5"><div class="m_237158121097854913bloop_markdown" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><p style="margin:15px 0px" class="">I know that there is this note in<span class="m_237158121097854913Apple-converted-space"> </span><a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" style="color:rgb(65,131,196);background-color:inherit;text-decoration:none" target="_blank" class="">Commonly Rejected Changes</a>:</p><blockquote style="margin:15px 0px;border-left-width:4px;border-left-style:solid;border-left-color:rgb(221,221,221);padding:0px 15px;color:rgb(119,119,119)" class=""><div style="margin:0px" class="">Remove support for<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">default</code>: in switch and just use<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">case _:</code>:<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">default</code><span class="m_237158121097854913Apple-converted-space"> </span>is widely used,<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">case _</code><span class="m_237158121097854913Apple-converted-space"> </span>is too magical, and default is widely precedented in many C family languages.</div></blockquote><p style="margin:15px 0px" class="">I really like to use the<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">switch</code><span class="m_237158121097854913Apple-converted-space"> </span>instead of<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">if case</code><span class="m_237158121097854913Apple-converted-space"> </span>for pattern matching, just because it’s neat block design. I do not want to remove<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">default</code><span class="m_237158121097854913Apple-converted-space"> </span>from switches because it’s a must have and powerful feature.</p><p style="margin:15px 0px" class="">I’d like to know why switches must be exhaustive.<span class="m_237158121097854913Apple-converted-space"> </span></p><pre style="margin:15px 0px;font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(204,204,204);overflow:auto;padding:4px 8px;word-break:normal;word-wrap:normal" class=""><code class="m_237158121097854913swift" style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:0px;margin:0px;padding:0px;word-break:normal;word-wrap:normal">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`
</code></pre><p style="margin:15px 0px" class="">Can’t we make<span class="m_237158121097854913Apple-converted-space"> </span><code style="font-family:Menlo,Consolas,'Liberation Mono',Courier,monospace;font-size:10pt;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;background-color:rgb(248,248,248);color:inherit;border:1px solid rgb(234,234,234);margin:0px 2px;padding:0px 5px;word-break:normal;word-wrap:normal" class="">default</code><span class="m_237158121097854913Apple-converted-space"> </span>optional, or at least on non-enum values?</p><div style="margin:15px 0px" class=""><br class="m_237158121097854913webkit-block-placeholder"></div></div><div class="m_237158121097854913bloop_original_html" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(254,254,254)"><div id="m_237158121097854913bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;margin:0px" class=""><br class=""></div><br class=""><div id="m_237158121097854913bloop_sign_1475484692455256832" class="m_237158121097854913bloop_sign"><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div></div></div></div></div></blockquote></div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></div></blockquote></div></div></div></div></div></blockquote></div></div></blockquote></body></html>