Raku编译时类型检查内容、未来变化及Rakudo相关技术咨询

你说得没错，截至2020年8月，Rakudo确实不会在编译时验证函数返回值是否符合类型声明——就像你举的这两个例子：

sub get-int(--> Int) { 'bug' }
sub get-int($a --> Int) { when $a == 5 { 'Rare bug' } default { 42 } }

哪怕返回字符串给声明为Int的函数，编译也能顺利通过，错误只会在运行时触发。下面我来逐个解答你的两个相关问题：

1. 如何了解当前编译时执行的类型检查？ #

目前Rakudo在编译时会执行以下几类类型检查：

• 语法层面的类型声明合法性校验：比如你写出sub foo(Str $x: Int)这种明显不符合语法规则的类型标注，编译器会直接抛出语法错误。
• 静态可确定的赋值类型检查：如果你声明变量时直接赋予类型不兼容的常量值，比如my Int $num = "hello"，编译器会立刻发现并报错——因为这是编译时就能确定的矛盾。
• 多重派发的签名冲突检查：如果你定义两个同名函数，但它们的签名在编译时无法区分（比如sub bar(Int $x)和sub bar(Int $y)），编译器会抛出冲突错误，因为它没法在编译时确定该调用哪个版本。
• 类型层次结构合法性检查：比如你尝试定义一个类继承自不可继承的类型（比如class MyStr is Str，因为Str是final类），编译时就会报错。

至于了解这些检查的途径：

• 官方文档中「Type Checking」相关章节会覆盖部分编译时检查内容，但信息可能比较零散，需要结合不同章节梳理。
• Rakudo源码里，编译时类型检查的核心逻辑主要集中在src/Perl6/TypeCheck.nqp和src/Perl6/Metamodel相关的代码模块中，不过读源码门槛较高，适合有一定NQP或Rakudo开发经验的人。
• 社区的技术博客、演讲分享（比如Raku官方博客的文章）偶尔会拆解编译时检查的细节，你可以关注这类内容。
• 整体来看，当前的检查机制并非零散随意，它主要围绕编译时可确定的静态信息展开，只是不像传统静态语言那样覆盖所有场景。

2. 编译时类型检查缺失是设计决策还是未来会改进？ #

这既是有意的设计决策，同时社区也在积极探索增加更多静态检查的可能性，两者并不冲突：

设计决策的原因 #

Raku的核心设计哲学之一是「渐进式类型」——允许开发者在动态灵活性和静态安全性之间自主选择。编译时不强制全面类型检查，是为了保留动态语言的便利性：比如快速原型开发、复杂元编程场景下的灵活度，这些都是Raku的核心优势之一。

你提到的Johnathan的回答里那句「Raku要求程序中定义的类型约束最迟在运行时强制执行」，正是这个设计的体现：Raku保证类型约束一定会生效，但不强制在编译时就完成全部检查，给了开发者更多控制空间——比如你可以选择通过类型注解获得运行时安全，同时保留动态修改类型的灵活性。

未来的改进方向 #

社区一直在讨论和实验增加可选的编译时静态检查特性：

• 比如类似strict-types的pragma，开发者可以开启它来获得更严格的编译时验证，包括函数返回值的类型检查。
• Rakudo的开发团队也在优化编译时的类型推断能力，对于一些逻辑简单的函数，编译器已经能自动推断出返回值类型，未来可能会允许开发者选择强制验证这些推断结果。
• 不过这些改进都会是可选特性，不会破坏Raku原有的动态灵活性——开发者可以根据项目需求（比如大型项目需要更强的静态安全，小型脚本需要快速开发）选择是否开启更严格的检查。

总的来说，未来Raku的编译时类型检查机制大概率会增强，但核心还是保持渐进式的设计，不会变成纯静态语言。

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