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

[D. Felipe Torres]

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 <sean at fifthace.com> 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 <
> 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
>
>


-- 
++++++++++++++++++++++++++
Diego Torres.
Phone (Mobile Germany): +49 157 30070985
Phone (Landline Chile): +56 2 29790978
Web: dtorres.me
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170106/cfd23cef/attachment.html>