> On Jan 26, 2017, at 3:12 AM, Dale Buckley <dale.buck...@monitisecreate.com> 
> wrote:
>> I put together a document compiling many conversations with many people 
>> about Swift’s ABI and what needs to happen prior to ABI stability. It is 
>> meant to be a blueprint for the project on how to approach and achieve ABI 
>> stability, as well as a resource to the community. It can be viewed fully 
>> rendered (and updated) 
>> athttps://github.com/apple/swift/blob/master/docs/ABIStabilityManifesto.md
>> Below is the raw markdown:
>> # Swift ABI Stability Manifesto
>> * Authors: [Michael Ilseman](https://github.com/milseman) (compiled through 
>> conversations with many others)
>> ## Introduction
>> ### The Big Picture
>> One of the top priorities for Swift right now is compatibility across future 
>> Swift versions. Compatibility aims at accomplishing two goals:
>> 1. *Source compatibility* means that newer compilers can compile code 
>> written in an older version of Swift. This aims to reduce the migration pain 
>> that Swift developers face when migrating to a newer Swift version. Without 
>> source compatibility, projects face version-lock where all source code in a 
>> project and its packages must be written in the same version of Swift. With 
>> source compatibility, package authors will be able to maintain a single code 
>> base across multiple Swift versions while allowing their users to use a 
>> newer version of Swift.
>> 2. *Binary framework&runtime compatibility* enables the distribution of 
>> frameworks in a binary form that works across multiple Swift versions. 
>> Binary frameworks include both a *Swift module file*, which communicates 
>> source-level information of the framework's API, and a *shared library*, 
>> which provides the compiled implementation that is loaded at runtime. Thus, 
>> there are two necessary goals for binary framework compatibility:
>> * *Module format stability* stabilizes the module file, which is the 
>> compiler's representation of the public interfaces of a framework. This 
>> includes API declarations and inlineable code. The module file is used by 
>> the compiler for necessary tasks such as type checking and code generation 
>> when compiling client code using a framework.
>> * *ABI stability* enables binary compatibility between applications and 
>> libraries compiled with different Swift versions. It is the focus of the 
>> rest of this document.
>> This document is an exploration and explanation of Swift's ABI alongside the 
>> goals and investigations needed before declaring Swift's ABI stable. It is 
>> meant to be a resource to the community as well as a declaration of the 
>> direction of Swift's ABI.
>> Throughout this document there will be references to issues in Swift's 
>> [issue tracking system](https://bugs.swift.org) denoted by "SR-xxxx". These 
>> references track open engineering and design tasks for Swift's ABI.
>> ### What Is ABI?
>> At runtime, Swift program binaries interact with other libraries and 
>> components through an ABI. ABI is Application Binary Interface, or the 
>> specification to which independently compiled binary entities must conform 
>> to be linked together and executed. These binary entities must agree on many 
>> low level details: how to call functions, how their data is represented in 
>> memory, and even where their metadata is and how to access it.
>> ABI is per-platform, as it is a low level concern influenced by both the 
>> architecture and the OS. Most platform vendors define a "standard ABI" which 
>> is used for C code and built on by C-family languages. Swift, however, is a 
>> very different language from C and has its own per-platform ABI. While most 
>> of this document is platform-agnostic, platform-specific concerns have 
>> influenced details of the design and implementation of Swift's ABI. For 
>> details on each platform's standard ABI, refer to the 
>> [Appendix](#platform-abis).
>> ### What Is ABI Stability?
>> ABI stability means locking down the ABI to the point that future compiler 
>> versions can produce binaries conforming to the stable ABI. Once an ABI is 
>> stable, it tends to persist for the rest of the platform's lifetime due to 
>> ever-increasing mutual dependencies.
>> ABI stability only affects invariants of externally visible public 
>> interfaces and symbols. Internal symbols, conventions, and layout can 
>> continue to change without breaking the ABI. For example, future compilers 
>> are free to change the calling conventions for internal function calls so 
>> long as the public interfaces are preserved.
>> Decisions about the ABI will have long-term ramifications and may limit the 
>> ways in which the language can grow and evolve in the future. Future Swift 
>> versions can add new, orthogonal aspects to the ABI, but any inefficiencies 
>> or inflexibilities present when stability is declared will (effectively) 
>> persist forever for that platform.
>> ABI changes that are new and orthogonal are called *ABI-additive* changes. 
>> ABI-additive changes may be taken advantage of when the minimum targeted 
>> Swift version supports them. This allows us to extend or progressively lock 
>> down more of the ABI. These may be ABI additions to support new features or 
>> that allow for more efficient data access. Examples appear throughout this 
>> document.
>> ### What Does ABI Stability Enable?
>> ABI stability enables OS vendors to embed a Swift standard library and 
>> runtime that is compatible with applications built with older or newer 
>> versions of Swift. This would remove the need for apps to distribute their 
>> own copy of these libraries on those platforms. It also allows for better 
>> decoupling of tools and better integration into the OS.
>> As noted earlier, ABI stability is necessary, though not sufficient, for 
>> binary frameworks. Module format stability is also required and is beyond 
>> the scope of this document.
>> ### Library Evolution
>> Expressive and performance-focused languages which have binary interfaces 
>> tend to exhibit the [fragile binary interface 
>> problem](https://en.wikipedia.org/wiki/Fragile_binary_interface_problem), 
>> which makes it difficult for any library or component to change over time 
>> without requiring every user to recompile with new versions of that library. 
>> A major push in Swift currently is the plan for [Library 
>> Evolution](https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst),
>>  which aims to grant flexibility for library authors to maintain backwards 
>> and forwards binary compatibility. Many implementation concerns therein 
>> could have an impact on ABI.
>> One of the goals of rolling out ABI stability is to remain flexible enough 
>> to accommodate library evolution changes without limiting the design space. 
>> Library evolution concerns will be addressed in each individual section, 
>> though a common refrain will be that the details are still undecided.
>> ## Components of the Swift ABI
>> In practice, ABI concerns can be tightly coupled. But, as a conceptual 
>> model, I'd like to break them out into 6 separate classifications:
>> 1. Types, such as structs and classes, must have a defined in-memory layout 
>> for instances of that type. For binary entities to interoperate, they must 
>> share the same layout conventions. This layout is discussed in the [Data 
>> Layout](#data-layout) section.
>> 2. Type metadata is used extensively by Swift programs, the Swift runtime, 
>> reflection, and tools such as debuggers and visualizers. This metadata must 
>> either have a defined memory layout, or have a set of defined APIs for 
>> querying the metadata of a type. Type metadata is discussed in the [Type 
>> Metadata](#metadata) section.
>> 3. Every exported or external symbol in a library needs a unique name upon 
>> which binary entities can agree. Swift provides function overloading and 
>> contextual name spaces (such as modules and types), which means that any 
>> name in source code might not be globally unique. A unique name is produced 
>> through a technique called *name mangling*. Swift's name mangling scheme is 
>> discussed in the [Mangling](#mangling) section.
>> 4. Functions must know how to call each other, which entails such things as 
>> the layout of the call stack, what registers are preserved, and ownership 
>> conventions. Calling conventions are discussed in the [Calling 
>> Convention](#calling-convention) section.
>> 5. Swift ships with a runtime library which handles such things as dynamic 
>> casting, reference counting, reflection, etc. Compiled Swift programs make 
>> external calls out to this runtime. Thus, Swift runtime API is Swift ABI. 
>> Runtime API stability is discussed in the [Runtime](#runtime) section.
>> 6. Swift ships with a standard library that defines many common types, 
>> structures, and operations on these. For a shipped standard library to work 
>> with applications written in different versions of Swift, it must expose a 
>> stable API. Thus, Swift Standard Library API is Swift ABI, as well as the 
>> layout of many of the types it defines. Swift standard library ABI stability 
>> concerns are discussed in the [Standard Library](#standard-library) section.
>> ##<a name="type-layout"></a>Data Layout
>> ### Background
>> First, let's define some common terminology.
>> * An *object* is a stored entity of some type, meaning it has a location in 
>> memory or in registers. Objects can be values of struct/enum type, class 
>> instances, references to class instances, values of protocol type, or even 
>> closures. This is [in contrast 
>> to](https://en.wikipedia.org/wiki/Object_(computer_science))the 
>> class-based-OO definition of object as being an instance of a class.
>> * A *data member* of an object is any value that requires layout within the 
>> object itself. Data members include an object's stored properties and 
>> associated values.
>> * A *spare bit* is a bit that is unused by objects of a given type. These 
>> often arise due to things such as alignment, padding, and address spaces, 
>> further described below.
>> * An *extra inhabitant* is a bit pattern that does not represent a valid 
>> value for objects of a given type. For example, a simple C-like enum with 3 
>> cases can fit in 2 bits, where it will have one extra inhabitant: the fourth 
>> unused bit pattern.
>> *Data layout*, also known as type layout, specifies the in-memory layout of 
>> an object's data. This includes the size of an object in memory, the 
>> alignment of an object (defined later), and how to find each data member 
>> within an object.
>> An object has a statically known layout if the compiler is able to determine 
>> its layout at compilation time. Objects whose layout is not determinable 
>> until runtime have *opaque layout*. Such objects are further discussed in 
>> the [opaque layout section](#opaque-layout)
>> #### Layout and Properties of Types
>> For every type `T` in Swift with statically known layout, the ABI specifies 
>> a means to determine:
>> * The *alignment* for that type: for `x : T`, the address of `x` modulo 
>> alignment is always zero.
>> * The *size* for that type: the byte size (possibly 0) without padding at 
>> the end.
>> * The *offset* for each data member (if applicable): the address at which 
>> every member resides, relative to the object's base address.
>> Derived from alignment and size is the *stride* of the type, which is the 
>> size of objects of that type rounded up to alignment (minimum 1). The stride 
>> is mostly useful for objects laid out contiguously in memory, such as in 
>> arrays.
>> <a name="type-properties"></a>Some types have interesting properties:
>> * A type is *trivial*, also known as POD ("plain ol' data"), if it merely 
>> stores data and has no extra copy, move, or destruction semantics. Trivial 
>> objects can be copied by replicating their bits, and are destroyed through 
>> deallocation. A type is trivial only if all data members are also trivial.
>> * A type is *bitwise movable* if there are no side table references 
>> dependent on its address. A 
>> [move](https://doc.rust-lang.org/book/ownership.html#move-semantics) 
>> operation can occur when an object is copied from one location into another 
>> and the original location is no longer used. Bitwise movable objects are 
>> moved by performing a bitwise copy and then invalidating the original 
>> location. A type is bitwise movable only if all its data members are also 
>> bitwise movable. All trivial types are bitwise movable.
>> An example of a trivial type is a Point struct that contains two Double 
>> fields: an x coordinate and a y coordinate. This struct is trivial, as it 
>> can be copied merely by copying its bits and its destruction performs no 
>> extra operations.
>> An example of a bitwise movable, but non-trivial, type is a struct that 
>> contains a reference to a class instance. Objects of that type cannot be 
>> copied merely by copying their bits, because a retain operation must be 
>> performed on the reference. Upon destruction, such objects must perform a 
>> release. However, the object can be moved from one address to another by 
>> copying its bits provided the original location is invalidated, keeping the 
>> overall retain count unchanged.
>> An example of a type that is neither trivial nor bitwise movable is a struct 
>> containing a weak reference. Weak references are tracked in a side table so 
>> that they can be nil-ed out when the referenced object is destroyed. When 
>> moving an object of such type from one address to another, the side table 
>> must be updated to refer to the weak reference's new address.
>> ####<a name="opaque-layout"></a>Opaque Layout
>> Opaque layout occurs whenever the layout is not known until runtime. This 
>> can come up for unspecialized generics, which do not have a known layout at 
>> compilation time. It can also come up for resilient types, which are 
>> described in the [next section](#layout-library-evolution).
>> The size and alignment of an object of opaque layout, as well as whether it 
>> is trivial or bitwise movable, is determined by querying its value witness 
>> table, which is described further in the [value witness table 
>> section](#value-witness-table). The offsets for data members are determined 
>> by querying the type's metadata, which is described further in the [value 
>> metadata section](#value-metadata). Objects of opaque layout must typically 
>> be passed indirectly, described further in the [function signature lowering 
>> section](#function-signature-lowering). The Swift runtime interacts with 
>> objects of opaque layout through pointers, and thus they must be 
>> addressable, described further in the [abstraction levels 
>> section](#abstraction-levels).
>> In practice, layout might be partially-known at compilation time. An example 
>> is a generic struct over type `T` that stores an integer as well as an 
>> object of type `T`. In this case, the layout of the integer itself is known 
>> and its location within the generic struct might be as well, depending on 
>> the specifics of the layout algorithm. However, the generic stored property 
>> has opaque layout, and thus the struct overall has an unknown size and 
>> alignment. We are investigating how to most efficiently lay out 
>> partially-opaque aggregates 
>> [[SR-3722](https://bugs.swift.org/browse/SR-3722)]. This will likely entail 
>> placing the opaque members at the end in order to guarantee known offsets of 
>> non-opaque data members.
>> ####<a name="layout-library-evolution"></a>Library Evolution
>> Library evolution introduces *resilient* layouts of public types by default 
>> and provides new annotations that freeze the layout for performance. A 
>> resilient layout avoids many of the pitfalls of the fragile binary problem 
>> by making the layout opaque. Resilient types have far more freedom to change 
>> and evolve without breaking binary compatibility: public data members can be 
>> rearranged, added, and even removed (by providing a computed getter/setter 
>> instead). The new annotations provide the ability to relinquish these 
>> freedoms by making stricter guarantees about their layout in order to be 
>> more efficiently compiled and accessed.
>> In order to allow for cross-module optimizations for modules that are 
>> distributed together, there is the concept of a *resilience domain*. A 
>> resilience domain is a grouping of modules which are version-locked with 
>> each other and thus do not have binary compatibility across multiple version 
>> requirements with each other. See [Resilience 
>> Domains](https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#resilience-domains)
>>  for more details.
>> Resilient types are required to have opaque layout when exposed outside 
>> their resilience domain. Inside a resilience domain, this requirement is 
>> lifted and their layout may be statically known or opaque as determined by 
>> their type (see [previous section](#opaque-layout)).
>> Annotations may be applied to a library's types in future versions of that 
>> library, in which case the annotations are versioned, yet the library 
>> remains binary compatible. How how this will impact the ABI is still under 
>> investigation [[SR-xxxx]()].
>> ####<a name="abstraction-levels"></a>Abstraction Levels
>> All types in Swift conceptually exist at multiple levels of abstraction. For 
>> example, an `Int` value is of a concrete type and can be passed to functions 
>> in registers. But, that same value might be passed to a function expecting a 
>> generic type `T`, which has opaque layout. Since the function is expecting 
>> its argument to be passed indirectly, the integer value must be promoted to 
>> the stack. When that value has type `T`, it is said to be at a higher 
>> abstraction level than when it was an integer. Moving between abstraction 
>> levels is done through a process called *reabstraction*.
>> For many types in Swift, reabstraction involves directly copying the value 
>> to memory so that it is addressable. Reabstraction may be more complicated 
>> for tuples and higher-order functions, explained later in the [tuples layout 
>> section](#tuples) and the [function signature lowering 
>> section](#lowering-higher-order-functions).
>> ### A Tour of Types
>> What follows is a breakdown of the different kinds of types in Swift and 
>> what needs to be specified.
>> #### Structs
>> The layout algorithm for structs should result in an efficient use of space, 
>> possibly by laying out fields in a different order than declared 
>> [[SR-3723](https://bugs.swift.org/browse/SR-3723)]. We may want a fully 
>> declaration-order-agnostic algorithm to allow data members to be reordered 
>> in source without breaking binary compatibility 
>> [[SR-3724](https://bugs.swift.org/browse/SR-3724)]. We also need to consider 
>> whether, by default, we want to ensure struct data members are addressable 
>> (i.e. byte-aligned) or if we'd rather do bit-packing to save space 
>> [[SR-3725](https://bugs.swift.org/browse/SR-3725)].
>> Zero sized structs do not take up any space as data members and struct 
>> members may be laid out in the padding of sub-structs. We may want to 
>> explore whether there are implementation benefits to capping alignment at 
>> some number, e.g. 16 on many platforms [[SR-xxxx]()].
>> ####<a name="tuples"></a>Tuples
>> Tuples are similar to anonymous structs, but they differ in that they 
>> exhibit structural subtyping: a tuple of type e.g. `(Bool, Bool)` can be 
>> passed anywhere expecting generic types `(T, U)`. But, the type `(T, U)` 
>> exists at a higher abstraction level than `(Bool, Bool)`. Due to this, 
>> tuples may face more expensive reabstraction costs if their layout is 
>> aggressively packed. Reabstracting such a tuple would involve splitting and 
>> promoting each element into their own addresses.
>> This may be an argument for a simple, declaration-order, non bit-packed 
>> layout algorithm for tuples. Tuples are often used for small local values 
>> and rarely persisted across ABI boundaries in a way that aggressive packing 
>> is performance-critical. This would also be more consistent with how 
>> fixed-size C arrays are presented in Swift, which are imported as tuples.
>> We should investigate whether to aggressively bit-pack tuple elements 
>> similarly to structs, paying the reabstraction costs, or if the benefits are 
>> not worth the costs [[SR-3726](https://bugs.swift.org/browse/SR-3726)].
>> Tuples should be binary compatible between labeled and unlabeled tuples of 
>> the same type and structure.
>> #### Enums
>> A value of enum type exists as one of many variants or cases. Determining 
>> which is the job of the *discriminator*, also known as a tag, which is an 
>> integer value denoting which case is presently stored. To save space, 
>> discriminators can be put in spare bits or be represented by extra 
>> inhabitants.
>> `@closed` enums, that is enums that can't have cases added to them later, 
>> can be classified into the following:
>> * Degenerate - zero cased, or single cased without an associated value
>> * Trivial - no associated values
>> * Single payload - an enum where only one case has associated values
>> * Multi-payload - an enum that has multiple cases with associated values
>> Degenerate enums take zero space. Trivial enums are just their discriminator.
>> Single payload enums try to fit their discriminator in the payload's extra 
>> inhabitants for the non-payload cases, otherwise they will store the 
>> discriminator after the payload. When the discriminator is stored after the 
>> payload, the bits are not set for the payload case. The payload is 
>> guaranteed to be layout compatible with the enum as the payload case does 
>> not use any extra inhabitants. Storing the discriminator after the payload 
>> may also result in more efficient layout of aggregates containing the enum, 
>> due to alignment.
>> The layout algorithm for multi-payload enums is more complicated and still 
>> needs to be developed [[SR-3727](https://bugs.swift.org/browse/SR-3727)]. 
>> The algorithm should try to rearrange payloads so as to coalesce cases and 
>> save space. This rearrangement can also improve performance and code size. 
>> For example, if ARC-ed payload components reside in the same location, 
>> operations like copy can be done directly on the values without extensive 
>> switching.
>> Enum raw values are not ABI, as they are implemented as code present in the 
>> computed property getter and setter. `@objc` enums are C-compatible, which 
>> means they must be trivial.
>> Library evolution adds the notion of `@open` enums (which will also be 
>> resilient), which allow library owners to add new cases and reorder existing 
>> cases without breaking binary compatibility. How this is accomplished is 
>> still to be determined.
>> #### Classes
>> There are two constructs present when discussing about class layout: *class 
>> instances*, which reside on the heap, and *references* to class instances, 
>> which are reference-counted pointers.
>> ##### Class Instances
>> The layout of class instances is mostly opaque. This is to avoid the vexing 
>> problem of [fragile binary 
>> interfaces](https://en.wikipedia.org/wiki/Fragile_binary_interface_problem), 
>> also known as the "fragile base class problem", in which seemingly minor 
>> changes to a base class break binary compatibility with subclasses.
>> The run-time type of a non-final class instance or a class existential is 
>> not known statically. To facilitate dynamic casts, the object must store a 
>> pointer to its type, called the *isa* pointer. The *isa* pointer is always 
>> stored at offset 0 within the object. How that type is represented and what 
>> information it provides is part of the class's metadata and is covered in 
>> the [class metadata section](#class-metadata). Similarly, the function for a 
>> non-final method call is also not known statically and is dispatched based 
>> on the run-time type. Method dispatch is covered in the [method dispatch 
>> section](#method-dispatch).
>> Class instances will, as part of ABI-stability, guarantee a word-sized field 
>> of opaque data following the isa field that may be used for reference 
>> counting by the runtime. But, the format and conventions of this opaque data 
>> will not be ABI at first in order to have more flexibility for language or 
>> implementation changes. Instead, runtime functions provide the means to 
>> interact with reference counts. This opaque data and its conventions may be 
>> locked down for more efficient access in the future, which will be an 
>> ABI-additive change.
>> ##### References
>> Classes are reference types. This means that Swift code dealing with class 
>> instances does so through references, which are pointers at the binary 
>> level. These references participate in [automatic reference 
>> counting](https://en.wikipedia.org/wiki/Automatic_Reference_Counting) (ARC).
>> References to Objective-C-compatible class instances (i.e. those that 
>> inherit from an Objective-C class or are imported from Objective-C) must 
>> provide the same bit-level guarantees to the Objective-C runtime as 
>> Objective-C references. Thus, such references are opaque: they have no 
>> guarantees other than that nil is 0 and provide no extra inhabitants.
>> References to native, non-Objective-C-compatible Swift class instances do 
>> not have this constraint. The alignment of native Swift class instances is 
>> part of ABI, providing spare bits in the lower bits of references. Platforms 
>> may also provide spare bits (typically upper bits) and extra inhabitants 
>> (typically lower addresses) for references due to limited address spaces.
>> We may want to explore using spare bits in references to store local 
>> reference counts in order to perform some ARC operations more efficiently 
>> [[SR-3728](https://bugs.swift.org/browse/SR-3728)]. These would need to be 
>> flushed to the object whenever a reference may escape or the local reference 
>> count reaches zero. If these local reference counts can cross ABI 
>> boundaries, then such a change will have to be implemented in an 
>> ABI-additive way with deployment target checking.
>> ####<a name="existential-containers"></a>Existential Containers
>> Any discussion of existentials quickly becomes bogged down in obscure 
>> terminology, so let's first establish some background surrounding the terms 
>> *existential values*, *existential containers*, and *witness tables*.
>> In type theory, an [existential 
>> type](https://en.wikipedia.org/wiki/Type_system#Existential_types) describes 
>> an interface of an abstract type. Values of an existential type are 
>> *existential values*. These arise in Swift when an object's type is a 
>> protocol: storing or passing an object of protocol type means that the 
>> actual run-time type is opaque (not known at compile time, and thus neither 
>> is its layout). But, that opaque type has known interfaces because that type 
>> conforms to the protocol.
>> A type's conformance to a protocol consists of functions (whether methods or 
>> getters and setters), but the specific addresses of those functions are not 
>> known at compilation time for existential values as their actual type is not 
>> known until run time. This is a similar situation as with references to 
>> non-final class instances, and is solved using a [similar 
>> technique](#method-dispatch). *Witness tables* are tables of function 
>> pointers implementing a protocol conformance and are further discussed in 
>> the [witness table section](#witness-tables).
>> *Existential containers* store values of protocol or protocol composition 
>> type alongside corresponding witness tables for each protocol conformance. 
>> For existentials that are not class-constrained (may be value types or 
>> classes), the container needs to store:
>> * the value itself: either in an inline buffer or as a pointer to 
>> out-of-line storage
>> * a pointer to the type metadata
>> * a witness table pointer for every conformance.
>> Class-constrained existentials omit the metadata pointer (as the object 
>> itself contains a pointer to its type), as well as any excess inline buffer 
>> space. `Any`, which is an existential value without any conformances, has no 
>> witness table pointer.
>> We are re-evaluating the inline buffer size for existential containers prior 
>> to ABI stability [[SR-3729](https://bugs.swift.org/browse/SR-3729)]. We are 
>> also considering making the out-of-line allocation be copy-on-write (COW) 
>> [[SR-xxxx]()]. We should also explore "exploding" existential parameters, 
>> i.e. converting an existential parameter into a protocol-constrained generic 
>> parameter [[SR-xxxx]()].
>> ### Declaring Stability
>> ABI stability means nailing down type layout and making decisions about how 
>> to handle the concerns of Library Evolution. The end result will be a 
>> technical specification of the layout algorithms that future compilers must 
>> adhere to in order to ensure binary compatibility 
>> [[SR-3730](https://bugs.swift.org/browse/SR-3730)].
>> For all of the areas discussed above, more aggressive layout improvements 
>> may be invented in the post-ABI stability future. For example, we may want 
>> to explore rearranging and packing nested type data members with outer type 
>> data members. Such improvements would have to be done in an ABI-additive 
>> fashion through deployment target and/or min-version checking. This may mean 
>> that the module file will need to track per-type ABI versioning information.
>> A potentially out of date description of Swift's current type layout can be 
>> found in the [Type Layout 
>> docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#type-layout).
>> ##<a name="metadata"></a>Type Metadata
>> While data layout specifies the layout of objects of a given type, *type 
>> metadata* holds information about the types themselves. The information 
>> available and how to access this information is part of Swift ABI.
>> Swift keeps metadata records for every *concrete type*. Concrete types 
>> include all non-generic types as well as generic types with concrete type 
>> parameters. These records are created by the compiler as well as lazily 
>> created at run time (e.g. for generic type instantiations). This metadata 
>> stores information about its type, discussed in each section below.
>> A potential approach to stability mechanism is to provide metadata 
>> read/write functions alongside the runtime to interact with metadata, giving 
>> some freedom to the underlying structures to grow and change. This 
>> effectively makes large portions of metadata opaque. But, certain fields 
>> require access to be as efficient as possible (e.g. dynamic casts, calling 
>> into witness tables) and the performance hit from going through an 
>> intermediary function would be unacceptable. Thus, we will probably freeze 
>> the performance-critical parts and use accessor functions for the rest 
>> [[SR-xxxx]()].
>> Metadata has many historical artifacts in its representation that we want to 
>> clean up [[SR-xxxx]()]. We also want to make small tweaks to present more 
>> semantic information in the metadata, to enable better future tooling and 
>> features such as reflection [[SR-xxxx]()]. Some of these need to be done 
>> before declaring ABI stability and some may be additive.
>> #### Declaring Stability
>> Stabilizing the ABI means producing a precise technical specification for 
>> the fixed part of the metadata layout of all language constructs so that 
>> future compilers and tools can continue to read and write them. A prose 
>> description is not necessarily needed, though explanations are useful. We 
>> will also want to carve out extra space for areas where it is likely to be 
>> needed for future functionality 
>> [[SR-3731](https://bugs.swift.org/browse/SR-3731)].
>> For more, but potentially out of date, details see the [Type Metadata 
>> docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#type-metadata).
>> ### Generic Parameters
>> Swift has a powerful generics system, which shows up both at compilation 
>> time (through specialization optimizations) and at run time when the type is 
>> unknown. Swift types may be parameterized over generic types, and thus every 
>> type's metadata describes whether generic type parameters are present and if 
>> so provides information about them.
>> At run time, objects only have concrete types. If the type in source code is 
>> generic, the concrete type is an instantiation of that generic type. Generic 
>> instantiation metadata provide type metadata for each generic type 
>> parameter. If the generic type is constrained, corresponding [witness 
>> tables](#witness-tables) for each protocol conformance are also provided in 
>> the metadata.
>> ###<a name="value-metadata"></a>Value Metadata
>> Named value types store the type name (currently mangled but we are 
>> investigating un-mangled [[SR-xxxx]()]) and a pointer to the type's parent 
>> for nested types.
>> Value type metadata also has kind-specific entries. Struct metadata stores 
>> information about its fields, field offsets, field names, and field 
>> metadata. Enum metadata stores information about its cases, payload sizes, 
>> and payload metadata. Tuple metadata stores information about its elements 
>> and labels.
>> #####<a name="value-witness-table"></a>Value Witness Tables
>> Every concrete type has a *value witness table* that provides information 
>> about how to lay out and manipulate values of that type. When a value type 
>> has [opaque layout](#opaque-layout), the actual layout and properties of 
>> that value type are not known at compilation time, so the value witness 
>> table is consulted.
>> The value witness table stores whether a type is trivial and/or bitwise 
>> movable, whether there are extra inhabitants and if so how to store and 
>> retrieve them, etc. For enums, the value witness table will also provide 
>> functionality for interacting with the discriminator. There may be more 
>> efficient ways of representing enums that simplify this functionality (or 
>> provide a fast path), and that's under investigation [[SR-xxxx]()].
>> These value witness tables may be constructed statically for known values or 
>> dynamically for some generic values. While every unique type in Swift has a 
>> unique metadata pointer, value witness tables can be shared by types so long 
>> as the information provided is identical (i.e. same layout). Value witness 
>> tables always represent a type at its highest [abstraction 
>> level](#abstraction-levels). The value witness table entries and structure 
>> need to be locked down for ABI stability [[SR-xxxx]()].
>> ###<a name="class-metadata"></a>Class Metadata
>> Swift class metadata is layout-compatible with Objective-C class objects on 
>> Apple's platforms, which places requirements on the contents of the first 
>> section of class metadata. In this first section, entries such as super 
>> class pointers, instance size, instance alignment, flags, and opaque data 
>> for the Objective-C runtime are stored.
>> Following that are superclass members, parent type metadata, generic 
>> parameter metadata, class members, and *vtables*, described below. Library 
>> evolution may present many changes to what exactly is present and will 
>> likely make many of the contents opaque to accommodate changes.
>> #####<a name="method-dispatch"></a>Method Dispatch
>> Invoking a non-final instance method involves calling a function that is not 
>> known at compile time: it must be resolved at run time. This is solved 
>> through the use of a *vtable*, or virtual method table (so called because 
>> overridable methods are also known as "virtual" methods). A *vtable* is a 
>> table of function pointers to a class or subclass's implementation of 
>> overridable methods. If the vtable is determined to be part of ABI, it needs 
>> a layout algorithm that also provides flexibility for library evolution.
>> Alternatively, we may decide to perform inter-module calls through opaque 
>> *thunks*, or compiler-created intermediary functions, which then perform 
>> either direct or vtable dispatch as needed [[SR-xxxx]()]. This enables 
>> greater library evolution without breaking binary compatibility by allowing 
>> internal class hierarchies to change. This would also unify non-final method 
>> dispatch between open and non-open classes while still allowing for 
>> aggressive compiler optimizations like de-virtualization for non-open 
>> classes. This approach would make vtables not be ABI, as that part of the 
>> type metadata would effectively be opaque to another module.
>> ### Protocol and Existential Metadata
>> #####<a name="witness-tables"></a>Protocol Witness Tables
>> The protocol witness table is a function table of a type's conformance to 
>> the protocol's interfaces. If the protocol also has an associated type 
>> requirement, then the witness table will store the metadata for the 
>> associated type. Protocol witness tables are used with [existential 
>> containers](#existential-containers) where the run time type is not known.
>> Protocol witness tables may be created dynamically by the runtime or 
>> statically by the compiler. The layout of a protocol witness table is ABI 
>> and we need to determine a layout algorithm that also accommodates library 
>> evolution concerns, where additional protocol requirements may be added with 
>> default fall-backs [[SR-3732](https://bugs.swift.org/browse/SR-3732)].
>> ##### Existential Metadata
>> Existential type metadata contains the number of witness tables present, 
>> whether the type is class-constrained, and a *protocol descriptor* for each 
>> protocol constraint. A protocol descriptor describes an individual protocol 
>> constraint, such as whether it is class-constrained, the size of conforming 
>> witness tables, and protocol descriptors for any protocols it refines. 
>> Protocol descriptors are layout compatible with the Objective-C runtime's 
>> protocol records on Apple platforms.
>> ### Function Metadata
>> In addition to common metadata entries, function type metadata stores 
>> information about the function signature: parameter and result type 
>> metadata, calling convention, per-parameter ownership conventions, and 
>> whether the function throws. Function type metadata always represents the 
>> function at its highest abstraction level, which is explained later in the 
>> [function signature lowering section](#lowering-higher-order-functions). 
>> Function parameters are currently modeled with a tuple-based design, but 
>> this should be updated to match modern Swift [[SR-xxxx]()]. As more 
>> ownership semantics are modeled, more information may be stored about each 
>> parameter.
>> ##<a name="mangling"></a>Mangling
>> Mangling is used to produce unique symbols. It applies to both external 
>> (public) symbols as well as internal or hidden symbols. Only the mangling 
>> scheme for external symbols is part of ABI.
>> ABI stability means a stable mangling scheme, fully specified so that future 
>> compilers and tools can honor it. For a potentially out-of-date 
>> specification of what the mangling currently looks like, see the [Name 
>> Mangling 
>> docs](https://github.com/apple/swift/blob/master/docs/ABI.rst#mangling).
>> There are some corner cases currently in the mangling scheme that should be 
>> fixed before declaring ABI stability. We need to come up with a 
>> canonicalization of generic and protocol requirements to allow for 
>> order-agnostic mangling [[SR-3733](https://bugs.swift.org/browse/SR-3733)]. 
>> We also may decide to more carefully mangle variadicity of function 
>> parameters, etc [[SR-3734](https://bugs.swift.org/browse/SR-3734)]. Most 
>> often, though, mangling improvements focus on reducing symbol size.
>> Mangling design centers around coming up with short and efficient manglings 
>> that still retain important properties such as uniqueness and integration 
>> with existing tools and formats. Given the prevalence of public symbols in 
>> libraries and frameworks, and debugging symbols in applications, the symbol 
>> names themselves can make up a significant portion of binary size. Reducing 
>> this impact is a major focus of stabilizing the mangling. 
>> Post-ABI-stability, any new manglings or techniques must be additive and 
>> must support the existing manglings.
>> There are many ways to improve the existing mangling without major impact on 
>> existing tools. Throughout these endeavors, we will be empirically measuring 
>> and tracking symbol size and its impact on binary size [[SR-xxxx]()]. ABI 
>> work on mangling focuses on producing *compact manglings* and using *suffix 
>> differentiation*.
>> ### Compact Manglings
>> Minor tweaks to shorten the mangling can have a beneficial impact on all 
>> Swift program binary sizes. These tweaks should compact existing manglings 
>> while preserving a simple unique mapping. One example is not distinguishing 
>> between struct/enum in mangling structures, which would also provide more 
>> library evolution freedom [[SR-xxxx]()]. We are considering dropping some 
>> internal witness table symbols when they don't provide any meaningful 
>> information conducive to debugging [[SR-xxxx]()]. We are currently 
>> overhauling word substitutions in mangling, with the goal of reducing as 
>> much redundancy in names as possible [[SR-xxxx]()].
>> There are other aggressive directions to investigate as well, such as 
>> mangling based on a known overload set for non-resilient functions. This 
>> does have the downside of making manglings unstable when new overloads are 
>> added, so its benefits would have to be carefully weighed [[SR-xxxx]()].
>> Any more ambitious reimagining of how to store symbols such as aggressive 
>> whole-library symbol name compression would have to be done in tight 
>> coupling with existing low level tools. Unfortunately, this might make some 
>> of the more ambitious options infeasible in time for ABI stability. They 
>> could be rolled out as ABI-additive using deployment target checking in the 
>> future.
>> ### Suffix Differentiation
>> There are many existing low level tools and formats that store and consume 
>> the symbol information, and some of them use efficient storage techniques 
>> such as tries. Suffix differentiation is about adjusting the mangling in 
>> ways that take advantage of them: by distinguishing manglings through 
>> suffixes, i.e. having common shared prefixes. This is currently underway and 
>> is resulting in binary size reductions for platforms that use these 
>> techniques [[SR-xxxx]()].
>> ##<a name="calling-convention"></a>Calling Convention
>> For the purposes of this document, "standard calling convention" refers to 
>> the C calling convention for a given platform (see 
>> [appendix](#platform-abis)), and "Swift calling convention" refers to the 
>> calling convention used by Swift code when calling other Swift code. The 
>> Swift runtime uses the standard calling convention, though it may make 
>> alterations (see section [Runtime calling 
>> convention](#runtime-calling-convention)).
>> Calling convention stability pertains to public interfaces. The Swift 
>> compiler is free to choose any convention for internal (intra-module) 
>> functions and calls.
>> For rationale and potentially-out-of-date details, see the [Swift Calling 
>> Convention 
>> Whitepaper](https://github.com/apple/swift/blob/master/docs/CallingConvention.rst).
>>  As part of nailing down the calling conventions, that document will either 
>> be updated with the final specifications of the calling conventions or else 
>> moved to a rationale document and a more succinct and rigorous specification 
>> put in its place.
>> ### Register convention
>> This section will be using the terms *callee-saved* and *scratch* to 
>> classify registers as part of a register convention.
>> * A *callee-saved register* must be preserved over the duration of a 
>> function call. If a called function (the *callee*) wishes to change the 
>> value stored in the register, it must restore it before returning.
>> * A *scratch* register, also known as caller-saved or callee-clobbered, is 
>> not preserved over the duration of a function call. If the register's value 
>> must be preserved, code surrounding a function call must save and restore 
>> the value.
>> Swift uses roughly the same categorization of registers as the standard 
>> calling convention. But, for some platforms, the Swift calling convention 
>> adds additional situational uses of some callee-saved registers: the *call 
>> context* register and the *error* register.
>> #### Call Context Register
>> The value held in the *call context* register depends on the kind of 
>> function called:
>> * Instance methods on class types: pointer to self
>> * Class methods: pointer to type metadata (which may be subclass metadata)
>> * Mutating method on value types: pointer to the value (i.e. value is passed 
>> indirectly)
>> * Non-mutating methods on value types: self may fit in one or more 
>> registers, else passed indirectly
>> * *Thick closures*, i.e. closures requiring a context: the closure context
>> Having the call context register be callee-saved is advantageous. It keeps 
>> the register stable across calls, where the context is very likely to be 
>> used and reused in subsequent or nested calls. Additionally, this makes 
>> partial application free as well as converting thin closures to thick.
>> #### Error Register
>> Throwing functions communicate error values to their callers through the 
>> *error* register on some platforms. The error register holds a pointer to 
>> the error value if an error occurred, otherwise 0. The caller of a throwing 
>> function is expected to quickly check for 0 before continuing on with 
>> non-error code, otherwise branching to code to handle or propagate the 
>> error. Using a callee-saved register for the error register enables free 
>> conversion from non-throwing to throwing functions, which is required to 
>> honor the subtyping relationship.
>> ###<a name="function-signature-lowering"></a>Function Signature Lowering
>> Function signature lowering is the mapping of a function's source-language 
>> type, which includes formal parameters and results, all the way down to a 
>> physical convention, which dictates what values are stored in what registers 
>> and what values to pass on the stack.
>> ABI stability requires nailing down and fully specifying this algorithm so 
>> that future Swift versions can lower Swift types to the same physical call 
>> signature as prior Swift versions. More in-depth descriptions and rationale 
>> of function signature lowering can be found in the [function signature 
>> lowering 
>> docs](https://github.com/apple/swift/blob/master/docs/CallingConvention.rst#function-signature-lowering).
>> Lowering the result value is usually done first, with a certain number of 
>> registers designated to hold the result value if it fits, otherwise the 
>> result value is passed on the stack. A good heuristic is needed for the 
>> limit and is architecture specific (e.g. 4 registers on modern 64-bit 
>> architectures) [[SR-xxxx]()].
>> Next comes lowering parameters, which proceeds greedily by trying to fit 
>> values into registers from left-to-right, though some parameters may be 
>> re-ordered. For example, closures are best placed at the end to take 
>> advantage of ABI compatibility between thick closures and thin ones without 
>> a context.
>> Some values must be passed and returned indirectly as they are *address 
>> only*. Address only values include [non-bitwise-copyable](#type-properties) 
>> values, values with [opaque layout](#opaque-layout), and 
>> non-class-constrained [existential values](#existential-containers). Even if 
>> the runtime type would normally be passed in a register, or even if the type 
>> is statically known at the call-site, if the callee receives or returns 
>> values with opaque layout, they must be passed or returned indirectly.
>> We should investigate whether it makes sense to split values with partially 
>> opaque layout by passing the non-opaque parts in registers [[SR-xxxx]()].
>> Parameter ownership is not reflected in the physical calling convention, 
>> though it will be noted in the mangling of the function name. Default 
>> argument expressions will not be ABI, as they will be emitted into the 
>> caller. This means that a library can add, modify, or remove default 
>> argument expressions without breaking binary compatibility (though 
>> modifying/removing may break source compatibility).
>> ####<a name="lowering-higher-order-functions"></a>Lowering Higher-Order 
>> Functions
>> Passing or returning higher-order functions may involve undergoing 
>> [reabstraction](#abstraction-levels), which requires that the compiler 
>> creates a thunk mapping between the actual calling convention and the 
>> expected calling convention.
>> For example, let's say there are two functions:
>> ```swift
>> func add1(_ i: Int) ->Int { return i+1 }
>> func apply<T,U>(_ f: (T) ->U, _ x: T) ->U { return f(x) }
>> ```
>> `apply`'s function parameter `f` must take and return its values indirectly, 
>> as `T` and `U` have opaque layout. If `add1` is passed to `apply`, the 
>> compiler will create a thunk for `apply` to call that takes a parameter 
>> indirectly and calls `add1` by passing it in register. The thunk will then 
>> receive the result in register and return it indirectly back to `apply`.
>> ### Stack Invariants
>> Calling conventions include invariants about the call stack, such as stack 
>> alignment. Unless there is a very compelling reason to deviate, Swift should 
>> just honor the stack invariants of the standard calling convention. This is 
>> because Swift functions may share their call stack with non-Swift code. For 
>> example a Swift function that calls an Objective-C function, which in turn 
>> calls another Swift function, would want to maintain the proper stack 
>> alignment (and any other stack invariants) for all calls. This is far 
>> simpler if they both honor the same invariants.
>> ###<a name="runtime-calling-convention"></a>Runtime Calling Convention
>> The Swift runtime uses the standard calling convention, though it may evolve 
>> to preserve more invariants. It's likely beneficial to introduce one or a 
>> number of tweaks to the scratch register sets of some runtime functions. 
>> Swift code that makes a call into the runtime assumes some registers are 
>> scratch, i.e. clobbered by the runtime function. But, some runtime functions 
>> may not need as many scratch registers and can guarantee more registers as 
>> callee-saved. Every formerly-scratch register that is denoted callee-saved 
>> (i.e. runtime function saved) relieves the register pressure of the 
>> surrounding Swift code making the runtime call.
>> Such changes to runtime functions can be rolled out incrementally in the 
>> future, and they are backwards compatible so long as no version of that 
>> function ever clobbers the now-saved registers. But, such a change is 
>> ratcheting, that is every register that is changed to be runtime-saved can 
>> no longer go back to being scratch without breaking binary compatibility. If 
>> the reduced scratch register set causes the runtime function to spill, then 
>> the whole exercise was pointless and actively harmful. Great care should be 
>> taken and testing applied for any change to ensure that the runtime function 
>> never spills in the future.
>> ##<a name="runtime"></a>Runtime
>> Swift exposes a runtime that provides APIs for compiled code. Calls into the 
>> Swift runtime are produced by the compiler for concerns such as memory 
>> management and run-time type information. Additionally, the runtime exposes 
>> low-level reflection APIs that are useful to the standard library and some 
>> users.
>> Every existing runtime function will need to be audited for its desirability 
>> and behavior [[SR-3735](https://bugs.swift.org/browse/SR-3735)]. For every 
>> function, we need to evaluate whether we want the API as is:
>> * If yes, then we need to precisely specify the semantics and guarantees of 
>> the API.
>> * If not, we need to either change, remove, or replace the API, and 
>> precisely specify the new semantics.
>> The runtime is also responsible for lazily creating new type metadata 
>> entries at run time, either for generic type instantiations or for resilient 
>> constructs. Library evolution in general introduces a whole new category of 
>> needs from the runtime by making data and metadata more opaque, requiring 
>> interaction to be done through runtime APIs. Additionally, ownership 
>> semantics may require new runtime APIs or modifications to existing APIs. 
>> These new runtime needs are still under investigation [[SR-xxxx]()].
>> There are many potential future directions to open up the ABI and operate on 
>> less-opaque data directly, as well a techniques such as call-site caching. 
>> These are ABI-additive, and will be interesting to explore in the future.
>> For a potentially-out-of-date listing of runtime symbols and some details, 
>> see the [Runtime 
>> docs](https://github.com/apple/swift/blob/master/docs/Runtime.md).
>> ##<a name="standard-library"></a>Standard Library
>> Any standard library API shipped post-ABI-stability must be supported into 
>> the future to ensure binary compatibility. The standard library will also be 
>> utilizing resilience annotations and *inlineable* code. Inlineable code is 
>> code that is bundled with the client's code, and is available for inlining 
>> to the optimizer if it decides to do so. The standard library faces the 
>> following (non-exhaustive) list of challenges for ensuring binary 
>> compatibility:
>> * Published public functions and types cannot be removed or changed in ways 
>> that break binary compatibility.
>> * Choosing what code to make inlineable will affect performance and 
>> flexibility.
>> * Internal functions called by inlineable code become ABI, and are subject 
>> to the same binary compatibility concerns as public functions.
>> * Non-resilient types cannot change their layout.
>> * Protocols cannot add new requirements.
>> ### Inlineability
>> Inlineable code that calls internal functions makes those internal functions 
>> ABI, as the client code will be making external calls to them. Thus, many 
>> internal interfaces in the standard library will need to be locked down if 
>> called from inlineable code. Whether to mark code inlineable will have to 
>> carefully weigh performance requirements against keeping flexibility for 
>> future changes.
>> This tradeoff between performance and flexibility also affects the ability 
>> to deploy bug fixes and performance improvements to users. Users that have 
>> inlined code from the standard library will not be able to get bug fixes and 
>> performance improvements in an OS update without performing a recompilation 
>> with the new library. For more information on this topic, see [Inlineable 
>> Functions](https://github.com/apple/swift/blob/master/docs/LibraryEvolution.rst#inlineable-functions).
>> ### Upcoming Changes
>> While the standard library is already ensuring source stability, it will be 
>> changing many of its fundamental underlying representations this year. When 
>> ABI stability lands, the standard library will be severely limited in the 
>> kinds of changes it can make to existing APIs and non-resilient types. 
>> Getting the standard library in the right place is of critical importance.
>> The programming model for String is still being redesigned [[SR-xxxx]()], 
>> and many types such as Int are undergoing implementation changes 
>> [[SR-xxxx]()]. At the same time, the standard library is simultaneously 
>> switching to new compiler features such as conditional conformances to clean 
>> up and deliver the best APIs [[SR-xxxx]()].
>> Another goal of Swift is to improve the applicability of Swift to systems 
>> programming. Ownership semantics may make a large impact, including things 
>> such as improved `inout` semantics that allow for efficient and safe array 
>> slicing. Providing the right abstractions for efficient use of contiguous 
>> memory is still under investigation [[SR-xxxx]()].
>> ## Next Steps
>> All progress and issue tracking will be done through JIRA on 
>> [bugs.swift.org(http://bugs.swift.org)](https://bugs.swift.org), using the 
>> "AffectsABI" label. We will make an ABI stability dashboard to more easily 
>> monitor specifics and progress. The next step is to start making issues for 
>> everything that needs fixing and issues for the directions we want to 
>> explore.
>> This document will be a living document until ABI stability is reached, 
>> updated with new findings and JIRA issues as they come up. After ABI 
>> stability is achieved, this document should be succeeded by technical 
>> specifications of Swift's ABI.
>> Issue tracking alone doesn't effectively communicate the overall progress 
>> and when ABI stability can be expected to land. Some issues take longer than 
>> others and there isn't a good indication of how long the known tasks will 
>> take, nor of how many unknown issues are yet to be filed. For that, a higher 
>> level view of the overall status will be provided, possibly on 
>> [swift.org(http://swift.org)](https://swift.org).
>> ## Appendix
>> ###<a name="platform-abis"></a>Standard ABIs
>> [Apple ARM64 iOS platform 
>> ABI](https://developer.apple.com/library/content/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html)
>>  is an vendor-specific variant of [ARM's 
>> AAPCS64](http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf).
>> [Apple ARM32 iOS platform 
>> ABI](https://developer.apple.com/library/content/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARMv7FunctionCallingConventions.html)
>>  is similarly a variant of [ARM's 
>> AAPCS](http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/IHI0042F_aapcs.pdf).
>> [Apple x86-64 MacOS platform 
>> ABI](https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/LowLevelABI/140-x86-64_Function_Calling_Conventions/x86_64.html)
>>  is based off of the generic [System V 
>> ABI](http://people.freebsd.org/~obrien/amd64-elf-abi.pdf) also used by BSD 
>> and Linux.
>> [Apple i386 MacOS platform 
>> ABI](https://developer.apple.com/library/content/documentation/DeveloperTools/Conceptual/LowLevelABI/130-IA-32_Function_Calling_Conventions/IA32.html#//apple_ref/doc/uid/TP40002492-SW4)
>>  is similarly based off of the generic [i386 System V 
>> ABI](http://www.sco.com/developers/devspecs/abi386-4.pdf).
> Fantastic read, really insightful but it does yield a few questions;
> How confident are we to lock down ABI stability based on so many dramatic 
> changes/additions planned for Swift 4?

Planning and scheduling might be better discussed in the other thread titled “A 
case for postponing ABI stability”. CC-ing Ted.

> My main concerns are whats highlighted in ‘Upcoming Changes’ around Strings 
> and Ownership semantics. This isn’t the first time Strings have been reworked 
> so it feels like the new world should be given time to mature and ensure that 
> there are no additional problems that need solving/tweaking before rushing 
> straight into committing ourselves to locking everything down and not giving 
> any room to ensure the new direction is 100% right.

We would want to be reasonably confident in the API surface as well as any 
implementation choices exposed by @inlineable and non-resilient types.

> There are ongoing discussions about the String Manifesto around 
> Grammars/Regex’s which feels like additional time will be needed to ensure 
> the right direction is chosen and planned out. If the implementation of that 
> plan is more extensive than the team are currently anticipating then it’s 
> implementation is something that might not be 100% complete by the time Swift 
> 4 is read to ship (although maybe if it’s not 100% complete it won’t make a 
> whole lot of difference to the ABI since the underlying structure will 
> probably not change if its been planned correctly).

Correct, if it’s planned sufficiently well, then Grammars/Regexes could be 

> I’m also curious how the standard library inline auditing will be done. Each 
> function will need to be assessed which is going to be a huge task in itself, 
> but I’m wondering what the assessment will involve and if there will be a 
> public place to see the conclusions and an opportunity for the community to 
> contribute.

That’s a good point. Ben Cohen (CC-ed) has done audits of ABI-affecting 
components in the standard library. He would know best how to engage the 
community in an inlineability audit.

> Dale
> ________________________________
> This message contains confidential and proprietary information of the sender, 
> and is intended only for the person(s) to whom it is addressed. Any use, 
> distribution, copying, disclosure or taking of any action in reliance upon it 
> by any other person is strictly prohibited. If you have received this message 
> in error, please notify the e-mail sender immediately, and delete the 
> original message without making a copy. Monitise accepts no liability if this 
> email harms any systems or data of the recipient (including as a result of 
> software virus infection or where this e-mail is modified or amended in any 
> way during or following transmission) or if this email is accessed by anyone 
> other than the person(s) to whom it is addressed.
> The Monitise group includes Monitise plc (Reg. No. 6011822), Monitise Group 
> Limited (Reg. No. 5590897), Monitise International Limited (Reg. No. 
> 5556711), Monitise Europe Limited (Reg. No. 4831976) and Mobile Money Network 
> Limited (Reg. No. 7153130). These companies are registered in England and 
> Wales and their registered office address is 2 Sheraton Street, London, W1F 
> 8BH, United Kingdom.
> -----------------------------------------------------------------------------------------------------------------------------------------
> This email message has been delivered safely and archived online by Mimecast.
> For more information please visit http://www.mimecast.com 
> -----------------------------------------------------------------------------------------------------------------------------------------

swift-evolution mailing list

Reply via email to