[swift-evolution] [Proposal] Rename fatalError() API

[Sean Heber]

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 <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution