Globals and Members¶

A global function, constant, or variable may have any access level less than or equal to the access level of its type. That is, a private constant can have public type, but not the other way around.

Accessors for variables have the same access level as their associated variable. The setter may be explicitly annotated with an access level less than or equal to the access level of the variable; this is written as private(set) or internal(set) before the var introducer.

An initializer, method, subscript, or property may have any access level less than or equal to the access level of its type (including the implicit ‘Self’ type), with a few additional rules:

• If the type’s access level is private, the access level of members defaults to private. If the type’s access level is internal or public, the access level of members defaults to internal.
• If a member is used to satisfy a protocol requirement, its access level must be at least as high as the protocol conformance’s; see Protocols below.
• If an initializer is required by a superclass, its access level must be at least as high as the access level of the subclass itself.
• Accessors for subscripts follow the same rules as accessors for variables.
• A member may be overridden whenever it is accessible.

The implicit memberwise initializer for a struct has the minimum access level of all of the struct’s stored properties, except that if all properties are public the initializer is internal. The implicit no-argument initializer for structs and classes follows the default access level for the type.

Currently, enum cases always have the same access level as the enclosing enum.

Deinitializers are only invoked by the runtime and do not nominally have access. Internally, the compiler represents them as having the same access level as the enclosing type.

Protocols¶

A protocol may have any access level less than or equal to the access levels of the protocols it refines. That is, a private ExtendedWidget protocol can refine an public Widget protocol, but not the other way around.

The access level of a requirement is the access level of the enclosing protocol, even when the protocol is public. Currently, requirements may not be given a lower access level than the enclosing protocol.

Swift does not currently support private protocol conformances, so for runtime consistency, the access level of the conformance of type T to protocol P is equal to the minimum of T’s access level and P’s access level; that is, the conformance is accessible whenever both T and P are accessible. This does not change if the protocol is conformed to in an extension. (The access level of a conformance is not currently reflected in the source, but is a useful concept for applying restrictions consistently.)

All members used to satisfy a conformance must have an access level at least as high as the conformance’s. This ensures consistency between views of the type; if any member has a lower access level than the conformance, then the member could be accessed anyway through a generic function constrained by the protocol.

A protocol may be used as a type whenever it is accessible. A nominal can conform to a protocol whenever the protocol is accessible.

Structs, Enums, and Classes¶

A struct, enum, or class may be used as a type whenever it is accessible. A struct, enum, or class may be extended whenever it is accessible.

A class may be subclassed whenever it is accessible. A class may have any access level less than or equal to the access level of its superclass.

Members in an extension have the same default access level as members declared within the extended type. However, an extension may be marked with an explicit access modifier (e.g. private extension), in which case the default access level of members within the extension is changed to match.

Extensions with explicit access modifiers may not add new protocol conformances, since Swift does not support private protocol conformances (see Protocols above).

A type may conform to a protocol with lower access than the type itself.

Types¶

A nominal type’s access level is the same as the access level of the nominal declaration itself. A generic type’s access level is the minimum of the access level of the base type and the access levels of all generic argument types.

A tuple type’s access level is the minimum of the access levels of its elements. A function type’s access level is the minimum of the access levels of its input and return types.

A typealias may have any access level up to the access level of the type it aliases. That is, a private typealias can refer to an public type, but not the other way around. This includes associated types used to satisfy protocol conformances.

Interaction with Objective-C¶

If an entity is exposed to Objective-C, most of the runtime guarantees and optimization opportunities go out the window. We have to use a particular selector for members, everything can be inspected at runtime, and even a private member can cause selector conflicts. In this case, access control is only useful for discipline purposes.

Members explicitly marked private are not exposed to Objective-C unless they are also marked @objc (or @IBAction or similar), even if declared within a class implicitly or explicitly marked @objc.

Any public entities will be included in the generated header. In an application or unit test target, internal entities will be exposed as well.

Parse: Option parsing¶

The command line arguments are parsed as options and inputs into Arg instances. Some miscellaneous validation and normalization is performed. Most of the implementation is provided by LLVM.

An important part of this step is selecting a ToolChain. This is the Swift driver’s view of the current platform’s set of compiler tools, and determines how it will attempt to accomplish tasks. More on this below.

One of the optional steps here is building an output file map. This allows a build system (such as Xcode) to control the location of intermediate output files. The output file map uses a simple JSON format mapping inputs to a map of output paths, keyed by file type. Entries under an input of “” refer to the top-level driver process.

Pipeline: Converting Args into Actions¶

At this stage, the driver will take the input Args and input files and establish a graph of Actions. This details the high-level tasks that need to be performed. The graph (a DAG) tracks dependencies between actions, but also manages ownership.

Build: Translating Actions into Jobs using a ToolChain¶

Once we have a graph of high-level Actions, we need to translate that into actual tasks to execute. This starts by determining the output that each Action needs to produce based on its inputs. Then we ask the ToolChain how to perform that Action on the current platform. The ToolChain produces a Job, which wraps up both the output information and the actual invocation. It also remembers which Action it came from and any Jobs it depends on. Unlike the Action graph, Jobs are owned by a single Compilation object and stored in a flat list.

When a Job represents a compile of a single file, it may also be used for dependency analysis, to determine whether it is safe to not recompile that file in the current build. This is covered by checking if the input has been modified since the last build; if it hasn’t, we only need to recompile if something it depends on has changed.

Execute: Running the Jobs in a Compilation using a TaskQueue¶

A Compilation’s goal is to make sure every Job in its list of Jobs is handled. If a Job needs to be run, the Compilation attempts to schedule it. If the Job’s dependencies have all been completed (or determined to be skippable), it is added to the TaskQueue; otherwise it is marked as blocked.

To support Jobs compiling individual Swift files, which may or may not need to be run, the Compilation keeps track of a DependencyGraph. (If file A depends on file B and file B has changed, file A needs to be recompiled.) When a Job completes successfully, the Compilation will both re-attempt to schedule Jobs that were directly blocked on it, and check to see if any other Jobs now need to run based on the DependencyGraph. See the section on Dependency Analysis for more information.

The Compilation’s TaskQueue controls the low-level aspects of managing subprocesses. Multiple Jobs may execute simultaneously, but communication with the parent process (the driver) is handled on a single thread. The level of parellelism may be controlled by a compiler flag.

If a Job does not finish successfully, the Compilation needs to record which jobs have failed, so that they get rebuilt next time the user tries to build the project.

Began Message¶

A “began” message indicates that a new task began. As with all task-based messages, it will include the task’s PID under the “pid” key. It may specify the task’s inputs as an array of paths under the “inputs” key. It may specify the task’s outputs as an array of objects under the “outputs” key. An “outputs” object will have two fields, a “kind” describing the type of the output, and a “path” containing the path to the output. A “began” message will specify the command which was executed under the “command” key.

Example:

{
  "kind": "began",
  "name": "compile",
  "pid": 12345,
  "inputs": [ "/src/foo.swift" ],
  "outputs": [
     {
       "type": "object",
       "path": "/build/foo.o"
     },
     {
       "type": "swiftmodule",
       "path": "/build/foo.swiftmodule"
     },
     {
       "type": "diagnostics",
       "path": "/build/foo.dia"
     },
  ],
  "command": "swift -frontend -c -primary-file /src/foo.swift /src/bar.swift -emit-module-path /build/foo.swiftmodule -emit-diagnostics-path /build/foo.dia"
}

Finished Message¶

A “finished” message indicates that a task finished execution. As with all task- based messages, it will include the task’s PID under the “pid” key. It will include the exit status of the task under the “exit-status” key. It may include the stdout/stderr of the task under the “output” key; if this key is missing, no output was generated by the task.

Example:

{
  "kind": "finished",
  "name": "compile",
  "pid": 12345,
  "exit-status": 0
  // "output" key omitted because there was no stdout/stderr.
}

Signalled Message¶

A “signalled” message indicates that a task exited abnormally due to a signal. As with all task-based message, it will include the task’s PID under the “pid” key. It may include an error message describing the signal under the “error-message” key. As with the “finished” message, it may include the stdout/stderr of the task under the “output” key; if this key is missing, no output was generated by the task.

Example:

{
  "kind": "signalled",
  "name": "compile",
  "pid": 12345,
  "error-message": "Segmentation fault: 11"
  // "output" key omitted because there was no stdout/stderr.
}

Skipped Message¶

A “skipped” message indicates that the driver determined a command did not need to run during the current compilation. A “skipped” message is equivalent to a “began” message, with the exception that it does not include the “pid” key.

Example:

{
  "kind": "skipped",
  "name": "compile",
  "inputs": [ "/src/foo.swift" ],
  "outputs": [
     {
       "type": "object",
       "path": "/build/foo.o"
     },
     {
       "type": "swiftmodule",
       "path": "/build/foo.swiftmodule"
     },
     {
       "type": "diagnostics",
       "path": "/build/foo.dia"
     },
  ],
  "command": "swift -frontend -c -primary-file /src/foo.swift /src/bar.swift -emit-module-path /build/foo.swiftmodule -emit-diagnostics-path /build/foo.dia"
}

rethrows¶

Functions which take a throwing function argument (including as an autoclosure) can be marked as rethrows:

extension Array {
  func map<U>(fn: ElementType throws -> U) rethrows -> [U]
}

It is an error if a function declared rethrows does not include a throwing function in at least one of its parameter clauses.

rethrows is identical to throws, except that the function promises to only throw if one of its argument functions throws.

More formally, a function is rethrowing-only for a function f if:

• it is a throwing function parameter of f,
• it is a non-throwing function, or
• it is implemented within f (i.e. it is either f or a function or closure defined therein) and it does not throw except by either:
  • calling a function that is rethrowing-only for f or
  • calling a function that is rethrows, passing only functions that are rethrowing-only for f.

It is an error if a rethrows function is not rethrowing-only for itself.

A rethrows function is considered to be a throwing function. However, a direct call to a rethrows function is considered to not throw if it is fully applied and none of the function arguments can throw. For example:

// This call to map is considered not to throw because its
// argument function does not throw.
let absolutePaths = paths.map { "/" + $0 }

// This call to map is considered to throw because its
// argument function does throw.
let streams = try absolutePaths.map { try InputStream(filename: $0) }

For now, rethrows is a property of declared functions, not of function values. Binding a variable (even a constant) to a function loses the information that the function was rethrows, and calls to it will use the normal rules, meaning that they will be considered to throw regardless of whether a non-throwing function is passed.

For the purposes of override and conformance checking, rethrows lies between throws and non-throws. That is, an ordinary throwing method cannot override a rethrows method, which cannot override a non-throwing method; but an ordinary throwing method can be overridden by a rethrows method, which can be overridden by a non-throwing method. Equivalent rules apply for protocol conformance.

try!¶

To concisely indicate that a call is known to not actually throw at runtime, try can be decorated with !, turning the error check into a runtime assertion that the call does not throw.

For the purposes of checking that all errors are handled, a try! expression is considered to handle any error originating from within its operand.

try! is otherwise exactly like try: it can appear in exactly the same positions and doesn’t affect the type of an expression.

Higher-order polymorphism¶

We should make it easy to write higher-order functions that behave polymorphically with respect to whether their arguments throw. This can be done in a fairly simple way: a function can declare that it throws if any of a set of named arguments do. As an example (using strawman syntax):

func map<T,U>(array: [T], fn: T -> U) throwsIf(fn) -> [U] {
  ...
}

There’s no need for a more complex logical operator than disjunction for normal higher-order stuff.

This feature is highly desired (e.g. it would allow many otherwise redundant overloads to be collapsed into a single definition), but it may or may not make it into Swift 2.0 based on schedule limitations.

Generic polymorphism¶

For similar reasons to higher-order polymorphism, we should consider making it easier to parameterize protocols on whether their operations can throw. This would allow the writing of generic algorithms, e.g. over Sequence, that handle both conformances that cannot throw (like Array) and those that can (like a hypothetical cloud-backed implementation).

However, this would be a very complex feature, yet to be designed, and it is far out-of-scope for Swift 2.0. In the meantime, most standard protocols will be written to not allow throwing conformances, so as to not burden the use of common generic algorithms with spurious error-handling code.

Statement-like functions¶

Some functions are designed to take trailing closures that feel like sub-statements. For example, autoreleasepool can be used this way:

autoreleasepool {
  foo()
}

The error-handling model doesn’t cause major problems for this. The compiler can infer that the closure throws, and autoreleasepool can be overloaded on whether its argument closure throws; the overload that takes a throwing closures would itself throw.

There is one minor usability problem here, though. If the closure contains throwing expressions, those expression must be explicitly marked within the closure with try. However, from the compiler’s perspective, the call to autoreleasepool is also a call that can throw, and so it must also be marked with try:

try autoreleasepool {    // 'try' is required here...
  let string = try parseString() // ...and here.
  ...
}

This marking feels redundant. We want functions like autoreleasepool to feel like statements, but marks inside builtin statements like if don’t require the outer statement to be marked. It would be better if the compiler didn’t require the outer try.

On the other hand, the “statement-like” story already has a number of other holes: for example, break, continue, and return behave differently in the argument closure than in statements. In the future, we may consider fixing that; that fix will also need to address the error-propagation problem.

using¶

A using statement would acquire a resource, holds it for a fixed period of time, optionally binds it to a name, and then releases it whenever the controlled statement exits. using has many similarities to defer. It does not subsume defer, which is useful for many ad-hoc and tokenless clean-ups. But it could be convenient for the common pattern of a type-directed clean-up.

Automatically importing CoreFoundation and C functions¶

CF APIs use CFErrorRef pretty reliably, but there are several problems here: 1) the memory management rules for CFErrors are unclear and potentially inconsistent. 2) we need to know when an error is raised.

In principle, we could import POSIX functions into Swift as throwing functions, filling in the error from errno. It’s nearly impossible to imagine doing this with an automatic import rule, however; much more likely, we’d need to wrap them all in an overlay.

In both cases, it is possible to pull these into the Swift error handling model, but because this is likely to require massive SDK annotations it is considered out of scope for iOS 9/OSX 10.11 & Swift 2.0.

Unexpected and universal errors¶

As discussed above, we believe that we can extend our current model to support untyped propagation for universal errors. Doing this well, and in particular doing it without completely sacrificing code size and performance, will take a significant amount of planning and insight. For this reason, it is considered well out of scope for Swift 2.0.

Kinds of propagation¶

I’ve heard people talk about explicit vs. implicit propagation. I’m not going to use those terms, because they’re not helpful: there are at least three different things about error-handling that can be more or less explicit, and some of the other dimensions are equally important.

The most important dimensions of variation are:

• Whether the language allows functions to be designated as producing errors or not; such a language has typed propagation.
• Whether, in a language with typed propagation, the default rule is that that a function can produce an error or that it can’t; this is the language’s default propagation rule.
• Whether, in a language with typed propagation, the language enforces this statically, so that a function which cannot produce an error cannot call a function which can without handling it; such a language has statically-enforced typed propagation. (A language could instead enforce this dynamically by automatically inserting code to assert if an error propagates out. C++ does this.)
• Whether the language requires all potential error sites to be identifiable as potential error sites; such a language has marked propagation.
• Whether propagation is done explicitly with the normal data-flow and control-flow tools of the language; such a language has manual propagation. In contrast, a language where control implicitly jumps from the original error site to the proper handler has automatic propagation.

Kinds of error¶

What is an error? There may be many different possible error conditions in a program, but they can be categorized into several kinds based on how programmers should be expected to react to them. Since the programmer is expected to react differently, and since the language is the tool of the programmer’s reaction, it makes sense for each group to be treated differently in the language.

To be clear, in many cases the kind of error reflects a conscious decision by the author of the error-producing code, and different choices might be useful in different contexts. The example I’m going to use of a “simple domain error” could easily be instead treated as a “recoverable error” (if the author expected automatic propagation to be more useful than immediate recovery) or even a “logic failure” (if the author wished to prevent speculative use, e.g. if checking the precondition was very expensive).

In order of increasing severity and complexity:

Propagation methods¶

At a language level, there are two basic ways an error can be propagated from an error site to something handling it.

The first is that it can be done with the normal evaluation, data flow, and control flow processes of the language; let’s call this manual propagation. Here’s a good example of manual propagation using special return values in an imperative language, C:

struct object *read_object(void) {
  char buffer[1024];
  ssize_t numRead = read(0, buffer, sizeof(buffer));
  if (numRead < 0) return NULL;
  ...
}

Here’s an example of manual propagation of an error value through out-parameters in another imperative language, Objective-C:

- (BOOL) readKeys: (NSArray<NSString*>**) strings error: (NSError**) err {
  while (1) {
    NSString *key;
    if ([self readKey: &key error: err]) {
      return TRUE;
    }
    ...
  }
  ...
}

Here’s an example of manual propagation using an ADT in an impure functional language, SML; it’s somewhat artificial because the SML library actually uses exceptions for this:

fun read_next_cmd () =
  case readline(stdin) of
    NONE => NONE
  | SOME line => if ...

All of these excerpts explicitly test for errors using the language’s standard tools for data flow and then explicitly bypass the evaluation of the remainder of the function using the language’s standard tools for control flow.

The other basic way to propagate errors is in some hidden, more intrinsic way not directly reflected in the ordinary control flow rules; let’s call this automatic propagation. Here’s a good example of automatic propagation using exceptions in an imperative language, Java:

String next = readline();

If readline encounters an error, it throws an exception; the language then terminates scopes until it dynamically reaches a try statement with a matching handler. Note the lack of any code at all implying that this might be happening.

The chief disadvantages of manual propagation are that it’s tedious to write and requires a lot of repetitive boilerplate. This might sound superficial, but these are serious concerns. Tedium distracts programmers and makes them careless; careless error-handling code can be worse than useless. Repetitive boilerplate makes code less readable, hurting maintainability; it occupies the programmer’s time, creating opportunity costs; it discourages handling errors well by making it burdensome to handle them at all; and it encourages shortcuts (such as extensive macro use) which may undermine other advantages and goals.

The chief disadvantage of automatic propagation is that it obscures the control flow of the code. I’ll talk about this more in the next section.

Note that automatic propagation needn’t be intrinsic in a language. The propagation is automatic if it doesn’t correspond to visible constructs in the source. This effect can be duplicated as a library with any language facility that allows restructuring of code (e.g. with macros or other term-rewriting facilities) or overloading of basic syntax (e.g. Haskell mapping its do notation onto monads).

Note also that multiple propagation strategies may be “in play” for any particular program. For example, Java generally uses exceptions in its standard libraries, but some specific APIs might opt to instead return null on error for efficiency reasons. Objective-C provides a fairly full-featured exceptions model, but the standard APIs (with a few important exceptions) reserve them solely for unrecoverable errors, preferring manual propagation with NSError out-parameters instead. Haskell has a large number of core library functions which return Maybe values to indicate success or error, but it also offers at least two features resembling traditional, automatically-propagating exceptions (the ErrorT monad transform and exceptions in the IO monad).

So, while I’m going to talk as if languages implement a single propagation strategy, it should be understood that reality will always be more complex. It is literally impossible to prevent programmers from using manual propagation if they want to. Part of the proposal will discuss using multiple strategies at once.

Marked propagation¶

Closely related to the question of whether propagation is manual or automatic is whether it is marked or unmarked. Let’s say that a language uses marked propagation if there is something at the call site which indicates that propagation is possible from that point.

To a certain extent, every language using manual propagation uses marked propagation, since the manual code to propagate the error approximately marks the call which generated the error. However, it is possible for the propagation logic to get separated from the call.

Marked propagation is at odds with one other major axis of language design: a language can’t solely use marked propagation if it ever performs implicit operations that can produce errors. For example, a language that wanted out-of-memory conditions to be recoverable errors would have to consider everything that could allocate memory to a source of propagation; in a high-level language, that would include a large number of implicit operations. Such a language could not claim to use marked propagation.

The reason this all matters is because unmarked propagation is a pretty nasty thing to end up with; it makes it impossible to directly see what operations can produce errors, and therefore to directly understand the control flow of a function. This leaves you with two options as a programmer:

• You can carefully consider the actual dynamic behavior of every function called by your function.
• You can carefully arrange your function so that there are no critical sections where an universal error can leave things in an unwanted state.

There are techniques for making the second more palatable. Chiefly, they involve never writing code that relies on normal control flow to maintain invariants and clean up after an operation; for example, always using constructors and destructors in C++ to manage resources. This is compulsory in C++ with exceptions enabled because of the possibility of implicit code that can throw, but it could theoretically be used in other languages. However, it still requires a fairly careful and rigorous style of programming.

It is possible to imagine a marked form of automatic propagation, where the propagation itself is implicit except that (local) origination points have to be explicitly marked. This is part of our proposal, and I’ll discuss it below.

Typed propagation¶

The next major question is whether error propagation is explicitly tracked and limited by the language. That is, is there something explicitly in the declaration of a function that tells the programmer whether it can produce errors? Let’s call this typed propagation.

- (instancetype)initWithContentsOfURL:(NSURL *)url encoding:(NSStringEncoding)enc error:(NSError **)error;

trait Writer {
  fn write_line(&mut self, s: &str) -> Result<(), IoError>;
}

fn parse_two_ints_and_add_them() {
  match parse_int() {
    Err e => Err e
    Ok x => match parse_int() {
      Err e => Err e
      Ok y => Ok (x + y)
    }
  }
}

Error Types¶

There are many kinds of error. It’s important to be able to recognize and respond to specific error causes programmatically. Swift should support easy pattern-matching for this.

But I’ve never really seen a point to coarser-grained categorization than that; for example, I’m not sure how you’re supposed to react to an arbitrary, unknown IO error. And if there are useful error categories, they can probably be expressed with predicates instead of public subclasses. I think we start with a uni-type here and then challenge people to come up with reasons why they need anything more.

Implementation design¶

There are several different common strategies for implementing automatic error propagation. (Manual propagation doesn’t need special attention in the implementation design.)

The implementation has two basic tasks common to most languages:

• Transferring control through scopes and functions to the appropriate handler for the error.
• Performing various semantic “clean up” tasks for the scopes that were abruptly terminated:
  • tearing down local variables, like C++ variables with destructors or strong/weak references in ARC-like languages;
  • releasing heap-allocated local variables, like captured variables in Swift or __block variables in ObjC;
  • executing scope-specific termination code, like C#’s using or Java/ObjC’s synchronized statements; and
  • executing ad hoc cleanup blocks, like finally blocks in Java or defer actions in Swift.

Any particular call frame on the stack may have clean-ups or potential handlers or both; call these interesting frames.

void *exception = ...;
SomeCXXType::~SomeCXXType(&foo);
objc_release(bar);
objc_release(baz);
_Unwind_Resume(exception);

CALL_WITH_FRAME_ADDRESS(&SomeCXXType::~SomeCXXType, FRAME_OFFSET_OF(foo))
CALL_WITH_FRAME_VALUE(&objc_release, FRAME_OFFSET_OF(bar))
CALL_WITH_FRAME_VALUE(&objc_release, FRAME_OFFSET_OF(baz))
RESUME

Clean-up actions¶

Many languages have a built-in language tool for performing arbitrary clean-up when exiting a scope. This has two benefits. The first is that, even ignoring error propagation, it acts as a “scope guard” which ensures that the clean-up is done if the scope is exited early due to a return, break, or continue statement; otherwise, the programmer must carefully duplicate the clean-up in all such places. The second benefit is that it makes clean-up tractable in the face of automatic propagation, which creates so many implicit paths of control flow out of the scope that expecting the programmer to cover them all with explicit catch-and-rethrow blocks would be ridiculous.

There’s an inherent tension in these language features between putting explicit clean-up code in the order it will be executed and putting it near the code it’s cleaning up after. The former means that a top-to-bottom read of the code tells you what actions are being performed when; you don’t have to worry about code implicitly intervening at the end of a scope. The latter makes it easy to verify at the point that a clean-up is needed that it will eventually happen; you don’t need to scan down to the finally block and analyze what happens there.

C¶

C doesn’t really have a consensus error-handling scheme. There’s a built-in unwinding mechanism in setjmp and longjmp, but it’s disliked for a host of good reasons. The dominant idiom in practice is for a function to encode failure using some unreasonable value for its result, like a null pointer or a negative count. The bad value(s) are often function-specific, and sometimes even argument- or state-specific.

On the caller side, it is unfortunately idiomatic (in some codebases) to have a common label for propagating failure at the end of a function (hence goto fail); this is because there’s no inherent language support for ensuring that necessary cleanup is done before propagating out of a scope.

C++¶

C++ has exceptions. Exceptions can have almost any type in the language. Propagation typing is tied only to declarations; an indirect function pointer is generally assumed to be able to throw. Propagation typing used to allow functions to be specific about the kinds of exceptions they could throw (:code:throws (std::exception)), but this is deprecated in favor of just indicating whether a function can throw (:code:noexcept(false)).

C++ aspires to making out-of-memory a recoverable condition, and so allocation can throw. Therefore, it is essentially compulsory for the language to assume that constructors might throw. Since constructors are called pervasively and implicitly, it makes sense for the default rule to be that all functions can throw. Since many error sites are implicit, there is little choice but to use automatic unmarked propagation. The only reasonable way to clean up after a scope in such a world is to allow the compiler to do it automatically. C++ programmers therefore rely idiomatically on a pattern of shifting all scope cleanup into the destructors of local variables; sometimes such local values are created solely to set up a cleanup action in this way.

Different error sites occur with a different set of cleanups active, and there are a large number of such sites. In fact, prior to C++11, compilers were forced to assume by default that destructor calls could throw, so cleanups actually created more error sites. This all adds up to a significant code-size penalty for exceptions, even in projects which don’t directly use them and which have no interest in recovering from out-of-memory conditions. For this reason, many C++ projects explicitly disable exceptions and rely on other error propagation mechanisms, on which there is no widespread consensus.

Objective C¶

Objective C has a first-class exceptions mechanism which is similar in feature set to Java’s: @throw / @try / @catch / @finally. Exception values must be instances of an Objective-C class. The language does a small amount of implicit frame cleanup during exception propagation: locks held by @synchronized are released, stack copies of __block variables are torn down, and ARC __weak variables are destroyed. However, the language does not release object pointers held in local variables, even (by default) under ARC.

Objective C exceptions used to be implemented with setjmp, longjmp, and thread-local state managed by a runtime, but the only surviving platform we support which does that is i386, and all others now use a “zero-cost” implementation that interoperates with C++ exceptions.

Objective C exceptions are mostly only used for unrecoverable conditions, akin to what I called “failures” above. There are a few major exceptions to this rule, where APIs that do use exceptions to report errors.

Instead, Objective C mostly relies on manual propagation, predominantly using out-parameters of type NSError**. Whether the call failed is usually not indicated by whether a non-nil error was written into this parameter; calls are permitted both to succeed and write an error object into the parameter (which should be ignored) and to report an error without creating an actual error object. Instead, whether the call failed is reported in the formal return value. The most common convention is for a false BOOL result or null object result to mean an error, but ingenious programmers have come up with many other conventions, and there do exist APIs where a null object result is valid.

CF APIs, meanwhile, have their own magnificent set of somewhat inconsistent conventions.

Therefore, we can expect that incrementally improving CF / Objective C interoperation is going to be a long and remarkably painful process.

Java¶

Java has a first-class exceptions mechanism with unmarked automatic propagation: throw / try / catch / finally. Exception values must be instances of something inheriting from Throwable. Propagation is generally typed with static enforcement, with the default being that a call cannot throw exceptions except for subclasses of Error and RuntimeException. The original intent was that these classes would be used for catastrophic runtime errors (Error) and programming mistakes caught by the runtime (RuntimeException), both of which we would classify as unrecoverable failures in our scheme; essentially, Java attempts to promote a fully statically-enforced model where truly catastrophic problems can still be handled when necessary. Unfortunately, these motivations don’t seem to have been communicated very well to developers, and the result is kindof a mess.

Java allows methods to be very specific about the kinds of exception they throw. In my experience, exceptions tend to fall into two categories:

• There are some very specific exception kinds that callers know to look for and handle on specific operations. Generally these are obvious, predictable error conditions, like a host name not resolving, or like a string not being formatted correctly.
• There are also a lot of very vague, black-box exception kinds that can’t really be usefully responded to. For example, if a method throws IOException, there’s really nothing a caller can do except propagate it and abort the current operation.

So specific typing is useful if you can exhaustively handle a small number of specific failures. As soon as the exception list includes any kind of black box type, it might as well be a completely open set.

C#¶

C#’s model is almost exactly like Java’s except that it is untyped: all methods are assumed to be able to throw. For this reason, it also has a simpler type hierarchy, where all exceptions just inherit from Exception.

The rest of the hierarchy doesn’t really make any sense to me. Many things inherit directly from Exception, but many other things inherit from a subclass called SystemException. SystemException doesn’t seem to be any sort of logical grouping: it includes all the runtime-assertion exceptions, but it also includes every exception that’s thrown anywhere in the core library, including XML and IO exceptions.

C# also has a using statement, which is useful for binding something over a precise scope and then automatically disposing it on all paths. It’s just built on top of try / finally.

Haskell¶

Haskell provides three different common error-propagation mechanisms.

The first is that, like many other functional languages, it supports manual propagation with a Maybe type. A function can return None to indicate that it couldn’t produce a more useful result. This is the most common failure method for functions in the functional subset of the library.

The IO monad also provides true exceptions with unmarked automatic propagation. These exceptions can only be handled as an IO action, but are otherwise untyped: there is no way to indicate whether an IO action can or cannot throw. Exceptions can be thrown either as an IO action or as an ordinary lazy functional computation; in the latter case, the exception is only thrown if the computation is evaluated for some reason.

The ErrorT monad transform provides typed automatic propagation. In an amusing twist, since the only native computation of ErrorT is throwError, and the reason to write a computation specifically in ErrorT is if it’s throwing, and every other computation must be explicitly lifted into the monad, ErrorT effectively uses marked propagation by omission, since everything that can’t throw is explicitly marked with a lift:

prettyPrintShiftJIS :: ShiftJISString -> ErrorT TranscodeError IO ()
prettyPrintShiftJIS str = do
  lift $ putChar '"'     -- lift turns an IO computation into an ErrorT computation
  case transcodeShiftJISToUTF8 str of
    Left error -> throwError error
    Right value -> lift $ putEscapedString value
  lift $ putChar '"'

Rust¶

Rust distinguishes between failures and panics.

A panic is an assertion, designed for what I called logic failures; there’s no way to recover from one, it just immediately crashes.

A failure is just when a function doesn’t produce the value you might expect, which Rust encourages you to express with either Option<T> (for simple cases, like what I described as simple domain errors) or Result<T> (which is effectively the same, except carrying an error). In either case, it’s typed manual propagation, although Rust does at least offer a standard macro which wraps the common pattern-match-and-return pattern for Result<T>.

The error type in Rust is a very simple protocol, much like this proposal suggests.

Go¶

Go uses an error result, conventionally returned as the final result of functions that can fail. The caller is expected to manually check whether this is nil; thus, Go uses typed manual propagation.

The error type in Go is an interface named error, with one method that returns a string description of the error.

Go has a defer statement:

defer foo(x, y)

The argument has to be a call (possibly a method call, possibly a call to a closure that you made specifically to immediately call). All the operands are evaluated immediately and captured in a deferred action. Immediately after the function exits (through whatever means), all the deferred actions are executed in LIFO order. Yes, this is tied to function exit, not scope exit, so you can have a dynamic number of deferred actions as a sort of implicit undo stack. Overall, it’s a nice if somewhat quirky way to do ad-hoc cleanup actions.

It is also a key part of a second, funky kind of error propagation, which is essentially untyped automatic propagation. If you call panic — and certain builtin operations like array accesses behave like they do — it immediately unwinds the stack, running deferred actions as it goes. If a function’s deferred action calls recover, the panic stops, the rest of the deferred actions for the function are called, and the function returns. A deferred action can write to the named results, allowing a function to turn a panic error into a normal, final-result error. It’s conventional to not panic over API boundaries unless you really mean it; recoverable errors are supposed to be done with out-results.

Scripting languages¶

Scripting languages generally all use (untyped, obviously) automatic exception propagation, probably because it would be quite error-prone to do manual propagation in an untyped language. They pretty much all fit into the standard C++/Java/C# style of throw / try / catch. Ruby uses different keywords for it, though.

I feel like Python uses exceptions a lot more than most other scripting languages do, though.

Automatic propagation¶

Swift should use automatic propagation of errors, rather than relying on the programmer to manually check for them and return out. It’s just a lot less boilerplate for common error handling tasks. This introduces an implicit control flow problem, but we can ameliorate that with marked propagation; see below.

There’s no compelling reason to deviate from the throw / catch legacy here. There are other options, like raise / handle. In theory, switching would somewhat dissociate Swift from the legacy of exceptions; people coming from other languages have a lot of assumptions about exceptions which don’t necessarily apply to Swift. However, our error model is similar enough to the standard exception model that people are inevitably going to make the connection; there’s no getting around the need to explain what we’re trying to do. So using different keywords just seems petty.

Therefore, Swift should provide a throw expression. It requires an operand of type Error and formally yields an arbitrary type. Its dynamic behavior is to transfer control to the innermost enclosing catch clause which is satisfied by the operand. A quick example:

if timeElapsed() > timeThreshold { throw HomeworkError.Overworked }

A catch clause includes a pattern that matches an error. We want to repurpose the try keyword for marked propagation, which it seems to fit far better, so catch clauses will instead be attached to a generalized do statement:

do {
  ...

} catch HomeworkError.Overworked {
  // a conditionally-executed catch clause

} catch _ {
  // a catch-all clause
}

Swift should also provide some tools for doing manual propagation. We should have a standard Rust-like :code:Result<T> enum in the library, as well as a rich set of tools, e.g.:

• A function to evaluate an error-producing closure and capture the result as a :code:Result<T>.
• A function to unpack a :code:Result<T> by either returning its value or propagating the error in the current context.
• A futures library that traffics in :code:Result<T> when applicable.
• An overload of dispatch_sync which takes an error-producing closure and propagates an error in the current context.
• etc.

Typed propagation¶

Swift should use statically-enforced typed propagation. By default, functions should not be able to throw. A call to a function which can throw within a context that is not allowed to throw should be rejected by the compiler.

Function types should indicate whether the function throws; this needs to be tracked even for first-class function values. Functions which do not throw are subtypes of functions that throw.

This would be written with a throws clause on the function declaration or type:

// This function is not permitted to throw.
 func foo() -> Int {
   // Therefore this is a semantic error.
   return try stream.readInt()
 }

 // This function is permitted to throw.
 func bar() throws -> Int {
   return try stream.readInt()
 }

 // ‘throws’ is written before the arrow to give a sensible and
 // consistent grammar for function types and implicit () result types.
 func baz() throws {
   if let byte = try stream.getOOB() where byte == PROTO_RESET {
     reset()
   }
 }

 // ‘throws’ appears in a consistent position in function types.
 func fred(callback: (UInt8) throws -> ()) throws {
    while true {
      let code = try stream.readByte()
      if code == OPER_CLOSE { return }
      try callback(code)
    }
 }

 // It only applies to the innermost function for curried functions;
 // this function has type:
 //   (Int) -> (Int) throws -> Int
 func jerry(i: Int)(j: Int) throws -> Int {
   // It’s not an error to use ‘throws’ on a function that can’t throw.
   return i + j
 }

The reason to use a keyword here is that it’s much nicer for function declarations, which generally outnumber function types by at least an order of magnitude. A punctuation mark would be easily lost or mistaken amidst all the other punctuation in a function declaration, especially if the punctuation mark were something like ! that can validly appear at the end of a parameter type. It makes sense for the keyword to appear close to the return type, as it’s essentially a part of the result and a programmer should be able to see both parts in the same glance. The keyword appears before the arrow for the simple reason that the arrow is optional (along with the rest of the return type) in function and initializer declarations; having the keyword appear in slightly different places based on the presence of a return type would be silly and would making adding a non-void return type feel awkward. The keyword itself should be descriptive, and it’s particularly nice for it to be a form of the verb used by the throwing expression, conjugated as if performed by the function itself. Thus, throw becomes throws; if we used raise instead, this would be raises, which I personally find unappealing for reasons I’m not sure I can put a name to.

It shouldn’t be possible to overload functions solely based on whether the functions throw. That is, this is not legal:

func foo() { ... } // called in contexts that cannot throw
func foo() throws { ... } // called in contexts that can throw

It is valuable to be able to overload higher-order functions based on whether an argument function throws; it is easy to imagine algorithms that can be implemented more efficiently if they do not need to worry about exceptions. (We do not, however, particularly want to encourage a pattern of duplicating This is straightforward if the primary type-checking pass is able to reliably decide whether a function value can throw.

Typed propagation checking can generally be performed in a secondary pass over a type-checked function body: if a function is not permitted to throw, walk its body and verify that there are no throw expressions or calls to functions that can throw. If all throwing calls must be marked, this can be done prior to type-checking to decide syntactically whether a function can apparently throw; of course, the later pass is still necessary, but the ability to do this dramatically simplifies the implementation of the type-checker, as discussed below. Certain type-system features may need to be curtailed in order to make this implementation possible for schedule reasons. (It’s important to understand that this is not the motivation for marked propagation. It’s just a convenient consequence that marked propagation makes this implementation possible.)

Reliably deciding whether a function value can throw is easy for higher-order uses of declared functions. The problem, as usual, is anonymous functions. We don’t want to require closures to be explicitly typed as throwing or non-throwing, but the fully-accurate inference algorithm requires a type-checked function body, and we can’t always type-check an anonymous function independently of its enclosing context. Therefore, we will rely on being able to do a pass prior to type-checking to syntactically infer whether a closure throws, then making a second pass after type-checking to verify the correctness of that inference. This may break certain kinds of reasonable code, but the multi-pass approach should let us heuristically unbreak targeted cases.

Typed propagation has implications for all kinds of polymorphism:

func map<T,U>(array: [T], fn: T throws -> U) throwsIf(fn) -> [U] {
  ...
}

enum HomeworkError : ErrorType {
  case Overworked
  case Impossible
  case EatenByCat(Cat)
  case StopStressingMeWithYourRules
}

Marked propagation¶

Swift should use marked propagation: there should be some lightweight bit of syntax decorating anything that is known be able to throw (other than a throw expression itself, of course).

Our proposed syntax is to repurpose try as something that can be wrapped around an arbitrary expression:

// This try applies to readBool().
if try stream.readBool() {

  // This try applies to both of these calls.
  let x = try stream.readInt() + stream.readInt()

  // This is a semantic error; it needs a try.
  var y = stream.readFloat()

  // This is okay; the try covers the entire statement.
  try y += stream.readFloat()
}

Developers can “scope” the try very tightly by writing it within parentheses or on a specific argument or list element:

// Semantic error: the try only covers the parenthesized expression.
let x = (try stream.readInt()) + stream.readInt()

// The try applies to the first array element.  Of course, the
// developer could cover the entire array by writing the try outside.
let array = [ try foo(), bar(), baz() ]

Some developers may wish to do this to make the specific throwing calls very clear. Other developers may be content with knowing that something within a statement can throw.

We also briefly considered the possibility of putting the marker into the call arguments clause, e.g.:

parser.readKeys(&strings, try)

This works as long as the only throwing calls are written syntactically as calls; this covers calls to free functions, methods, and initializers. However, it effectively requires Swift to forbid operators and property and subscript accessors from throwing, which may not be a reasonable limitation, especially for operators. It is also somewhat unnatural, and it forces users to mark every single call site instead of allowing them to mark everything within a statement at once.

Autoclosures pose a problem for marking. For the most part, we want to pretend that the expression of an autoclosure is being evaluated in the enclosing context; we don’t want to have to mark both a call within the autoclosure and the call to the function taking the autoclosure! We should teach the type-checking pass to recognize this pattern: a call to a function that throwsIf an autoclosure argument does.

There’s a similar problem with functions that are supposed to feel like statements. We want you to be able to write:

autoreleasepool {
  let string = parseString(try)
  ...
}

without marking the call to autoreleasepool, because this undermines the ability to write functions that feel like statements. However, there are other important differences between these trailing-closure uses and true built-in statements, such as the behavior of return, break, and continue. An attribute which marks the function as being statement-like would be a necessary step towards addressing both problems. Doing this reliably in closures would be challenging, however.

Other syntax¶

if exists(filename) {
  let file = open(filename, O_READ)
  defer close(file)

  while let line = try file.readline() {
    ...
  }

  // close occurs here, at the end of the formal scope.
}

C and Objective-C Interoperation¶

It’s of paramount importance that Swift’s error model interact as cleanly with Objective-C APIs as we can make it.

In general, we want to try to import APIs that produce errors as throwing; if this fails, we’ll import the API as an ordinary non-throwing function. This is a safe approach only under the assumption that importing the function as throwing will require significant changes to the call. That is, if a developer writes code assuming that an API will be imported as throwing, but in fact Swift fails to import the API that way, it’s important that the code doesn’t compile.

Fortunately, this is true for the common pattern of an error out-parameter: if Swift cannot import the function as throwing, it will leave the out-parameter in place, and the compiler will complain if the developer fails to pass an error argument. However, it is possible to imagine APIs where the “meat” of the error is returned in a different way; consider a POSIX API that simply sets errno. Great care would need to be taken when such an API is only partially imported as throwing.

Let’s wade into the details.

+ (NSInteger)writePropertyList:(id)plist
                      toStream:(NSOutputStream *)stream
                        format:(NSPropertyListFormat)format
                       options:(NSPropertyListWriteOptions)opt
                         error:(out NSError **)error
  NS_ERROR_RESULT(0)

- (AVKeyValueStatus)statusOfValueForKey:(NSString *)key
                                  error:(NSError **)
  NS_ERROR_RESULT(AVKeyValueStatusFailed);

- (NSData *)dataFromRange:(NSRange)range
       documentAttributes:(NSDictionary *)dict
                    error:(NSError **)error;

func dataFromRange(range: NSRange,
                   documentAttributes dict: NSDictionary) throws -> NSData

- (NSDocument *)duplicateAndReturnError:(NSError **)outError;

func duplicateAndReturnError() throws -> NSDocument

- (BOOL)validateForDelete:(NSError **)error;

func validateForDelete() throws

Implementation design¶

Error propagation for the kinds of explicit, typed errors that I’ve been focusing on should be handled by implicit manual propagation. It would be good to bias the implementation somewhat towards the non-error path, perhaps by moving error paths to the ends of functions and so on, and perhaps even by processing cleanups with an interpretive approach instead of directly inlining that code, but we should not bias so heavily as to seriously compromise performance. In 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 ErrorType 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 case.

Designated Initializers¶

There are two kinds of initializers in Swift: designated initializers and convenience initializers. A designated initializer is responsible for the primary initialization of an object, including the initialization of any stored properties, chaining to one of its superclass’s designated initializers via a super.init call (if there is a superclass), and performing any other initialization tasks, in that order. For example, consider a subclass B of A:

class B : A {
  var d: Double

  init int(i: Int) string(s: String) {
    self.d = Double(i)            // initialize stored properties
    super.init(int: i, string: s) // chain to superclass
    completeInitForB()            // perform other tasks
  }

  func completeInitForB() { /* ... */ }
}

Consider the following construction of an object of type B:

var b = B(int: 17, string: "Seventeen")

Initialization proceeds in several steps:

1. An object of type B is allocated by the runtime.
2. B‘s initializer initializes the stored property d to 17.0.
3. B‘s initializer chains to A‘s initializer.
4. A‘s initializer initialize’s the stored properties i and s‘.
5. A‘s initializer calls completeInit(), then returns.
6. B‘s initializer calls completeInitForB(), then returns.

A class generally has a small number of designated initializers, which act as funnel points through which the object will be initialized. All of the designated initializers for a class must be written within the class definition itself, rather than in an extension, because the complete set of designated initializers is part of the interface contract with subclasses of a class.

The other, non-designted initializers of a class are called convenience initializers, which tend to provide additional initialization capabilities that are often more convenient for common tasks.

Convenience Initializers¶

A convenience initializer is an initializer that provides an alternative interface to the designated initializers of a class. A convenience initializer is denoted by the return type Self in the definition. Unlike designated initializers, convenience initializers can be defined either in the class definition itself or within an extension of the class. For example:

extension A {
  init() -> Self {
    self.init(int: 17, string: "Seventeen")
  }
}

A convenience initializer cannot initialize the stored properties of the class directly, nor can it invoke a superclass initializer via super.init. Rather, it must dispatch to another initializer using self.init, which is then responsible for initializing the object. A convenience initializer is not permitted to access self (or anything that depends on self, such as one of its properties) prior to the self.init call, although it may freely access self after self.init.

Convenience initializers and designated initializers can both be used to construct objects, using the same syntax. For example, the A initializer above can be used to build a new A object without any arguments:

var a2 = A() // uses convenience initializer

Initializer Inheritance¶

One of the primary benefits of convenience initializers is that they can be inherited by subclasses. Initializer inheritance eliminates the need to repeat common initialization code—such as initial values of stored properties not easily written in the class itself, or common registration tasks that occur during initialization—while using the same initialization syntax. For example, this allows a B object to be constructed with no arguments by using the inherited convenience initializer defined in the previous section:

var b2 = B()

Initialization proceeds as follows:

1. A B object is allocated by the runtime.
2. A‘s convenience initializer init() is invoked.
3. A‘s convenience initializer dispatches to init int:string: via the self.init call. This call dynamically resolves to B‘s designated initializer.
4. B‘s designated initializer initializes the stored property d to 17.0.
5. B‘s designated initializer chains to A‘s designated initializer.
6. A‘s designated initializer initialize’s the stored properties i and s‘.
7. A‘s designated initializer calls completeInit(), then returns.
8. B‘s designated initializer calls completeInitForB(), then returns.
9. A‘s convenience initializer returns.

Convenience initializers are only inherited under certain circumstances. Specifically, for a given subclass to inherit the convenience initializers of its superclass, the subclass must override each of the designated initializers of its superclass. For example B provides the initializer init int:string:, which overrides A‘s designated initializer init int:string: because the initializer name and parameters are the same. If we had some other subclass OtherB of A that did not provide such an override, it would not inherit A‘s convenience initializers:

class OtherB : A {
  var d: Double

  init int(i: Int) string(s: String) double(d: Double) {
    self.d = d                    // initialize stored properties
    super.init(int: i, string: s) // chain to superclass
  }
}

var ob = OtherB()   // error: A's convenience initializer init() not inherited

Note that a subclass may have different designated initializers from its superclass. This can occur in a number of ways. For example, the subclass might override one of its superclass’s designated initializers with a convenience initializer:

class YetAnotherB : A {
  var d: Double

  init int(i: Int) string(s: String) -> Self {
    self.init(int: i, string: s, double: Double(i)) // dispatch
  }

  init int(i: Int) string(s: String) double(d: Double) {
    self.d = d                    // initialize stored properties
    super.init(int: i, string: s) // chain to superclass
  }
}

var yab = YetAnotherB()   // okay: YetAnotherB overrides all of A's designated initializers

In other cases, it’s possible that the convenience initializers of the superclass simply can’t be made to work, because the subclass initializers require additional information provided via a parameter that isn’t present in the convenience initializers of the superclass:

class PickyB : A {
  var notEasy: NoEasyDefault

  init int(i: Int) string(s: String) notEasy(NoEasyDefault) {
    self.notEasy = notEasy
    super.init(int: i, string: s) // chain to superclass
  }
}

Here, PickyB has a stored property of a type NoEasyDefault that can’t easily be given a default value: it has to be provided as a parameter to one of PickyB‘s initializers. Therefore, PickyB takes over responsibility for its own initialization, and none of A‘s convenience initializers will be inherited into PickyB.

Synthesized Initializers¶

When a particular class does not specify any designated initializers, the implementation will synthesize initializers for the class when all of the class’s stored properties have initial values in the class. The form of the synthesized initializers depends on the superclass (if present).

When a superclass is present, the compiler synthesizes a new designated initializer in the subclass for each designated initializer of the superclass. For example, consider the following class C:

class C : B {
  var title: String = "Default Title"
}

The superclass B has a single designated initializer,:

init int(i: Int) string(s: String)

Therefore, the compiler synthesizes the following designated initializer in C, which chains to the corresponding designated initializer in the superclass:

init int(i: Int) string(s: String) {
  // title is already initialized in the class C
  super.init(int: i, string: s)
}

The result of this synthesis is that all designated initializers of the superclass are (automatically) overridden in the subclass, becoming designated initializers of the subclass as well. Therefore, any convenience initializers in the superclass are also inherited, allowing the subclass (C) to be constructed with the same initializers as the superclass (B):

var c1 = C(int: 17, string: "Seventeen")
var c2 = C()

When the class has no superclass, a default initializer (with no parameters) is implicitly defined:

class D {
  var title = "Default Title"

  /* implicitly defined */
  init() { }
}

var d = D() // uses implicitly-defined default initializer

Required Initializers¶

Objects are generally constructed with the construction syntax T(...) used in all of the examples above, where T is the name of the type. However, it is occasionally useful to construct an object for which the actual type is not known until runtime. For example, one might have a View class that expects to be initialized with a specific set of coordinates:

struct Rect {
  var origin: (Int, Int)
  var dimensions: (Int, Int)
}

class View {
  init frame(Rect) { /* initialize view */ }
}

The actual initialization of a subclass of View would then be performed at runtime, with the actual subclass being determined via some external file that describes the user interface. The actual instantiation of the object would use a type value:

func createView(viewClass: View.Type, frame: Rect) -> View {
  return viewClass(frame: frame) // error: 'init frame:' is not 'required'
}

The code above is invalid because there is no guarantee that a given subclass of View will have an initializer init frame:, because the subclass might have taken over its own initialization (as with PickyB, above). To require that all subclasses provide a particular initializer, use the required attribute as follows:

class View {
  @required init frame(Rect) {
    /* initialize view */
  }
}

func createView(viewClass: View.Type, frame: Rect) -> View {
  return viewClass(frame: frame) // okay
}

The required attribute allows the initializer to be used to construct an object of a dynamically-determined subclass, as in the createView method. It places the (transitive) requirement on all subclasses of View to provide an initializer init frame:. For example, the following Button subclass would produce an error:

class Button : View {
  // error: 'Button' does not provide required initializer 'init frame:'.
}

The fix is to implement the required initializer in Button:

class Button : View {
  @required init frame(Rect) { // okay: satisfies requirement
    super.init(frame: frame)
  }
}

Initializers in Protocols¶

Initializers may be declared within a protocol. For example:

protocol DefaultInitializable {
  init()
}

A class can satisfy this requirement by providing a required initializer. For example, only the first of the two following classes conforms to its protocol:

class DefInit : DefaultInitializable {
  @required init() { }
}

class AlmostDefInit : DefaultInitializable {
  init() { } // error: initializer used for protocol conformance must be 'required'
}

The required requirement ensures that all subclasses of the class declaring conformance to the protocol will also have the initializer, so they too will conform to the protocol. This allows one to construct objects given type values of protocol type:

func createAnyDefInit(typeVal: DefaultInitializable.Type) -> DefaultInitializable {
  return typeVal()
}

De-initializers¶

While initializers are responsible for setting up an object’s state, de-initializers are responsible for tearing down that state. Most classes don’t require a de-initializer, because Swift automatically releases all stored properties and calls to the superclass’s de-initializer. However, if your class has allocated a resource that is not an object (say, a Unix file descriptor) or has registered itself during initialization, one can write a de-initializer using deinit:

class FileHandle {
  var fd: Int32

  init withFileDescriptor(fd: Int32) {
    self.fd = fd
  }

  deinit {
    close(fd)
  }
}

The statements within a de-initializer (here, the call to close) execute first, then the superclass’s de-initializer is called. Finally, stored properties are released and the object is deallocated.

Methods Returning Self¶

A class method can have the special return type Self, which refers to the dynamic type of self. Such a method guarantees that it will return an object with the same dynamic type as self. One of the primary uses of the Self return type is for factory methods:

extension View {
  class func createView(frame: Rect) -> Self {
    return self(frame: frame)
  }
}

Within the body of this class method, the implicit parameter self is a value with type View.Type, i.e., it’s a type value for the class View or one of its subclasses. Therefore, the restrictions are the same as for any value of type View.Type: one can call other class methods and construct new objects using required initializers of the class, among other things. The result returned from such a method must be derived from the type of Self. For example, it cannot return a value of type View, because self might refer to some subclass of View.

Instance methods can also return Self. This is typically used to allow chaining of method calls by returning Self from each method, as in the builder pattern:

class DialogBuilder {
  func setTitle(title: String) -> Self {
    // set the title
    return self;
  }

  func setBounds(frame: Rect) -> Self {
    // set the bounds
    return self;
  }
}

var builder = DialogBuilder()
                .setTitle("Hello, World!")
                .setBounds(Rect(0, 0, 640, 480))

Three-Phase Initialization¶

The three-phase initialization model used by Swift’s initializers ensures that all stored properties get initialized before any code can make use of self. This is important uses of self—say, calling a method on self—could end up referring to stored properties before they are initialized. Consider the following Objective-C code, where instance variables are initialized after the call to the the superclass initializer:

@interface A : NSObject
- (instancetype)init;
- (void)finishInit;
@end

@implementation A
- (instancetype)init {
  self = [super init];
  if (self) {
    [self finishInit];
  }
  return self;
}
@end

@interface B : A
@end

@implementation B {
  NSString *ivar;
}

- (instancetype)init {
  self = [super init];
  if (self) {
    self->ivar = @"Default name";
  }
  return self;
}

- (void) finishInit {
  NSLog(@"ivar has the value %@\n", self->ivar);
}
@end

When initializing a B object, the NSLog statement will print:

ivar has the value (null)

because -[B finishInit] executes before B has had a chance to initialize its instance variables. Swift initializers avoid this issue by splitting each initializer into three phases:

1. Initialize stored properties. In this phase, the compiler verifies that self is not used except when writing to the stored properties of the current class (not its superclasses!). Additionally, this initialization directly writes to the storage of the stored properties, and does not call any setter or willSet/didSet method. In this phase, it is not possible to read any of the stored properties.

2. Call to superclass initializer, if any. As with the first step, self cannot be accessed at all.

3. Perform any additional initialization tasks, which may call methods on self, access properties, and so on.

Note that, with this scheme, self cannot be used until the original class and all of its superclasses have initialized their stored properties, closing the memory safety hole.

Initializer Inheritance Model¶

FIXME: To be written

Initializers and Init Methods¶

Designated and Convenience Initializers¶

Allocation and Deallocation¶

Dynamic Subclassing¶

Default¶

I keep going back and forth about having a “default” case-introducer. On the one hand, I kindof want to encourage total matches. On the other hand, (1) having it is consistent with C, (2) it’s not an unnatural style, and (3) there are cases where exhaustive switching isn’t going to be possible. We can certainly recommend complete matches in switches, though.

If we do have a ‘default’, I think it makes the most sense for it to be semantically a complete match and therefore require it to be positioned at the end (on pain of later matches being irrelevant). First, this gives more sensible behavior to ‘default where x.isPurple()’, which really doesn’t seem like it should get reordered with the surrounding cases; and second, it makes the matching story very straightforward. And users who like to put ‘default:’ at the top won’t accidentally get unexpected behavior because coverage checking will immediately complain about the fact that every case after an unguarded ‘default’ is obviously dead.

Case groups¶

A case-group lets you do the same thing for multiple cases without an extra syntactic overhead (like a ‘fallthrough’ after every case). For some types (e.g. classic functional linked lists) this is basically pointless, but for a lot of other types (Int, enums, etc.) it’s pervasive.

The most important semantic design point here is about bound variables in a grouped case, e.g. (using ‘var’ as a “bind this variable” introducer; see the pattern grammar):

switch (pair) {
case (var x, 0):
case (0, var y):
  return 1
case (var x, var y)
  return foo(x-1,y) + foo(x,y-1)
}

It’s tempting to just say that an unsound name binding (i.e. a name not bound in all cases or bound to values of different types) is just always an error, but I think that’s probably not the way to go. There are two things I have in mind here: first, these variables can be useful in pattern guards even if they’re not used in the case block itself, and second, a well-chosen name can make a pattern much more self-documenting. So I think it should only be an error to refer to an unsound name binding.

The most important syntactic design point here is whether to require (or even allow) the ‘case’ keyword to be repeated for each case. In many cases, it can be much more compact to allow a comma-separated list of patterns after ‘case’:

switch (day) {
case .Terrible, .Horrible, .NoGood, .VeryBad:
  abort()
case .ActuallyPrettyReasonableWhenYouLookBackOnIt:
  continue
}

or even more so:

case 0...2, 5...10, 14...18, 22...:
  flagConditionallyAcceptableAge()

On the other hand, if this list gets really long, the wrapping gets a little weird:

case .Terrible, .Horrible, .NoGood, .VeryBad,
     .Awful, .Dreadful, .Appalling, .Horrendous,
     .Deplorable, .Unpleasant, .Ghastly, .Dire:
  abort()

And while I think pattern guards should be able to apply to multiple cases, it would be nice to allow different cases in a group to have different pattern guards:

case .None:
case .Some(var c) where c.isSpace() || c.isASCIIControl():
  skipToEOL()

So really I think we should permit multiple ‘case’ introducers:

case .Terrible, .Horrible, .NoGood, .VeryBad:
case .Awful, .Dreadful, .Appalling, .Horrendous:
case .Deplorable, .Unpleasant, .Ghastly, .Dire:
  abort()

With the rule that a pattern guard can only use bindings that are sound across its guarded patterns (those within the same ‘case’), and the statement itself can only use bindings that are sound across all of the cases. A reference that refers to an unsound binding is an error; lookup doesn’t just ignore the binding.

Scoping¶

Despite the lack of grouping braces, the semantics are that the statements in each case-group form their own scope, and falling off the end causes control to resume at the end of the switch statement — i.e. “implicit break”, not “implicit fallthrough”.

Chris seems motivated to eventually add an explicit ‘fallthrough’ statement. If we did this, my preference would be to generalize it by allowing the match to be reperformed with a new value, e.g. fallthrough(something), at least optionally. I think having local functions removes a lot of the impetus, but not so much as to render the feature worthless.

Syntactically, braces and the choice of case keywords are all bound together. The thinking goes as follows. In Swift, statement scopes are always grouped by braces. It’s natural to group the cases with braces as well. Doing both lets us avoid a ‘case’ keyword, but otherwise it leads to ugly style, because either the last case ends in two braces on the same line or cases have to further indented. Okay, it’s easy enough to not require braces on the match, with the grammar saying that cases are just greedily consumed — there’s no ambiguity here because the switch statement is necessarily within braces. But that leaves the code without a definitive end to the cases, and the closing braces end up causing a lot of unnecessary vertical whitespace, like so:

switch (x)
case .foo {
  …
}
case .bar {
  …
}

So instead, let’s require the switch statement to have braces, and we’ll allow the cases to be written without them:

switch (x) {
case .foo:
  …
case .bar:
  …
}

That’s really a lot prettier, except it breaks the rule about always grouping scopes with braces (we definitely want different cases to establish different scopes). Something has to give, though.

We require the trailing colon because it’s a huge cue for separating things, really making single-line cases visually appealing, and the fact that it doesn’t suggest closing punctuation is a huge boon. It’s also directly precedented in C, and it’s even roughly the right grammatical function.

Case selection semantics¶

The semantics of a switch statement are to first evaluate the value operand, then proceed down the list of case-introducers and execute the statements for the switch-group that had the first satisfied introducer.

It is an error if a case-pattern can never trigger because earlier cases are exhaustive. Some kinds of pattern (like ‘default’ cases and ‘_’) are obviously exhaustive by themselves, but other patterns (like patterns on properties) can be much harder to reason about exhaustiveness for, and of course pattern guards can make this outright undecidable. It may be easiest to apply very straightforward rules (like “ignore guarded patterns”) for the purposes of deciding whether the program is actually ill-formed; anything else that we can prove is unreachable would only merit a warning. We’ll probably also want a way to say explicitly that a case can never occur (with semantics like llvm_unreachable, i.e. a reliable runtime failure unless that kind of runtime safety checking is disabled at compile-time).

A ‘default’ is satisfied if it has no guard or if the guard evaluates to true.

A ‘case’ is satisfied if the pattern is satisfied and, if there’s a guard, the guard evaluates to true after binding variables. The guard is not evaluated if the pattern is not fully satisfied. We’ll talk about satisfying a pattern later.

Non-exhaustive switches¶

Since falling out of a statement is reasonable behavior in an imperative language — in contrast to, say, a functional language where you’re in an expression and you need to produce a value — there’s a colorable argument that non-exhaustive matches should be okay. I dislike this, however, and propose that it should be an error to make an non-exhaustive switch; people who want non-exhaustive matches can explicitly put in default cases. Exhaustiveness actually isn’t that difficult to check, at least over ADTs. It’s also really the behavior that I would expect from the syntax, or at least implicitly falling out seems dangerous in a way that nonexhaustive checking doesn’t. The complications with checking exhaustiveness are pattern guards and matching expressions. The obvious conservatively-safe rule is to say “ignore cases with pattern guards or matching expressions during exhaustiveness checking”, but some people really want to write “where x < 10” and “where x >= 10”, and I can see their point. At the same time, we really don’t want to go down that road.

Var bindings¶

Variable bindings only have a single pattern, which has to be exhaustive, which also means there’s no point in supporting guards here. I think we just get this:

decl-var ::= 'var' attribute-list? pattern-exhaustive value-specifier

Function parameters¶

The functional languages all permit you to directly pattern-match in the function declaration, like this example from SML:

fun length nil = 0
  | length (a::b) = 1 + length b

This is really convenient, but there’s probably no reasonable analogue in Swift. One specific reason: we want functions to be callable with keyword arguments, but if you don’t give all the parameters their own names, that won’t work.

The current Swift approximation is:

func length(list : List) : Int {
  switch list {
    case .nil: return 0
    case .cons(_,var tail): return 1 + length(tail)
  }
}

That’s quite a bit more syntax, but it’s mostly the extra braces from the function body. We could remove those with something like this:

func length(list : List) : Int = switch list {
  case .nil: return 0
  case .cons(_,var tail): return 1 + length(tail)
}

Anyway, that’s easy to add later if we see the need.

Assignment¶

This is a bit iffy. It’s a lot like var bindings, but it doesn’t have a keyword, so it’s really kindof ambiguous given the pattern grammar.

Also, l-value patterns are weird. I can come up with semantics for this, but I don’t know what the neighbors will think:

var perimeter : double
.feet(x) += yard.dimensions.height // returns Feet, which has one constructor, :feet.
.feet(x) += yard.dimensions.width

It’s probably better to just have l-value tuple expressions and not try to work in arbitrary patterns.

Pattern-match expression¶

This is an attempt to provide that dispensation for query functions we were talking about.

I think this should bind looser than any binary operators except assignments; effectively we should have:

expr-binary ::= # most of the current expr grammar

expr ::= expr-binary
expr ::= expr-binary 'is' expr-primary pattern-guard?

The semantics are that this evaluates to true if the pattern and pattern-guard are satisfied.

if s is Window where x.isVisible {
  // can use Window methods on x here
}

if x is Window && x.isVisible { ... }

Two kinds of pattern¶

We’re blurring the distinction between patterns and expressions a lot here. My current thinking is that this simplifies things for the programmer — the user concept becomes basically “check whether we’re equal to this expression, but allow some holes and some more complex ‘matcher’ values”. But it’s possible that it instead might be really badly confusing. We’ll see! It’ll be fun!

This kindof forces us to have parallel pattern grammars for the two major clients:

• Match patterns are used in switch and matches, where we’re decomposing something with a real possibility of failing. This means that expressions are okay in leaf positions, but that name-bindings need to be explicitly advertised in some way to reasonably disambiguate them from expressions.
• Exhaustive patterns are used in var declarations and function signatures. They’re not allowed to be non-exhaustive, so having a match expression doesn’t make any sense. Name bindings are common and so shouldn’t be penalized.

You might think that having a “pattern” as basic as foo mean something different in two different contexts would be confusing, but actually I don’t think people will generally think of these as the same production — you might if you were in a functional language where you really can decompose in a function signature, but we don’t allow that, and I think that will serve to divide them in programmers’ minds. So we can get away with some things. :)

Binding patterns¶

In general, a lot of these productions are the same, so I’m going to talk about *-patterns, with some specific special rules that only apply to specific pattern kinds.

*-pattern ::= '_'

A single-underscore identifier is always an “ignore” pattern. It matches anything, but does not bind it to a variable.

exhaustive-pattern ::= identifier
match-pattern ::= '?' identifier

Any more complicated identifier is a variable-binding pattern. It is illegal to bind the same identifier multiple times within a pattern. However, the variable does come into scope immediately, so in a match pattern you can have a latter expression which refers to an already-bound variable. I’m comfortable with constraining this to only work “conveniently” left-to-right and requiring more complicated matches to use guard expressions.

In a match pattern, variable bindings must be prefixed with a ? to disambiguate them from an expression consisting of a variable reference. I considered using ‘var’ instead, but using punctuation means we don’t need a space, which means this is much more compact in practice.

Annotation patterns¶

exhaustive-pattern ::= exhaustive-pattern ':' type

In an exhaustive pattern, you can annotate an arbitrary sub-pattern with a type. This is useful in an exhaustive pattern: the type of a variable isn’t always inferrable (or correctly inferrable), and types in function signatures are generally outright required. It’s not as useful in a match pattern, and the colon can be grammatically awkward there, so we disallow it.

‘is’ patterns¶

match-pattern ::= 'is' type

This pattern is satisfied if the dynamic type of the matched value “satisfies” the named type:

• if the named type is an Objective-C class type, the dynamic type must be a class type, and an ‘isKindOf:’ check is performed;
• if the named type is a Swift class type, the dynamic type must be a class type, and a subtype check is performed;
• if the named type is a metatype, the dynamic type must be a metatype, and the object type of the dynamic type must satisfy the object type of the named type;
• otherwise the named type must equal the dynamic type.

This inquiry is about dynamic types; archetypes and existentials are looked through.

The pattern is ill-formed if it provably cannot be satisfied.

In a ‘switch’ statement, this would typically appear like this:

case is NSObject:

It can, however, appear in recursive positions:

case (is NSObject, is NSObject):

case is NSObject:

case NSObject:

case NSObject.type:

while expr is ParenExpr {
  expr = expr.getSubExpr()
}

“Call” patterns¶

match-pattern ::= match-pattern-identifier match-pattern-tuple?
match-pattern-identifier ::= '.' identifier
match-pattern-identifier ::= match-pattern-identifier-tower
match-pattern-identifier-tower ::= identifier
match-pattern-identifier-tower ::= identifier
match-pattern-identifier-tower ::= match-pattern-identifier-tower '.' identifier

A match pattern can resemble a global name or a call to a global name. The global name is resolved as normal, and then the pattern is interpreted according to what is found:

• If the name resolves to a type, then the dynamic type of the matched value must match the named type (according to the rules below for ‘is’ patterns). It is okay for this to be trivially true.

  In addition, there must be an non-empty arguments clause, and each element in the clause must have an identifier. For each element, the identifier must correspond to a known property of the named type, and the value of that property must satisfy the element pattern.

• If the name resolves to a enum element, then the dynamic type of the matched value must match the enum type as discussed above, and the value must be of the specified element. There must be an arguments clause if and only if the element has a value type. If so, the value of the element is matched against the clause pattern.

• Otherwise, the argument clause (if present) must also be syntactically valid as an expression, and the entire pattern is reinterpreted as an expression.

This is all a bit lookup-sensitive, which makes me uncomfortable, but otherwise I think it makes for attractive syntax. I’m also a little worried about the way that, say, f(x) is always an expression but A(x) is a pattern. Requiring property names when matching properties goes some way towards making that okay.

I’m not totally sold on not allowing positional matching against struct elements; that seems unfortunate in cases where positionality is conventionally unambiguous, like with a point.

Matching against struct types requires arguments because this is intended to be used for structure decomposition, not dynamic type testing. For the latter, an ‘is’ pattern should be used.

Expression patterns¶

match-pattern ::= expression

When ambiguous, match patterns are interpreted using a pattern-specific production. I believe it should be true that, in general, match patterns for a production accept a strict superset of valid expressions, so that (e.g.) we do not need to disambiguate whether an open paren starts a tuple expression or a tuple pattern, but can instead just aggressively parse as a pattern. Note that binary operators can mean that, using this strategy, we sometimes have to retroactively rewrite a pattern as an expression.

It’s always possible to disambiguate something as an expression by doing something not allowing in patterns, like using a unary operator or calling an identity function; those seem like unfortunate language solutions, though.

Satisfying an expression pattern¶

A value satisfies an expression pattern if the match operation succeeds. I think it would be natural for this match operation to be spelled the same way as that match-expression operator, so e.g. a member function called ‘matches’ or a global binary operator called ‘~’ or whatever.

The lookup of this operation poses some interesting questions. In general, the operation itself is likely to be associated with the intended type of the expression pattern, but that type will often require refinement from the type of the matched value.

For example, consider a pattern like this:

case 0...10:

We should be able to use this pattern when switching on a value which is not an Int, but if we type-check the expression on its own, we will assign it the type Range<Int>, which will not necessarily permit us to match (say) a UInt8.

Order of evaluation of patterns¶

I’d like to keep the order of evaluation and testing of expressions within a pattern unspecified if I can; I imagine that there should be a lot of cases where we can rule out a case using a cheap test instead of a more expensive one, and it would suck to have to run the expensive one just to have cleaner formal semantics. Specifically, I’m worried about cases like case [foo(), 0]:; if we can test against 0 before calling foo(), that would be great. Also, if a name is bound and then used directly as an expression later on, it would be nice to have some flexibility about which value is actually copied into the variable, but this is less critical.

*-pattern ::= *-pattern-tuple
*-pattern-tuple ::= '(' *-pattern-tuple-element-list? '...'? ')'
*-pattern-tuple-element-list ::= *-pattern-tuple-element
*-pattern-tuple-element-list ::= *-pattern-tuple-element ',' pattern-tuple-element-list
*-pattern-tuple-element ::= *-pattern
*-pattern-tuple-element ::= identifier '=' *-pattern

Tuples are interesting because of the labelled / non-labelled distinction. Especially with labelled elements, it is really nice to be able to ignore all the elements you don’t care about. This grammar permits some prefix or set of labels to be matched and the rest to be ignored.