Więc czytam Eric Lippert's 'Constraints are not part of the signature', a teraz rozumiem, że specyfikacja określa, że ograniczenia typu są sprawdzane PO rozdzielczości przeciążenia, ale nadal nie jest jasne, dlaczego tak MUSI być w tym przypadku. Poniżej jest przykład Erica:Dlaczego ograniczenia typu nie są częścią podpisu metody?
nie skompilować, ponieważ rozdzielczość przeciążenie dla: Foo(new Giraffe())
wnioskuje że Foo<Giraffe>
to najlepszy mecz przeciążenie ale potem ograniczenia typu fail i błąd czasu kompilacji jest wyrzucane. W słowach Erica:
Zasada tutaj jest rozdzielczość przeciążania (i wnioskowania typu metody) znaleźć najlepsze możliwe dopasowanie między listą argumentów i listę formalnych parametrów każdej metody. Oznacza to, że patrzą na podpis metody kandydata.
Ograniczenia typu NIE są częścią podpisu, ale dlaczego nie mogą być? Jakie są scenariusze, w których złym pomysłem jest uwzględnienie ograniczeń typu w podpisie? Czy jest to trudne lub niemożliwe do zrealizowania? Nie jestem zwolennikiem tego, że jeśli najlepiej wybrane przeciążenie jest z jakiegokolwiek powodu niemożliwe do wywołania, w milczeniu powrócić do drugiego najlepszego; Nienawidziłbym tego. Po prostu staram się zrozumieć, dlaczego ograniczenia typu nie mogą być wykorzystywane do wpływania na wybór najlepszego przeciążenia.
Wyobrażam sobie, że wewnętrznie w C# kompilator, jedynie rozdzielczości przeciążeniowych (to nie na stałe przepisać metody), co następuje:
static void Foo<T>(T t) where T : Reptile { }
zostaje zwerbowany do:
static void Foo(Reptile t) { }
Dlaczego nie możesz "wciągnąć" wiązań typu do listy formalnych parametrów? W jaki sposób zmienia to podpis w jakikolwiek zły sposób? Mam wrażenie, że tylko wzmacnia podpis. Wtedy Foo<Reptile>
nigdy nie będzie uważane za kandydata na przeciążenie.
Edytuj 2: Nic dziwnego, że moje pytanie było tak mylące. Nie czytałem poprawnie bloga Erica i zacytowałem niewłaściwy przykład. Edytowałem w przykładzie, który uważam za bardziej odpowiedni. Zmieniłem też tytuł na bardziej szczegółowy. To pytanie nie wydaje się tak proste, jak sobie wyobrażałem, być może brakuje mi jakiejś ważnej koncepcji. Jestem mniej pewny, że jest to materiał stackoverflow, może być najlepsze, aby to pytanie/dyskusja zostały przeniesione gdzie indziej.
Fragment o Legwanach, który zacytowałeś na górze twojego pytania, miał na celu zilustrowanie sytuacji, w której typ wnioskowania * nie * bierze pod uwagę ograniczenie, a mianowicie ograniczenie T w C, a zatem ostateczna rozdzielczość przeciążania * * w tym przykładzie metoda * nietypowa *. Czy jesteś * pewien *, który jest istotnym fragmentem artykułu, który zamierzasz zacytować, aby zadać to pytanie? Pozostała część pytania wydaje się nie wynikać z tego logicznie. –
Myślę, że raczej chciałeś zapytać, dlaczego to jest, gdy wnioskowanie o typie * się powiedzie *, ale określa typ, który narusza ograniczenie * w parametrze typu metody *, dlaczego nie można rozwiązać problemu z przeciążeniem, gdy istnieje alternatywa. Stwierdzam, że to pytanie jest bardzo mylące, ale z drugiej strony jest to myląca część specyfikacji. –
Masz rację. Błędnie odczytałem Twojego bloga i użyłem niewłaściwego przykładu. Nic dziwnego, że moje pytanie było tak zagmatwane. Próbowałem wyjaśnić moje pytanie najlepiej jak potrafię; Przeczytam także niektóre z twoich innych blogów, aby sprawdzić, czy mogę poprawić moją wiedzę na ten temat. – Daryl