说实话,很多Swift开发者学到函数、闭包、可选型之后就停了,觉得“语法差不多够用”。但一旦你开始去读第三方开源库,或者接手一个有一定规模的Swift项目,就会发现自己经常被一些看不懂的符号卡住——比如 <<、&+ 这种“奇奇怪怪”的表达方式,再比如别人自定义了一个 ~= 或者 •• 这样的操作符,读起来一脸懵。这些就是Swift的高级运算符。这篇笔记我打算系统梳理一遍这块内容,包括位运算符、溢出运算符、运算符重载和自定义运算符。我自己当年学的时候踩了不少坑,这次一并写出来,希望能帮你少走弯路。内容定位是进阶Swift开发者,当然如果基础语法还不熟,先把基础打牢再看这篇会更舒服。
1. 内容整体设计与思路拆解
1.1 为什么要把“高级运算符”单独拎出来讲
很多语言把运算符当成一个“固定语法表”丢给开发者,你只需要背下来就行。但Swift不是这样,运算符在Swift里是一套可以被扩展的语法体系。这意味着你不仅能使用现成的 + - * /,还能定义自己的运算符,或者让已有运算符支持你自己的类型——这套能力在C、Java、Objective-C里都做不到,或者说做起来非常别扭。
所以Swift的高级运算符,核心要搞明白的东西其实分两大类:
- 第一类是系统内置但平时不常用到的运算符,主要是位运算符、溢出运算符、区间运算符的复杂用法等,难点在于理解它们的计算规则,以及在什么场景下该用它们。
- 第二类是“运算符重载”和“自定义运算符”,这个属于语言高级特性,难点在于设计层面,不是语法层面。用得好,代码的可读性和领域表达力会显著提升,用不好就是大型灾难现场。
这篇笔记的编排思路,就是从“读懂内置高级运算符”到“自定义一套能表达特定语义的运算符”,由浅入深走一遍。中间会穿插我在实际项目里用过的场景,方便你对应到自己的代码里。
1.2 一套运算符背后的编译原理逻辑
先补充一个底层认知。你在Swift里写的表达式,比如 a + b 或 value & 0xFF,本质上不是CPU直接认识的操作,而是编译器把你表达式的符号翻译成对某个函数或指令的调用。+ 之所以能作用于整数,是因为Swift标准库为整数类型实现了这个运算符函数;同理,<< 能被左移,背后也是整型类型实现了对应协议 BinaryInteger 里的方法。所以你可以把“运算符”理解成语法糖 + 方法调用的结合体。
这就解释了为什么你能为自定义类型重载运算符:运算符本质是函数,而函数允许你定义同名但参数不同的版本。编译器在编译表达式时,会根据操作数类型去匹配该用哪个函数,这个过程发生在编译期。这也是为什么Swift的运算符重载具备类型安全特性——你要是把一个自定义类型和一个 Int 做 + 运算,而二者之间没有实现过对应的运算符函数,编译器会直接报错,不会让你编译通过。
搞懂这个底层逻辑之后,再看高级运算符的各个细节,你会感觉非常清晰。记住这句话:运算符问题的本质,是函数匹配和表达式解析的问题。
需要模型API调用? 免费领10W Token,多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心内置高级运算符解析
2.1 位运算符:用二进制思维处理数据的底层工具
位运算符(Bitwise Operators)是所有“高级运算符”里的基础。Swift一共提供了六个位运算符:按位取反 ~、按位与 &、按位或 |、按位异或 ^、按位左移 <<、按位右移 >>。
它们操作的是整数在内存里的二进制位。具体规则我简洁列一下:
~:按位取反,0变1,1变0。&:按位与,两位均为1时结果为1,否则为0。|:按位或,两位只要有一个1就为1,否则为0。^:按位异或,两位相同时为0,不相同时为1。<<:将所有位向左移动指定位数,低位补0。>>:将所有位向右移动指定位数,无符号数高位补0,有符号数高位由符号位填充(算术右移)。
位运算最常见的活用场景有几个。权限系统设计是典型一个。例如设置一个 Int,用每1位表示一项权限的开关状态,通过 | 来叠加权限,用 & 判断权限是否存在,用 ^ 来切换权限状态。
swift复制struct Permission: OptionSet {
let rawValue: Int
static let read = Permission(rawValue: 1 << 0)
static let write = Permission(rawValue: 1 << 1)
static let execute = Permission(rawValue: 1 << 2)
}
let userPermission: Permission = [.read, .execute]
if userPermission.contains(.read) {
print("有读权限")
}
OptionSet 是Swift协议里位掩码比较优雅的实现方式,内部原理就是位运算。这个例子你把位运算代入进去理解就很自然:一组权限本质是一个二进制整型,每一个二进制位代表一种权限,通过左移运算符把某一位“点亮”,通过按位或把多个权限拼到一起,通过按位与检测目标位是否为1。SwiftUI里也有类似用法,比如 Text("Hello").font(.system(size: 14)).bold() 里,看似是链式调用,但很多场景下系统内部依然依赖bits级别的计算来优化UI状态表达。
第二个非常实用的场景是二进制协议编解码。我做蓝牙外设开发时,经常要把多个开关状态数值合并成一个字节发送硬件端。这时候位运算是绕不开的:
swift复制// 把一个包含多个开关状态的对象编码成单字节
var byte: UInt8 = 0
if leftFootSensorActive { byte |= (1 << 0) }
if rightFootSensorActive { byte |= (1 << 1) }
if armSensorAttached { byte |= (1 << 2) }
// 然后通过BLE写入 byte
反过来,解析硬件返回的状态字节时同样是一顿 & 配合位移拆位。
第三个场景是掩码计算和状态标志。比如你拿到了一个 UInt8 值,只关心其中的后4个bit,就需要 value & 0x0F 来做掩码保留。这类操作在图像处理、加密算法、底层内存布局分析中都很常见。
建议:Swift的位运算符和C语言几乎完全一致,如果你之前做过单片或底层相关工作,这块几乎可以直接迁移。如果是纯应用层开发,初学阶段不必深究到每一行都手写位运算,但要知道这些能力的存在,遇到需要做二进制解析或者性能敏感处理时能想到它。
2.2 有符号整数的右移陷阱:逻辑移位与算术移位
位运算里面最容易踩坑的是 >> 右移。很多初学者以为右移就是所有位往右挪,左边补 0 完事。但实际上,Swift对有符号整数的位移做了算术移位的处理——也就是说,右移后左端补的 0 还是 1,取决于符号位。
举个非常典型的例子:
swift复制let negativeNumber: Int8 = -2
// -2 在二进制补码表示中为:1111 1110
let shifted = negativeNumber >> 1
// 如果是逻辑移位,左边补0得到:0111 1111,数值为127。
// 但Swift中是算术移位,符号位为1,左边补1,得到:1111 1111,数值为 -1。
print(shifted) // 输出:-1
为什么Swift要这样处理?因为对于有符号整数而言,右移相当于除以2的幂,为了保证负数除以2的结果仍然为负数,就必须用符号位填充高位。这是一种语义连续性的保护。同理,-8 >> 1 得到 -4,-8 >> 2 得到 -2,这样才符合“右移等价于整除2”的直觉。
你如果没有意识到这一点,在处理纯位掩码(bitmask)场景时,如果错误地把一个有符号整数用来装位模式,然后去做右移拆分,就会拿到一堆令人困惑的 -1。所以我个人的习惯是:如果纯粹想处理二进制位模式,一律用无符号类型 UInt8、UInt16 或 UInt32,这样所有位移都是逻辑移位,行为可预测,不用操心符号位带来的干扰。
2.3 溢出运算符:Swift为何选择崩溃而不是静默出错
接下来我们聊一个很多新手第一次接触会觉得“Swift是不是有点激进”的特性——溢出运算符。
在C语言里,如果定义一个 UInt8,赋值给它 255 + 1,实际结果是 0,不会报错,程序也不崩溃。这是无符号整数溢出。但是Swift反着来:你在Release下如果对一个整数做了超出它表达范围的运算,程序直接崩溃,你在Debug下编译阶段就会看到“arithmetic operation resulted in an Overflow”的报错提示。
swift复制var maxUInt8 = UInt8.max
// maxUInt8 = 255
// maxUInt8 = maxUInt8 + 1
// 这行代码直接触发溢出错误/崩溃
你可能会想,这种“安全到死”的设计是不是太死板了,明明有时候我就需要它自然溢出回绕。别急,Swift为此提供了三个“主动拥抱溢出”的运算符:&+、&-、&*。它们的存在意义就是告诉你:我知道你在做什么,我允许你溢出回绕。
swift复制var value = UInt8.max
value = value &+ 1
print(value) // 输出:0,因为回绕了
我做过一段时间的OpenGL渲染相关的事情。顶点坐标计算时经常需要把数据严格限定在0~255范围,或者需要做颜色的RGB值调整时,此刻用 &+ 就能让溢出自动回绕,省去一个手动 %255 的步骤,虽然需要你注意适用前提,但确实方便。
这个设计背后有更深层次的原因。Swift的主打安全,它是一种“宁可失败也不要默默给你错结果”的语言。一个整数溢出如果不被发现,可能带来难以追踪的逻辑错误——这种 bug 在金融计算和数据处理场景里会比较棘手。相比之下程序崩在事发当场,反而更容易快速定位修复。这个理念贯穿了Swift整个语言设计,比如数组越界会崩溃、可选值强制解包空值也会崩溃,本质上都是同一个理念。
实践提醒:
&+、&-、&*是绕回语义,并不是饱和运算。如果你想在溢出时停留在最大值或最小值,Swift标准库并没有提供一个默认的内置“饱和加”运算符,需要你通过addingReportingOverflow之类的API或自定义逻辑去处理。写底层代码时要注意区分。
3. 运算符重载:让自定义类型也具备运算能力
3.1 运算符重载的本质与实现规则
前面提到,运算符本质是函数。运算符重载(Operator Overloading)的本质,就是给你的自定义类型定义这些运算符函数。
假设你在开发一个向量库,Vector3 代表三维向量。你希望在两个向量之间执行 +、- 操作,直接写 vectorA + vectorB 会非常直观。这时候运算符重载就派上用场了:
swift复制struct Vector3 {
var x: Double
var y: Double
var z: Double
static func + (left: Vector3, right: Vector3) -> Vector3 {
return Vector3(
x: left.x + right.x,
y: left.y + right.y,
z: left.z + right.z
)
}
static func - (left: Vector3, right: Vector3) -> Vector3 {
return Vector3(
x: left.x - right.x,
y: left.y - right.y,
z: left.z - right.z
)
}
}
let v1 = Vector3(x: 1, y: 2, z: 3)
let v2 = Vector3(x: 4, y: 5, z: 6)
let sum = v1 + v2 // (5, 7, 9)
这个例子很简单,但有几点重载运算符必须要记牢的规则:
- 运算符函数必须声明为
static(或在类型里使用static/class关键字)。 - 重载二元运算符时,固定有两个参数,分别对应左操作数和右操作数。
- 重载一元运算符时,固定只有一个参数,而且函数名前面的关键字会有些变化(下面马上讲到)。
- 运算符函数的
+号本身并没有默认的交换律或结合律,你必须理解到编译器只是把表达式翻译为静态分派的函数调用,并不会帮你判断操作数的顺序正确性。
我常用的另一个场景是复数的运算。虽然Swift标准库没有原生复数类型,但你在做信号处理、图形变换时经常需要,自定义一个 Complex 结构体,重载四则运算后就能用非常自然的写法完成复数计算:
swift复制struct Complex {
var real: Double
var imaginary: Double
static func + (lhs: Complex, rhs: Complex) -> Complex {
return Complex(
real: lhs.real + rhs.real,
imaginary: lhs.imaginary + rhs.imaginary
)
}
static func * (lhs: Complex, rhs: Complex) -> Complex {
return Complex(
real: lhs.real * rhs.real - lhs.imaginary * rhs.imaginary,
imaginary: lhs.real * rhs.imaginary + lhs.imaginary * rhs.real
)
}
}
3.2 重载运算符时容易忽略的对等性和组合性
如果你自己动手写过重载,你会发现“实现 + 容易,实现一整套运算符难”。这里说的难不是编码难,而是设计难。核心要处理好两点:对等性和组合性。
对等性指什么?如果你定义了 ==,Swift要求你同时定义 != 以保证逻辑完整。你可以只实现 == 和 != 中的一个吗?严格来说编译器默认允许你只写 ==,因为 != 可以使用默认实现吗?注意,Equatable 协议要求实现 ==,而 != 默认是基于 == 取反实现。但在自定义类型里如果你完全手工写运算符而不是遵循协议,就很可能出现“只有 == 没有 !=”的不对称情况,调用处直接编译报错。所以尽量使用协议驱动的写法。
组合性指的是什么?如果你定义了 +,通常应当顺带考虑 +=。同时,如果 + 对值类型有交换语义(比如加法、位或),建议两边都提供参与过运算的版本,保持API的完整性。比如复数做了 + 后,用户自然会期待 += 也能用,你没实现就只能写 c1 = c1 + c2,写得多了会觉得憋屈。
另一个常见问题是不要重载你控制范围之外的类型运算。例如,你为了图省事给自定义类型和 Int 之间实现了 * 运算,但只想在有逻辑意义时才这样做。如果代码库很大,日后其他协作者很可能会对这一运算产生错误的理解。运算符的可读性非常依赖于使用场景和命名,如果两个毫无关系的类型之间出现了 *,写代码是省了事,读代码的人就惨了。
3.3 前缀与后缀运算符的重载写法
Swift里一元运算符分两种:前缀运算符(比如 -a、!a)和后缀运算符(Swift里少数,如可选性的 a! 强制解包,但不建议自己定义后缀运算符去干扰它)。在自定义类型里去重载一元运算符时,语法上多一个修饰:
swift复制struct Matrix {
var values: [Double]
// 重载负号,让矩阵取相反数
static prefix func - (matrix: Matrix) -> Matrix {
return Matrix(values: matrix.values.map { -$0 })
}
// 重载 !,比如用来表示矩阵的转置(虽然语义不太贴切,仅示例)
static prefix func ! (matrix: Matrix) -> Matrix {
// 转置逻辑略
return matrix
}
}
前缀运算符声明在 func 前面加上 prefix 关键字,后缀用 postfix。需要注意,Swift中 ! 已经被可选型强制解包和编译诊断使用,如果你在自己的类型上重载 ! 这种符号,一般只限定在这个类型的上下文使用,而且通常意味着“取反”或某个和语义相符的操作。但大多数情况下,如果语义不够明确,我都不建议去重载 !、? 这类从别的类型继承过来的系统级符号,而是优先成对自定义符号。
4. 自定义运算符:成体系的领域表达工具
4.1 定义你的第一个自定义运算符
自定义运算符是整个Swift语言非常有特色的一块。简单说,你可以自己发明一套符号,然后在自己的类型上实现对它的运算逻辑。
声明一个运算符需要两步。第一步是告诉编译器这个符号存在、以及它放在哪:
swift复制prefix operator √
infix operator ±: AdditionPrecedence
prefix operator表示这是一个前缀一元运算符(比如放在参数前面的)。infix operator表示这是一个二元(中缀)运算符,两个操作数中间夹着它。- 后缀运算符要用
postfix operator,不过我实际项目里很少用。
第二步就是写对应的运算符函数。比如给 Double 扩展一个手动开根号的运算符:
swift复制prefix func √ (number: Double) -> Double {
return number.squareRoot()
}
extension Double {
static func ± (left: Double, right: Double) -> ClosedRange<Double> {
return (left - right)...(left + right)
}
}
这时你就可以写:
swift复制let root = √16.0 // 输出 4.0
let range = 5.0 ± 1.0 // 4.0...6.0
let errorRange = 100.0 ± 1.5 // 98.5...101.5,这种表达一些实验误差范围很语义化
这个 ± 算是一个很好的应用场景。在科学计算、工程测量领域,用 ± 直接表达误差范围比写 (value - tolerance)...(value + tolerance) 清晰多了。自定运算符往往正是适合这些有领域语义、符号本身能唤起天然理解的场景。
4.2 优先级与结合性:决定一长串表达式如何按预期解析
自定义运算符最容易被忽视的是优先级组(Precedence Group)。如果你自定义了一个中缀运算符,却没有给它指定优先级组,Swift会默认它属于 DefaultPrecedence——这个优先级组比较特殊,赋值、三元条件这些语句不能直接和它相邻使用,而且结合性并不是预期的。更让新手迷惑的是:两个没有指定优先级组的自定义运算符写在一个表达式里,编译器会直接报错,要求你显式加括号。
所以,定义中缀运算符时最好显式声明优先级组。例如:
swift复制infix operator •: MultiplicationPrecedence
extension Array where Element: Numeric {
// 实现两个数组的点乘
static func • (lhs: Array<Element>, rhs: Array<Element>) -> Element? {
guard lhs.count == rhs.count, !lhs.isEmpty else { return nil }
return zip(lhs, rhs).reduce(0) { $0 + $1.0 * $1.1 }
}
}
上面我用了 MultiplicationPrecedence,这样在写 a • b + c 时会先把 a • b 求出来,结果再加 c。因为点乘的本质是一系列乘法累加,与乘法的优先级保持一致是非常合理的。
如果你要自定义一个全新语义的运算,建议按情况使用已有的系统优先级组,或者自定义一个优先级组并继承一个合适的级别:
swift复制precedencegroup PowerPrecedence {
higherThan: MultiplicationPrecedence // 比乘法优先级更高
associativity: right // 右结合,2 ^ 3 ^ 2 解析为 2 ^ (3 ^ 2)
assignment: false
}
infix operator ^^: PowerPrecedence
func ^^ (lhs: Double, rhs: Double) -> Double {
return pow(lhs, rhs)
}
let value = 2 ^^ 3 ^^ 2 // 因为右结合,实际是 2 ^^ (3 ^^ 2) = 2 ^ 9 = 512
自定优先级组的思考方式其实就像重新设计数学运算表:如果你定义了一个新的中缀运算符,你就得决定它和 +、* 比较谁先算,也决定多个相同运算符出现时是从左往右算还是从右往左算。
4.3 设计自己的运算符:要不要为“好看”埋单
在我接手过的代码评审里,看过不少自定义运算符翻车现场。最常见的莫过于把一串项目代号里的自定义符号加进去,比如 enum 操作 <~> 某个闭包,当时觉得很优雅,过了三个月回头看,两人都不确定它到底做了什么。因此我自己心里有一条“自定义运算符使用规范”:
- 只在语义非常清晰、短期内不可能变化的领域场景里使用。比如数学、物理、单位计算。
- 如果这个符号你需要在文档里花两句话以上向别人解释,说明它不值得自定义,用普通命名函数更好。
- 自定义运算符不要出现在公开框架的基础API层,除非这个框架本身就是数学库或DSL工具。
- 尽量使用键盘能打出的符号,避免使用生僻Unicode字符,否则团队其他成员甚至会被输入法折磨。
当然,很多优秀的Swift库确实使用自定义运算符来表达精简API。比如处理函数式编程的一些库会用 |> 做管道操作,让数据按链式顺序流过多个变换函数。这个运算符实现后,代码会非常接近自然语言。但我给的建议永远是:经典、通用、语义明确的自定义运算符是宝藏;为读代码的人负责是第一原则。
4.4 与代码生成工具的横向对比:为什么自定义运算符不是万能的
有些朋友看到自定义运算符,第一反应是“可以用它做一整套类似SwiftGen那种代码生成能力了”。这里稍微展开一下。SwiftGen这类库解决的问题是“把资源名、字符串、颜色等硬编码内容转换成类型安全的Swift代码”,它是在编译前生成代码来规避硬编码带来的风险,并不会去做运算符层面的语义扩展。自定义运算符解决的是“让类型之间的组合语义更加自然”,比如点乘、误差范围、向量加法。前者是自动化代码生成问题,后者是表达式可读性问题——两者完全不冲突。
如果你发现自己频繁地在为某个类型写带明确领域语义的 func,并且代码里到处是 add(...)、combined(with:...),可以考虑这个场景是否适合用运算符来表达。但其实大多数业务代码场景里,我反而建议多写命名函数,因为函数名能承接“上下文信息”,而运算符不能。比如 combined(with:options:) 这种长长的函数名,确实有它不可替代的表达力。
5. 常见问题与排查技巧实录
5.1 运算符优先级与括号使用混乱
新手最容易碰到的错误是:写完一堆自定义中缀运算符后,编译器提示 “Adjacent operators are in non-associative precedence group”,然后有人就暴力加括号了。要排掉这一类问题,建议按以下步骤梳理:
- 先查看你的运算符定义式,使用的是哪个优先级组,确认表达式中其他运算符的优先级关系。
- 如果两种不同优先级组的中缀运算符相邻,比如
a <op1> b <op2> c,编译器无法推断时,需要你给其中一段加括号,或者调整优先级定义。 - 注意高度关联的运算符尽量放在同一个优先级组里,否则容易各管各的,组合使用的时候就不断被迫加括号。
提醒:在
if条件、guard语句、switch case里使用自定义运算符时,表达式会和=、三元运算混在一起,这种时候Swift的解析规则会变得敏感,建议多用括号显式标明边界,不要省。我测试发现,加括号后不仅可读性更高,还能避免编译器推导歧义。
5.2 == 重载了但数组排序报错
很多人给自定义结构体重载了 ==,然后自信用 sort 或 max,结果编译器直接提示没有实现 Comparable。原因是,系统常用的 >、<、>=、<= 这些比较运算,Swift是通过 Comparable 协议来约束的,而 Comparable 不仅要求 ==,还要求实现 <,而且 < 才是排序的关键方法。
swift复制struct Student {
let name: String
let age: Int
}
extension Student: Comparable {
static func == (lhs: Student, rhs: Student) -> Bool {
return lhs.name == rhs.name && lhs.age == rhs.age
}
static func < (lhs: Student, rhs: Student) -> Bool {
return lhs.age < rhs.age
}
}
let students = [Student(name: "A", age: 20), Student(name: "B", age: 18)]
let sorted = students.sorted()
比较有意思的是Swift隐藏了不少默认行为。比如对于一个只有==重载且数据类型里包含的属性都遵循 Equatable 时,== 甚至可以用派生实现。但对于排序而言,只实现 == 是不够的,< 没实现的话,sort就无从谈起。这个坑踩过一次就记住了。
5.3 进阶排查思路:从编译原理的角度理解运算符问题
调试运算符相关问题,最高效的思路仍然是回到那个底层认知——运算符就是函数,表达式就是函数调用。如果碰到一个无法编译的表达式,可以手动把它改写成函数调用形式,通常很快就能明白问题所在。
比如 value + 1,如果 value 是自定义类型,就等价于 MyType.+(value, 1),如果你发现自己没有重载 Int 作为第二参数的版本,马上就知道是类型不匹配问题。同理,自定义运算符的报错大多是“找不到接收者”“参数类型不符”,这时候先检查你在哪个类型上实现了运算符函数,再检查参数标签(其实运算符没有标签,就纯靠参数类型匹配),最后看优先级和结合性。比起死记硬背文档,这个排查路子要高效得多。
6. 实操经验总结与一些具体的扩展方向
6.1 从“能用”到“设计得当”的进阶路径
运算符相关的能力,想从“看得懂”到“设计得很顺”,建议按这个顺序练手:
- 第一阶段:把官方文档里的位运算符例子都自己敲一遍,尤其是有符号右移和无符号右移的区别,多跑几个负数验证结果。
- 第二阶段:在自己的项目中,找一些能自然把逻辑转为位掩码的场景。比如给一个业务对象增加多个“特性开关”,用
OptionSet实现一版,替换掉原来的[Bool]方案。 - 第三阶段:写一个自定义数值类型,比如角度
Angle或三维向量Vector3,完整实现它需要的四则运算和比较运算符,试着感受运算符重载让业务代码如何变“瘦”。 - 第四阶段:只在领域语义极其明确的场景下,设计少量自定义运算符,并在项目文档里写清楚语义。不要为了炫技而盲目去碰它。
我个人实操中最有收获的,是重载工具类中间将 Range 构造封装成可读性更强的 ... 变体,以及用自定义的 ± 表达公差范围。这些改动让调用的地方可读性直接上一个台阶,代码评审时交流成本也低了很多。
6.2 最后再分享一个调试小技巧
在Xcode里遇到运算符相关的编译错误时,不要把思维局限于运算符本身。用Xcode的“Quick Help”或者直接在代码里跳转到运算符定义处,看它的接收者是谁、优先级组是什么。特别是当运算符被某个类型用extension实现得很多时,跳转时可能会让你选择具体是哪一个实现,这说明运算符函数其实可以和普通函数一样形成“重载集合”。想快速找到自己想看的那份,就看参数类型是否和你用的一致。这个小习惯我在排查项目里引入第三方库导致同一运算符命名冲突时帮了大忙。
另外一个比较容易忽视的是运算符函数和普通函数一样,会被fileprivate、internal、public等访问控制修饰符限定作用范围。如果你想在别的模块里使用自定义运算符,就必须把运算符声明和运算符函数都标记为public,只公开运算符声明而不公开函数,别的模块只能看到该运算符的存在,一用就报错。这种怪问题我有一次耗费了不少时间才定位出来,先记一笔记在这里。
