Dart语言中关于库增强文件作为程序入口点的探讨

在Dart语言项目中，最近有一个关于库增强文件（augmentation library）能否作为程序入口点的技术讨论。这个讨论涉及到Dart语言规范、编译器前端实现以及工具链行为等多个方面。

背景

Dart程序通常以一个包含main()函数的库文件作为入口点。然而，在Dart的模块化系统中，存在两种特殊的文件类型：部分文件（part file）和库增强文件（augmentation library）。这些文件不能独立存在，必须归属于某个主库文件。

技术讨论

在早期的实现中，Dart允许在某些特定情况下将部分文件作为程序入口点执行，前提是能唯一确定该部分文件所属的主库。但这种行为被认为是一个不太理想的设计选择，因为它增加了复杂性而没有带来实质性的好处。

对于库增强文件，情况有所不同。每个库增强文件都有一个明确指定的主库文件（通过"augment library"指令），不存在部分文件中可能出现的归属不明确问题。尽管如此，语言团队经过讨论后认为：

1. 允许库增强文件作为入口点不会增加表达能力（因为可以直接执行主库文件）
2. 可能会造成用户混淆（不同文件执行产生相同效果）
3. 增加了实现复杂性

决策结果

经过Dart语言团队和工具团队的多方讨论，最终达成共识：

• 不允许将库增强文件指定为程序入口点
• 只有完整的库文件才能作为程序入口
• 这一限制将在编译器前端(CFE)层面实现

相关技术细节

值得注意的是，这个决策并不影响库增强文件中定义main()函数的合法性。如果一个库增强文件中定义了main()函数，那么该函数将成为所属主库的一部分，主库文件仍然可以作为合法的程序入口点。

这个决策主要影响工具链行为，特别是dart命令如何处理用户指定的入口文件。当用户尝试直接执行一个库增强文件时，工具应该在程序执行前就报错，而不是尝试查找或构建对应的主库。

实现考量

这一限制的实现需要考虑以下技术点：

1. 错误报告的时机：应该在程序执行前的早期阶段就报告错误
2. 与宏系统的交互：虽然宏可能生成main()函数，但这不影响入口点的限制
3. 工具链一致性：确保所有Dart工具对入口点的处理保持一致

总结

Dart语言通过这一设计决策，保持了语言规范的简洁性和工具链行为的一致性。虽然技术上可以实现库增强文件作为入口点，但出于用户体验和实现复杂性的考虑，最终选择了更为保守和明确的设计方案。这体现了Dart语言设计中对开发者体验和实现质量的重视。