Если выполняются все следующие условия:
все возможные значения вашего типа MyClass<T>
(включая null
, если это не тип значения!) Соответствуют действительному значению T
неявный оператор никогда не выбрасывает (даже для null
!)
неявное преобразование имеет смысловой смысл и не смущает клиента-программиста
тогда в этом нет ничего плохого. Конечно, вы могли бы сделать любую из этих трех вещей, но это был бы плохой дизайн. В частности, неявный оператор throw может быть очень сложным для отладки, потому что место, где он вызывается, не говорит, что он вызывается.
Например, предположим, что T?
не имеет неявного преобразования в T
(где T
, конечно, тип значения). Если бы существовал такой неявный оператор, он должен был бы выдавать, когда T?
равен нулю, поскольку нет очевидного значения для преобразования null
в такое значение, которое имело бы смысл для любого типа значения T
.
Позвольте мне привести пример, где у меня возникли проблемы при отладке проблемы, когда неявный оператор выдал:
public string Foo()
{
return some_condition ? GetSomething() : null;
}
Здесь GetSomething
вернул что-то типа, который я написал, который имеет неявное пользовательское преобразование в string
. Я сделал абсолютно уверенным , что GetSomething
никогда не сможет вернуть null
, и все же я получил NullReferenceException
! Зачем? Поскольку приведенный выше код не эквивалентен
return some_condition ? (string)GetSomething() : (string)null;
но до
return (string)(some_condition ? GetSomething() : (Something)null);
Теперь вы можете видеть, откуда взялся null
!