Неявное преобразование группы методов (часть 2)

Ответ 1

Существует два типа операторов: пользовательские операторы и предопределенные операторы. Раздел 7.3.5 "Пользовательские операторы-кандидаты" не применяются к предопределенным операторам. Например, операторы на decimal выглядят как пользовательские операторы в декомпиляторе, но С# рассматривает их как предопределенные операторы и применяет к ним числовое продвижение (числовое продвижение не применяется к пользовательским операторам).

Раздел 7.10.8 "Операторы равенства делегатов" определяют operator ==(Delegate, Delegate) как предопределенный оператор, поэтому я думаю, что все правила о пользовательских операторах не применяются к этому оператору (хотя это не 100% ясно в спецификации, как в этом случае предопределенный оператор не применяется всякий раз, когда пользовательский оператор будет).

Every delegate type implicitly provides the following predefined comparison operators: 
bool operator ==(System.Delegate x, System.Delegate y);
bool operator !=(System.Delegate x, System.Delegate y); 

Но сам System.Delegate не считается типом делегата, поэтому единственным кандидатом на разрешение перегрузки является operator ==(object, object).

Ответ 2

Компилятор работает очень разные и необычные с делегатами. Существует много скрытой обработки. Обратите внимание, что правило "общий базовый тип" в этом руководстве применяется к "пользовательским операторам". Делегаты являются внутренними и системными. Например, вы можете написать Action a = M; вместо Action a = new Action(M);. И вы можете добавить a += M; после этого. Проверьте, что происходит в CIL, это интересно в первый раз.

Кроме того, для сравнения делегатов это опасно и нетривиально. Каждый делегат на самом деле является делегатом многоадресной рассылки. Вы можете добавить несколько указателей на функции в один и тот же делегат. Делегаты [L(); M(); N();] равны делегировать [M();]? Указатель функции содержит экземпляр класса (например, метод). Имеет ли [a.M();] значение [b.M();]? Все, что зависит от случая, и реализация сравнения требует перехода через список вызовов.

Наследование делегатов из общего базового типа. Делегат является неявным, и эта проблема может возникнуть в других сценариях, например. generic constraint: вы не можете указать Delegate как ограничение на общий параметр T. Здесь компилятор явно отклоняет это. То же самое и о создании собственных классов, унаследованных от Delegate.

Это ответ на оба вопроса - "Делегат" не является чисто FCL, он тесно связан с компилятором. Если вы действительно хотите, чтобы Microsoft делегировал поведение сравнения - просто вызывайте явно Equals(a, b)

Ответ 3

предупреждение CS0253: возможное непреднамеренное сравнение ссылок; чтобы получить сравнение значений, введите правую сторону, чтобы ввести "System.Action"

Это предупреждение, которое вы получаете за этот код С#. Не игнорируйте это предупреждение, команда С# хорошо знала, что код, сгенерированный для этого сравнения, был неожиданным. Им не нужно было создавать этот код, они могли бы легко сделать то, что вы ожидали. Как этот код делает:

Module Module1
    Sub M()
    End Sub

    Sub Main()
        Dim a = New Action(AddressOf M)
        Dim b = DirectCast(New Action(AddressOf M), [Delegate])
        Console.WriteLine(a = b)      ''got True here
        Console.Read()
    End Sub
End Module

Что генерирует почти тот же MSIL, за исключением того, что вместо ceq вы получаете:

 IL_001d:  call bool [mscorlib]System.Delegate::op_Equality(class [mscorlib]System.Delegate,
                                                            class [mscorlib]System.Delegate)

Что вы надеялись на код С#. Это был код VB.NET, если вы его не узнали. Иначе причина, по которой Microsoft поддерживает два основных управляемых языка, хотя они имеют очень похожие возможности. Но с очень разными вариантами использования. Всякий раз, когда было создано несколько способов генерации кода, команда С# последовательно выбирала для своей производительности команду VB.NET для удобства.

И производительность, безусловно, является ключевым здесь, сравнение объектов-делегатов дорого. Правила изложены в Ecma-335, раздел II.14.6.1. Но вы можете рассуждать сами за себя, есть много проверок. Он должен проверить совместимость целевого объекта делегата. И для каждого аргумента он должен проверить, является ли значение конвертируемым. Расходы, которые команда С# не хочет скрывать.

И нет, вы получаете предупреждение, чтобы напомнить вам, что они сделали неинтуитивный выбор..

Ответ 4

Ключевым моментом здесь является то, что оператор == и метод Equals для типа Delegate - это две разные вещи. Для ссылочных типов == выглядит, если обе ссылки указывают на один и тот же объект, если оператор == не переопределен (см. == Оператор (С# )).

Поскольку вы создаете два разных объекта Action, хотя они внутренне вызывают один и тот же метод, они представляют собой разные объекты в разных местах в памяти и не имеют значения или string, поэтому == в этом случае a ReferenceEquals и не вызывает метод Delegate.Equals, который был переопределен, чтобы увидеть, имеют ли оба объекта одно и то же. Для ссылочных типов, отличных от string, это поведение по умолчанию == или Equals.