最近在 Reddit 的 r/C_Programming 和 r/compilers 两个社区发帖讨论了一个问题当某个编程模式被大量项目反复实现时它是否应该从库升格为语言特性这个看似简单的问题引发了两场很有价值的讨论也让我重新思考了语言设计的边界。C 语言其实一直在“克制地演进”很多人认为 C 几十年来几乎没有变化。这种说法并不准确。C 一直在发展只是它的发展方式非常谨慎。它并不会因为某个功能“方便”就加入语言而是会考虑这个特性是否需要编译器理解是否影响类型系统、优化或者内存模型是否能在不同平台上保持统一语义C 的设计哲学并不是追求更多功能而是在寻找一个边界哪些信息应该继续隐藏在库后面哪些信息已经必须成为编译器理解的语义。例如memcpy() printf() malloc()这些功能非常重要但它们本质上属于代码复用问题。开发者需要调用它们但编译器不需要理解它们背后的抽象模型因此留在库中更加合理。而 C11 的 _Atomic 则是一个经典的反例。原子操作早期可以用库函数实现但编译器不知道“这个变量是原子的”就无法正确处理内存序、指令选择和优化限制。只有把 _Atomic 纳入语言编译器才能生成正确的代码。GObject库能解决但代价不小讨论中被多次提到的 GObject 是很好的案例。它在纯 C 上构建了一套完整的对象系统类型、继承、信号、反射。这说明 C 程序员确实有更强抽象的需求。但 GObject 依然停留在库层面因为它对编译器来说仍然只是“结构体 函数指针”。编译器看不到类关系、方法分派等信息导致优化受限、代码碎片化。这正是核心矛盾库足够灵活但重复实现带来了维护成本和兼容性问题。两个社区的视角差异r/C_Programming更关注稳定性。“库能解决就用库为什么改语言”增加语言特性意味着编译器支持、标准维护、长期兼容等沉重负担。r/compilers更关注表达力和优化。“如果编译器能理解这个抽象能否带来本质上更好的代码生成”这种差异很有代表性一个守护 C 的小而美另一个追求语言能力的边界。静态组合 vs 语言原语有人提出很多抽象可以通过模板、trait、comptime 等机制在编译期静态组合C、Rust、Zig 都在这么做。这确实是强大且优雅的方向。但组合已有机制和让编译器原生理解新抽象不是一回事。泛型就是一个例子宏、模板、运行时都能模拟但只有语言级支持才能让类型关系成为编译器可优化的第一等公民。异构计算正在挑战边界今天代码可能运行在 CPU、GPU、NPU 等不同设备上。CUDA/OpenCL 等方案用 API 解决了问题但开发者仍需面对不同的内存模型和编译流程。“代码在哪里执行”——这到底只是一个库调用还是正在成为需要语言表达的新语义真正的问题不是“C 要不要变高级”最容易引起误解的表述是“C 该不该成为高级语言” 这会让很多人立刻进入防御模式以为有人想把 C 变成 C。更准确的问题是哪些抽象应该留在库哪些应该成为语言和编译器能理解的能力C 的成功正源于它清晰的边界。未来 C 是否需要调整边界不取决于“功能越来越多”而取决于软件世界是否出现了新的基础概念这些概念已经无法被简单库机制优雅地表达。我的思考AET 的视角这次讨论让我意识到语言设计中的争论往往不是“支持增加功能”和“反对增加功能”的简单对立而是两个问题的权衡抽象能力的收益和语言复杂度的长期成本。在设计 AET 的过程中我也在持续思考这个问题。AET 不是简单给 C 堆语法而是尝试让编译器理解更多程序员真正关心的信息泛型语义、执行设备、扩展的目标模型等。语言的真正价值不只是写得更方便而是让编译器和程序员站在同一边。总结本文的中心思想其实就是下面这个流程图库模式|边界语言抽象|编译器语法