Decompose项目中Kotlin/Wasm编译器对SlotNavigator.dismiss扩展函数的严格类型检查问题

在Kotlin多平台开发中，Decompose作为一个流行的组件化框架，其路由系统提供了强大的导航功能。近期在Kotlin/Wasm平台上发现了一个与类型系统相关的有趣问题，涉及到SlotNavigator.dismiss扩展函数的实现细节。

问题背景

SlotNavigator.dismiss是Decompose框架中用于关闭当前slot的便捷扩展函数。其原始实现使用了星投影(*)作为泛型参数，这在大多数Kotlin平台上都能正常工作。然而，在Kotlin/Wasm编译目标下，这种实现方式会引发ClassCastException(CCE)。

技术分析

问题的核心在于泛型类型系统的处理差异。原始实现如下：

inline fun SlotNavigator<*>.dismiss(crossinline onComplete: (isSuccess: Boolean) -> Unit = {}) {
    navigate(
        transformer = { null },
        onComplete = { _, oldConfiguration -> onComplete(oldConfiguration != null) },
    )
}

这里使用SlotNavigator<*>表示接受任何类型的SlotNavigator，但在Wasm平台上，*会被解析为Nothing?类型。这意味着oldConfiguration参数理论上只能接受null值。当实际传入非null值时，严格的Wasm编译器会插入类型检查，导致CCE异常。

解决方案

更健壮的实现应该明确指定泛型参数的上界：

inline fun <C : Any> SlotNavigator<C>.dismiss(crossinline onComplete: (isSuccess: Boolean) -> Unit = {}) {
    navigate(
        transformer = { null },
        onComplete = { _, oldConfiguration -> onComplete(oldConfiguration != null) },
    )
}

这种修改确保了类型安全，同时保持了函数的原有功能。它明确表示接受任何非空类型C的SlotNavigator，避免了Nothing?带来的类型问题。

影响范围

这个问题在Kotlin 2.2.0-RC版本中变得明显，表明Kotlin编译器对Wasm平台上的类型检查变得更加严格。虽然在其他平台上可能不会立即显现问题，但这种类型不安全的实现始终存在潜在风险。

最佳实践建议

1. 在编写泛型扩展函数时，尽量避免使用星投影(*)，除非确实需要处理未知类型
2. 对于明确需要非空类型参数的场景，使用上界来确保类型安全
3. 在多平台项目中，特别关注Wasm平台上的类型检查行为
4. 编写跨平台测试用例，验证不同平台上的类型系统行为一致性

这个问题展示了Kotlin多平台开发中类型系统微妙但重要的差异，提醒开发者在编写跨平台代码时需要更加注意类型安全。