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

Question

很多静态类型语言,如C++和C#中,有局部变量类型推断(用关键字auto和var分别,我想).

但是,我没有看到许多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;
}

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

---

我的问题:

• 返回类型推断作为一个概念,有什么不利或微妙的陷阱,我没有看到？(除了可读性 - 我已经明白了.)
• 是否存在一些极端情况会导致静态类型语言出现问题或含糊不清？(通过"介绍",我指的是局部变量类型推断尚未存在的问题.)

Answer 1

是的，有缺点。您已经提到过：可读性。第二 - 必须计算类型，因此需要时间（在图灵完备的类型系统中，它可能是无限的）。但也有一些不同之处——类型系统的理论要复杂得多。

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

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

因此，每次设计类型系统时，设计者都必须选择她想要停止的级别。动态语言决定根本不推断类型，scala 决定进行一些本地推断，但不进行某些本地推断，例如，对于重载或递归函数，而 c++ 决定不推断结果