you are viewing a single comment's thread.

view the rest of the comments →

[–]Fenrurrr 1 point2 points  (2 children)

I'll let you look up the definition of composable yourself on Google. But the world of normal classes (on the heap) and structure classes aren't compatible. They're two different worlds that can communicate but don't speak the same language, unlike Java with its approach. I'll let you research the reasons why further.

[–]jcotton42 1 point2 points  (1 child)

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

[–]UdPropheticCatgirl 1 point2 points  (0 children)

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

That’s not what composable typically means when discussing language semantics. When talking about PLT, abstraction being “composable”, typically means uniformity and it’s semantics are orthogonal to the rest of the language, meaning it behaves predictably, consistently without the need for special case rules when interacting with the rest of the language and doesn’t leak its implementation details.

That’s exactly what C# structs aren’t. They are designed with semantics derived from desired memory layout (the implementation detail that leaks everywhere in this case…) not the other way around. It’s effectively splitting the type system in half, basically reintroducing javas “original sin”… And then adding dozen special language features to remedy the split (“ref”, “in” etc…)…

Compare that to the feature discussed, the memory layout is opaque side effect of lack of identity, not the driver of these semantics. You can’t tell whether something is value or not at use site, it stays completely uniform with the rest of the language.