[ragnese]

"Data" is such an overloaded and vague term, anyway. Almost all classes have "data", so what the heck is a "data class"? Is it one that only has data (not behavior)? Nope- these can have arbitrary methods.

So, I'm kind of glad they didn't use it. (But, to clarify, I really don't care what color the bike shed is)

I'm more wondering why they didn't go with "struct" or "value class", especially because the latter is exactly what we've been calling "class whose equals() is defined by content rather than identity" for many years.

[kaba0]

Because while in the end project valhalla will not call them value classes, it is a sort of an overloaded term.

Structs/value types can be mutable, records are not. They are basically tuples with names. And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

[ragnese]

> Structs/value types can be mutable, records are not.

Fair point about record fields not being reassignable (not the same as immutable for others reading this).

> And as far as I know, while records have a sane default equals defined, they are still identity objects in that they are passed by reference.

Well, sure. All non-primitives are passed by reference. That doesn't stop them from being referred to as value types.

But in light of your first point, I agree that choosing a totally new term probably makes sense.

[kaba0]

I stand corrected, shallowly immutable or as you note fields not being reassignable it is.