Интересные моменты в C# (boxing unboxing)

Еще по поводу распаковки Nullable. Ключевое слово as работает с такими типами, значение null получается при любой неудачной распаковке:

object box = 42L;
int? unbox = box as int?; // null

Это довольно удобно при работе с ADO.NET, поскольку значение DBNull автоматически превращается в обычный null во время распаковки.

Типичный вопрос на собеседовании об упаковке и распаковке выглядит следующим образом — «Что будет при запуске данного кода, и если он не будет работать то как его исправить?».

Тестовый код:
object box = (int)42; long unbox = (long)box;

Вы так и не ответили на свой вопрос: что будет при запуске кода? Если будет ошибка компиляции с очевидным сообщением, то всё остальное запоминать не нужно, и задвать такие вопросы на собеседовани — трата времени всех участвующих.

То есть информация, конечно, интересная и полезная, но не то чтобы очень важная.

Подобное поведение при распаковке не является частью стандарта языка. Т.е., да, оно работает, но это незадокументированное расширение, и полагаться на него не стоит. Аналогично с приведением массивов, когда int[] можно успешно скастить к uint[] через object.

А синтаксис T? для Nullable<T> появился в той же версии языка, что и сам Nullable — C# 2.0. И, кстати говоря, вот эти два варианта дают один и тот же результат:

object x = (int)123;
object x = (int?)123;

Т.е. пакуется не Nullable, а его значение. Если спросить у полученного object его тип через GetType(), то вы получите int, а не Nullable. Если значения нет — после запаковки получается null. Поэтому такой вещи, как «распаковка из Nullable», просто не существует.

Вообще, про такие вещи лучше все-таки читать в спецификации, а не пытаться реверс-инжинирить их на кусках кода.

> Представьте себе удивление человека, когда вы ему напишете другой правильный вариант.

Давайте назовём это «работающий вариант», а не «правильный»? А то ведь начнут писать так.

Для ещё худшей читаемости кода надо было назвать enum, скажем, StringType.