Swift结果构建器中传入最终类型对象为何可编译运行？

这是Swift结果构建器的内置设计特性，核心原因是编译器会为结果构建器自动合成适配最终类型实例的方法，同时支持混合不同类型的输入元素。

1. 自动合成的buildExpression方法 #

当你定义一个结果构建器（比如SwiftSyntax中的@CodeBlockItemListBuilder），Swift编译器会自动为它生成一系列必要的辅助方法，其中就包括接收构建器最终输出类型的buildExpression(_:)方法。

以你的示例为例，CodeBlockItemListBuilder的最终输出类型是CodeBlockItemListSyntax，编译器会自动合成：

static func buildExpression(_ value: CodeBlockItemListSyntax) -> CodeBlockItemListSyntax {
    return value
}

所以当你在闭包里直接传入itemList时，这个方法会直接把该实例作为构建器的输出返回，不需要额外转换，代码自然可以编译通过。

2. 混合输入的合法性 #

结果构建器同时支持将单个子元素（比如CodeBlockItemSyntax）转换为最终类型。比如CodeBlockItemListBuilder还会合成接收CodeBlockItemSyntax的buildExpression方法：

static func buildExpression(_ item: CodeBlockItemSyntax) -> CodeBlockItemListSyntax {
    return CodeBlockItemListSyntax([item])
}

再配合自动合成的buildBlock方法（用于合并多个元素）：

static func buildBlock(_ parts: CodeBlockItemListSyntax...) -> CodeBlockItemListSyntax {
    // 将多个列表拼接成一个大列表
    let combinedElements = parts.flatMap { $0.elements }
    return CodeBlockItemListSyntax(combinedElements)
}

当你混合传入单个Item和ItemList时，编译器会先把每个元素都转换为CodeBlockItemListSyntax，再通过buildBlock合并成一个最终的列表。你看到的"输出异常"，通常是因为这种合并是简单的元素拼接，而不是你预期的嵌套或其他逻辑，但语法上完全合法。

总结 #

这种设计是为了让结果构建器API的使用更灵活：你既可以用多元素的闭包语法逐步构建结果，也可以直接传入已经预构建好的最终类型实例，甚至混合两种方式，避免不必要的重复代码。

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