返回类型推断有缺点吗?如果是的话,他们是什么?

时间:2014-03-07 13:31:53

标签: language-agnostic type-inference

很多静态类型的语言,比如C ++和C#,都有局部变量类型推断(我认为分别是关键字autovar。)

但是,我没有看到许多C派生语言(除了评论中提到的那些)实现编译时返回类型推理。在我提出问题之前,我将用“返回类型推断”来描述我的意思。 (我肯定意味着按返回类型重载。)

以假设的C#语言考虑此代码:

private auto SomeMethod(int x)
{
    return 3 * x;
}

对于人类和编译器而言,返回类型为int(并且编译器可以对其进行验证)非常明显。

多条路径也是如此:

private auto SomeOtherMethod(int x)
{
    if(x == 0) return 1;
    else return 3 * x;
}

它仍然没有含糊不清,因为在所述语言中已经存在一种算法来解决两个表达式是否具有兼容类型的问题:

private auto YetAnotherMethod(int x)
{
    var r = (x == 0) ? 1 : 3 * x;
    return r;
}

由于算法存在并且已经以某种形式实现,因此在这方面可能不是技术问题。但是,我还没有在静态类型的语言中看到它,这让我想到它是否有不好之处。


我的问题:

  • 作为一个概念,返回类型推断是否有任何缺点或者我没有看到的微妙陷阱? (除了可读性 - 我已经明白了。)
  • 是否存在一些会给静态类型语言带来问题或歧义的极端情况?(通过“介绍”,我指的是局部变量的问题类型推断还没有。)

1 个答案:

答案 0 :(得分:1)

是的,有缺点。你已经提到的一个:可读性。第二 - 必须计算类型,因此需要时间(在图灵完整类型系统中它可能是无限的)。但也有不同之处 - 类型系统理论要复杂得多。

让我们编写一个获取列表并返回其头部的函数。什么是它的类型?或者函数接受一个函数,一个参数应用它并返回结果。在许多语言中,你不能声明它。为了支持这种东西,java引入了泛型,它失败了。目前,由于一致性问题,它是该语言最讨厌的功能之一

另一件事:返回类型不仅取决于函数体,还取决于调用的上下文。让我们来看看haskell(我见过最好的类型系统)http://learnyouahaskell.com/types-and-typeclasses 有一个名为read的函数,它接受一个字符串,解析它并返回......无论你需要什么,一个int,一个数组。

所以每次设计一个类型系统时,设计师都必须选择她想要停止的级别。动态语言决定不推断类型,scala决定做一些局部推理,但不是,例如,对于重载或递归函数,c ++决定不推断结果