Mengapa kelebihan beban dengan jenis pengembalian tidak diizinkan? (setidaknya dalam bahasa yang biasanya digunakan)

Saya tidak tahu tentang semua bahasa pemrograman, tetapi jelas bahwa biasanya kemungkinan overloading metode dengan mempertimbangkan jenis kembalinya (dengan asumsi argumennya adalah jumlah dan jenis yang sama) tidak didukung.

Maksud saya sesuatu seperti ini:

 int method1 (int num)
 {

 }
 long method1 (int num)
 {

 }

Ini bukan masalah besar untuk pemrograman tetapi pada beberapa kesempatan saya akan menyambutnya.

Jelas tidak akan ada cara bagi bahasa-bahasa tersebut untuk mendukung itu tanpa ada cara untuk membedakan metode apa yang sedang dipanggil, tetapi sintaks untuk itu dapat sesederhana sesuatu seperti [int] method1 (num) atau [long] method1 (num) dengan cara itu kompiler akan tahu mana yang akan dipanggil.

Saya tidak tahu tentang bagaimana kompiler bekerja tetapi itu tampaknya tidak terlalu sulit untuk dilakukan, jadi saya bertanya-tanya mengapa hal seperti itu biasanya tidak dilaksanakan.

Apa alasan mengapa hal seperti itu tidak didukung?

Ini menyulitkan pengecekan tipe.

Ketika Anda hanya mengizinkan overloading berdasarkan tipe argumen, dan hanya mengizinkan deduksi tipe variabel dari inisialisasi mereka, semua informasi tipe Anda mengalir dalam satu arah: naik pohon sintaks.

var x = f();

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

Saat Anda mengizinkan informasi jenis untuk bepergian di kedua arah, seperti menyimpulkan tipe variabel dari penggunaannya, Anda memerlukan pemecah kendala (seperti Algoritma W, untuk sistem tipe Hindley-Milner) untuk menentukan jenisnya.

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]

Di sini, kita perlu meninggalkan tipe xsebagai variabel tipe yang tidak terselesaikan ∃T, di mana yang kita tahu adalah bahwa itu dapat diuraikan. Hanya nanti, ketika xdigunakan pada tipe konkret, kita memiliki cukup informasi untuk menyelesaikan kendala dan menentukan itu ∃T = int, yang menyebarkan informasi tipe ke bawah pohon sintaks dari ekspresi panggilan ke x.

Jika kami gagal menentukan jenisnya x, kode ini akan kelebihan beban juga (jadi pemanggil akan menentukan jenisnya) atau kami harus melaporkan kesalahan tentang ambiguitas.

Dari sini, seorang perancang bahasa dapat menyimpulkan:

• Ini menambah kompleksitas implementasi.

• Itu membuat pemeriksaan ketik lebih lambat — dalam kasus patologis, secara eksponensial terjadi.

• Lebih sulit menghasilkan pesan kesalahan yang baik.

• Itu terlalu berbeda dari status quo.

• Saya tidak merasa ingin mengimplementasikannya.

Karena ambigu. Menggunakan C # sebagai contoh:

var foo = method(42);

Kelebihan mana yang harus kita gunakan?

Ok, mungkin itu agak tidak adil. Kompiler tidak dapat mengetahui jenis apa yang akan digunakan jika kami tidak memberitahukannya dalam bahasa hipotetis Anda. Jadi, pengetikan tersirat tidak mungkin dalam bahasa Anda dan ada metode anonim dan Linq bersama dengannya ...

Bagaimana dengan yang ini? (Tanda tangan sedikit didefinisikan ulang untuk menggambarkan titik.)

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

....

long foo = method(42);

Haruskah kita menggunakan intkelebihan, atau shortkelebihan? Kami tidak tahu, kami harus menentukannya dengan [int] method1(num)sintaks Anda . Yang agak menyakitkan untuk diurai dan menulis jujur.

long foo = [int] method(42);

Masalahnya, sintaksisnya mirip dengan metode generik dalam C #.

long foo = method<int>(42);

(C ++ dan Java memiliki fitur serupa.)

Singkatnya, perancang bahasa memilih untuk memecahkan masalah dengan cara yang berbeda untuk menyederhanakan penguraian dan mengaktifkan fitur bahasa yang jauh lebih kuat.

Anda mengatakan Anda tidak tahu banyak tentang kompiler. Saya sangat merekomendasikan belajar tentang tata bahasa dan parser. Setelah Anda memahami apa itu tata bahasa bebas konteks, Anda akan memiliki ide yang lebih baik tentang mengapa ambiguitas adalah hal yang buruk.

Semua fitur bahasa menambah kompleksitas, sehingga mereka harus memberikan manfaat yang cukup untuk membenarkan gotcha yang tak terhindarkan, kasing sudut, dan kebingungan pengguna yang dibuat oleh setiap fitur. Untuk sebagian besar bahasa, yang satu ini tidak memberikan manfaat yang cukup untuk membenarkannya.

Dalam sebagian besar bahasa, Anda akan mengharapkan ekspresi method1(2)memiliki tipe yang pasti dan nilai pengembalian yang lebih atau kurang dapat diprediksi. Tetapi jika Anda mengizinkan overloading pada nilai yang dikembalikan, itu berarti tidak mungkin untuk mengatakan apa arti ekspresi itu secara umum tanpa mempertimbangkan konteks di sekitarnya. Pertimbangkan apa yang terjadi ketika Anda memiliki unsigned long long foo()metode yang implementasinya berakhir return method1(2)? Haruskah yang memanggil long-returning overload atau int-returning overload atau hanya memberikan kesalahan kompilator?

Plus, jika Anda harus membantu kompiler dengan membubuhi keterangan tipe pengembalian, Anda tidak hanya menciptakan lebih banyak sintaks (yang meningkatkan semua biaya yang disebutkan untuk memungkinkan fitur ada sama sekali), tetapi Anda secara efektif melakukan hal yang sama seperti membuat dua metode dengan nama berbeda dalam bahasa "normal". Apakah [long] method1(2)lebih intuitif daripada long_method1(2)?

Di sisi lain, beberapa bahasa fungsional seperti Haskell dengan sistem tipe statis yang sangat kuat memungkinkan perilaku semacam ini, karena inferensi tipe mereka cukup kuat sehingga Anda jarang perlu membuat anotasi jenis pengembalian dalam bahasa tersebut. Tapi itu hanya mungkin karena bahasa-bahasa itu benar-benar menegakkan keamanan jenis, lebih dari bahasa tradisional mana pun, bersama dengan mengharuskan semua fungsi menjadi murni dan transparan referensial. Itu bukan sesuatu yang akan layak di sebagian besar bahasa OOP.

Hal ini tersedia dalam Swift dan bekerja dengan baik di sana. Jelas Anda tidak dapat memiliki tipe ambigu di kedua sisi sehingga harus diketahui di sebelah kiri.

Saya menggunakan ini dalam penyandian sederhana / decode API .

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

Itu berarti panggilan di mana tipe parameter diketahui, seperti initobjek, bekerja sangat sederhana:

    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)
    }

Jika Anda memperhatikan dengan seksama, Anda akan melihat dechOptpanggilan di atas. Saya menemukan cara sulit bahwa membebani nama fungsi yang sama di mana pembeda mengembalikan opsi terlalu rentan terhadap kesalahan karena konteks panggilan dapat memperkenalkan harapan itu adalah opsional.

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