Dlaczego niedozwolone jest przeciążanie typami zwrotów? (przynajmniej w zwykle używanych językach)

Nie znam wszystkich języków programowania, ale jasne jest, że zwykle nie jest możliwe przeładowanie metody, biorąc pod uwagę jej typ zwracany (zakładając, że jej argumenty mają tę samą liczbę i ten sam typ).

Mam na myśli coś takiego:

 int method1 (int num)
 {

 }
 long method1 (int num)
 {

 }

To nie jest tak, że to duży problem z programowaniem, ale przy niektórych okazjach byłbym z tego zadowolony.

Oczywiście nie byłoby sposobu, aby te języki mogły to obsługiwać bez sposobu na odróżnienie wywoływanej metody, ale składnia tego może być tak prosta, jak coś takiego jak [int] method1 (num) lub [long] method1 (num) w ten sposób kompilator będzie wiedział, który będzie nazywany.

Nie wiem, jak działają kompilatory, ale nie wydaje się to takie trudne, więc zastanawiam się, dlaczego coś takiego zwykle nie jest wdrażane.

Jakie są powody, dla których coś takiego nie jest obsługiwane?

Utrudnia to sprawdzanie typu.

Gdy zezwalasz na przeciążanie tylko na podstawie typów argumentów i zezwalasz tylko na dedukowanie typów zmiennych z ich inicjatorów, wszystkie informacje o typie płyną w jednym kierunku: w górę drzewa składniowego.

var x = f();

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

Jeśli zezwalasz na przesyłanie informacji o typie w obu kierunkach, na przykład poprzez dedukcję typu zmiennej na podstawie jej użycia, potrzebujesz solvera ograniczającego (takiego jak Algorytm W dla systemów typu Hindley – Milner), aby określić typ.

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]

Tutaj musieliśmy pozostawić xtyp zmiennej typu nierozwiązanego ∃T, a wszystko, co wiemy o tym, to to, że jest on analizowalny. Dopiero później, gdy xzostanie użyty w konkretnym typie, mamy wystarczającą ilość informacji, aby rozwiązać ograniczenie i określić to ∃T = int, co propaguje informacje o typie w dół drzewa składni od wyrażenia wywołania do x.

Jeśli nie uda nam się określić typu x, albo ten kod również zostanie przeciążony (tak więc wywołujący określi typ), albo będziemy musieli zgłosić błąd dotyczący niejednoznaczności.

Na tej podstawie projektant języka może stwierdzić:

• Dodaje złożoności implementacji.

• Powoduje spowolnienie sprawdzania typu - w przypadkach patologicznych wykładniczo.

• Trudniej jest wytwarzać dobre komunikaty o błędach.

• To zbyt różni się od status quo.

• Nie mam ochoty go wdrażać.

Ponieważ to niejednoznaczne. Używając C # jako przykładu:

var foo = method(42);

Jakiego przeciążenia powinniśmy użyć?

Ok, może to było trochę niesprawiedliwe. Kompilator nie może ustalić, jakiego typu użyć, jeśli nie powiemy tego w twoim hipotetycznym języku. Tak więc niejawne pisanie jest niemożliwe w twoim języku i są tam anonimowe metody i Linq ...

Co powiesz na ten? (Nieznacznie przedefiniowano podpisy, aby zilustrować ten punkt).

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

....

long foo = method(42);

Czy powinniśmy użyć intprzeciążenia, czy shortprzeciążenia? Po prostu nie wiemy, będziemy musieli to określić przy pomocy twojej [int] method1(num)składni. Co jest trochę kłopotliwe, aby parsować i pisać szczerze.

long foo = [int] method(42);

Chodzi o to, że jest zaskakująco podobna składnia do ogólnej metody w C #.

long foo = method<int>(42);

(C ++ i Java mają podobne funkcje).

Krótko mówiąc, projektanci języków postanowili rozwiązać problem w inny sposób, aby uprościć analizę i włączyć znacznie bardziej zaawansowane funkcje językowe.

Mówisz, że niewiele wiesz o kompilatorach. Gorąco polecam naukę gramatyki i parserów. Kiedy zrozumiesz, czym jest gramatyka bezkontekstowa, będziesz miał o wiele lepsze pojęcie o tym, dlaczego dwuznaczność jest złą rzeczą.

Wszystkie funkcje językowe zwiększają złożoność, więc muszą zapewniać wystarczającą korzyść, aby uzasadnić nieuniknione problemy, przypadki narożne i zamieszanie użytkownika, które powoduje każda funkcja. W przypadku większości języków ten po prostu nie zapewnia wystarczających korzyści, aby to uzasadnić.

W większości języków można oczekiwać, że wyrażenie method1(2)będzie miało określony typ i mniej lub bardziej przewidywalną wartość zwracaną. Ale jeśli zezwolisz na przeciążanie zwracanych wartości, oznacza to, że nie można powiedzieć, co to wyrażenie ogólnie oznacza, bez uwzględnienia otaczającego go kontekstu. Zastanów się, co się dzieje, gdy masz unsigned long long foo()metodę, której implementacja kończy się return method1(2)? Czy powinno to wywołać longprzeciążenie intpowrotu lub przeciążenie powrotu, czy po prostu dać błąd kompilatora?

Ponadto, jeśli musisz pomóc kompilatorowi, dodając adnotację typu zwracanego, nie tylko wymyślasz więcej składni (co podnosi wszystkie wyżej wymienione koszty związane z dopuszczeniem funkcji w ogóle), ale skutecznie robisz to samo, co tworzenie dwie metody o różnych nazwach w „normalnym” języku. Czy jest [long] method1(2)bardziej intuicyjny niż long_method1(2)?

Z drugiej strony niektóre języki funkcjonalne, takie jak Haskell z bardzo silnymi statycznymi systemami typów, pozwalają na tego rodzaju zachowanie, ponieważ ich wnioskowanie o typach jest na tyle silne, że rzadko trzeba opisywać typ zwracany w tych językach. Ale jest to możliwe tylko dlatego, że języki te naprawdę egzekwują bezpieczeństwo tekstu, bardziej niż jakikolwiek tradycyjny język, a także wymagają, aby wszystkie funkcje były czyste i referencyjnie przejrzyste. To nie jest coś, co kiedykolwiek byłoby wykonalne w większości języków OOP.

To jest dostępny w Swift i działa dobrze tam. Oczywiście nie możesz mieć dwuznacznego typu po obu stronach, więc musisz wiedzieć po lewej.

Użyłem tego w prostym API do kodowania / dekodowania .

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

Oznacza to, że wywołania, w których znane są typy parametrów, takie jak initobiekt, działają bardzo prosto:

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

Jeśli zwracasz szczególną uwagę, zauważysz dechOptpołączenie powyżej. Dowiedziałem się na własnej skórze, że przeciążenie tej samej nazwy funkcji, w której wyróżnik zwraca wartość opcjonalną, jest zbyt podatne na błędy, ponieważ kontekst wywołania może wprowadzić oczekiwanie, że jest ona opcjonalna.

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