为何Swift的malloc与MemoryLayout.size使用/返回有符号整数？

首先是Swift对应的内存相关接口定义：

public func malloc(_ __size: Int) -> UnsafeMutableRawPointer!

@frozen public enum MemoryLayout<T> {
    public static func size(ofValue value: T) -> Int
    // 其余成员省略
}

和C标准中malloc接收无符号size_t入参、sizeof返回size_t的设计不同，Swift的对应接口统一使用有符号Int类型，这个设计是多维度权衡后的结果，和底层基于libc实现并不冲突，具体考量如下：

• 统一的API设计惯例
  Int是Swift中与平台指针位宽完全对齐的原生整数类型：32位平台下等价于Int32，64位平台下等价于Int64。整个Swift标准库中，所有和长度、计数、容量相关的API——比如数组的count属性、字符串UTF8编码长度、集合的预留容量——统一返回Int类型。内存大小本质上也是一种长度计量值，和其他同场景API保持类型一致，可以省掉大量跨调用时的有符号/无符号类型转换代码，也能从根源上减少类型转换过程中溢出、类型不匹配导致的低级bug。
• 规避无符号类型的经典误用风险
  C语言采用无符号size_t属于历史遗留设计，实际开发中这类设计带来的坑非常多：比如两个无符号数做减法，本应得到负数的场景会直接下溢成一个数值极大的正整数；用无符号类型做倒序循环索引时，判断i >= 0会直接导致死循环——因为无符号数的取值永远不可能小于0。
  而内存分配场景下，开发者根本不可能申请到大小超过Int.max的内存块：64位平台下Int.max数值为9EB，远超过当前所有消费级设备、服务器设备的物理内存加虚拟内存总和上限，无符号类型能多表示的一倍正数范围在这个场景下完全没有用武之地。为了完全用不上的数值范围承担无符号类型的误用风险，投入产出比极低。
• 底层桥接无额外成本
  虽然底层libc的malloc确实接收无符号size_t参数，但Swift在标准库封装层做了完备的边界校验：调用底层malloc实现前，会先判断传入的Int值是否非负，如果传入负值会直接触发前置检查崩溃，不会把非法值透传给libc。对于合法的非负内存大小值，在平台位宽一致的前提下，从Int转换为size_t是零开销操作，不存在性能损耗。

针对“Swift试图摆脱C语言的历史遗留设计是该设计核心原因”的说法，这个方向确实是设计时的参考考量之一，但绝非核心原因。整个设计的核心出发点是实用性：从API一致性、开发安全性、实际场景可用性三个维度权衡后，使用Int的收益远高于沿用无符号size_t，并不是为了刻意对抗C语言的设计逻辑。如果无符号类型在内存操作场景存在不可替代的价值，Swift也不会强行做类型替换。

内容的提问来源于stack exchange，提问作者Vitaly