没有类型转换的语言

Question

我的问题几乎就是标题所说的：是否有可能有一种不允许显式类型转换的编程语言？

为了澄清我的意思，假设我们正在使用某种类似 C# 的语言，具有父 Base 类和子 Derived 类。显然，这样的代码是安全的：

Base a = new Derived();

因为向上继承层次结构是安全的，但

Dervied b = (Base)a;

不能保证安全，因为向下继承层次结构不安全。

但是，无论安全性如何，此类向下转换在许多语言（例如 Java 或 C#）中都是有效的 - 代码将编译，并且如果类型不正确，则在运行时将失败。因此从技术上讲，代码仍然是安全的，但是通过运行时检查而不是编译时检查（顺便说一句，我不喜欢运行时检查）。

我个人认为完整的编译时类型安全非常重要，至少从理论角度来看，最多从可靠代码的角度来看。编译时类型安全的一个后果是不再需要强制转换（我认为这很好，因为它们无论如何都很丑）。任何类似强制转换的行为都可以通过隐式转换运算符或构造函数来实现。

所以我想知道，目前是否有任何 OO 语言在编译时提供如此严格的类型安全性，以至于强制转换已经过时了？即，他们不允许任何不安全的转换操作？或者有什么原因这不起作用？

感谢您的任何意见。

编辑

如果我可以通过例子来澄清，这就是我如此讨厌沮丧的重要原因。

假设我有以下内容（大致基于 C# 的集合）：

public interface IEnumerable<T>
{
     IEnumerator<T> GetEnumerator();
     
     IEnumerable<T> Filter( Func<T, bool> );
}

public class List<T> : IEnumerable<T>
{
    // All of list's implementation here
}

现在假设有人决定编写如下代码：

List<int> list = new List<int>( new int[]{1, 2, 3, 4, 5, 6} );
// Let's filter out the odd numbers
List<int> result = (List<int>)list.Filter( x => x % 2 != 0 );

请注意最后一行的强制转换是如何必要的。但这有效吗？不是一般情况下。当然，List.Filter 的实现将返回另一个 List 是有道理的，但这并不能保证（它可以是 List.Filter 的任何子类型）代码>IEnumerable）。即使它在某个时间点运行，更高的版本也可能会改变这一点，从而暴露出代码是多么脆弱。

几乎所有我认为需要向下转型的情况都会归结为类似这个例子的东西 - 一个方法具有某个类或接口的返回类型，但由于我们知道一些实现细节，所以我们有信心向下转型结果。但这是反 OOP 的，因为 OOP 实际上鼓励从实现细节中进行抽象。那么为什么我们还是要这样做，即使是使用纯 OOP 语言呢？

Answer 1

通过提高类型系统的能力可以逐渐消除沮丧。

针对您给出的示例提出的一种解决方案是添加将方法的返回类型声明为“与此相同”的功能。这允许子类返回子类而不需要强制转换。因此，你会得到这样的结果：

public interface IEnumerable<T>
{
 IEnumerator<T> GetEnumerator();

 This<T> Filter( Func<T, bool> );
}

public class List<T> : IEnumerable<T>
{
    // All of list's implementation here
}

现在强制转换是不必要的：

List<int> list = new List<int>( new int[]{1, 2, 3, 4, 5, 6} );
// Compiler "knows" that Filter returns the same type as its receiver
List<int> result = list.Filter( x => x % 2 != 0 );

其他向下强制转换的情况也提出了通过改进类型系统的解决方案，但这些改进尚未针对 C#、Java 或 C++ 进行。

Answer 2

嗯，当然有可能有根本没有子类型的编程语言，那么自然就不需要向下转换。大多数非面向对象语言都属于这一类。

即使在像 Java 这样基于类的 OO 语言中，大多数向下转型也可以通过让基类拥有一个方法来正式替换

Foo meAsFoo() {
   return null;
}

，然后子类将重写该方法以返回自身。然而，这仍然只是表达运行时测试的另一种方式，还有使用起来更复杂的缺点。并且很难在不失去基于继承的子类型的所有其他优点的情况下禁止该模式。

当然，这只有在您能够修改父类的情况下才有可能。我怀疑您可能会认为这是一个优点，但是考虑到人们可以修改父类并因此使用解决方法的频率，我不确定这对于鼓励“好”来说值得多少设计（对于一些或多或少任意的“好”值）。

可以说，如果该语言提供大小写匹配的构造而不是向下转换的表达式，那么它会更加鼓励安全编程：

Shape x = .... ;
switch( x ) {
  case Rectangle r:
    return 5*r.diagonal();
  case Circle c:
    return c.radius();
  case Point:
    return 0 ;
  default:
    throw new RuntimeException("This can't happen, and I, "+
            "the programmer, take full responsibility");
}

但是，如果没有封闭世界，那么在实践中可能会出现问题假设（现代编程语言似乎不愿意做）许多这样的切换将需要程序员知道永远不会发生的default：情况，这很可能会使程序员变得不敏感到最终的投掷。

Answer 3

有许多语言都具有鸭子类型和/或隐式类型转换。我当然会想到 Perl；标量类型的子类型如何在内部进行转换的复杂性经常受到批评，但也受到赞扬，因为当它们确实按照您的预期工作时，它们有助于该语言的 DWIM 感觉。

传统的 Lisp 是另一个很好的例子 - 你拥有的只是原子和列表，以及同时存在的 nil 。否则，两者永远不会相遇……

（不过，您似乎来自一个编程语言必然是面向对象、强类型和编译的宇宙。）