[C# Feature Request] Abstract Classes inherit from interfaces passing implementation responsility

[GrantHoffman]

Abstract classes should allow the responsibility of implementations to be passed to child class. Here is an example of how it can be useful

public interface IFoo
{
     int Id { get; set; }
}

public abstract class FooAdapter : IFoo
{
      public Bar ToDTO()
      {
           return Mapper.Map<Bar, IFoo>(this)
      }     
}

public class FooImplementationAdapter : FooAdapter
{
     public int Id {get; set; }
}

This would prove to be extremely useful in the case of a generic, where you do not know the implementation details, but still would like to provide a base class

[HaloFour]

So, in effect this proposal is a request that when an abstract class implements an interface but doesn't provide implementations for non-default members of that interface that the compiler would automatically insert abstract members in its place?

That FooAdapter above would implicitly be:

public abstract class FooAdapter : IFoo
{
      public Bar ToDTO()
      {
           return Mapper.Map<Bar, IFoo>(this)
      }

      // inserted by the compiler
      public abstract int Id { get; set; }
}

[Mafii]

@HaloFour no I think it was the idea that an abstract class doesn't have to implement/provide abstract members for it's interfaces, but every inheriting class would have to provide that implementation. I can't really see the gain over a abstract member tho.

Only thing is that the inheriting class (ConcreteFooAdapter : FooAdapter) doesn't have to override, but rather just provide the implementation.

Is this what you meant @GrantHoffman ?

[wanton7]

How would you do a cast from FooImplementationAdapter to FooAdapter if there are no interface implementation with abstract members?

[Mafii]

@wanton7 the concrete implementation will have it. So it will work at runtime as far as I can understand.

Having a explicit implementation of the interface also hides the method from being used when not being of type of the interface.

[HaloFour]

It does appear that the CLR supports this out of the box. An abstract type may simply omit implementations of the interfaces that it implements. The resultant assembly is verifiable, too.

The C# compiler doesn't quite know what to do when it encounters such a type, though. If you inherit from said abstract class the compiler doesn't recognize that the interface members aren't implemented. So the project would compile fine and fail at runtime with a TypeLoadException as the extending class doesn't provide the implementation of the interface.

To test this I created an assembly using IL which would match the following C#:

public interface IFoo {
    void Do();
}

public abstract class FooBase : IFoo { } // not legal C#, perfectly legal IL

Then I created another project with the following C#:

public class Foo : FooBase { }

That project compiled fine.

Regardless of whether or not C# adds the functionality to omit interface implementations, I think that the compiler should be at least fixed to detect and error on missing interface implementations from parent abstract classes, just in case other compilers may generate such beasts.

[HaloFour]

Also, Java does support this functionality. You simply omit the interface members in the abstract class and any class that extends from that abstract class is required to provide it. Since Java lacks explicit implementation it's not really more than shorthand for providing abstract members for the interface members. However, since C# does have explicit implementation I could see how that might be useful in allowing a class to extend an abstract class while providing explicit/hidden implementations to its interface members.

[Mafii]

@HaloFour

explicit implementation [...] to extend an abstract class while providing explicit/hidden implementations to its interface members

I just thought of that aswell. It might be the most useful part of this proposal.

Also, it wouldn't make one overriding the members instead of simply implementing them.

[louthy]

Then I created another project with the following C#:
public class Foo : FooBase { }

@HaloFour What happens if you implement Do in Foo. Does it then all work OK?

[HaloFour]

@louthy

Yes, as long as the implementation of Do is explicitly marked virtual it seems that the CLR will correctly use it as the override. You can't implement and seal at the same time since the compiler doesn't recognize the fact that you're implementing an interface member. You also obviously can't explicitly implement for the same reason. From IL you can do all of these things.

[GrantHoffman]

@Mafii Sorry for getting back to this so late, You understood correctly only Inheriting classes would have to provide implementation.

[jnm2]

This would follow logically in the footsteps of #52, blurring some of the distinctions between abstract classes and interfaces.

[jnm2]

@GrantHoffman s/responsility/responsibility

[GrantHoffman]

@jnm2 what does your last comment mean?

[jnm2]

Sorry, it means spelling error. (In the title.)