[Proposal] Rename fatalError() API


(D. Felipe Torres) #1

*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
<https://github.com/search?l=Swift&q=fatalError()&type=Code&utf8=✓> 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


(David Sweeris) #2

I LOL’d (and not that quiet, inner, “I’m just saying ‘lol’ to be polite” kind, either).

···

On Jan 6, 2017, at 2:30 PM, Sean Heber via swift-evolution <swift-evolution@swift.org> wrote:

I assume this is meant to be a joke? I don’t really get it.


(Sean Heber) #3

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


(Adrian Zubarev) #4

Huge –1.

Shameful willItToCompile(finishLater:)

···

--
Adrian Zubarev
Sent with Airmail

Am 6. Januar 2017 um 22:53:39, D. Felipe Torres via swift-evolution (swift-evolution@swift.org) schrieb:

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\(&quot;Unicorns go here&quot;\)

}

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: &quot;Unicorns go here&quot;\)

}

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


(D. Felipe Torres) #5

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@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@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@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


(David Sweeris) #6

I wouldn’t be horribly opposed to adding a function called “willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other equally explicit name, simply because that way it’d be easy to ensure that all such code was revisited before shipping the product.

I wouldn’t be horribly in favor, either, because putting a special phrase in the string that you pass to fatalError() does the same thing, and doesn’t complicate the language.

- Dave Sweeris

···

On Jan 6, 2017, at 2:58 PM, D. Felipe Torres via swift-evolution <swift-evolution@swift.org> wrote:

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"


(Benjamin Spratling) #7

-Ben

···

Sent from my iPhone.

On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

I wouldn’t be horribly opposed to adding a function called “willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other equally explicit name, simply because that way it’d be easy to ensure that all such code was revisited before shipping the product.

Come on, it's swift, it'd have to be named something like, "UnsafeCompilable". :slight_smile:


(Derrick Ho) #8

+1️⃣ for unsafecompilable

···

On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution < swift-evolution@swift.org> wrote:

-Ben

Sent from my iPhone.

> On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I wouldn’t be horribly opposed to adding a function called
“willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other
equally explicit name, simply because that way it’d be easy to ensure that
all such code was revisited before shipping the product.

Come on, it's swift, it'd have to be named something like,
"UnsafeCompilable". :slight_smile:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Alex Blewitt) #9

There's already NSUnimplemented for this kind of use case, and NSRequiresConcreteImplementation for catching subclasses that fail to implement a required (but perhaps optional) method, although these are statement based rather than expression based.

Alex

···

On 6 Jan 2017, at 23:15, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 6, 2017, at 2:58 PM, D. Felipe Torres via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

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 wouldn’t be horribly opposed to adding a function called “willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other equally explicit name, simply because that way it’d be easy to ensure that all such code was revisited before shipping the product.

I wouldn’t be horribly in favor, either, because putting a special phrase in the string that you pass to fatalError() does the same thing, and doesn’t complicate the language.


(David Sweeris) #10

Lol, +1

···

On Jan 6, 2017, at 16:03, Derrick Ho <wh1pch81n@gmail.com> wrote:

+1️⃣ for unsafecompilable

On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution <swift-evolution@swift.org> wrote:

-Ben

Sent from my iPhone.

> On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution <swift-evolution@swift.org> wrote:
>
> I wouldn’t be horribly opposed to adding a function called “willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other equally explicit name, simply because that way it’d be easy to ensure that all such code was revisited before shipping the product.

Come on, it's swift, it'd have to be named something like, "UnsafeCompilable". :slight_smile:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution


(Tony Allevato) #11

Why not take advantage of emoji identifiers?

let :soon: = { fatalError($0) }
func foo(x: Int) -> Int {
  🔜("implement this")
}

Major drawback: Difficult-to-impossible to read on dark color schemes.

···

On Fri, Jan 6, 2017 at 6:54 PM David Sweeris via swift-evolution < swift-evolution@swift.org> wrote:

On Jan 6, 2017, at 16:03, Derrick Ho <wh1pch81n@gmail.com> wrote:

+1️⃣ for unsafecompilable
On Fri, Jan 6, 2017 at 6:22 PM Benjamin Spratling via swift-evolution < > swift-evolution@swift.org> wrote:

-Ben

Sent from my iPhone.

> On Jan 6, 2017, at 5:15 PM, David Sweeris via swift-evolution < > swift-evolution@swift.org> wrote:
>
> I wouldn’t be horribly opposed to adding a function called
“willItToCompile”, “compileAnyway”, “noSrslyIDontCare”, or some other
equally explicit name, simply because that way it’d be easy to ensure that
all such code was revisited before shipping the product.

Come on, it's swift, it'd have to be named something like,
"UnsafeCompilable". :slight_smile:
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Lol, +1
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution