On Thu, Dec 7, 2017 at 09:15 Letanyan Arumugam <letanya...@gmail.com> wrote:
> > > On 07 Dec 2017, at 17:02, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > > On Thu, Dec 7, 2017 at 00:37 Letanyan Arumugam via swift-evolution < > swift-evolution@swift.org> wrote: > >> >> This seems marginally tolerable, but excessive. >> >> 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. >> >> 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. >> > > 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. > >> >> > 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? > 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. >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
