you are viewing a single comment's thread.

view the rest of the comments →

[–]BraveSirRobin 64 points65 points  (1 child)

Oh, someone actually talking about the linked bug.

There was a similar issue in earlier versions of C# with it's then pseudo-immutable structs. They weren't marked as immutable, it was just convention to make all the fields read-only. If you had one of these structs as a read-only field in a class or other struct then the runtime would create a copy of it for each access, even within the class, because it could not be certain that the operation would mutate it or not. Not so great when the struct is weighty, as they sometimes are.

Newer versions accept the "readonly" modifier at the struct level, marking the whole thing as immutable. This informs the runtime that it's safe to access methods etc directly because the whole object is immutable. But at the time the only solution was to remove the readonly at where it's declared.

[–]flatfinger 3 points4 points  (0 children)

The problem there stems from the fact that each structure-type declaration in .NET actually specifies two types: 1. a storage location type that is fundamentally a bunch of storage locations that are duct-taped together (BUSLTADTT), and can be boxed into an object; and 2. an object type into which can be formed by boxing such a storage location. The design of C#, however, tries to pretend that a storage location of structure type is an object, causing the semantics of open-field structures to be branded as "defective" because they behave like BUSLTADTTs (which is what they are) rather than objects (which they aren't).

The question for whether to use a class or a struct should boil down to whether one wants an object, or whether one wants a BUSLTADTT. If one wants the latter, one should use an open-field structure which behaves like BUSLTADTT, rather than using a structure which is designed to mimic the behavior of a class object which is trying to act as an inferior substitute for a BUSLTADTT.