李柏特先生举的例子有几个问题。它是为了说明结构是复制的，以及如果你不小心的话，这可能是一个问题。看看这个例子，我认为这是一个坏的编程习惯的结果，而不是结构或类的问题。

结构应该只有公共成员，不需要任何封装。如果是这样，那么它真的应该是一个类型/类。你真的不需要两个构念来表达同一件事。 如果有一个类包含一个结构，则可以调用该类中的一个方法来更改成员结构。我认为这是一个良好的编程习惯。

正确的实现如下所示。

struct Mutable {
public int x;
}

class Test {
    private Mutable m = new Mutable();
    public int mutate()
    { 
        m.x = m.x + 1;
        return m.x;
    }
  }
  static void Main(string[] args) {
        Test t = new Test();
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
        System.Console.WriteLine(t.mutate());
    }

看起来这是编程习惯的问题，而不是结构本身的问题。结构体应该是可变的，这是它的思想和意图。

更改的结果voila表现如预期:

1 2 3. 按任意键继续…

我不会说可变性是邪恶的，但可变性通常是程序员急于提供最大功能的标志。在现实中，这通常是不需要的，反过来，使界面更小，更容易使用，更难使用错误(=更健壮)。

其中一个例子就是竞态条件中的读/写和写/写冲突。这些在不可变结构中根本不可能发生，因为写操作不是有效的操作。

另外，我认为可变性几乎从来都不是真正需要的，程序员只是认为它在未来可能会出现。例如，改变日期是没有意义的。相反，在旧日期的基础上创建一个新的日期。这是一个廉价的操作，所以性能不是一个考虑因素。

可变结构体并不邪恶。

在高绩效环境下，它们是绝对必要的。例如，当缓存线和垃圾收集成为瓶颈时。

我不认为在这些完全有效的用例中使用不可变结构体是“邪恶的”。

我可以看到c#的语法没有帮助区分值类型或引用类型的成员的访问，所以我完全赞成使用强制不变性的不可变结构，而不是可变结构。

然而，与其简单地给不可变结构贴上“邪恶”的标签，我建议接受这种语言，提倡更有帮助和建设性的经验法则。

例如:"struct是默认复制的值类型。如果你不想复制他们，你需要一份推荐信。 “首先尝试使用只读结构体”。

当某种东西可以变异时，它就获得了一种认同感。

struct Person {
    public string name; // mutable
    public Point position = new Point(0, 0); // mutable

    public Person(string name, Point position) { ... }
}

Person eric = new Person("Eric Lippert", new Point(4, 2));

Because Person is mutable, it's more natural to think about changing Eric's position than cloning Eric, moving the clone, and destroying the original. Both operations would succeed in changing the contents of eric.position, but one is more intuitive than the other. Likewise, it's more intuitive to pass Eric around (as a reference) for methods to modify him. Giving a method a clone of Eric is almost always going to be surprising. Anyone wanting to mutate Person must remember to ask for a reference to Person or they'll be doing the wrong thing.

如果你让类型是不可变的，这个问题就消失了;如果我不能修改eric，无论我收到eric还是eric的克隆对我来说都没有区别。更一般地说，如果类型的所有可观察状态都保存在以下成员中，则按值传递是安全的:

不可变的 引用类型 安全通过价值

如果满足这些条件，那么可变值类型的行为就像引用类型一样，因为浅拷贝仍然允许接收方修改原始数据。

The intuitiveness of an immutable Person depends on what you're trying to do though. If Person just represents a set of data about a person, there's nothing unintuitive about it; Person variables truly represent abstract values, not objects. (In that case, it'd probably be more appropriate to rename it to PersonData.) If Person is actually modeling a person itself, the idea of constantly creating and moving clones is silly even if you've avoided the pitfall of thinking you're modifying the original. In that case it'd probably be more natural to simply make Person a reference type (that is, a class.)

诚然，函数式编程已经告诉我们，使所有东西都不可变是有好处的(没有人可以秘密地保留对eric的引用并改变他)，但由于这在OOP中不是惯用的，因此对于使用您的代码的其他人来说仍然是不直观的。

Value types basically represents immutable concepts. Fx, it makes no sense to have a mathematical value such as an integer, vector etc. and then be able to modify it. That would be like redefining the meaning of a value. Instead of changing a value type, it makes more sense to assign another unique value. Think about the fact that value types are compared by comparing all the values of its properties. The point is that if the properties are the same then it is the same universal representation of that value.

正如Konrad所提到的，更改日期也没有意义，因为值代表的是唯一的时间点，而不是具有任何状态或上下文依赖关系的时间对象的实例。

希望这能让你明白。可以肯定的是，它更多的是关于您试图用值类型捕获的概念，而不是实际的细节。

如果你曾经用C/ c++这样的语言编程，结构体可以作为可变的。只要把球传给裁判，没有什么会出错的。我发现的唯一问题是c#编译器的限制，在某些情况下，我无法强迫这个愚蠢的东西使用对结构的引用，而不是Copy(比如当结构是c#类的一部分时)。

所以，可变结构体不是邪恶的，是c#把它们变成了邪恶的。我一直在c++中使用可变结构体，它们非常方便和直观。相比之下，c#让我完全放弃了作为类成员的结构体，因为它们处理对象的方式。他们的便利让我们付出了代价。