I assume this is meant to be a joke? I don’t really get it. I use fatalError() often to catch mistakes I make later. It works very well for this and I’ve got into the habit of using it whenever I want to make damn sure my assumptions don’t get violated in the future. I also use precondition() constantly for this, but fatalError() has the very handy property of getting rid of the need to return a dummy value for functions that are meant to be overridden by a subclass, for example, or have complex switch statements that the compiler cannot prove to be complete.
l8r Sean > On Jan 6, 2017, at 3:53 PM, D. Felipe Torres via swift-evolution > <[email protected]> wrote: > > Introduction > > This function was introduced along others to halt execution of the running > instance to convey a state of affairs without resolution whatsoever. This > proposal lays the case that this function is not performing its stated > mission and attempts to help it come forward with its real intentions in > order to have a better conformance with the Swift naming guidelines. > > Motivation > > The main motivation to this proposal is to act as a catalyst for the > community to acknowledge the identity of this function and stay true to the > values bestowed upon us by Chris Lattner and his disciples, the Core Team. > > As evidenced in a quick search over a the great repository of Gitxandria we > are witness to several examples of the true calling of fatalError(). A few > examples are cited below for those who receive this letter in print. > > //Example 1 > switch result { > case .Success(let response): > print("Today's horoscope is: \(response)") > break > case .Failure(let error): > fatalError("Present \(error) to user") > } > > //Example 2 > func cell(at index: Int) -> Cell { > if (0..<10).contains(index) { > return Cell(horses[index]) > } > if (10..<20).contains(index) { > return Cell(ponies[index]) > } > > fatalError("Unicorns go here") > } > > As seen in the previous examples, the calling of fatalError is seldom that. > > Proposed solution > > The proposed solution is to rename `fatalError(_ message: String)` to > `willItToCompile(finishLater: String)` to convey the right terminology for > it's calling. Here are the revised examples: > > //Example 1 > switch result { > case .Success(let response): > print("Today's horoscope is: \(response)") > break > case .Failure(let error): > willItToCompile(finishLater: "Present \(error) to user") > } > > //Example 2 > func cell(at index: Int) -> Cell { > if (0..<10).contains(index) { > return Cell(horses[index]) > } > if (10..<20).contains(index) { > return Cell(ponies[index]) > } > > willItToCompile(finishLater: "Unicorns go here") > } > > As you can see, the intent of this code is clearer and the true meaning of > the developer is revealed. > > Source Compatibility > > This is an important issue, we must stand to this shameful tradition and > break it. Functions deserve to be called by their purest and true identity, > we are still within the window of source breaking changes so there is no > better time, the time is now! > > Alternatives considered > > Keep calling it the same shameful name to an innocent function who has done > nothing but bring us joy to our development cycles and help us throughout > hard times. > > > ------ > Merry Christmas and > Happy New Year > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
