Contents

SE-0112: Improved NSError Bridging

* Proposal: [SE-0112](0112-nserror-bridging.md) * Authors: [Doug Gregor](https://github.com/DougGregor), [Charles Srstka](https://github.com/CharlesJS) * Review Manager: [Chris Lattner](https://github.com/lattner) * Status: **Implemented (Swift 3.0)** * Decision Notes: [Rationale](https://forums.swift.org/t/accepted-se-0112-improved-nserror-bridging/3362)

Introduction

Swift's error handling model interoperates directly with Cocoa's NSError conventions. For example, an Objective-C method with an `NSError**` parameter, e.g.,

- (nullable NSURL *)replaceItemAtURL:(NSURL *)url options:(NSFileVersionReplacingOptions)options error:(NSError **)error;

will be imported as a throwing method:

func replaceItem(at url: URL, options: ReplacingOptions = []) throws -> URL

Swift bridges between `ErrorProtocol-conforming types and NSError so, for example, a Swift enum that conforms to ErrorProtocol can be thrown and will be reflected as an NSError with a suitable domain and code. Moreover, an NSError produced with that domain and code can be caught as the Swift enum type, providing round-tripping so that Swift can deal in ErrorProtocol values while Objective-C deals in NSError` objects.

However, the interoperability is incomplete in a number of ways, which results in Swift programs having to walk a careful line between the `ErrorProtocol-based Swift way and the NSError`-based way. This proposal attempts to bridge those gaps.

Swift-evolution thread: Charles Srstka's pitch for Consistent bridging for NSErrors at the language boundary, which discussed Charles' original proposal that addressed these issues by providing `NSError to ErrorProtocol` bridging and exposing the domain, code, and user-info dictionary for all errors. This proposal expands upon that work, but without directly exposing the domain, code, and user-info.

Motivation

There are a number of weaknesses in Swift's interoperability with Cocoa's error model, including:

  1. There is no good way to provide important error information when

throwing an error from Swift. For example, let's consider a simple application-defined error in Swift:

``swift enum HomeworkError : Int, ErrorProtocol { case forgotten case lost case dogAteIt } ``

One can throw `HomeworkError.dogAteIt and it can be interpreted as an NSError by Objective-C with an appropriate error domain (effectively, the mangled name of the HomeworkError type) and code (effectively, the case discriminator). However, one cannot provide a localized description, help anchor, recovery attempter, or any other information commonly placed into the userInfo dictionary of an NSError. To provide these values, one must specifically construct an NSError` in Swift, e.g.,

``swift throw NSError(code: HomeworkError.dogAteIt.rawValue, domain: HomeworkError._domain, userInfo: [ NSLocalizedDescriptionKey : "the dog ate it" ]) ``

  1. There is no good way to get information typically associated with

`NSError's userInfo in Swift. For example, the Swift-natural way to catch a specific error in the AVError error domain doesn't give one access to the userInfo` dictionary, e.g.,:

``swift catch let error as AVError where error == .diskFull { // AVError is an enum, so one only gets the equivalent of the code. // There is no way to access the localized description (for example) or // any other information typically stored in the userInfo dictionary. } ``

The workaround is to catch as an `NSError`, which is quite a bit more ugly:

``swift catch let error as NSError where error._domain == AVFoundationErrorDomain && error._code == AVFoundationErrorDomain.diskFull.rawValue { // okay: userInfo is finally accessible, but still weakly typed } ``

This makes it extremely hard to access common information, such as the localized description. Moreover, the `userInfo dictionary is effectively untyped so, for example, one has to know a priori that the value associated with the known AVErrorTimeKey will be typed as CMTime`:

``swift catch let error as NSError where error._domain = AVFoundationErrorDomain { if let time = error.userInfo[AVErrorTimeKey] as? CMTime { // ... } } ``

It would be far better if one could catch an `AVError` directly and query the time in a type-safe manner:

``swift catch let error as AVError { if let time = error.time { // ... } } ``

  1. `NSError is inconsistently bridged with ErrorProtocol`. Swift

interoperates by translating between `NSError and ErrorProtocol when mapping between a throwing Swift method/initializer and an Objective-C method with an NSError* parameter. However, an Objective-C method that takes an NSError parameter (e.g., to render it) does not bridge to ErrorProtocol, meaning that NSError is part of the API in Swift in some places (but not others). For example, NSError leaks through when the following UIDocument` API in Objective-C:

``objc - (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted; ``

is imported into Swift as follows:

``swift func handleError(_ error: NSError, userInteractionPermitted: Bool) ``

One would expect the first parameter to be imported as `ErrorProtocol`.

Proposed solution

This proposal involves directly addressing (1)-(3) with new protocols and a different way of bridging Objective-C error code types into Swift, along with some conveniences for working with Cocoa errors:

  1. Introduce three new protocols for describing more information about

errors: `LocalizedError, RecoverableError, and CustomNSError. For example, an error type can provide a localized description by conforming to LocalizedError`:

``swift extension HomeworkError : LocalizedError { var errorDescription: String? { switch self { case .forgotten: return NSLocalizedString("I forgot it") case .lost: return NSLocalizedString("I lost it") case .dogAteIt: return NSLocalizedString("The dog ate it") } } } ``

  1. Imported Objective-C error types should be mapped to struct types

that store an `NSError so that no information is lost when bridging from an NSError to the Swift error types. We propose to introduce a new macro, NS_ERROR_ENUM`, that one can use to both declare an enumeration type used to describe the error codes as well as tying that type to a specific domain constant, e.g.,

``objc typedef NS_ERROR_ENUM(NSInteger, AVError, AVFoundationErrorDomain) { AVErrorUnknown = -11800, AVErrorOutOfMemory = -11801, AVErrorSessionNotRunning = -11803, AVErrorDeviceAlreadyUsedByAnotherSession = -11804, // ... } ``

The imported `AVError will have a struct that allows one to access the userInfo` dictionary directly. This retains the ability to catch via a specific code, e.g.,

``swift catch AVError.outOfMemory { // ... } ``

However, catching a specific error as a value doesn't lose information:

``swift catch let error as AVError where error.code == .sessionNotRunning { // able to access userInfo here! } ``

This also gives the ability for one to add typed accessors for known keys within the `userInfo` dictionary:

```swift extension AVError { var time: CMTime? { get { return userInfo[AVErrorTimeKey] as? CMTime? }

set { userInfo[AVErrorTimeKey] = newValue.map { $0 as CMTime } } } } ```

  1. Bridge `NSError to ErrorProtocol, so that all NSError`

uses are bridged consistently. For example, this means that the Objective-C API:

``objc - (void)handleError:(NSError *)error userInteractionPermitted:(BOOL)userInteractionPermitted; ``

is imported into Swift as:

``swift func handleError(_ error: ErrorProtocol, userInteractionPermitted: Bool) ``

This will use the same bridging logic in the Clang importer that we use for other value types (`Array, String, URL`, etc.), but with the runtime translation we've already been doing for catching/throwing errors.

When we introduce this bridging, we will need to remove `NSError's conformance to ErrorProtocol to avoid creating cyclic implicit conversions. However, one can still explicitly turn an NSError into ErrorProtocol via a bridging cast, e.g., nsError as ErrorProtocol`.

  1. In Foundation, add an extension to `ErrorProtocol` that provides

access to the localized description, which is available for all error types.

``swift extension ErrorProtocol { var localizedDescription: String { return (self as! NSError).localizedDescription } } ``

For the Cocoa error domain, which is encapsulated by the `NSCocoaError` type, add typed access for common user-info keys. Note that we focus only on those user-info keys that are read by user code (vs. only accessed by frameworks):

```swift extension NSCocoaError { // Note: for exposition only. Not actual API. private var userInfo: [NSObject : AnyObject] { return (self as! NSError).userInfo }

var filePath: String? { return userInfo[NSFilePathErrorKey] as? String }

var stringEncoding: String.Encoding? { return (userInfo[NSStringEncodingErrorKey] as? NSNumber) .map { String.Encoding(rawValue: $0.uintValue) } }

var underlying: ErrorProtocol? { return (userInfo[NSUnderlyingErrorKey] as? NSError)?.asError }

var url: URL? { return userInfo[NSURLErrorKey] as? URL } } ```

  1. Rename `ErrorProtocol to Error`: once we've completed the

bridging story, `Error becomes the primary way to work with error types in Swift, and the value type to which NSError` is bridged:

``swift func handleError(_ error: Error, userInteractionPermitted: Bool) ``

Detailed design

This section details both the design (including the various new
protocols, mapping from Objective-C error code enumeration types into
Swift types, etc.) and the efficient implementation of this design to
interoperate with ``NSError``. Throughout the detailed design, we
already assume the name change from ``ErrorProtocol`` to ``Error``.

### New protocols

This proposal introduces several new protocols that allow error types
to expose more information about error types.

The ``LocalizedError`` protocol describes an error that provides
localized messages for display to the end user, all of which provide
default implementations. The conforming type can provide
implementations for any subset of these requirements:

```swift
protocol LocalizedError : Error {
  /// A localized message describing what error occurred.
  var errorDescription: String? { get }

  /// A localized message describing the reason for the failure.
  var failureReason: String? { get }

  /// A localized message describing how one might recover from the failure.
  var recoverySuggestion: String? { get }

  /// A localized message providing "help" text if the user requests help.
  var helpAnchor: String? { get }
}

extension LocalizedError {
  var errorDescription: String? { return nil }
  var failureReason: String? { return nil }
  var recoverySuggestion: String? { return nil }
  var helpAnchor: String? { return nil }
}
```

The ``RecoverableError`` protocol describes an error that might be recoverable:

```swift
protocol RecoverableError : Error {
  /// Provides a set of possible recovery options to present to the user.
  var recoveryOptions: [String] { get }

  /// Attempt to recover from this error when the user selected the
  /// option at the given index. This routine must call handler and
  /// indicate whether recovery was successful (or not).
  ///
  /// This entry point is used for recovery of errors handled at a
  /// "document" granularity, that do not affect the entire
  /// application.
  func attemptRecovery(optionIndex recoveryOptionIndex: Int,
                       resultHandler handler: (recovered: Bool) -> Void)

  /// Attempt to recover from this error when the user selected the
  /// option at the given index. Returns true to indicate
  /// successful recovery, and false otherwise.
  ///
  /// This entry point is used for recovery of errors handled at
  /// the "application" granularity, where nothing else in the
  /// application can proceed until the attmpted error recovery
  /// completes.
  func attemptRecovery(optionIndex recoveryOptionIndex: Int) -> Bool
}

extension RecoverableError {
  /// By default, implements document-modal recovery via application-model
  /// recovery.
  func attemptRecovery(optionIndex recoveryOptionIndex: Int,
                       resultHandler handler: (recovered: Bool) -> Void) {
    handler(recovered: attemptRecovery(optionIndex: recoveryOptionIndex))
  }
}
```

Error types that conform to ``RecoverableError`` may be given an
opportunity to recover from the error. The user can be presented with
some number of (localized) recovery options, described by
``recoveryOptions``, and the selected option will be passed
to the appropriate ``attemptRecovery`` method.

The ``CustomNSError`` protocol describes an error that wants to
provide custom ``NSError`` information. This can be used, e.g., to
provide a specific domain/code or to populate ``NSError``'s
``userInfo`` dictionary with values for custom keys that can be
accessed from Objective-C code but are not covered by the other
protocols.

```swift
/// Describes an error type that fills in the userInfo directly.
protocol CustomNSError : Error {
  var errorDomain: String { get }
  var errorCode: Int { get }
  var errorUserInfo: [String : AnyObject] { get }
}
```

Note that, unlike with ``NSError``, the provided ``errorUserInfo`` requires
``String`` keys. This is in line with common practice for ``NSError``
and is important for the implementation (see below). All of these
properties are defaulted, so one can provide any subset:

```swift
extension CustomNSError {
  var errorDomain: String { ... }
  var errorCode: Int { ... }
  var errorUserInfo: [String : AnyObject] { ... }
}
```

### Mapping error types to ``NSError``

Every type that conforms to the ``Error`` protocol is implicitly
bridged to ``NSError``. This has been the case since Swift 2, where
the compiler provides a domain (i.e., the mangled name of the type)
and code (based on the discriminator of the enumeration type). This
proposal also allows for the ``userInfo`` dictionary to be populated
by the runtime, which will check for conformance to the various
protocols (``LocalizedError``, ``RecoverableError``, or
``CustomNSError``) to retrieve information.

Conceptually, this could be implemented by eagerly creating a
``userInfo`` dictionary for a given instance of ``Error``:

```swift
func createUserInfo(error: Error) -> [NSObject : AnyObject] {
  var userInfo: [NSObject : AnyObject] = [:]

  // Retrieve custom userInfo information.
  if let customUserInfoError = error as? CustomNSError {
    userInfo = customUserInfoError.userInfo
  }

  if let localizedError = error as? LocalizedError {
    if let description = localizedError.errorDescription {
      userInfo[NSLocalizedDescriptionKey] = description
    }

    if let reason = localizedError.failureReason {
      userInfo[NSLocalizedFailureReasonErrorKey] = reason
    }

    if let suggestion = localizedError.recoverySuggestion {   
      userInfo[NSLocalizedRecoverySuggestionErrorKey] = suggestion
    }

    if let helpAnchor = localizedError.helpAnchor {   
      userInfo[NSHelpAnchorErrorKey] = helpAnchor
    }
  }

  if let recoverableError = error as? RecoverableError {
    userInfo[NSLocalizedRecoveryOptionsErrorKey] = recoverableError.recoveryOptions
    userInfo[NSRecoveryAttempterErrorKey] = RecoveryAttempter()
  }
}
```

The ``RecoveryAttempter`` class is an implementation detail. It will
implement the informal protocol [``NSErrorRecoveryAttempting``](https://developer.apple.com/library/ios/documentation/Cocoa/Reference/Foundation/Protocols/NSErrorRecoveryAttempting_Protocol/) for the given error:

```swift
class RecoveryAttempter : NSObject {
  @objc(attemptRecoveryFromError:optionIndex:delegate:didRecoverSelector:contextInfo:)
  func attemptRecovery(fromError nsError: NSError,
                       optionIndex recoveryOptionIndex: Int,
                       delegate: AnyObject?,
                       didRecoverSelector: Selector,
                       contextInfo: UnsafeMutablePointer<Void>) {
    let error = nsError as! RecoverableError
    error.attemptRecovery(optionIndex: recoveryOptionIndex) { success in
      // Exposition only: this part will actually have to be
      // implemented in Objective-C to pass the BOOL and void* through.
      delegate?.perform(didRecoverSelector, with: success, with: contextInfo)
    }
  }

  @objc(attemptRecoveryFromError:optionIndex:)
  func attemptRecovery(fromError nsError: NSError,
                       optionIndex recoveryOptionIndex: Int) -> Bool {
    let error = nsError as! RecoverableError
    return error.attemptRecovery(optionIndex: recoveryOptionIndex)
  }
}
```

The actual the population of the ``userInfo`` dictionary should not be
eager. ``NSError`` provides the notion of global "user info value
providers" that it uses to lazily request the values for certain keys,
via `setUserInfoValueProvider(forDomain:provider:)`, which is declared
as:

```swift
extension NSError {
  @available(OSX 10.11, iOS 9.0, tvOS 9.0, watchOS 2.0, *)
  class func setUserInfoValueProvider(forDomain errorDomain: String,
                                      provider: ((NSError, String) -> AnyObject?)? = nil)
}
```

The runtime would need to register a user info value provider for each
error type the first time it is bridged into ``NSError``, supplying
the domain and the following user info value provider function:

```swift
func userInfoValueProvider(nsError: NSError, key: String) -> AnyObject? {
  let error = nsError as! Error
  switch key {
  case NSLocalizedDescriptionKey:
    return (error as? LocalizedError)?.errorDescription

  case NSLocalizedFailureReasonErrorKey:
    return (error as? LocalizedError)?.failureReason

  case NSLocalizedRecoverySuggestionErrorKey:
    return (error as? LocalizedError)?.recoverySuggestion

  case NSHelpAnchorErrorKey:
    return (error as? LocalizedError)?.helpAnchor

  case NSLocalizedRecoveryOptionsErrorKey:
    return (error as? RecoverableError)?.recoveryOptions

  case NSRecoveryAttempterErrorKey:
    return error is RecoverableError ? RecoveryAttempter() : nil

  default:
    guard let customUserInfoError = error as? CustomNSError else { return nil }
    return customUserInfoError.userInfo[key]
  }
}
```

On platforms that predate the introduction of user info value
providers, there are alternate implementation strategies, including
introducing a custom ``NSDictionary`` subclass to use as the
``userInfo`` in the ``NSError`` that lazily populates the dictionary
by, effectively, calling the ``userInfoValueProvider`` function
above for each requested key. Or, one could eagerly populate
``userInfo`` on older platforms.

### Importing error types from Objective-C

In Objective-C, error domains are typically constructed using an
enumeration describing the error codes and a constant describing the
error domain, e.g,

```objc
extern NSString *const AVFoundationErrorDomain;

typedef NS_ENUM(NSInteger, AVError) {
  AVErrorUnknown                                      = -11800,
  AVErrorOutOfMemory                                  = -11801,
  AVErrorSessionNotRunning                            = -11803,
  AVErrorDeviceAlreadyUsedByAnotherSession            = -11804,
  // ...
}
```

This is currently imported as an ``enum`` that conforms to ``Error``:

```swift
enum AVError : Int {
  case unknown                                      = -11800
  case outOfMemory                                  = -11801
  case sessionNotRunning                            = -11803
  case deviceAlreadyUsedByAnotherSession            = -11804

  static var _domain: String { return AVFoundationErrorDomain }
}
```

and Swift code introduces an extension that makes it an ``Error``,
along with some implementation magic to allow bridging from an
``NSError`` (losing ``userInfo`` in the process):

```swift
extension AVError : Error {
  static var _domain: String { return AVFoundationErrorDomain }
}
```

Instead, error enums should be expressed with a new macro,
``NS_ERROR_ENUM``, that ties together the code and domain in the
Objective-C header:

```objc
extern NSString *const AVFoundationErrorDomain;

typedef NS_ERROR_ENUM(NSInteger, AVError, AVFoundationErrorDomain) {
  AVErrorUnknown                                      = -11800,
  AVErrorOutOfMemory                                  = -11801,
  AVErrorSessionNotRunning                            = -11803,
  AVErrorDeviceAlreadyUsedByAnotherSession            = -11804,
  // ...
}
```

This will import as a new struct ``AVError`` that contains an
``NSError``, so there is no information loss. The actual enum will
become a nested type ``Code``, so that it is still accessible. The
resulting struct will be as follows:

```swift
struct AVError {
  /// Stored NSError. Note that error.domain == AVFoundationErrorDomain is an invariant.
  private var error: NSError

  /// Describes the error codes; directly imported from AVError
  enum Code : Int, ErrorCodeProtocol {
    typealias ErrorType = AVError

    case unknown                                      = -11800
    case outOfMemory                                  = -11801
    case sessionNotRunning                            = -11803
    case deviceAlreadyUsedByAnotherSession            = -11804

    func errorMatchesCode(_ error: AVError) -> Bool {
      return error.code == self
    }
  }

  /// Allow one to create an error (optionally) with a userInfo dictionary.
  init(_ code: Code, userInfo: [NSObject: AnyObject] = [:]) {
    error = NSError(code: code.rawValue, domain: _domain, userInfo: userInfo)
  }

  /// Retrieve the code.
  var code: Code { return Code(rawValue: error.code)! }

  /// Allow direct access to the userInfo dictionary.
  var userInfo: [NSObject: AnyObject] { return error.userInfo }

  /// Make it easy to refer to constants without context.
  static let unknown: Code = .unknown
  static let outOfMemory: Code = .outOfMemory
  static let sessionNotRunning: Code = .sessionNotRunning
  static let deviceAlreadyUsedByAnotherSession: Code = .deviceAlreadyUsedByAnotherSession
}

// Implementation detail: makes AVError conform to Error
extension AVError : Error {
  static var _domain: String { return AVFoundationErrorDomain }

  var _code: Int { return error.code }
}
```

This syntax allows one to throw specific errors fairly easily, with
or without ``userInfo`` dictionaries:

```swift
throw AVError(.sessionNotRunning)
throw AVError(.sessionNotRunning, userInfo: [ ... ])
```

The ``ImportedErrorCode`` protocol is a helper so that we can define
a general ``~=`` operator, which is used by both ``switch`` case
matching and ``catch`` blocks:

```swift
protocol ErrorCodeProtocol {
  typealias ErrorType : Error

  func errorMatchesCode(_ error: ErrorType) -> Bool
}

func ~= <EC: ErrorCodeProtocol> (error: Error, code: EC) -> Bool {
  guard let myError = error as? EC.ErrorType else { return false }
  return code.errorMatchesCode(myError)
}
```

### Mapping ``NSError`` types back into Swift

When an ``NSError`` object bridged to an ``Error`` instance, it may be
immediately mapped back to a Swift error type (e.g., if the error was
created as a ``HomeworkError`` instance in Swift and then passed
through ``NSError`` unmodified) or it might be leave as an instance of
``NSError``. The error might then be catch as a particular Swift error
type, e.g.,

```swift
catch let error as AVError where error.code == .sessionNotRunning {
  // able to access userInfo here!
}
```

In this case, the mapping from an ``NSError`` instance to ``AVError``
goes through an implementation-detail protocol
``_ObjectiveCBridgeableError``:

```swift
protocol _ObjectiveCBridgeableError : Error {
  /// Produce a value of the error type corresponding to the given NSError,
  /// or return nil if it cannot be bridged.
  init?(_bridgedNSError error: NSError)
}
```

The initializer is responsible for checking the domain and
(optionally) the code of the incoming ``NSError`` to map it to an instance
of the Swift error type. For example, ``AVError`` would adopt this
protocol as follows:

```swift
// Implementation detail: makes AVError conform to _ObjectiveCBridgeableError
extension AVError : _ObjectiveCBridgeableError {
  init?(_bridgedNSError error: NSError) {
    // Check whether the error comes from the AVFoundation error domain
    if error.domain != AVFoundationErrorDomain { return nil }

    // Save the error
    self.error = error
  }
}
```

We do not propose that ``_ObjectiveCBridgeableError`` become a public
protocol, because the core team has already deferred a similar
proposal
([SE-0058](0058-objectivecbridgeable.md))
to make the related protocol ``_ObjectiveCBridgeable`` public.

Other Issues

`NSError codes and domains are important for localization of error messages. This is barely supported today by genstrings`, but becomes considerably harder when the domain and code are hidden (as they are in Swift). We would need to consider tooling to make it easier to localize error descriptions, recovery options, etc. in a sensible way. Although this is out of the scope of the Swift language per se, it's an important part of the developer story.

Impact on existing code

This is a major source-breaking change for Objective-C APIs that operate on `NSError values, because those parameter/return/property types will change from NSError to Error`. There are ~400 such APIs in the macOS SDK, and closer to 500 in the iOS SDK, which is a sizable number. Fortunately, this is similar in scope to the Foundation value types proposal, and can use the same code migration mechanism. That said, the scale of this change means that it should either happen in Swift 3 or not at all.

Future directions

Better tooling for describing errors

When adopting one of the new protocols (e.g., `LocalizedError) in an enum, one will inevitably end up with a number of switch` statements that have to enumerate all of the cases, leading to a lot of boilerplate. Better tooling could improve the situation considerably: for example, one could use something like Cocoa's stringsdict files to provide localized strings identified by the enum name, case name, and property. That would eliminate the need for the switch-on-all-cases implementations of each property.

Round-tripping errors through `userInfo`

The `CustomNSError protocol allows one to place arbitrary key/value pairs into NSError's userInfo dictionary. The implementation-detail _ObjectiveCBridgeableError protocol allows one to control how a raw NSError is mapped to a particular error type. One could effectively serialize the entire state of a particular error type into the userInfo dictionary via CustomNSError, then restore it via _ObjectiveCBridgeableError, allowing one to form a complete NSError in Objective-C that can reconstitute itself as a particular Swift error type, which can be useful both for mixed-source projects and (possibly) as a weak form of serialization for NSError`s.

Alternatives considered

Exposing the domain, code, and user-info dictionary directly

This proposal does not directly expose the domain, code, or user-info dictionary on `ErrorProtocol`, because these notions are superseded by Swift's strong typing of errors. The domain is effectively subsumed by the type of the error (e.g., a Swift-defined error type uses its mangled name as the domain); the code is some type-specific value (e.g., the discriminator of the enum); and the user-info dictionary is an untyped set of key-value pairs that are better expressed in Swift as data on the specific error type.

Bridging `NSError to a new value type Error`

One could introduce a new value type, `Error`, that stores a domain, code, and user-info dictionary but provides them with value semantics. Doing so would make it easier to create "generic" errors that carry some information. However, we feel that introducing new error types in Swift is already easier than establishing a new domain and a set of codes, because a new enum type provides this information naturally in Swift.