Composed Inheritance

[UniqeId6542]

I sometimes want to mix and match independent features, but find that the ownership requirement of using composition makes that option less viable.
For example, suppose I define the following 3 classes:

public class Person {
    public int Energy { get; protected set; }
}

public class Mage : Person {
    public void Fireball() { this.Energy -= 2; }
}

public class Swordsman : Person {
    public void Slash() { this.Energy -= 1; }
}

If I wanted to make a MagicSwordsman using composition, I would run into issues of making the methods public while also accessing the base class's property. (Yes, it CAN be done. But it gets looking more like a hack.)
If, instead, I could inherit from a generic type (support what currently makes the CS0689 error), I could have:

public class Mage<T> : T where T : Person {...}

public class Swordsman<T> : T where T : Person {...}

public class MagicSwordsman : Mage<Swordsman<Person>> { }

(With interfaces, MagicSwordsman could also follow the pattern. That, or allowing a constraint of more than one class.)

Composed Inheritance vs. Inheritance

• This doesn't have the diamond problem of C++. The inheritance is still a line, but just defined by the end class. (or composed by the client)
• This is more flexible than normal inheritance

Composed Inheritance vs. Composition

• This doesn't need proxy methods for clients to access owned classes.
• This makes it easier to use shared resources. (E.g. Energy in the above example)
• This is less flexible than composition. This makes it harder to inject a specific component dynamically at runtime.

Composed Inheritance vs. Extension Methods

• This supports state variables. Each part is a class, so adding fields works just fine.
• This supports overriding methods.
• This doesn't support adding logic to all classes that implement an interface.

(Yes, this is the same as my previous post; but with a different approach to the description. #79887)

Could support for this be added to .NET / C#?