Raku在编译时执行什么类型的检查？将来会改变吗？

如何解决Raku在编译时执行什么类型的检查？将来会改变吗？

当前（截至2020年8月），Rakudo并未在编译时对函数的返回值进行类型检查；也就是说，它不提供函数满足其返回约束的静态保证。具体来说，以下两个函数都可以作为Raku编译：

sub get-int(--> Int) { 'bug' }

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

我有两个相关的问题：

1. 是否有任何方法可以知道在编译时当前进行的类型检查（如果有）？ （通过某人在文档中某处编写的列表，还是在Rakudo来源中的中心位置），还是比它更特别？

2. 是否缺少编译时间来检查故意的设计决策？还是添加更多的静态类型检查，而这可能会很一天，但是还没有实现？

（我熟悉Johnathan对The performance penalties for types/constraints in Raku?的出色回答，该陈述指出：“ Raku要求将类型约束写入程序的要求最迟在运行时 实施。”该答案描述了各种方法可以避免类型检查的运行时成本，但是没有说明在编译时进行什么类型的检查（这肯定会避免运行时成本！）。

解决方法

目前在编译时很少进行类型检查；它主要是作为静态优化器的副作用而发生的。今天的检查主要是关于子例程的调用，其中：

• 我们可以确定调用的范围，并知道传递的参数数量将永远不匹配
• 我们有文字参数，可以看到它们永远不可能与签名匹配

这是静态优化器进行更多内联工作后的剩余内容。如今，它仅在编译时内联本机运算符，其余部分留给VM的动态优化器使用，该动态优化器具有更强大的内联能力，也可以内联（允许推测性优化，但也意味着可以恢复原始堆栈跟踪，而静态优化器会丢失此信息）。

在编译时做更多事情被认为是可取的，但是有一些实际问题需要考虑。

1. 引入其他检查还会导致以前工作的代码损坏。考虑具有代码路径的模块，该模块将无法通过更严格的编译时检查，但是该模块正在从未遇到这种情况的系统中使用。如果开始无法在较新版本的编译器上进行编译，则在升级编译器后将无法部署该系统。通常，这意味着执行的检查应随语言版本的更改而变化。 （记住，这仍然意味着人们在编写代码时应声明所针对的语言版本。）
2. 在编译时进行更多检查将“确实避免运行时成本”可能是正确的，但这样做并非无关紧要。托管运行时不能盲目地信任给出的字节码中的承诺，因为这可能导致违反内存安全性（导致SIGSEGV或更糟）。在像Raku这样的语言中，这很明显是正确的，类型检查的语义是可编程的，但在JVM，CLR等上则是正确的。 Raku中与类型相关的最大优势来自于使用本机类型，这可以避免大量分配，从而避免了垃圾收集工作。
3. 实施进一步的检查将增加编译器的复杂性，并增加编译所需的时间。首先，这已经是一个问题。在大约十年的时间里，编译器前端未见任何重大的体系结构更改。当前为宏奠定基础的RakuAST工作还涉及对编译器前端的几乎重写。改进的体系结构应简化实现进一步的编译时类型检查的工作，但同时也在考虑如何并行化编译方面，这可以使编译器在不增加挂钟编译时间的情况下做更多的事情。

当前的编译器前端检查完成后，似乎很有可能引入更多的编译时检查（但仅在下一个语言版本中启用），至少在有人进行检查的情况下。

但是，在这一领域还有一个更加令人兴奋的机会：由于将有一个Raku程序的API，并且伴随着针对自定义编译器传递的计划，因此不久将有可能实现类型检查器作为模块！其中一些可能导致检查，使其成为将来的Raku语言版本。其他模块可能是特定于域的，旨在使更正确地使用给定模块。其他人可能会执行不符合基本语言实质的严格要求，但是某些用户可能希望选择加入。