@discardableResult是否会触发编译器优化？相关技术咨询

首先得明确：@discardableResult的核心设计目的确实是抑制“未使用返回值”的编译器警告，但它也能间接帮助编译器做出更合理的优化，下面我会拆解你的疑问：

1. 它会不会让编译器忽略函数内的return语句？ #

答案是：不会直接忽略。

编译器是否会跳过return语句相关的计算，取决于这个计算有没有副作用，而不是@discardableResult本身。举个例子：

• 如果你的return语句返回的是纯计算结果（比如return newValue * 2，没有修改全局状态、没有IO操作等副作用），当返回值未被使用时，不管有没有@discardableResult，编译器都可能通过死代码消除优化掉这个计算——但@discardableResult会告诉编译器：“开发者明确允许丢弃返回值，不用怀疑这是个疏忽”，让编译器更放心地执行这个优化，而不会因为担心是开发者漏用返回值而保留计算。
• 如果return语句的计算有副作用（比如return logAndReturn(newValue)，里面包含打印日志、网络请求等），那么即使加了@discardableResult，编译器也绝对不会跳过这个计算，因为副作用是开发者预期要执行的逻辑。

简单说：@discardableResult不直接控制return语句的执行，它只是给编译器一个“返回值可丢弃是预期行为”的提示，让编译器在做优化时没有顾虑。

2. 它实际能实现哪些优化？ #

虽然它不是专门的优化属性，但它能解锁以下几类优化场景：

• 无副作用返回值的死代码消除：如上面所说，当返回值是纯计算结果且未被使用时，编译器可以安全地跳过这个计算，节省不必要的CPU/内存开销。如果没有@discardableResult，编译器可能会因为不确定开发者是否真的想丢弃返回值，而保留这个计算（或者至少会抛出警告，迫使你要么使用返回值，要么加@discardableResult）。
• 链式调用的灵活优化：比如你写了一个支持链式调用的API（比如obj.setX(1).setY(2)），但有时候用户只想调用单个方法而不继续链式。@discardableResult允许这种用法，同时编译器可以根据用户是否使用返回值，决定是否保留后续链式的中间对象创建——比如如果用户只调用obj.setX(1)，编译器可能优化掉setX返回的对象实例（如果没有其他引用的话）。
• 减少编译阶段的警告处理开销：虽然这不算运行时优化，但大量的“未使用返回值”警告会增加编译时的诊断工作量，@discardableResult消除这些警告后，编译过程会更顺畅。

3. 什么时候值得为了优化使用它？ #

如果你的函数满足以下条件，@discardableResult的优化收益会比较明显：

• 函数返回值的计算有一定开销（比如复杂的数学运算、对象实例化）；
• 这个函数经常被调用且返回值经常被丢弃；
• 返回值的计算没有副作用（或者副作用是可被安全忽略的？不，副作用不能忽略，所以只有纯计算的返回值才会被优化）。

如果你的函数主要是为了返回值存在，只是偶尔被丢弃，那@discardableResult主要是为了代码整洁（避免警告），优化收益可能不大。

举个具体的代码例子：

class Counter {
    var value = 0
    
    @discardableResult
    func increment() -> Int {
        value += 1
        // 一个开销较大的纯计算
        return value * Int.random(in: 1...10000) * Int.random(in: 1...10000)
    }
}

let counter = Counter()
// 调用时不使用返回值
counter.increment()

在这个例子中，编译器看到@discardableResult，知道返回值可以被丢弃，同时因为返回值的计算是纯函数（没有副作用），它会直接跳过这个随机数相乘的计算，只执行value += 1的逻辑，从而节省了不必要的计算开销。

内容的提问来源于stack exchange，提问作者Sylvan M.