Merge pull request #3459 from apple/nserror-bridging

Implement SE-0112: Improved NSError bridging

Author: DougGregor

apinotes/Foundation.apinotes

@@ -89,7 +89,7 @@ Classes:
   SwiftName: NSDateInterval
   SwiftBridge: DateInterval
 - Name: NSError
-  SwiftName: NSError
+  SwiftBridge: Swift.Error
   Methods:
   - Selector: 'setUserInfoValueProviderForDomain:provider:'
     SwiftName: setUserInfoValueProvider(forDomain:provider:)

benchmark/single-source/ErrorHandling.swift

@@ -12,7 +12,7 @@
 
 import TestsUtils
 
-enum PizzaError : ErrorProtocol {
+enum PizzaError : Error {
   case Pepperoni, Olives, Anchovy
 }
 

docs/ErrorHandling.rst

@@ -257,7 +257,7 @@ Throwing an error
 
 The ``throw`` statement begins the propagation of an error.  It always
 takes an argument, which can be any value that conforms to the
-``ErrorProtocol`` protocol (described below).
+``Error`` protocol (described below).
 
 ::
 
@@ -311,15 +311,15 @@ be marked ``throws``).
 
 We expect to refine the ``catch`` syntax with usage experience.
 
-``ErrorProtocol``
+``Error``
 -----------------
 
-The Swift standard library will provide ``ErrorProtocol``, a protocol with
+The Swift standard library will provide ``Error``, a protocol with
 a very small interface (which is not described in this proposal).  The
 standard pattern should be to define the conformance of an ``enum`` to
 the type::
 
-  enum HomeworkError : ErrorProtocol {
+  enum HomeworkError : Error {
     case Overworked
     case Impossible
     case EatenByCat(Cat)
@@ -332,13 +332,13 @@ within that namespace, and optional values to attach to each option.
 Note that this corresponds very cleanly to the ``NSError`` model of an
 error domain, an error code, and optional user data.  We expect to
 import system error domains as enums that follow this approach and
-implement ``ErrorProtocol``.  ``NSError`` and ``CFError`` themselves will also
-conform to ``ErrorProtocol``.
+implement ``Error``.  ``NSError`` and ``CFError`` themselves will also
+conform to ``Error``.
 
 The physical representation (still being nailed down) will make it
-efficient to embed an ``NSError`` as an ``ErrorProtocol`` and vice-versa.  It
+efficient to embed an ``NSError`` as an ``Error`` and vice-versa.  It
 should be possible to turn an arbitrary Swift ``enum`` that conforms to
-``ErrorProtocol`` into an ``NSError`` by using the qualified type name as the
+``Error`` into an ``NSError`` by using the qualified type name as the
 domain key, the enumerator as the error code, and turning the payload
 into user data.
 

docs/ErrorHandlingRationale.rst

@@ -215,7 +215,7 @@ implementing it in the future:
   a major compatibility break.
 
 - With some admitted awkwardness, external exceptions can be reflected
-  into an ``ErrorProtocol`` - like model automatically by the catch
+  into an ``Error`` - like model automatically by the catch
   mechanism.
 
 - In the meanwhile, developers who must handle an Objective-C
@@ -1523,12 +1523,12 @@ allowed in a blocking context.
 Error type
 ~~~~~~~~~~
 
-The Swift standard library will provide ``ErrorProtocol``, a protocol with
+The Swift standard library will provide ``Error``, a protocol with
 a very small interface (which is not described in this proposal).  The
 standard pattern should be to define the conformance of an ``enum`` to
 the type::
 
-  enum HomeworkError : ErrorProtocol {
+  enum HomeworkError : Error {
     case Overworked
     case Impossible
     case EatenByCat(Cat)
@@ -1545,13 +1545,13 @@ techniques for that will work fine in the future.
 Note that this corresponds very cleanly to the ``NSError`` model of an
 error domain, an error code, and optional user data.  We expect to
 import system error domains as enums that follow this approach and
-implement ``ErrorProtocol``.  ``NSError`` and ``CFError`` themselves will also
-conform to ``ErrorProtocol``.
+implement ``Error``.  ``NSError`` and ``CFError`` themselves will also
+conform to ``Error``.
 
 The physical representation (still being nailed down) will make it
-efficient to embed an ``NSError`` as an ``ErrorProtocol`` and vice-versa.  It
+efficient to embed an ``NSError`` as an ``Error`` and vice-versa.  It
 should be possible to turn an arbitrary Swift ``enum`` that conforms to
-``ErrorProtocol`` into an ``NSError`` by using the qualified type name as the
+``Error`` into an ``NSError`` by using the qualified type name as the
 domain key, the enumerator as the error code, and turning the payload
 into user data.
 
@@ -1808,9 +1808,9 @@ Let's wade into the details.
 Error types
 ~~~~~~~~~~~
 
-``NSError`` and ``CFError`` should implement the ``ErrorProtocol`` protocol.  It
+``NSError`` and ``CFError`` should implement the ``Error`` protocol.  It
 should be possible to turn an arbitrary Swift ``enum`` that conforms to
-``ErrorProtocol`` into an ``NSError`` by using the qualified type name as the
+``Error`` into an ``NSError`` by using the qualified type name as the
 domain key, the enumerator as the error code, and turning the payload
 into user data.
 
@@ -2030,7 +2030,7 @@ other words, we should not use table-based unwinding.
 
 Error propagation for universal errors should be handled by
 table-based unwinding.  ``catch`` handlers can catch both, mapping
-unwind exceptions to ``ErrorProtocol`` values as necessary.  With a
+unwind exceptions to ``Error`` values as necessary.  With a
 carefully-designed interpretation function aimed to solve the specific
 needs of Swift, we can avoid most of the code-size impact by shifting
 it to the unwind tables, which needn't ever be loaded in the common

docs/FailableInitializers.rst

@@ -119,7 +119,7 @@ self value looks like it should have been consumed but it wasn't.
 
 It is also difficult to encode this tri-state return for throwing initializers.
 One can imagine changing the try_apply and throw SIL instructions to support
-returning a pair (ErrorProtocol, AnyObject) instead of a single ErrorProtocol. But
+returning a pair (Error, AnyObject) instead of a single Error. But
 this would ripple changes throughout various SIL analyses, and require IRGen
 to encode the pair return value in an efficient way.
 

docs/GenericsManifesto.md

@@ -205,11 +205,11 @@ Generic parameters could be given the ability to provide default arguments, whic
 ```
 public final class Promise<Value, Reason=Error> { ... }
 
-func getRandomPromise() -> Promise<Int, ErrorProtocol> { ... }
+func getRandomPromise() -> Promise<Int, Error> { ... }
 
 var p1: Promise<Int> = ...
 var p2: Promise<Int, Error> = p1     // okay: p1 and p2 have the same type Promise<Int, Error>
-var p3: Promise = getRandomPromise() // p3 has type Promise<Int, ErrorProtocol> due to type inference
+var p3: Promise = getRandomPromise() // p3 has type Promise<Int, Error> due to type inference
 ```
 
 ### Generalized `class` constraints
@@ -737,4 +737,4 @@ if let storedInE1 = e1 openas T {     // T is a the type of storedInE1, a copy o
     if storedInE1 == storedInE2 { ... } // okay: storedInT1 and storedInE2 are both of type T, which we know is Equatable
   }
 }
-```
+```

docs/Lexicon.rst

@@ -266,4 +266,4 @@ source code, tests, and commit messages. See also the `LLVM lexicon`_.
     A compilation mode where all files in a module are compiled in a single
     process. In this mode there is no `primary file`; all files are parsed,
     type-checked, and optimized together at the SIL level. LLVM optimization
-    and object file generation may happen all together or in separate threads.
+    and object file generation may happen all together or in separate threads.

docs/SIL.rst

@@ -3415,7 +3415,7 @@ container may use one of several representations:
   * `init_existential_metatype`_
   * `open_existential_metatype`_
 
-- **Boxed existential containers**: The standard library ``ErrorProtocol`` protocol
+- **Boxed existential containers**: The standard library ``Error`` protocol
   uses a size-optimized reference-counted container, which indirectly stores
   the conforming value. Boxed existential containers can be ``retain``-ed
   and ``release``-d. The following instructions manipulate boxed existential
@@ -3428,22 +3428,22 @@ container may use one of several representations:
 
 Some existential types may additionally support specialized representations
 when they contain certain known concrete types. For example, when Objective-C
-interop is available, the ``ErrorProtocol`` protocol existential supports
+interop is available, the ``Error`` protocol existential supports
 a class existential container representation for ``NSError`` objects, so it
 can be initialized from one using ``init_existential_ref`` instead of the
 more expensive ``alloc_existential_box``::
 
   bb(%nserror: $NSError):
-    // The slow general way to form an ErrorProtocol, allocating a box and
+    // The slow general way to form an Error, allocating a box and
     // storing to its value buffer:
-    %error1 = alloc_existential_box $ErrorProtocol, $NSError
-    %addr = project_existential_box $NSError in %error1 : $ErrorProtocol
+    %error1 = alloc_existential_box $Error, $NSError
+    %addr = project_existential_box $NSError in %error1 : $Error
     strong_retain %nserror: $NSError
     store %nserror to %addr : $NSError
 
     // The fast path supported for NSError:
     strong_retain %nserror: $NSError
-    %error2 = init_existential_ref %nserror: $NSError, $ErrorProtocol
+    %error2 = init_existential_ref %nserror: $NSError, $Error
 
 init_existential_addr
 `````````````````````

docs/proposals/EnumStyle.rst

@@ -40,7 +40,7 @@ amounts of language sugar it's given, vends initializers corresponding to
     init(success: Wrapped) {
       self = .Success(success)
     }
-    init(error: ErrorProtocol) {
+    init(error: Error) {
       self = .Error(error)
     }
 
@@ -50,7 +50,7 @@ amounts of language sugar it's given, vends initializers corresponding to
       case .Error: return nil
       }
     }
-    var error: ErrorProtocol? {
+    var error: Error? {
       switch self {
       case .Success: return nil
       case .Error(let error): return error
@@ -76,7 +76,7 @@ I'd like to start discussion by proposing the following:
 
     enum Result<Wrapped> {
       case init(success: Wrapped)
-      case init(error: ErrorProtocol)
+      case init(error: Error)
     }
 
   Constructing a value of the case can then be done with the usual initializer
@@ -147,7 +147,7 @@ other kinds of initializer::
 
   enum Result<Wrapped> {
     case init(success: Wrapped)
-    case init(error: ErrorProtocol)
+    case init(error: Error)
   }
 
   enum List<Element> {

docs/proposals/RemoteMirrors.rst

@@ -77,7 +77,7 @@ Boxes
 ~~~~~
 
 These are used for heap-allocating mutable values captured in closures, for
-indirect enum cases, and for ErrorProtocol existential values. They have an
+indirect enum cases, and for Error existential values. They have an
 identifying isa pointer and reference count, but the isa pointer is shared by
 all boxes and thus does not describe the heap layout of the box.