Swift-Format 中关于 @unchecked Sendable 换行问题的分析与解决

在 Swift 语言开发中，Swift-Format 是一个重要的代码格式化工具，它帮助开发者保持代码风格的一致性。最近发现了一个关于属性修饰符在继承列表中的换行问题，这个问题涉及到 Swift 5.5 引入的 Sendable 协议和 @unchecked 属性。

问题背景

当类声明中包含带有属性的协议继承时，如 @unchecked Sendable，当前的 Swift-Format 会在属性与协议名之间进行换行，导致代码可读性下降。例如：

public class ProtocolAddress: ClonableHandleOwner<SignalMutPointerProtocolAddress>, @unchecked
  Sendable
{
  // 类实现
}

这种格式化方式显然不是最优的，理想情况下应该保持属性与其修饰的协议在同一行。

技术分析

这个问题源于 Swift-Format 对继承列表的处理逻辑尚未完全适配 Swift 语言的新特性。具体来说：

1. Sendable 是 Swift 5.5 引入的并发安全标记协议
2. @unchecked 属性用于指示编译器跳过对类型线程安全的静态检查
3. 当前格式化器将继承列表中的每个条目视为独立元素，没有考虑属性与类型名之间的语义关联

解决方案

核心解决思路是在语法树处理阶段，将属性与其修饰的类型名视为一个逻辑单元。具体实现需要：

1. 在语法分析阶段识别属性-类型名对
2. 在格式化阶段为这对元素添加分组标记
3. 确保格式化器在处理换行时保持这对元素的完整性

这种处理方式符合代码可读性原则，即保持语义相关的元素在视觉上的紧密性。

更广泛的影响

这个问题不仅限于 @unchecked Sendable 组合，还可能影响其他类似的属性-类型组合。解决方案应该具有通用性，能够处理所有可能的属性修饰继承条目的情况。

最佳实践建议

在编写包含属性修饰的继承列表时，开发者可以：

1. 尽量保持属性与其修饰的协议在同一行
2. 如果确实需要换行，考虑在逗号后换行，保持属性与协议的完整性
3. 对于特别长的继承列表，可以考虑每个继承条目单独一行

随着 Swift 并发模型的不断完善，这类代码模式可能会变得更加常见，因此格式化工具的正确处理显得尤为重要。

总结

Swift-Format 的这一改进将提升代码的可读性和一致性，特别是在处理现代 Swift 并发特性时。作为开发者，了解这些格式化规则有助于编写出更清晰、更易维护的代码。同时，这也提醒我们，工具链需要不断演进以适应语言特性的发展。