标准的Swift值类型依赖于隐式复制和ARC来管理堆分配资源，允许值在函数边界之间自由复制。相比之下，声明为~Copyable（不可复制）的结构完全禁止隐式复制，强制执行唯一所有权。当这样的结构传递给函数时，Swift要求显式的所有权注解：consuming将所有权永久转移给被调用者，borrowing在不移动或复制的情况下授予临时只读访问权限，而inout提供临时独占可变访问。这种模型消除了仅可移动资源的ARC开销，并在编译时确保安全性，防止使用后移动或双重复制错误。
我们在构建一个高频交易应用程序，其中一个2MB市场数据包表示一个内核空间的DMA缓冲区，必须保持唯一以确保一致性和性能。
问题：在处理阶段之间（网络输入、验证、策略引擎）传递这个缓冲区而不复制底层内存或在热路径中触发引用计数。标准类引入了不可接受的ARC延迟，而手动不安全指针则有泄漏和悬空引用的风险。
**解决方案1：引用计数类。**我们考虑将缓冲区包装在一个具有deinit处理程序的类中。优点包括熟悉的内存管理和易于共享。然而，缺点非常严重：每次通过组件传递都会触发原子保留/释放操作，这破坏了缓存局部性并违反了我们100微秒的延迟要求。
解决方案2：不安全的原始指针。使用UnsafeMutablePointer<UInt8>和手动分配完全避免了ARC。优点是没有开销和完全控制。缺点包括缺乏编译时安全性保证——开发人员可能轻易地双重释放缓冲区或访问已释放的内存，导致生产中的崩溃。
**解决方案3：具有所有权修饰符的不可复制结构。**我们定义了struct MarketDataBuffer: ~Copyable，其中包含指针。接收缓冲区的函数使用consuming来获取所有权（例如，func process(_ buffer: consuming MarketDataBuffer)），而检查函数使用borrowing（例如，func validate(_ buffer: borrowing MarketDataBuffer)）。这提供了唯一所有权的编译时强制执行和零运行时开销。
选择的解决方案和结果：我们选择了解决方案3。结果是一个确定性的数据管道，编译器防止了意外复制和使用后移动错误。系统处理数据包时ARC流量为零，并确保DMA缓冲区在任何时刻只有一个逻辑所有者，显著提高了延迟一致性。
将函数参数标记为consuming如何影响调用者在函数返回后使用不可复制值的能力？
当一个参数被标记为consuming时，函数在进入时获取值的所有权。对于~Copyable类型来说，这构成了一种破坏性的移动，而不是复制。调用者必须放弃该值，在函数调用完成后，原始变量变为未初始化且不可访问。尝试访问它会导致编译时错误。这强制执行线性所有权，确保该值在其生命周期内只有一个所有者。对于可复制类型，consuming会触发隐式复制以满足要求，但对于不可复制类型，则不会发生复制。
为什么不可复制类型不能存储在Swift 6.0之前的标准泛型集合中，如Array？
在Swift 6.0之前，标准库中的泛型类型隐式要求其类型参数符合Copyable。由于不可复制类型使用~Copyable约束显式选择退出Copyable，它们违反了这一隐式要求，无法存储在Array或Optional中。Swift 6.0引入了不可复制的泛型，允许容器有条件地支持不可复制元素，通过传播~Copyable约束。然而，像append这样的操作必须使用consuming语义，并且如果集合包含不可复制元素，则集合本身变为不可复制，这要求在API边界上仔细处理所有权。
在适用于不可复制类型时，borrowing参数修饰符与传统的inout修饰符有什么区别？
borrowing修饰符在不转移所有权的情况下授予对值的临时不可变访问。调用者保留该值，并可以在函数返回后继续使用它，前提是它在函数内部没有被消耗。相反，inout表示可变借用：它要求独占访问，暂时将值移动到函数内部以允许修改，然后再将其移回。对于不可复制类型，borrowing对于只读检查至关重要，而inout则对于修改是必要的。至关重要的是，borrowing防止函数消耗或移动该值，而inout确保值以有效的、可能已修改的状态返回给调用者。