Nitpick: C# struct can be on the heap (when it's "boxed").
The fundamental difference between C# class and struct is how they treat assignment operation. The class has "reference semantics" (assignment creates a new reference to the same object) and struct has "value semantics" (assignment creates a new object).
C# uses terms "reference types" (of which "class" is one) and "value types" (of which "struct" is one) to make the difference clear.
Structs being on the stack (most of the time) is just a consequence of their value semantics, and should be treated mostly as an implementation detail.
I’m aware of the differences between structs and classes, boxing etc. (.net dev since ‘02),
. My point is “class” can some times be a faceless “value” with no identity, and some times have an identity. The “records” feature is a way of addressing this difference, but like everything else it’s tacked on a bit late. A value class, like a value type (struct, enum), should/could be immutable, have structural equality etc.
I’d like my language to be extremely explicit about whether an object has identity or not. It ties into things like ownership, move vs. copy, disposal etc too.
Nitpick: C# struct can be on the heap (when it's "boxed").
The fundamental difference between C# class and struct is how they treat assignment operation. The class has "reference semantics" (assignment creates a new reference to the same object) and struct has "value semantics" (assignment creates a new object).
C# uses terms "reference types" (of which "class" is one) and "value types" (of which "struct" is one) to make the difference clear.
Structs being on the stack (most of the time) is just a consequence of their value semantics, and should be treated mostly as an implementation detail.