From 9fab9035d6f670792844cc9a6f671515b69604e5 Mon Sep 17 00:00:00 2001
From: Aaron Turon <aturon@mozilla.com>
Date: Fri, 29 Aug 2014 14:36:39 -0700
Subject: [PATCH] RFC: rename fail! to panic!

---
 active/0000-panic.md | 67 ++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)
 create mode 100644 active/0000-panic.md

diff --git a/active/0000-panic.md b/active/0000-panic.md
new file mode 100644
index 00000000000..20333d10dcd
--- /dev/null
+++ b/active/0000-panic.md
@@ -0,0 +1,67 @@
+- Start Date: (fill me in with today's date, 2014-08-29)
+- RFC PR #: (leave this empty)
+- Rust Issue #: (leave this empty)
+
+# Summary
+
+Rename "task failure" to "task panic", and `fail!` to `panic!`.
+
+# Motivation
+
+The current terminology of "task failure" often causes problems when
+writing or speaking about code. You often want to talk about the
+possibility of an operation that returns a `Result` "failing", but
+cannot because of the ambiguity with task failure. Instead, you have
+to speak of "the failing case" or "when the operation does not
+succeed" or other circumlocutions.
+
+Likewise, we use a "Failure" header in rustdoc to describe when
+operations may fail the task, but it would often be helpful to
+separate out a section describing the "Err-producing" case.
+
+We have been steadily moving away from task failure and toward
+`Result` as an error-handling mechanism, so we should optimize our
+terminology accordingly: `Result`-producing functions should be easy
+to describe.
+
+# Detailed design
+
+Not much more to say here than is in the summary: rename "task
+failure" to "task panic" in documentation, and `fail!` to `panic!` in
+code.
+
+The choice of `panic` emerged from a
+[discuss thread](http://discuss.rust-lang.org/t/renaming-task-failure/310/20)
+and
+[workweek discussion](https://github.com/rust-lang/meeting-minutes/blob/master/workweek-2014-08-18/error-handling.md).
+It has precedent in a language setting in Go, and of course goes back
+to Kernel panics.
+
+With this choice, we can use "failure" to refer to an operation that
+produces `Err` or `None`, "panic" for unwinding at the task level, and
+"abort" for aborting the entire process.
+
+The connotations of panic seem fairly accurate: the process is not
+immediately ending, but it is rapidly fleeing from some problematic
+circumstance (by killing off tasks) until a recovery point.
+
+# Drawbacks
+
+The term "panic" is a bit informal, which some consider a drawback.
+
+Making this change is likely to be a lot of work.
+
+# Alternatives
+
+Other choices include:
+
+- `throw!` or `unwind!`. These options reasonably describe the current
+  behavior of task failure, but "throw" suggests general exception
+  handling, and both place the emphasis on the mechanism rather than
+  the policy. We also are considering eventually adding a flag that
+  allows `fail!` to abort the process, which would make these terms misleading.
+
+- `abort!`. Ambiguous with process abort.
+
+- `die!`. A reasonable choice, but it's not immediately obvious what
+  is being killed.