Рекурсивные вызовы equalityкомпаратора (как используется в реализации operator==, созданной быстрым действием Visual Studio)

#c#

Вопрос:

Учитывая следующий исходный класс:

         public class Sample
        {
            public string One;
            public string Two;
        }
 

в Visual Studio (16.9.4) вы можете выполнить быстрое действие «Создать равные», а затем выбрать «Реализовать IEquatable» и «Создать операторы». Он сгенерирует следующий код:

             public override bool Equals(object obj)
            {
                return Equals(obj as Sample);
            }

            public bool Equals(Sample other)
            {
                return other != null amp;amp;
                       One == other.One amp;amp;
                       Two == other.Two;
            }

            public static bool operator ==(Sample left, Sample right)
            {
                return EqualityComparer<Sample>.Default.Equals(left, right);
            }

            public static bool operator !=(Sample left, Sample right)
            {
                return !(left == right);
            }
 

Это рекурсивно — operator== вызовет EqualityComparer то, что может вызвать operator== снова, что вызовет EqualityComparer снова:

пример рекурсивных вызовов

В этом случае, когда оба left и right не являются нулевыми EqualityComparer вызовами Sample.Equals , но когда один из них равен нулю, это не так, нарушая бесконечный цикл.

Но есть ли гарантия, что это будет работать именно так — что не будет бесконечного цикла? Я имею в виду, что это имеет смысл, но было бы неплохо, если бы, например, документация также поддерживала это… Я проверил EqualityComparer документы и ничего не смог найти…

Комментарии:

1. Я тоже не могу найти никаких таких документов. Я бы предпочел остаться на безопасной стороне и использовать !ReferenceEquals(other, null) вместо этого.

2. Пожалуйста, сообщите об этом в корпорацию Майкрософт с помощью встроенной функции отчетов о проблемах Visual Studio. Вы можете добавить ссылку на этот вопрос, чтобы у них был контекст.

3. @Sweeper Лично я нахожу !(other is null) более лаконичным

4. Вы продемонстрировали сценарий, который приводит к генерации кода, приводящего к кажущейся бесконечной рекурсии. Visual Studio не должна генерировать код, который делает это, потому что это приведет к несчастным разработчикам. Поэтому, если вы сообщите о проблеме в MS, они могут разобраться в ней, либо согласиться с вами и предложить решение, либо объяснить вам, почему вы ошибаетесь.

5. @pkruk Сравнение двух ненулевых экземпляров довольно распространено, вам не кажется? Только по этой причине об этом следует сообщить г-же