The dream to inherit from a struct in c#

Question

There I am making a 2D game in C# XNA 4.0, and run across yet again a petty annoyance of mine; the Rectangle. For those using basic collision, this is almos

Answer 1

Value types are fundamentally incompatible with the style of inheritance that is applicable to class types, but it would be helpful to be able to declare a "derived struct" in such a way that the compiler would recognize a bidirectional identity-preserving conversion between the derived type and the original. The derived struct would be required to have exactly one field, called "Base" (though a C# compiler could accept the keyword base as a substitute), whose type was that of the struct being derived. All members of "Base" whose names did not match those of the surrounding type would be regarded as members of the enclosing structure.

The primary things a "derived struct" would offer, but which are presently lacking, would be:

1. The ability to access members of the wrapped struct without having to add an extra layer of syntactic indirection. For example, if one had an instance `MyFancyPoint` of a type defived from `Point`, one could say `MyFancyPoint.X += 5` rather than `MyFancyPoint.Base.X += 5`.
2. The ability to do more than one implicit or explicit type conversion at a time. C# generally generally only allows conversion from `X` to `Y` except when a direct conversion exists, in part because searching through all possible conversion sequences would be difficult, and in part because doing so would often yield ambiguities as to which sequence of conversions should be employed. If all types wrapping a particular struct are assumed to represent a "cloud" with mutal identity-preserving conversions, a conversion between two derived structs `XX:X` and `YY:Y` could be regarded unambiguously as a conversion to `X`, then `Y`, then `YY` (which would be legal iff `X` to `Y` conversion exists).
3. The ability to regard a ByRef to an instance of one type as a ByRef to an instance of the other, and a ByRef to a field of one to be considered a ByRef of the corresponding field in the other.

I'm not sure any changes to the runtime would be required to support any of these features, if one accepts that an item of a boxed derived type may only be unboxed as that same derived type; allowing a boxed version of a struct to be cast directly to an instance of an identity-convertible derived one would be helpful, but might add complexity. I'm not sure if such behavior would be required to make generics work. Unfortunately, I get the feeling that many of the people responsible for making this sort of decision really don't like value types. Because of some design decisions early in the history of .net (especially the lack of "const ref" parameters and a means of exposing properties by ref), making structs work in semantically-correct fashion can be a challenge, and I think some of the implementers would rather use the problems with structs as an excuse not to improve .net's handling of them, than add features that would fix the problems.