戻り値型のオーバーロードが許可されないのはなぜですか？（少なくとも通常使用される言語）

すべてのプログラミング言語について知っているわけではありませんが、通常、戻り値の型（引数の数と型が同じであると想定）を考慮してメソッドをオーバーロードする可能性がサポートされていないことは明らかです。

私はこのようなものを意味します：

 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]

あなたが旅行に型情報を許可する場合は、両方のように、その使用から変数の型を推論するよう指示、あなたはタイプを決定するために（ヒンドリー-ミルナーのタイプのシステムのためのそのようなアルゴリズム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]

ここでは、の型をx未解決の型変数として残す必要∃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オーバーロードまたは-returningオーバーロードを呼び出すのか、intそれとも単にコンパイラエラーを与えるのか？

さらに、戻り値の型に注釈を付けることでコンパイラーを支援する必要がある場合は、より多くの構文を考案するだけでなく（機能を存在させるために前述のすべてのコストが発生します）、作成と同じことを効率的に実行できます「通常の」言語の2つの異なる名前のメソッド。である[long] method1(2)よりもより直感的なlong_method1(2)？

一方、非常に強力な静的型システムを備えたHaskellのような一部の関数型言語では、このような動作が可能です。それらの型推論は、これらの言語で戻り型に注釈を付ける必要がほとんどないほど強力であるためです。しかし、それが可能なのは、これらの言語がすべての関数が純粋で参照透過であることを要求するとともに、従来の言語よりも真にタイプセーフを実施するためです。これは、ほとんどのOOP言語で実現可能なものではありません。

これは Swift で利用可能であり、そこで正常に動作します。明らかに、両側にあいまいなタイプを設定することはできないため、左側で認識される必要があります。

これを単純なエンコード/デコード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);
}