This document describes the user-facing API and internal implementation of proto2 and proto3 messages in Apple’s Swift programming language.
One of the key goals of protobufs is to provide idiomatic APIs for each language. In that vein, interoperability with Objective-C is a non-goal of this proposal. Protobuf users who need to pass messages between Objective-C and Swift code in the same application should use the existing Objective-C proto library. The goal of the effort described here is to provide an API for protobuf messages that uses features specific to Swift—optional types, algebraic enumerated types, value types, and so forth—in a natural way that will delight, rather than surprise, users of the language.
By convention, both typical protobuf message names and Swift structs/classes are UpperCamelCase, so for most messages, the name of a message can be the same as the name of its generated type. (However, see the discussion below about prefixes under Packages.)
Enum cases in protobufs typically are UPPERCASE_WITH_UNDERSCORES, whereas in Swift they are lowerCamelCase (as of the Swift 3 API design guidelines). We will transform the names to match Swift convention, using a whitelist similar to the Objective-C compiler plugin to handle commonly used acronyms.
Typical fields in proto messages are lowercase_with_underscores, while in Swift they are lowerCamelCase. We will transform the names to match Swift convention by removing the underscores and uppercasing the subsequent letter.
Swift has a large set of reserved words—some always reserved and some contextually reserved (that is, they can be used as identifiers in contexts where they would not be confused). As of Swift 2.2, the set of always-reserved words is:
_, #available, #column, #else, #elseif, #endif, #file, #function, #if, #line, #selector, as, associatedtype, break, case, catch, class, continue, default, defer, deinit, do, dynamicType, else, enum, extension, fallthrough, false, for, func, guard, if, import, in, init, inout, internal, is, let, nil, operator, private, protocol, public, repeat, rethrows, return, self, Self, static, struct, subscript, super, switch, throw, throws, true, try, typealias, var, where, while
The set of contextually reserved words is:
associativity, convenience, dynamic, didSet, final, get, infix, indirect, lazy, left, mutating, none, nonmutating, optional, override, postfix, precedence, prefix, Protocol, required, right, set, Type, unowned, weak, willSet
It is possible to use any reserved word as an identifier by escaping it with backticks (for example, let `class` = 5). Other name-mangling schemes would require us to transform the names themselves (for example, by appending an underscore), which requires us to then ensure that the new name does not collide with something else in the same namespace.
While the backtick feature may not be widely known by all Swift developers, a small amount of user education can address this and it seems like the best approach. We can unconditionally surround all property names with backticks to simplify generation.
Some remapping will still be required, though, to avoid collisions between generated properties and the names of methods and properties defined in the base protocol/implementation of messages.
This section describes how the features of the protocol buffer syntaxes (proto2 and proto3) map to features in Swift—what the code generated from a proto will look like, and how it will be implemented in the underlying library.
Modules are the main form of namespacing in Swift, but they are not declared using syntactic constructs like namespaces in C++ or packages in Java. Instead, they are tied to build targets in Xcode (or, in the future with open-source Swift, declarations in a Swift Package Manager manifest). They also do not easily support nesting submodules (Clang module maps support this, but pure Swift does not yet provide a way to define submodules).
We will generate types with fully-qualified underscore-delimited names. For example, a message Baz in package foo.bar would generate a struct named Foo_Bar_Baz. For each fully-qualified proto message, there will be exactly one unique type symbol emitted in the generated binary.
Users are likely to balk at the ugliness of underscore-delimited names for every generated type. To improve upon this situation, we will add a new string file level option, swift_package_typealias, that can be added to .proto files. When present, this will cause typealiases to be added to the generated Swift messages that replace the package name prefix with the provided string. For example, the following .proto file:
option swift_package_typealias = "FBP"; package foo.bar; message Baz { // Message fields }
would generate the following Swift source:
public struct Foo_Bar_Baz { // Message fields and other methods } typealias FBPBaz = Foo_Bar_Baz
It should be noted that this type alias is recorded in the generated .swiftmodule so that code importing the module can refer to it, but it does not cause a new symbol to be generated in the compiled binary (i.e., we do not risk compiled size bloat by adding typealiases for every type).
Other strategies to handle packages that were considered and rejected can be found in Appendix A.
Proto messages are natural value types and we will generate messages as structs instead of classes. Users will benefit from Swift’s built-in behavior with regard to mutability. We will define a ProtoMessage protocol that defines the common methods and properties for all messages (such as serialization) and also lets users treat messages polymorphically. Any shared method implementations that do not differ between individual messages can be implemented in a protocol extension.
The backing storage itself for fields of a message will be managed by a ProtoFieldStorage type that uses an internal dictionary keyed by field number, and whose values are the value of the field with that number (up-cast to Swift’s Any type). This class will provide type-safe getters and setters so that generated messages can manipulate this storage, and core serialization logic will live here as well. Furthermore, factoring the storage out into a separate type, rather than inlining the fields as stored properties in the message itself, lets us implement copy-on-write efficiently to support passing around large messages. (Furthermore, because the messages themselves are value types, inlining fields is not possible if the fields are submessages of the same type, or a type that eventually includes a submessage of the same type.)
Required fields in proto2 messages seem like they could be naturally represented by non-optional properties in Swift, but this presents some problems/concerns.
Serialization APIs permit partial serialization, which allows required fields to remain unset. Furthermore, other language APIs still provide has* and clear* methods for required fields, and knowing whether a property has a value when the message is in memory is still useful.
For example, an e-mail draft message may have the “to” address required on the wire, but when the user constructs it in memory, it doesn’t make sense to force a value until they provide one. We only want to force a value to be present when the message is serialized to the wire. Using non-optional properties prevents this use case, and makes client usage awkward because the user would be forced to select a sentinel or placeholder value for any required fields at the time the message was created.
In proto2, fields can have a default value specified that may be a value other than the default value for its corresponding language type (for example, a default value of 5 instead of 0 for an integer). When reading a field that is not explicitly set, the user expects to get that value. This makes Swift optionals (i.e., Foo?) unsuitable for fields in general. Unfortunately, we cannot implement our own “enhanced optional” type without severely complicating usage (Swift’s use of type inference and its lack of implicit conversions would require manual unwrapping of every property value).
Instead, we can use implicitly unwrapped optionals. For example, a property generated for a field of type int32 would have Swift type Int32!. These properties would behave with the following characteristics, which mirror the nil-resettable properties used elsewhere in Apple’s SDKs (for example, UIView.tintColor):
The final point in the list above implies that the optional cannot be checked to determine if the field is set to a value other than its default: it will never be nil. Instead, we must provide has* methods for each field to allow the user to check this. These methods will be public in proto2. In proto3, these methods will be private (if generated at all), since the user can test the returned value against the zero value for that type.
For convenience, dotting into an unset field representing a nested message will return an instance of that message with default values. As in the Objective-C implementation, this does not actually cause the field to be set until the returned message is mutated. Fortunately, thanks to the way mutability of value types is implemented in Swift, the language automatically handles the reassignment-on-mutation for us. A static singleton instance containing default values can be associated with each message that can be returned when reading, so copies are only made by the Swift runtime when mutation occurs. For example, given the following proto:
message Node { Node child = 1; string value = 2 [default = "foo"]; }
The following Swift code would act as commented, where setting deeply nested properties causes the copies and mutations to occur as the assignment statement is unwound:
var node = Node() let s = node.child.child.value // 1. node.child returns the "default Node". // 2. Reading .child on the result of (1) returns the same default Node. // 3. Reading .value on the result of (2) returns the default value "foo". node.child.child.value = "bar" // 4. Setting .value on the default Node causes a copy to be made and sets // the property on that copy. Subsequently, the language updates the // value of "node.child.child" to point to that copy. // 5. Updating "node.child.child" in (4) requires another copy, because // "node.child" was also the instance of the default node. The copy is // assigned back to "node.child". // 6. Setting "node.child" in (5) is a simple value reassignment, since // "node" is a mutable var.
In other words, the generated messages do not internally have to manage parental relationships to backfill the appropriate properties on mutation. Swift provides this for free.
Proto scalar value fields will map to Swift types in the following way:
| .proto Type | Swift Type |
|---|---|
double | Double |
float | Float |
int32 | Int32 |
int64 | Int64 |
uint32 | UInt32 |
uint64 | UInt64 |
sint32 | Int32 |
sint64 | Int64 |
fixed32 | UInt32 |
fixed64 | UInt64 |
sfixed32 | Int32 |
sfixed64 | Int64 |
bool | Bool |
string | String |
bytes | Foundation.NSData |
The proto spec defines a number of integral types that map to the same Swift type; for example, intXX, sintXX, and sfixedXX are all signed integers, and uintXX and fixedXX are both unsigned integers. No other language implementation distinguishes these further, so we do not do so either. The rationale is that the various types only serve to distinguish how the value is encoded on the wire; once loaded in memory, the user is not concerned about these variations.
Swift’s lack of implicit conversions among types will make it slightly annoying to use these types in a context expecting an Int, or vice-versa, but since this is a data-interchange format with explicitly-sized fields, we should not hide that information from the user. Users will have to explicitly write Int(message.myField), for example.
Embedded message fields can be represented using an optional variable of the generated message type. Thus, the message
message Foo { Bar bar = 1; }
would be represented in Swift as
public struct Foo: ProtoMessage { public var bar: Bar! { get { ... } set { ... } } }
If the user explicitly sets bar to nil, or if it was never set when read from the wire, retrieving the value of bar would return a default, statically allocated instance of Bar containing default values for its fields. This achieves the desired behavior for default values in the same way that scalar fields are designed, and also allows users to deep-drill into complex object graphs to get or set fields without checking for nil at each step.
The design and implementation of enum fields will differ somewhat drastically depending on whether the message being generated is a proto2 or proto3 message.
For proto2, we do not need to be concerned about unknown enum values, so we can use the simple raw-value enum syntax provided by Swift. So the following enum in proto2:
enum ContentType { TEXT = 0; IMAGE = 1; }
would become this Swift enum:
public enum ContentType: Int32, NilLiteralConvertible { case text = 0 case image = 1 public init(nilLiteral: ()) { self = .text } }
See below for the discussion about NilLiteralConvertible.
For proto3, we need to be able to preserve unknown enum values that may come across the wire so that they can be written back if unmodified. We can accomplish this in Swift by using a case with an associated value for unknowns. So the following enum in proto3:
enum ContentType { TEXT = 0; IMAGE = 1; }
would become this Swift enum:
public enum ContentType: RawRepresentable, NilLiteralConvertible { case text case image case UNKNOWN_VALUE(Int32) public typealias RawValue = Int32 public init(nilLiteral: ()) { self = .text } public init(rawValue: RawValue) { switch rawValue { case 0: self = .text case 1: self = .image default: self = .UNKNOWN_VALUE(rawValue) } public var rawValue: RawValue { switch self { case .text: return 0 case .image: return 1 case .UNKNOWN_VALUE(let value): return value } } }
Note that the use of a parameterized case prevents us from inheriting from the raw Int32 type; Swift does not allow an enum with a raw type to have cases with arguments. Instead, we must implement the raw value initializer and computed property manually. The UNKNOWN_VALUE case is explicitly chosen to be “ugly” so that it stands out and does not conflict with other possible case names.
Using this approach, proto3 consumers must always have a default case or handle the .UNKNOWN_VALUE case to satisfy case exhaustion in a switch statement; the Swift compiler considers it an error if switch statements are not exhaustive.
This is required to clean up the usage of enum-typed properties in switch statements. Unlike other field types, enum properties cannot be implicitly-unwrapped optionals without requiring that uses in switch statements be explicitly unwrapped. For example, if we consider a message with the enum above, this usage will fail to compile:
// Without NilLiteralConvertible conformance on ContentType public struct SomeMessage: ProtoMessage { public var contentType: ContentType! { ... } } // ERROR: no case named text or image switch someMessage.contentType { case .text: { ... } case .image: { ... } }
Even though our implementation guarantees that contentType will never be nil, if it is an optional type, its cases would be some and none, not the cases of the underlying enum type. In order to use it in this context, the user must write someMessage.contentType! in their switch statement.
Making the enum itself NilLiteralConvertible permits us to make the property non-optional, so the user can still set it to nil to clear it (i.e., reset it to its default value), while eliminating the need to explicitly unwrap it in a switch statement.
// With NilLiteralConvertible conformance on ContentType public struct SomeMessage: ProtoMessage { // Note that the property type is no longer optional public var contentType: ContentType { ... } } // OK: Compiles and runs as expected switch someMessage.contentType { case .text: { ... } case .image: { ... } } // The enum can be reset to its default value this way someMessage.contentType = nil
One minor oddity with this approach is that nil will be auto-converted to the default value of the enum in any context, not just field assignment. In other words, this is valid:
func foo(contentType: ContentType) { ... } foo(nil) // Inside foo, contentType == .text
That being said, the advantage of being able to simultaneously support nil-resettability and switch-without-unwrapping outweighs this side effect, especially if appropriately documented. It is our hope that a new form of resettable properties will be added to Swift that eliminates this inconsistency. Some community members have already drafted or sent proposals for review that would benefit our designs:
The allow_alias option in protobuf slightly complicates the use of Swift enums to represent that type, because raw values of cases in an enum must be unique. Swift lets us define static variables in an enum that alias actual cases. For example, the following protobuf enum:
enum Foo { option allow_alias = true; BAR = 0; BAZ = 0; }
will be represented in Swift as:
public enum Foo: Int32, NilLiteralConvertible { case bar = 0 static public let baz = bar // ... etc. } // Can still use .baz shorthand to reference the alias in contexts // where the type is inferred
That is, we use the first name as the actual case and use static variables for the other aliases. One drawback to this approach is that the static aliases cannot be used as cases in a switch statement (the compiler emits the error “Enum case ‘baz’ not found in type ‘Foo’”). However, in our own code bases, there are only a few places where enum aliases are not mere renamings of an older value, but they also don’t appear to be the type of value that one would expect to switch on (for example, a group of named constants representing metrics rather than a set of options), so this restriction is not significant.
This strategy also implies that changing the name of an enum and adding the old name as an alias below the new name will be a breaking change in the generated Swift code.
The oneof feature represents a “variant/union” data type that maps nicely to Swift enums with associated values (algebraic types). These fields can also be accessed independently though, and, specifically in the case of proto2, it’s reasonable to expect access to default values when accessing a field that is not explicitly set.
Taking all this into account, we can represent a oneof in Swift with two sets of constructs:
oneof fields.oneof and which provides the corresponding field values as case arguments.This approach fulfills the needs of proto consumers by providing a Swift-idiomatic way of simultaneously checking which field is set and accessing its value, providing individual properties to access the default values (important for proto2), and safely allows a field to be moved into a oneof without breaking clients.
Consider the following proto:
message MyMessage { oneof record { string name = 1 [default = "unnamed"]; int32 id_number = 2 [default = 0]; } }
In Swift, we would generate an enum, a property for that enum, and properties for the fields themselves:
public struct MyMessage: ProtoMessage { public enum Record: NilLiteralConvertible { case name(String) case idNumber(Int32) case NOT_SET public init(nilLiteral: ()) { self = .NOT_SET } } // This is the "Swifty" way of accessing the value public var record: Record { ... } // Direct access to the underlying fields public var name: String! { ... } public var idNumber: Int32! { ... } }
This makes both usage patterns possible:
// Usage 1: Case-based dispatch switch message.record { case .name(let name): // Do something with name if it was explicitly set case .idNumber(let id): // Do something with id_number if it was explicitly set case .NOT_SET: // Do something if it’s not set } // Usage 2: Direct access for default value fallback // Sets the label text to the name if it was explicitly set, or to // "unnamed" (the default value for the field) if id_number was set // instead let myLabel = UILabel() myLabel.text = message.name
As with proto enums, the generated oneof enum conforms to NilLiteralConvertible to avoid switch statement issues. Setting the property to nil will clear it (i.e., reset it to NOT_SET).
To be written.
To be written.
We will not include reflection or descriptors in the first version of the Swift library. The use cases for reflection on mobile are not as strong and the static data to represent the descriptors would add bloat when we wish to keep the code size small.
In the future, we will investigate whether they can be included as extensions which might be able to be excluded from a build and/or automatically dead stripped by the compiler if they are not used.
Each proto package could be declared as its own Swift module, replacing dots with underscores (e.g., package foo.bar becomes module Foo_Bar). Then, users would simply import modules containing whatever proto modules they want to use and refer to the generated types by their short names.
This solution is simply not possible, however. Swift modules cannot circularly reference each other, but there is no restriction against proto packages doing so. Circular imports are forbidden (e.g., foo.proto importing bar.proto importing foo.proto), but nothing prevents package foo from using a type in package bar which uses a different type in package foo, as long as there is no import cycle. If these packages were generated as Swift modules, then Foo would contain an import Bar statement and Bar would contain an import Foo statement, and there is no way to compile this.
We can “fake” namespaces in Swift by declaring empty structs with private initializers. Since modules are constructed based on compiler arguments, not by syntactic constructs, and because there is no pure Swift way to define submodules (even though Clang module maps support this), there is no source-drive way to group generated code into namespaces aside from this approach.
Types can be added to those intermediate package structs using Swift extensions. For example, a message Baz in package foo.bar could be represented in Swift as follows:
public struct Foo { private init() {} } public extension Foo { public struct Bar { private init() {} } } public extension Foo.Bar { public struct Baz { // Message fields and other methods } } let baz = Foo.Bar.Baz()
Each of these constructs would actually be defined in a separate file; Swift lets us keep them separate and add multiple structs to a single “namespace” through extensions.
Unfortunately, these intermediate structs generate symbols of their own (metatype information in the data segment). This becomes problematic if multiple build targets contain Swift sources generated from different messages in the same package. At link time, these symbols would collide, resulting in multiple definition errors.
This approach also has the disadvantage that there is no automatic “short” way to refer to the generated messages at the deepest nesting levels; since this use of structs is a hack around the lack of namespaces, there is no equivalent to import (Java) or using (C++) to simplify this. Users would have to declare type aliases to make this cleaner, or we would have to generate them for users.