Yeah, it was meant as a joke. I'm well aware of the uses you write about, I do that myself but felt like doing this piece based on the particular use case described in the "proposal"
I apologize for not stating it as such and maybe I should not have sent this here. On Fri, Jan 6, 2017 at 11:30 PM, Sean Heber <[email protected]> wrote: > 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 > > -- ++++++++++++++++++++++++++ Diego Torres. Phone (Mobile Germany): +49 157 30070985 Phone (Landline Chile): +56 2 29790978 Web: dtorres.me
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
