<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 07 Dec 2017, at 17:46, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <<a href="mailto:letanyan.a@gmail.com" class="">letanyan.a@gmail.com</a>> wrote:<br class=""><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class="m_-6257870125286603675Apple-interchange-newline">
</div>
<div class=""><br class=""><blockquote type="cite" class=""><div class="">On 07 Dec 2017, at 17:02, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-6257870125286603675Apple-interchange-newline"><div class=""><div class=""><br class=""><div class="gmail_quote"><div dir="auto" class="">On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family:Helvetica;font-size:12px;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" class=""><div class="">This seems marginally tolerable, but excessive.</div><div class=""><br class=""></div><div class="">Do we mark every usage of a type that can generate precondition failures or fatal errors for reasons other than “no such method?” No, we don’t.</div><div class=""><br class=""></div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""><div class="">fatalError shouldn’t be used excessively. API surface areas for these types are going to be massive (infinite technically). I assume many people are going to be writing a lot of code would these types and calling many methods and properties which would all essentially have a fatalError. Would you consider it good code if the majority of all your types had methods defined with fatalError calls.</div></div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">What is the basis for this claim? Probably the majority of standard library methods check preconditions and trap on failure. That is how I write my code as well.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br class="">
</blockquote></div></div>
</div></blockquote><br class=""></div></div><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class="">I’m talking specifically about fatalError not precondition. fatalError is something that goes out with production code while precondition is used for debugging. I think you would agree a shipped program that has many states of being unrecoverable is not a good design?</div></div></blockquote><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Precondition checks are active in release code. When a program encounters conditions that have no obvious recovery, trapping immediately is the only safe option; this is what Swift means by “safety” and the practice is encouraged.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><div class=""></div></div></blockquote></div></div><div dir="auto" class=""><br class=""></div>
</div></blockquote></div><br class=""><div class="">Apologies I was looking at the -Ounchecked flag reference.</div><div class="">My original argument about failing for no discernible reason still stands. precondition is a thought out check for a failing state. member lookup failures are going to be because things don’t exist for which you presumably expected to exist.</div></body></html>