7-14.【高级特性】为什么返回 Never 可以帮助编译器进行优化？返回 Never 并不只是给开发者看的“语义标记”

返回 Never 并不只是给开发者看的“语义标记”，它对编译器（Swift Compiler）来说是一个非常强烈的信号。

在 Swift 的编译流程中，编译器会将代码转换为 SIL (Swift Intermediate Language) ，并在此阶段构建 控制流图 (Control Flow Graph, CFG) 。Never 的存在允许编译器对这个图进行深度剪枝。

以下是 Never 帮助优化的具体维度：

1. 控制流图 (CFG) 的剪枝

编译器在分析程序逻辑时，会将代码视为一系列相连的节点。普通的函数节点会有“进入”和“退出”两个连线。

普通函数：编译器必须假设函数执行完后会回到调用处，因此必须保留调用点之后的节点。
Never 函数：编译器知道该节点是终点（Sink Node） 。它会直接切断该节点之后的所有连线。

优化结果： 编译器可以安全地删除所有“不可达代码（Unreachable Code）”。这不仅减少了生成的机器码体积（Binary Size），还让编译器能更专注于有效路径的优化。

2. 寄存器与栈帧管理的简化

在标准的函数调用约定（Calling Convention）中，调用一个函数前，编译器需要：

保存当前的寄存器状态。
在栈上分配空间。
准备好接收返回值的寄存器。

如果编译器确定一个函数返回 Never，它在调用处可以变得非常“粗暴”：

无需清理栈：既然程序都要崩了或终止了，调用后的栈平衡（Stack Balancing）操作就没意义了。
无需恢复寄存器：调用前保存的那些寄存器永远不会被重新加载。
尾调用优化 (TCO) ：编译器更容易将此类调用优化为直接跳转（Jump），而不需要维护复杂的调用链。

3. 提升分支预测器的效率

现代 CPU 使用分支预测（Branch Prediction）来提前加载指令。

当编译器知道某个分支（如 guard 的 else 块）最终会走向 Never 时，它会给指令流打上特殊的标记（如在汇编层面使用 unlikely 指令提示）。

这能引导 CPU 优先预测“正常路径”，减少由于分支预测失败导致的流水线清空（Pipeline Flush）。
性能提升：虽然单次忽略不计，但在高性能循环或底层框架中，这种确定性非常宝贵。

4. 完备性检查 (Exhaustiveness Check)

这是开发者感知最明显的一点。在处理 switch 语句时，如果某个 case 导致了 Never，编译器可以利用这一点来证明整个 switch 已经“穷尽”了所有可能。

Swift

enum Status { case ok, failed }

func handle(_ status: Status) -> Int {
    switch status {
    case .ok:
        return 200
    case .failed:
        fatalError() // 返回 Never
        // 这里不需要写 return，编译器知道这路不通，逻辑已经闭环
    }
}

如果这里返回的是 Void 而不是 Never，编译器会报错，强制要求你在 failed 分支也返回一个 Int。通过 Never，编译器减少了为了满足语法正确性而产生的冗余跳转指令。

总结：`Never` 的三层收益

维度	收益
编译期	加快编译速度，因为需要分析的代码路径减少了。
二进制体积	自动剔除永远不会执行的指令块。
运行期	更好的缓存利用率和更精准的 CPU 分支预测。

面试核心概括：

消除死代码：编译器知道返回 Never 的函数永远不会执行完，因此会直接剔除该调用点之后的所有指令，减小二进制体积。
简化控制流：它告诉编译器某些分支（如 Result<T, Never> 的错误分支）是逻辑上不可能到达的，从而免去编写多余的 return 或错误处理逻辑。
优化底层调用：由于不需要返回调用点，编译器可以跳过维护 CPU 栈帧、保护寄存器等 ABI 调用约定 的开销，直接进行跳转或中止。

英文版

7-14. [Advanced] Why does returning `Never` help the compiler with optimization?

Returning Never is more than a "semantic marker" for developers; it is a powerful signal to the Swift Compiler.

During the compilation process, Swift converts code into SIL (Swift Intermediate Language) and builds a Control Flow Graph (CFG) . The presence of Never allows the compiler to perform deep "pruning" on this graph.

Here are the specific dimensions where Never aids optimization:

1. Pruning the Control Flow Graph (CFG)

When analyzing program logic, the compiler treats code as a series of connected nodes. A standard function node typically has two edges: "entry" and "exit."

Standard Functions: The compiler must assume the function will eventually return to the call site, requiring it to preserve all nodes following that call.
Never Functions: The compiler identifies this node as a Sink Node. It effectively severs all outgoing connections from that point.

Optimization Result: The compiler can safely delete all "Unreachable Code." This reduces the Binary Size and allows the optimizer to focus exclusively on valid execution paths.

2. Simplifying Register and Stack Frame Management

Under standard Calling Conventions (ABI), before calling a function, the compiler must:

Save the current register states.
Allocate space on the stack.
Prepare registers to receive a return value.

If the compiler is certain a function returns Never, it can be much more "aggressive" at the call site:

No Stack Balancing: Since the program is terminating or crashing, there is no need for stack cleanup operations after the call.
No Register Recovery: The registers saved prior to the call will never need to be reloaded.
Tail Call Optimization (TCO) : The compiler can easily optimize these calls into simple jumps (JMP), avoiding the overhead of maintaining a complex call stack.

3. Enhancing Branch Predictor Efficiency

Modern CPUs use Branch Prediction to speculatively load instructions. When the compiler knows a branch (such as a guard's else block) leads to Never, it can mark that path with specific hints (like using the unlikely directive at the assembly level).

This guides the CPU to prioritize the "normal path," reducing Pipeline Flushes caused by misprediction.
Performance Gain: While negligible in a single instance, this determinism is invaluable in high-performance loops or low-level frameworks.

4. Exhaustiveness Checks

This is the most visible benefit for developers. When handling switch statements, if a case results in Never, the compiler uses this to prove the switch is logically "exhaustive."

Swift

enum Status { case ok, failed }

func handle(_ status: Status) -> Int {
    switch status {
    case .ok:
        return 200
    case .failed:
        fatalError() // Returns Never
        // No 'return' is required here; the compiler knows this path is a dead end.
    }
}

If the function returned Void instead of Never, the compiler would throw an error, forcing you to return an Int even in the failed branch. Never eliminates the need for redundant jump instructions used merely to satisfy syntactic correctness.

Summary: The Triple Benefits of `Never`

Dimension	Benefit
Compile-time	Faster compilation by reducing the number of code paths that require analysis.
Binary Size	Automatically strips away instruction blocks that will never be executed.
Runtime	Improved cache utilization and more accurate CPU branch prediction.

Core Interview Summary:

Dead Code Elimination: The compiler knows a Never function will never finish, so it strips all instructions following the call site, shrinking the binary size.
Simplified Control Flow: It signals that certain branches (e.g., the error branch of a Result<T, Never>) are logically unreachable, removing the need for redundant return statements or error handling logic.
Low-level Optimization: Since control never returns to the caller, the compiler skips the overhead of ABI calling conventions—such as protecting registers or maintaining stack frames—and performs a direct jump or termination.

7-14.【高级特性】为什么返回 Never 可以帮助编译器进行优化？