当 Swift 编译泛型函数时，传递给泛型参数的具体类型可能在不同的模块或库中定义，这些模块或库是在不同时间编译的。其他语言早期的泛型方法通常需要单态化（为每个类型生成单独的代码），这会导致二进制膨胀并阻止泛型的动态链接。Swift 需要一个解决方案，在性能和单独编译的灵活性、以及对库变化的弹性之间取得平衡。
问题：像 func process<T>(_ value: T) 这样的泛型函数必须能够将 T 复制到局部变量中、移动它或者在退出作用域时销毁它。然而，编译器在构建时无法知道 T 是一个微不足道的 Int（8 字节）、一个大的结构体（4KB），还是一个包含堆缓冲区的引用计数结构体。在没有这个知识的情况下，函数无法知道分配多少栈空间、如何对齐内存，或者如何管理 T 可能拥有的任何堆资源的生命周期。此外，对于 按需拷贝（COW） 类型，如 Array 或 Data，我们必须确保复制结构体值仅仅是增加引用计数，而不是进行代价高昂的深层复制。
解决方案：Swift 使用 值见证表 (VWT)。每个类型都有一个 VWT（或对布局兼容类型共享一个公共的 VWT），其中包含基本操作的函数指针：size、alignment、stride、destroy、initializeWithCopy、assignWithCopy、initializeWithTake 和 assignWithTake。在编译泛型代码时，LLVM 生成对这些见证函数的调用，而不是内联指令。对于 COW 优化，类似类型的 initializeWithCopy 见证执行一个浅拷贝（保留缓冲区引用），而实际的唯一性检查和缓冲区复制则推迟到通过类型的自身方法进行更改时。这允许泛型算法正确处理任何值类型，同时保留 COW 的性能特性。
想象一下开发一个高性能音频处理库，用户可以定义自定义采样格式。你需要实现一个高效存储和旋转样本的泛型 RingBuffer<T>，而无需过多的复制。该缓冲区必须处理诸如 Float（4 字节）这样的小微不足道类型，以及诸如 AudioPacket（一个包装有 16KB 堆缓冲区并具有 COW 语义的结构体）这样的大型复杂类型。
考虑的解决方案之一是要求用户遵循包含显式 clone() 和 dispose() 方法的 Clonable 协议。这种方法提供了完全控制权，但迫使用户为每种类型编写样板代码，阻止结合使用标准库类型（如 Array），并且如果忘记 dispose() 则可能导致内存泄漏。它也未能利用编译器为微不足道类型生成的优化。
另一种方法涉及使用 UnsafeMutablePointer 和 memcpy 进行所有操作。虽然对于 Float 来说很快，但这对于引用计数结构体或 COW 类型是破坏性的，因为它通过复制指针值而不保持它们，从而导致使用后释放崩溃或缓冲区损坏，当环形缓冲区覆盖旧数据时。这需要手动内存管理，容易出错，并且绕过了 Swift 的安全保证。
最终解决方案利用了 Swift 内置的泛型机制，通过 ContiguousArray<T> 作为环形缓冲区的后备，这在内部为所有元素操作使用 VWT。对于旋转逻辑，我们使用了 withUnsafeMutableBufferPointer 结合 moveInitialize(from:count:)，它调用 VWT 的移动见证。这在不调用拷贝构造函数的情况下转移值的所有权，保持 COW 语义，避免不必要的引用计数增加。选择这种方法，因为它在保持内存安全的同时，能够通过编译器对热路径的专门化实现近乎最佳的性能，同时在边界情况回退到 VWT。
最终结果是一个环形缓冲区，以零拷贝方式旋转大型 COW 音频包，同时为微不足道类型保持 O(1) 性能，没有公共 API 中的自定义协议要求或不安全代码。
为什么在泛型函数中复制大型结构体有时看起来比在专门的非泛型上下文中复制要慢，即使两者都使用值语义？
在已知具体类型的专门上下文中，Swift 编译器可以直接将复制操作内联为 memcpy，甚至是向量化的 SIMD 指令。然而，在未专门化的泛型代码中，复制操作通过 VWT 的 initializeWithCopy 函数指针被调度。这种间接性阻止了内联，并阻碍了诸如死存储消除或向量化之类的后续优化。编译器无法证明复制没有副作用（例如，引用的保留计数），迫使它生成保守的、较慢的代码。理解这个区别对于性能关键的泛型算法至关重要。
当泛型初始化器在属性赋值的中途抛出错误时，Swift 如何处理部分初始化值的销毁？
当一个泛型结构体的初始化器在初始化了一些属性之后但未初始化其他属性时抛出错误，Swift 必须避免泄露已初始化的值。编译器生成一个错误清理路径，该路径反向查询已初始化属性的 VWT 的 destroy 见证。由于 VWT 知道具体类型的确切布局和清理过程，因此可以在不需要知道具体设置了哪个属性的情况下，正确销毁部分构造的值。这一机制确保了即使在复杂值类型的故障场景中也能保证内存安全。
值见证表与存在容器之间的关系是什么，为什么当擦除为 any 协议时，大型值类型会被堆分配？
一个 存在容器（any Protocol 的盒子）通常具有 3 个字的内联存储（在 64 位系统上为 24 字节）。当一个大于此内联缓冲区的值被擦除为一个存在类型时，Swift 会在堆上分配该值，并在容器中存储一个指针。该值的 VWT 与类型元数据一起存储在容器中。VWT 提供了分配堆箱所需的 size 和 alignment，以及当该存在超出作用域时清理它的 destroy 见证。这种分离允许存在容器具有固定大小，同时仍然容纳任意大小的值类型，不过代价是对大值进行了堆分配和间接访问。