5.11 · Package access, SPI, internal imports, strict memory safety and pre-specialisation

The finer controls of a module boundary: who can see a declaration, who has to import a dependency, which unsafe code is marked, and how a library offers specialised generics.

Mental model. Beyond public and internal there are four more dials on what crosses a module: package, SPI, import visibility and unsafe marking.

Who can see what

package, @_spi and import access levels.

  1. How do package access and @_spi differ from public and internal, and what do they look like in a .swiftinterface? 5.11.1 · L5
    package access is visible to every module compiled with the same package name (-package-name, set by SwiftPM from the package manifest) and to nobody else.…
  2. What does internal import (SE-0409) change, and why does it matter for API leakage and build times? 5.11.2 · L5
    Without it, a plain import Dep in any file makes Dep visible to the whole module and, since it is effectively public, lets Dep’s types appear in public API…

Safety and speed at the edge

Strict memory safety and exported specialisations.

  1. What is strict memory safety (Swift 6.2), what does the unsafe keyword mark, and what does it not do? 5.11.3 · L5
    Swift is memory safe except where you reach for unsafe constructs: UnsafePointer and friends, unsafeBitCast, unchecked Unmanaged, C pointers. Strict memory…
  2. How can a library with library evolution still offer a fast generic function, and what does @_specialize(exported: true) do? 5.11.4 · L8
    In a library built with -enable-library-evolution a generic function that is not @inlinable compiles once, takes the type through metadata and witness tables…

More in Compiler & language internals