Это не ошибка 2015 года, а, возможно, ошибка языка C#. Приведенное ниже обсуждение касается того, почему члены-экземпляры не могут создавать циклы и почему Nullable<T> вызывает эту ошибку, но не должен применяться к статическим членам.

Я бы представил это как ошибку языка, а не ошибку компилятора.

Компиляция этого кода в VS2013 дает следующую ошибку компиляции:

Член структуры «ConsoleApplication1.Program.MyStruct.Empty» типа «System.Nullable» вызывает цикл в макете структуры

Быстрый поиск выдает этот ответ, в котором говорится:

Недопустимо иметь структуру, которая содержит себя в качестве члена.

К сожалению, тип System.Nullable<T>, который используется для обнуляемых экземпляров типов значений, также является типом значений и поэтому должен иметь фиксированный размер. Заманчиво думать о MyStruct? как о ссылочном типе, но на самом деле это не так. Размер MyStruct? основан на размере MyStruct... что, по-видимому, приводит к циклу в компиляторе.

Возьмем, например:

public struct Struct1
{
    public int a;
    public int b;
    public int c;
}

public struct Struct2
{
    public Struct1? s;
}

Используя System.Runtime.InteropServices.Marshal.SizeOf(), вы обнаружите, что Struct2 имеет длину 16 байтов, что указывает на то, что Struct1? является не ссылкой, а структурой, которая на 4 байта (стандартный размер заполнения) длиннее, чем Struct1.

Что здесь не происходит

В ответ на ответ и комментарии Джулиуса Депуллы, вот что фактически происходит, когда вы получаете доступ к полю static Nullable<T>. Из этого кода:

public struct foo
{
    public static int? Empty = null;
}

public void Main()
{
    Console.WriteLine(foo.Empty == null);
}

Вот сгенерированный IL из LINQPad:

IL_0000:  ldsflda     UserQuery+foo.Empty
IL_0005:  call        System.Nullable<System.Int32>.get_HasValue
IL_000A:  ldc.i4.0    
IL_000B:  ceq         
IL_000D:  call        System.Console.WriteLine
IL_0012:  ret         

Первая инструкция получает адрес статического поля foo.Empty и помещает его в стек. Этот адрес гарантированно не равен нулю, поскольку Nullable<Int32> является структурой, а не ссылочным типом.

Затем вызывается Nullable<Int32> скрытая функция-член get_HasValue для получения значения свойства HasValue. Это не может привести к нулевой ссылке, поскольку, как упоминалось ранее, адрес поля типа значения не должен быть нулевым, независимо от значения, содержащегося в адресе.

Остальное просто сравнивает результат с 0 и отправляет результат на консоль.

Ни в коем случае в этом процессе невозможно «вызвать нулевое значение для типа», что бы это ни значило. Типы значений не имеют нулевых адресов, поэтому вызов метода для типов значений не может напрямую привести к ошибке ссылки на нулевой объект. Вот почему мы не называем их ссылочными типами.

Во-первых, при анализе этих проблем важно создать минимальный репродуктор, чтобы мы могли сузить круг проблем. В исходном коде есть три отвлекающих маневра: readonly, static и Nullable<T>. Нет необходимости воспроизводить проблему. Вот минимальная реплика:

struct N<T> {}
struct M { public N<M> E; }
class P { static void Main() { var x = default(M); } }

Это компилируется в текущей версии VS, но при запуске выдает исключение загрузки типа.

• Исключение не вызывается использованием E. Он срабатывает при любой попытке доступа к типу M. (Как и следовало ожидать в случае исключения загрузки типа.)
• Исключение воспроизводит, является ли поле статическим или экземпляром, доступным только для чтения или нет; это не имеет ничего общего с природой поля. (Однако это должно быть поле! Проблема не воспроизводится, если это, скажем, метод.)
• Исключение не имеет ничего общего с «вызовом»; в минимальном воспроизведении ничего не "вызывается".
• Исключение не имеет ничего общего с оператором доступа к членам «.». В минимальной репродукции его нет.
• Исключение не имеет ничего общего с нулевыми значениями; ничто не может быть обнулено в минимальном воспроизведении.

Теперь давайте проведем еще несколько экспериментов. Что, если мы создадим классы N и M? Сообщу вам результаты:

• Поведение воспроизводится только тогда, когда оба являются структурами.

Мы могли бы продолжить обсуждение вопроса о том, воспроизводится ли проблема только тогда, когда M в каком-то смысле «непосредственно» упоминает о себе, или же «косвенный» цикл также воспроизводит ошибку. (Последнее верно.) И, как отмечает Кори в своем ответе, мы также можем спросить: «Должны ли типы быть универсальными?» Нет; есть репродуктор еще более минимальный, чем этот, без дженериков.

Однако я думаю, что у нас достаточно, чтобы завершить обсуждение воспроизводящего устройства и перейти к насущному вопросу: «является ли это ошибкой, и если да, то в чем?»

Тут явно что-то напутано, и у меня сегодня нет времени разбираться, на кого ложиться вина. Вот некоторые мысли:

• Правило против структур, содержащих элементы сами по себе, здесь явно не применяется. (См. раздел 11.3.1 спецификации C# 5, который у меня есть под рукой. Я отмечаю, что этот раздел может выиграть от тщательного переписывания с учетом обобщений; некоторые формулировки здесь немного неточны.) Если E является статическим, тогда этот раздел не применяется; если он не статичен, то оба макета N<M> и M могут быть вычислены независимо.

• Я не знаю другого правила языка C#, запрещающего такое расположение типов.

• Возможно, спецификация CLR запрещает такое расположение типов, и CLR имеет право выдать здесь исключение.

Итак, теперь давайте суммируем возможности:

• В CLR есть ошибка. Топология этого типа должна быть допустимой, и CLR неправильно бросать ее сюда.

• Поведение CLR правильное. Топология этого типа недопустима, и это правильно для CLR. (В этом случае может случиться так, что в CLR есть ошибка спецификации, поскольку этот факт не может быть адекватно объяснен в спецификации. Сегодня у меня нет времени заниматься спецификациями CLR.)

Предположим ради аргумента, что верно второе. Что мы можем теперь сказать о C#? Некоторые возможности:

• Спецификация языка C# запрещает эту программу, но реализация позволяет. В реализации есть ошибка. (Я считаю этот сценарий ложным.)

• Спецификация языка C# не запрещает эту программу, но ее можно заставить сделать это при разумных затратах на реализацию. В этом сценарии неисправна спецификация C#, она должна быть исправлена, а реализация должна быть исправлена ​​для соответствия.

• Спецификация языка C# не запрещает программу, но обнаружение проблемы во время компиляции не может быть осуществлено по разумной цене. Это относится практически к любому сбою во время выполнения; ваша программа дала сбой во время выполнения, потому что компилятор не смог помешать вам написать ошибочную программу. Это просто еще одна программа с ошибками; к сожалению, у вас не было причин знать, что это ошибка.

Подводя итог, наши возможности:

• В CLR есть ошибка
• Спецификация C# содержит ошибку
• В реализации C# есть ошибка
• В программе есть ошибка

Одно из этих четырех должно быть правдой. Я не знаю, что это такое. Если бы меня попросили угадать, я бы выбрал первое; Я не вижу причин, по которым загрузчик типа CLR должен отказываться от этого. Но, возможно, есть веская причина, которую я не знаю; надеюсь, вмешается эксперт по семантике загрузки типов CLR.

ОБНОВИТЬ:

Эта проблема отслеживается здесь:

https://github.com/dotnet/roslyn/issues/10126

Подводя итог выводам команды C# в этом выпуске:

• Программа является законной согласно спецификациям CLI и C#.
• Компилятор C# 6 разрешает эту программу, но некоторые реализации интерфейса командной строки вызывают исключение загрузки типа. Это ошибка в этих реализациях.
• Команда CLR знает об ошибке, и, по-видимому, ее трудно исправить в ошибочных реализациях.
• Команда разработчиков C# рассматривает возможность сделать юридический код выдающим предупреждение, поскольку он будет давать сбой во время выполнения в некоторых, но не во всех версиях CLI.

Этим занимаются команды C# и CLR; следить за ними. Если у вас есть какие-либо вопросы по этой проблеме, пожалуйста, напишите об ошибке отслеживания, а не здесь.

Теперь, когда у нас было продолжительное обсуждение того, что и почему, вот способ обойти проблему, не дожидаясь, пока различные группы .NET отследят проблему и решат, что можно с ней сделать.

Проблема, по-видимому, ограничена типами полей, которые являются типами значений, которые каким-то образом ссылаются на этот тип либо как общие параметры, либо как статические члены. Например:

public struct A { public static B b; }
public struct B { public static A a; }

Ух, я чувствую себя грязным сейчас. Плохой ООП, но он демонстрирует, что проблема существует без какого-либо вызова дженериков.

Таким образом, поскольку они являются типами значений, загрузчик типов определяет, что здесь задействован циклический подход, который следует игнорировать из-за ключевого слова static. Компилятор C# был достаточно умен, чтобы понять это. Должно ли это быть или нет, зависит от спецификаций, которые я не комментирую.

Однако при замене A или B на class проблема исчезает:

public struct A { public static B b; }
public class B { public static A a; }

Таким образом, проблемы можно избежать, используя ссылочный тип для хранения фактического значения и преобразования поля в свойство:

public struct MyStruct
{
    private static class _internal { public static MyStruct? empty = null; }
    public static MyStruct? Empty => _internal.empty;
}

Это намного медленнее, потому что это свойство, а не поле, и вызовы к нему будут вызывать метод get, поэтому я бы не стал использовать его для кода, критичного для производительности, но в качестве обходного пути он, по крайней мере, позволяет вам выполнять работу до тех пор, пока доступно правильное решение.

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