Gilad Bracha 写道：.
等等：我们生活在一个幸运的世界，神灵赐予了我们类型推断这样的礼物。如果我根本不需要写类型，让编译器自己推断我需要的类型呢？问题是，推断仅在模块内（如果有的话）有效。如果你在模块边界依赖推断，你的模块就会泄露实现信息。为什么？因为如果你从实现中推断类型，当修改你的实现时，这些类型可能会变化。这就是为什么，即使在ML中，签名也是明确声明的。
说得很好。对于公开声明（即某种可重用单元可见的声明，无论是一个模块、包、类还是其他任何东西）的类型推断，可能会向客户端泄露实现细节，暴露比重用该单元的代码应该看到的更具体的类型。例如
shared local paymentProcessor(Payment payment) { //note: "shared local" is not legal in Ceylon
switch (payment)
case (is CreditCard) { return creditCardProcessor; }
case (is Check) { return checkProcessor; }
}
paymentProcessor()的返回类型可能应该是某种抽象类型，比如Processor，以抽象模块的内部结构，但实际上，使用类型推断隐藏的是更具体的东西，比如CreditCardProcessor|CheckProcessor如果重用代码也使用类型推断，那么最终可能导致一个疯狂的情况，即重用代码对它应该从未在源代码中明确提及的类型有编译时的依赖！例如，在另一个模块中，我们编写.
这里，
local paymentProcessor = paymentProcessor(payment);
paymentProcessor也获得类型这是我们将类型推断限制为非共享的原因。如果重用代码也使用类型推断，那么最终可能导致一个疯狂的情况，即重用代码对它应该从未在源代码中明确提及的类型有编译时的依赖！例如，在另一个模块中，我们编写.
的原始原因。shared在Ceylon中的声明。直到我开始在类型检查器中实现类型推断，我才意识到这个限制有一个额外的优点：我们可以在代码的单次遍历中完成所有类型推断。
