为什么不允许使用返回类型进行重载？（至少使用常用语言）

我不了解所有编程语言，但很明显，通常不支持考虑到方法的返回类型（假设其参数具有相同的数字和类型）而重载方法的可能性。

我的意思是这样的：

 int method1 (int num)
 {

 }
 long method1 (int num)
 {

 }

这并不是编程的大问题，但在某些情况下，我会对此表示欢迎。

显然，如果没有区分所调用方法的方法，这些语言将无法支持它，但是其语法可能像[int] method1（num）或[long] method1（num）这样简单。这样，编译器将知道哪个将被调用。

我不知道编译器是如何工作的，但这看起来并不难，所以我想知道为什么通常不会实现这样的事情。

为什么不支持类似的原因是什么？

它使类型检查变得复杂。

当您仅允许基于参数类型的重载，并且仅允许从其初始化程序推导变量类型时，所有类型信息都朝一个方向流动：在语法树上。

var x = f();

given      f   : () -> int  [upward]
given      ()  : ()         [upward]
therefore  f() : int        [upward]
therefore  x   : int        [upward]

当您允许类型信息在两个方向上传播时（例如，根据变量的用法推导变量的类型），您需要一个约束求解器（例如Hindley-Milner类型系统的Algorithm W）来确定类型。

var x = parse("123");
print_int(x);

given      parse        : string -> T  [upward]
given      "123"        : string       [upward]
therefore  parse("123") : ∃T           [upward]
therefore  x            : ∃T           [upward]
given      print_int    : int -> ()    [upward]
therefore  print_int(x) : ()           [upward]
therefore  int -> ()    = ∃T -> ()     [downward]
therefore  ∃T           = int          [downward]
therefore  x            : int          [downward]

在这里，我们需要将type x作为未解析的type变量保留，我们所∃T知道的仅是可解析的。直到以后，当x将其用于具体类型时，我们才具有足够的信息来解决约束并确定约束∃T = int，从而将类型信息从调用表达式向下传播到语法树中x。

如果我们无法确定的类型x，那么该代码也将被重载（以便调用者确定类型），或者我们将不得不报告有关歧义的错误。

由此，语言设计师可以得出以下结论：

• 它增加了实现的复杂性。

• 在病理情况下，它会使类型检查变慢，呈指数级下降。

• 很难产生良好的错误消息。

• 它与现状有很大的不同。

• 我不想实现它。

因为模棱两可。以C＃为例：

var foo = method(42);

我们应该使用哪个过载？

好吧，也许那有点不公平。如果我们不使用您的假设语言告诉编译器，编译器将无法确定使用哪种类型。因此，在您的语言中隐式键入是不可能的，并且还有匿名方法和Linq以及它。

这个怎么样？（稍微重新定义了签名以说明要点。）

short method(int num) { ... }
int method(int num) { ... }

....

long foo = method(42);

我们应该使用int过载还是short过载？我们只是不知道，我们必须使用您的[int] method1(num)语法来指定它。老实说，解析和编写代码有点麻烦。

long foo = [int] method(42);

事实是，它与C＃中的通用方法惊人地相似。

long foo = method<int>(42);

（C ++和Java具有相似的功能。）

简而言之，语言设计人员选择以不同的方式解决问题，以简化解析并启用更强大的语言功能。

您说您对编译器了解不多。我强烈建议您学习语法和解析器。一旦了解了上下文无关文法是什么，您就会对歧义为何不好的想法有了更好的了解。

所有语言功能都增加了复杂性，因此它们必须提供足够的好处来证明每种功能不可避免的陷阱，极端情况和用户困惑。对于大多数语言，这种语言根本无法提供足够的好处来证明其合理性。

在大多数语言中，您希望表达式method1(2)具有确定的类型和或多或少可预测的返回值。但是，如果允许重载返回值，则意味着在不考虑表达式周围环境的情况下，无法分辨该表达式的含义。考虑一下当您的unsigned long long foo()方法的实现以结尾时会发生什么return method1(2)？那应该调用long-returning过载还是int-returning过载，或者只是给出编译器错误？

另外，如果您必须通过注释返回类型来帮助编译器，那么您不仅在发明更多语法（这增加了上述所有允许存在该功能的成本），而且您实际上在做与创建相同的事情“正常”语言中的两种名称不同的方法。是[long] method1(2)不是更直观long_method1(2)？

另一方面，像Haskell这样具有强大静态类型系统的功能语言确实允许这种行为，因为它们的类型推断足够强大，您几乎不需要在这些语言中注释返回类型。但这是唯一可能的，因为这些语言真正地实现了类型安全，而不是任何传统语言，而且要求所有功能都是纯净的且引用透明的。在大多数OOP语言中这都不是可行的。

它是提供斯威夫特和工作正常那里。显然，您不能在两面都使用模棱两可的类型，因此必须在左侧知道它。

我在简单的编码/解码API中使用了它。

public protocol HierDecoder {
  func dech() throws -> String
  func dech() throws -> Int
  func dech() throws -> Bool

这意味着调用已知参数类型的调用（例如init对象的）非常简单：

    private static let typeCode = "ds"
    static func registerFactory() {
        HierCodableFactories.Register(key:typeCode) {
            (from) -> HierCodable in
            return try tgDrawStyle(strokeColor:from.dech(), fillColor:from.dechOpt(), lineWidth:from.dech(), glowWidth: from.dech())
        }
    }
    func typeKey() -> String { return tgDrawStyle.typeCode }
    func encode(to:HierEncoder) {
        to.ench(strokeColor)
        to.enchOpt(fillColor)
        to.ench(lineWidth)
        to.ench(glowWidth)
    }

如果您一直在密切注意，您会注意到dechOpt上面的电话。我发现很难的方法是，在区分符返回可选值的地方重载相同的函数名太容易出错，因为调用上下文可能会引入期望它是可选值的情况。

int main() {
    auto var1 = method1(1);
}