Flow Typing与Borrow Checking：PL设计巧思

A Few Good Ideas in Programming Languages

▲ 106airhangerf1571 HN 评论区

我分享了几项让我着迷的编程语言特性。首先是Flow Typing，它在Crystal和TypeScript中让静态类型语言拥有动态语言的灵活感，通过控制流分析在编译期推断变量类型，既安全又高效。其次是Rust的Borrow Checking，它通过严格的借用规则在编译期杜绝数据竞争，无需垃圾回收即可保障内存安全，虽增加了学习成本，却是并发编程的优雅解法。最后是D语言的Contract Programming，它用enforce和invariant等语法糖，让函数前置后置条件及对象不变式变得清晰可维护，将断言从调试工具升级为设计契约。这些特性展示了类型系统与语言设计如何平衡安全、性能与开发者体验。

这展示了如何利用巧妙的类型推断，让编译型语言拥有动态语言的感受，却无需付出太多运行时代价。
阅读原文 →HN 评论区RSS

HN 评论区

71
  1. phtrivier

    为了较真一下，我们是不是该提一句，设计契约（Design by Contract）其实是源自 Eiffel 的？

    （不过也有可能，写过 Eiffel 的人比写过 D 的还少，所以谁知道呢）

  2. prydt

    我没想到这篇帖子会发到这里。我是这里的资深潜水员。

    我对编程语言设计和人机工程学（ergonomics）真的很感兴趣。你们希望看到哪些小众的 PL 特性得到更广泛的采用？

  3. Panzerschrek

    > Borrow Checking

    这个名字起得让人很困惑。它暗示这里发生了某种“借用”，而且这仅仅是一个可选的检查，但事实并非如此。它应该被命名为“强制静态使用分析”之类的。

    在我的编程语言中也有类似的机制。但这不仅仅是检查，因为它还会影响代码生成，通过追踪哪些变量仍在使用、哪些可以被销毁来实现。

  4. vallerie

    我知道这很有争议，但我真的非常喜欢 C++26 的契约断言（contract assertions）。

    我发现它们能让你、你的调用者、IDE、智能体等等，远比以前更快地理解方法的契约，因为你实际上不需要通读整个方法体。如果前置条件正确而后置条件失败，你就可以相当确定地把 bug 报告发给该方法的所有者，因为要么是前置条件错了，要么就是方法本身错了。

  5. leoc

    如果你真的想在拥有静态类型的同时（当然还有可变性）做面向对象编程，你基本上就必须拥有类似 Flow Typing 的东西，才能避开那些圆形/椭圆形的废话。（只要 Flow Typing 还算得上是真正的静态类型！）

同日更多故事

2026-09-12