当当前项目中的等效结构不可访问时，为什么可以访问由单独项目提供的未初始化结构？答案

【问题标题】：Why is an uninitialized struct provided by a separate project accessible when the equivalent struct in the current project isn't?当当前项目中的等效结构不可访问时，为什么可以访问由单独项目提供的未初始化结构？
【发布时间】：2018-05-13 17:57:19
【问题描述】：

如果结构没有字段，则无需初始化即可访问它。
如果当前项目中的结构有字段，则会收到错误“Use of unassigned local variable”。
如果不同项目中的结构具有字段，则无需初始化即可访问它。

这种行为似乎奇怪地不一致。使用不同项目中的字段访问未初始化的结构不会导致错误的原因是什么，但如果它是在同一个项目中声明的呢？语言规范是否解决了这个问题？

这里有一些示例代码演示了各种场景。

项目 1

static void Main()
{
    A a;
    a.ToString();    // No problem

    B<int> b;
    b.ToString();    // Use of unassigned local variable 'b'

    C<int> c;
    c.ToString();    // No problem
}

public struct A 
{
}

public struct B<T> 
{
    T[] a;
}

项目 2

public struct C<T>
{
    T[] a;
}

（使用VS2017 15.4.5）

【问题讨论】：

我不知道规范中有没有提到它，但this 是一些有趣的读物。基本上我们倾向于将私有字段视为实现而不是接口，但 C# 中明确赋值的规则要求将结构的私有字段视为其接口的一部分。
在某种程度上肯定相关。但是参考程序集和我的示例之间的区别在于Project 2 不是参考程序集。这是一个适当的程序集，从技术上讲，所有这些私有字段都以某种方式在程序集中（即反射会返回它们）
是的，这是不同的。这个github issue answers。这似乎是为了向后兼容旧版本的编译器。
@mikez 这是一个很棒的链接。使用 <Features>strict</Features> 标志实际上解决了我的根本问题。如果您将其作为答案发布（可能直接包含该标志），请立即接受。

标签： c# struct initialization

【解决方案1】：

这是编译器作者有意做出的决定，以保持与不符合规范的旧编译器的向后兼容性。您可以在编译时使用/features:strict 标志获得正确的行为。

见github issue #1722:

这是一个非常痛苦但有意为之的决定。这复制了先前编译器的（错误）行为。我强烈建议您添加编译器标志 /features:strict 以获得正确的、规范要求的（但不是向后兼容的）行为。

【讨论】：

很好，也许可以添加一些关于<Features>strict</Features> 的内容，这样你就会得到你想要的编译器错误。但是 +1，谢谢！
相关：stackoverflow.com/questions/37299549/…