Suggestion: Allow interfaces to constrain what types can implement them

[AderitoSilva]

Consider the following code:

public class BaseClass { }
public interface ISharedFeatures : BaseClass { }

The code above doesn't compile, because an interface can't inherit from a class. But, suppose it could specify that only a certain type can implement it. Now, you would know that every ISharedFeatures object is guaranteed to be a BaseClass or class that derives from BaseClass. This would mean that you could make derived classes that share common functionality (using an interface), but that don't inherit from the same ancestors. Let me illustrate this with a more concrete problem:

// This is the base class for a game object.
public abstract class GameObject { }

// An object that can be destroyed by damage.
public abstract class DestructibleObject : GameObject
{ 
    public abstract void Destroy();
}

// An object that the player can pick (a consumable, a power up, etc.).
public abstract class PickableObject : GameObject
{
    public abstract void Pick();
}

// An object that can be picked, but also destroyed.
public class DestructiblePickableObject : GameObject
{

}

The code above works, but there is a problem. Not all pickables are destructible, and not all destructibles are pickable. We cannot make our DestructiblePickableObject inherit from both DestructibleObject and PickableObject, so, now if there is code that only accepts a destructible object, we cannot pass it our DestructiblePickableObject object, for example. We can solve this by using an interface, like IDestructible, and implement it in both DestructibleObject and in DestructiblePickableObject classes. Now, code that requires a destructible object can just require an IDestructible, like this:

public void Damage(IDestructible obj) { }

However, now we have a different problem: the IDestructible is not guaranteed to be a GameObject. And that is what my suggestion of allowing an interface to inherit from a class tries to solve. If IDestructible inherits from GameObject, only GameObject and its derived classes could implement it, and it would be guaranteed to be a GameObject to any of its consumers.

Right now, we can solve this in a hacky way like this:

public IDestructible
{ 
    GameObject Instance { get; }
    void Destroy();
}

public abstract class DestructibleObject : GameObject, IDestructible
{ 
    GameObject IDestructible.Instance => this;
    public abstract void Destroy();
}

So, now, you could consume it like this:

public void Damage(IDestructible obj)
{
    obj.Instance.DoSomething();
    obj.Destroy();
}

But the hacky solution above is not pretty and not practical. It would be much easier if IDestructible was declared like this:

// Only allow IDestructible to be implemented by GameObject
public IDestructible : GameObject
{ 
    void Destroy();
}

Maybe this is somewhat of a niche use case, but I already had to deal with that problem a few times.

What are your thoughts on this suggestion? Do you think it would be even possible to implement reliably in the language? And what could go wrong?

[HaraGabi]

How would you handle state?
Classes can have state, interfaces can not. If we derive an interface from a class, that interface would have to have state.

Why can't GameObject be an interface itself? That way the rest of the interfaces could inherit from IGameObject.

[AderitoSilva]

How would you handle state? Classes can have state, interfaces can not. If we derive an interface from a class, that interface would have to have state.

As I said, it would be more of a type constraint on interfaces than an actual inheritance. So, the interface would not have state. It would just be a constraint that says: this interface can only be implemented by this type of class, and therefore it is guaranteed to be castable to that class.

Why can't GameObject be an interface itself? That way the rest of the interfaces could inherit from IGameObject.

It could implement IGameObject. And, because GameObject might be really complex, you might want to inherit from it instead of implementing IGameObject from scratch. But that forces you to replicate your member signatures in both the interface and the implementation, even if you are really sure that only care about the implementation.

[HaraGabi]

As I said, it would be more of a type constraint on interfaces than an actual inheritance. So, the interface would not have state. It would just be a constraint that says: this interface can only be implemented by this type of class, and therefore it is guaranteed to be castable to that class.

Then I think it shouldn't be called inheritance.

Could something like this help?

interface IDestructible  {}
class GameObject  { }
record struct DestructibleGameObject<T>(T Value) where T : GameObject , IDestructible   {}

Then your methods can just ask for a DestructibleGameObject

[HaraGabi]

Sorry, one more question.

If IDestructible is guaranteed to be a GameObject why isn't it an abstract class that inherits from GameObject?

[AderitoSilva]

Sorry, one more question.

If IDestructible is guaranteed to be a GameObject why isn't it an abstract class that inherits from GameObject?

Like I mention in the example in my original post, the problem arises when you have something like DestructibeObject, PickableObject and DestructiblePickableObject. An object can inherit from PickableObject or from DestructibleObject, but not from both. Using interfaces, is a way to make DestructiblePickableObject be both IDestructible and IPickable.

[FaustVX]

You can try to use generic method
sharplab.io

void Damage<T>(T destuctibleObject)
    where T : GameObject, IDestructible
{ }

[AderitoSilva]

Using generic constraints is a perfectly valid way of doing it. And, for a simple method like this, it would be fine. But suppose you have a class or struct that requires an IDestructible as constructor parameter, or that exposes it as a property. The class/struct definition would need to be generic as well.

[FaustVX]

You can also write an analyzer.
It's not perfect, but it will be way faster than having a language change

class C
{
  public C([Require<IDestructible>]GameObject obj)
  {
    var destructible = (IDestructible)obj;
    ...
  }
}

var c = new C(destructibleObject); // error if not IDestructible

[HaloFour]

public interface IGameObject {
    IGameObject Instance { get; }
}

public interface IDestructible : IGameObject { 
    void Destroy();
}

public abstract class DestructibleObject : IGameObject, IDestructible { 
    IGameObject IDestructible.Instance => this;
    public abstract void Destroy();
}

[DavidArno]

What are your thoughts on this suggestion? Do you think it would be even possible to implement reliably in the language? And what could go wrong?

You later clarify that what you desire is for SomeObject to be able to inherit from both PickableObject and DestructibleObject. Java was very deliberately designed as a single-inheritance model and C# copied that. Multiple Inheritance suffers from fundamental problems like the diamond problem, which is why languages like C# and Java steered well clear of it.

Whilst multiple inheritance could be implemented - C++ supports it, for example - there is a vanishingly small chance that the .NET runtime and C# teams would ever add support for it to the runtime and C#, respectively.

Perhaps instead, you could turn the problem on its head and avoid inheritance altogether by using interfaces:

public interface IDestructible
{ 
    public void Destroy();
}

public interface IGameObject
{
    public void DoSomething();
}

public interface IDestructibleObject : IGameObject, IDestructible;

public void Damage(IDestructibleObject obj)
{
    obj.DoSomething();
    obj.Destroy();
} 

[AderitoSilva]

I think I choose the wrong approach to specifying this suggestion. Inheritance is probably a very wrong word to describe what I was trying to suggest, and thus the confusion.

My suggestion, probably, has nothing to do with inheritance, but rather with type constraints.

• Instead of: interface X inherits from class Y;
• It should be: interface X can only be implemented by class Y (and its derivates);

[CyrusNajmabadi]

It should be: interface X can only be implemented by class Y (and its derivates);

Restrictions on the language are satisfiable today with analyzers. That's why we introduced them:-)

[HaraGabi]

#399 might be an interesting alternative to what you need. Specifically the intersection types.

[danmitreanu]

The usual pattern I use for restricting interface inheritors is

public abstract class GameObject {}

// Use this for APIs like Scene.DoAllThings(IGameThing[] things);
public interface IGameThing { void DoThing(); }

// Use this for inheritance
public interface IGameThing<T> : IGameThing where T : GameObject, IGameThing<T> {}

public abstract class GameThing : GameObject, IGameThing<GameThing>
{
    public abstract void DoThing();
}