是否应始终在Haskell中使用coerce函数？

已知背景 #

• 始终可以使用Data.Coerce中的coerce函数替代newtype的包装与解包操作
• coerce的执行速度总是更快（有时性能与显式包装/解包相当）

可读性痛点示例 #

以下代码中嵌套的coerce调用可读性极差，复杂场景下还需额外添加类型注解，进一步恶化可读性：

import Data.Semigroup

class Semigroup s => LAction s x where
  (<>$) :: s -> x -> x

instance Num x => LAction (Sum x) x where
  s <>$ x =  coerce (coerce s + x)

问题与解答 #

1. 是否存在可以避免使用coerce且能保证性能不降低的场景？ #

存在。你可以通过显式定义newtype的包装/解包辅助函数，并配合GHC的优化选项（如-O2）来实现与coerce完全一致的性能。

以Sum类型为例，你可以手动定义辅助函数：

unSum :: Sum x -> x
unSum (Sum a) = a

wrapSum :: x -> Sum x
wrapSum = Sum

随后改写实例代码：

instance Num x => LAction (Sum x) x where
  s <>$ x = wrapSum (unSum s + x)

开启-O2优化后，GHC会将这些手动包装/解包函数完全内联并消除，最终生成的机器码与使用coerce的版本毫无区别——既保持了代码可读性，又不会损失任何性能。

另外，base库已经为常见newtype（如Sum、Product）提供了现成的辅助函数（比如getSum/Sum、getProduct/Product），直接使用即可，无需自行定义。

2. GHC是否具备自动执行coercion的优化机制？ #

是的，GHC拥有自动处理coercion的优化能力，核心通过重写规则和类型导向的代码消除实现。

当你使用显式的newtype构造器（如Sum x）或模式匹配（如Sum a -> a）时，开启-O1及以上优化后，GHC会识别这些操作属于无开销的coercion，直接将其从最终生成的代码中移除，不会产生任何运行时开销。

需要注意的是，-O2优化级别能提供更全面的覆盖，确保这类无开销操作被彻底消除，建议在生产代码中启用。

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