He leído la siguiente afirmación con respecto a la comparación de los tipos de valores de C# en C# en profundidad, segunda edición varias veces.Comparaciones directas de los tipos de valores de C#
página 77,
Cuando un parámetro de tipo no está restringida (no hay restricciones se aplican a él), puede utilizar == y! = Operadores, pero sólo para comparar un valor de ese tipo con nula. No puede comparar dos valores de tipo T entre sí.
...
Cuando un parámetro de tipo está limitado a ser un tipo de valor, == y! = No se puede utilizar con él en absoluto.
Si entiendo (yo no lo creo) de manera correcta, que básicamente me dice que no se puede uso == o! = Para comparar dos tipos de valor. ¿Por qué por qué?
Será mejor si se puede dar un ejemplo simple para este caso. ¿Puede alguien darme una pequeña idea de lo que el párrafo anterior trata de transmitir?
Sospecho que esto es para evitar confusiones con la sobrecarga del operador, ya que un operador == sobrecargado no se usaría cuando el parámetro de tipo genérico es un tipo de valor. Sin embargo, puede usar Object.Equals, que tipos de valores de buen comportamiento implementarán y que tendrán el mismo comportamiento que == (para tipos de buen comportamiento). –
@ Dan Bryant, no es solo para evitar confusiones. No hay garantía de que un tipo de valor admita los operadores == y! =, Y * no podemos usar la implementación System.Object para los tipos de valor, porque la igualdad de referencia de prueba solo funciona en las instancias encuadradas. * Bueno, podríamos en teoría especificar que los operandos estén enmarcados para usar la verificación de igualdad de referencia, pero que la expresión siempre sería falsa, lo cual es claramente inútil. – phoog
@phoog, el 'Objeto.Equals' estático realmente llamará a la implementación Equals del Objeto (incluso si es un tipo de valor encuadrado), por lo que es una forma válida de comparar los tipos de valores pares. También maneja la comparación de null con tipos de valores. 'Object.ReferenceEquals' fuerza explícitamente a que el cheque sea para igualdad de referencia, lo que puede ser útil en casos donde un tipo de referencia prevalece sobre el operador de igualdad, pero tiene un error para el caso de comparación nula (He encontrado esto antes con un tercero party API.) –