在语言设计圈子里，关于语言应该使用structural equivalence 还是name equivalence，曾经存在过长期争论。 ALGOL 或 ML 或 Modula-3 等语言使用结构等价，而......嗯，几乎大多数编程语言都使用命名等价（包括 Modula-2）。
支持结构对等的典型论据是什么？反对它的典型论据是什么？支持名称等效的典型论据是什么？反对它的典型论据是什么？
【问题讨论】：
标签： computer-science language-design type-equivalence
我认为结构化类型系统的优势在于，它们鼓励您创建面向接口用户需求的细粒度接口，而不是实现者提供的。
在主格类型系统中，您需要对接口的共同依赖。在结构化类型系统中，该要求被消除：您可以构建一个松散耦合的系统，而无需创建放置所有接口的公共库。每个客户端都可以独立地声明它期望从协作者那里得到的接口。
结构类型系统的缺点是它们将类与可能无法真正实现正确契约的接口相匹配。例如，如果你有这个接口：
public interface IBananaProvider
{
/// Returns a banana, never null.
Banana GetBanana();
}
那么下面的类将被隐式考虑在结构类型系统中实现IBananaProvider。但是，该类违反了返回的香蕉永远不会为空的后置条件：
public class SomeBananaProvider
{
// returns a banana or null if we're all out
public Banana GetBanana()
{
if (bananas.Count > 0)
{
return bananas.RemoveLast();
}
else
{
return null;
}
}
}
如果合同以某种方式正式指定并被视为类型结构的一部分，则可以解决此问题。我认为事情正在朝着这个方向发展，例如System.Diagnostics.Contracts 在 .NET 4.0 中。
【讨论】：
支持严格名称等效的一个很好的论据（例如，在 Ada 中可用）是，编译器可以拒绝意外混合不同单位的代码，例如厘米和英寸，或摄氏度和华氏度。
在具有严格名称等效性的语言中，您可以有两种类型
type celsius based on float;
type fahrenheit based on float;
var c : celsius; var f : fahrenheit;
c := f; /* compile time error: incompatible types */
虽然，在一种语言中失去名称等价性和结构等价性......
type celsius is float;
type fahrenheit is float;
c := f; /* no error and no warning here */
...您最终会因计算错误而导致不可预知的行为，具体取决于应用程序和系统的类型，这可能会导致严重的经济损失甚至死亡。如果没有严格的名称等效性，这样的逻辑错误也很难追踪。
【讨论】：