<div>On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <<a href="mailto:letanyan.a@gmail.com">letanyan.a@gmail.com</a>> wrote:<br><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"><div><br class="m_-6257870125286603675Apple-interchange-newline">
</div>
<div><br><blockquote type="cite"><div>On 07 Dec 2017, at 17:02, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-6257870125286603675Apple-interchange-newline"><div><div><br><div class="gmail_quote"><div dir="auto">On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></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"><div><br><blockquote type="cite"><div><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"><div>This seems marginally tolerable, but excessive.</div><div><br></div><div>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><br></div></div></div></blockquote></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div><div>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"><br></div><div dir="auto">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>
</blockquote></div></div>
</div></blockquote><br></div></div><div style="word-wrap:break-word;line-break:after-white-space"><div>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"><br></div><div dir="auto">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"><div></div></div></blockquote></div></div><div dir="auto"><br></div>